Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Get rid of those boolean function parameters (2015)

mortoray.com

Post reply on HN
Print view View original

31–40 of 119 posts

Re: Get rid of those boolean function parameters (2015)

#31

Post by tsimionescu »

10x-dev wrote: post #29
tsimionescu wrote: post #23

Earlier quoted context omitted.

That would require every bit of software that presents this program not only to understand my programming langauge, but also to have enough context on the rest of the program to actually recognize the function and know what each parameter represents. Not to mention, code is itself a presentation layer. Why would you put some presentation concerns in one layer (e.g. identifier names, indentation&styling), but others i…

> every bit of software that presents this program not only to understand my programming language You can either change your program to fit existing tools, or you can build smarter tools. I prefer the latter. > code itself is a presentation layer Not for the tool it isn't edit: I think we can all agree that ideally we fix this in the language itself by adding optional named parameters

No matter how smart the tool is, unless it can see the definition of the function, it can't guess the parameter name. Code is often shared on mail, chat programs etc, requring me to send compilable code snippets to get nice presentation out of a blob of text would be significant overkill...

Re: Get rid of those boolean function parameters (2015)

#33

Post by Camillo »

henrikeh wrote: post #13
cormacrelf wrote: post #11

From the article: > I’d like a language that can contextually resolve enums, so I can just type something like calc_formula( ia, ib, is_gain ). Swift does this and it should be considered for any new language design. Enum.variant can be shortened to .variant, including for variants with data in them, .variant(arg). Perfect solution, because the dot is an autocomplete trigger.

Fwiw, Ada does this too.

Does this feature have a general name? Swift users seem to call it "dot syntax", which is not a good name. I want to google "C++ should have " and find a proposal from 2013 that never moved forward, but "C++ should have dot syntax" is just silly.

Re: Get rid of those boolean function parameters (2015)

#34

Post by cphoover »

flohofwoe wrote: post #4

As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…

In JS we can use JSON/object literal syntax and object destructuring to serve a similar purpose:

    myFunc({
        aBoolFlag : true,
        anotherBoolFlag : false,
        aString : "Hello World"
    });

    const myFunc = ({ aBoolFlag, anotherBoolFlag, aString }) => { /* do something with them... */ };

Re: Get rid of those boolean function parameters (2015)

#35

Post by nirvdrum »

debacle wrote: post #32

If someone submitted a PR where all of their boolean parameters were actually enums I would reject it, open a PR of my own from the same branch, and reject that one too. These clever micro-optimizations are a pathology of bored, well-meaning developers.

Could you please elaborate? To me, it looks like the article posits using boolean flags instead of enums is a code legibility issue, not a performance matter. There may still be good reason to reject a large PR such as the one you described. But, I don't get where the micro-optimization appears.

Re: Get rid of those boolean function parameters (2015)

#36

Post by jameshart »

Inform7 - an interactive fiction language - is often instructive in suggesting different approaches to syntax from those used in mainstream programming, and indeed in this case it has a couple of interesting constructions to avoid naked Booleans.

Most directly relevant to this, it has the concept of ‘options’ as arguments to ‘phrases’ (which are basically functions). This would let you write something like:

    to decide what number is  the calculated formula for (a: a number) and (b: a number), with gain or without gain
And within the function you could use ‘with gain’ and ‘without gain’ as if they were booleans:

   If with gain, decide on a+b;
And at the calling site you would call the function like so:

    Let c be the calculated formula for 3 and 4, with gain
(http://inform7.com/book/WI_11_14.html)

Obviously in Inform7 you are more likely to be using this in a much more naturalistic way, effectively adding ‘adverbs’ to the ‘verbs’ your phrases are defining:

    To recount the story so far, cursorily or in great detail…
Another similar Inform language feature is its mechanism for Boolean properties.

You can declare a Boolean property on a ‘kind’ or a ‘thing’ just by saying that it ‘can’ be true:

    A chair can be comfy.
    The table can be scratched.
You can also use ‘either/or’ forms to make these booleans richer and more expressive:

   A chair can be comfy or hard.
(You can also go on and add more values, of course - at this point it’s really an enumeration)

These sorts of properties on kinds become ‘adjectives’, and you can use them in both declarations:

   The overstuffed armchair is a comfy chair in the living room.
And in expressions:

   If the target is a comfy chair…
The idea that Boolean parameters are really adverbs and Boolean properties are really adjectives I think says something quite profound, and there’s definitely room for other languages to do better at acknowledging the first-class role these kinds of constructs could have with the right syntax.

Re: Get rid of those boolean function parameters (2015)

#37

Post by Certhas »

flohofwoe wrote: post #4

As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…

In Julia you have positional and keyword arguments, separated by a semicolon.

  function f(; a, b)
    a+b
  end
Default values are optional. This can only be called with named arguments like f(; a=5, b=7). Unfortunately the separation isn't required to be explicit when calling the function, so calling f(a=5, b=7) also works. Generally calling functions is extremely permissive (e.g. a function with two positional and two keyword arguments function g(a, b=5; c, d=8) can be called with keywords and positions interleaved g(1, c = 7, 5)), leading to potential confusion at the call site. Our coding guidelines enforce separation of positional and keyword at call sites, and with that additional restriction I have found Julias behaviour in this regard very pleasant. E.g.:

  calc_something(a, b; bool_flag=true)
is the best style for this type of thing that I have seen.

Re: Get rid of those boolean function parameters (2015)

#38

Post by sbuttgereit »

amw-zero wrote: post #21
flohofwoe wrote: post #4

As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…

Many newer languages support named function arguments: Swift, Kotlin, etc.

Some rather old fashioned languages do as well... for example PostgreSQL's PL/pgSQL supports named function arguments, too.

Re: Get rid of those boolean function parameters (2015)

#39

Post by bjourne »

Named parameters misses the point. Functions should do one thing and only one thing. This is why we have cos, sin, and tan and not a universal function for trigonometry: trig(mode='cos', ...). Such functions often become cumbersome to use since they are essentially multiple functions baked into one.

Re: Get rid of those boolean function parameters (2015)

#40

Post by kevin_thibedeau »

flohofwoe wrote: post #4

As pointed out in some of the article's comments, a much better solution would be if all languages allowed putting the name in front of function parameters (and while at it, also not enforce a specific parameter order and skip default-value parameters). A workaround in C99 (and more limited in C++20) is to use a single struct which bundles all the function parameters, and then use designated initialization, this also…

For C* langs you can just insert a block comment with the arg name:

  my_func(/*a_bool_flag*/ true, yadda);
Post reply on HN