Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

They're not reserved keywords. Existing/package defined min/max functions would take precedence. They have the same semantics as `append`


sort by: page size:

see, that was missing from the tutorial, or did I miss it? :ok and :nope - are those valid keywords or functions?

I believe he was referring to use of .append by the author. You defined it the way he recommends, which has the desired behavior.

I know it doesn't matter but it strangely bothers me that the example code defines a function's keyword arguments as kawargs.

Some languages let you spell out the arguments upon calling a function.

clamp(x:3, min:1, max:5)

Oh look! No mental strain required to think about what the function does nor what the order should be to minimize mistakes; it’s clear as day!

I wish more languages adopted the option to do this.


Thanks for pointing it out. Still, it seems highly unlikely someone would decide to use such a function declaration yet want to use the proposed syntax to pass both positional and keyword arguments.

Moreover, you could also allow for something like passing a structure of parameters.

clamp({min:2, max:5, x:3})

^parameters can be rearranged as you see fit

There! Now the programmer can decide what’s the way they want to call the function that makes the most sense to them.


I didn't know the last one. Nevertheless I find the mix of functions with no arguments, function values and optionnal parenthesis quite confusing syntax wise.

I find the word “clamp” extremely satisfying for this concept, especially with optional named parameters in order to leave off one bound e.g. `x.clamp(low=10)` but it still works fine with both required and anonymous, it’s just a bit less convenient.

Thank you for sharing. I wish this were the default behavior of positional and keyword arguments rather than requiring a `/, *` in every function definition.

the function keyword is unnecessary - removing it makes the function creation more cross-compatible with different shells.

This sums up my opinion on this pretty well.

On 1 I'll just say it'd be nice if append (and other varargs functions) could take multiple of individually listed and slice-expanded args at the same time. As in: `append(a[:2], 3, a[2:]...)`. I already expect append to be O(n), and this would be some very nice sugar.


It gets really annoying when you have short single-arg functions. Imagine what swap(_:_) or Collection.suffix(_) would look like with mandatory first arguments.

It would make me sad to type getSqrt(), getMin(), getMax(), getStrLen(), getSizeOf(), get…

Putting a verb in the function name is not a bad idea, but if you find yourself identifying the verb as “get”, then it’s a useless three extra letters.


Ah that one is my favorite. The second parameter is optional, but if you don't pass it in it's a noop. Don't really get where that came from.

It would be far more useful if it supported function arguments. I wonder how much of the other features they'd have to give up to support those within 512 bytes.

Regarding:

    "- Comment strings appearing before argument lists in
    functions. I would like to see the entire protocol, 
    name and args, before reading the docstring which may 
    refer to the args."
I think writing one doc string for a multivariate function is better than having to write one for many. Check out clojure core's min function:

    (defn ^number min
      "Returns the least of the nums."
      ([x] x)
      ([x y] (cljs.core/min x y))
      ([x y & more]
       (reduce min (cljs.core/min x y) more)))

So there are occasions for this related to efficiency. Where would you prefer the docstring?

I'm sorry, but I really see no point in this article.

Do you realize that if the optional arguments were not included in Function#length, you'd just be saying "They are not reflected in the function’s length property. C'mon, man" instead ?

Also, I don't understand Whoop-dee-freakin’-doo.


You don't need syntax for that. Regular function application has the highest precedence and functions always have exactly one argument.

Unfortunately, named arguments lead to arbitrary-order arguments which then make partial application quite awkward.

Think: f(fst:x, snd:y), what is the type of f(snd:4)?

I think this can be implemented, but then f(3, fst:5) is either an error or counter-intuitive.

next

Legal | privacy