On 2/4/12 10:26 AM, Graydon Hoare wrote:
1. I'm ok with binding on operators, yeah. We've lacked a good way to
easily denote op+ and such for a while, and _+_ fits nicely in our
syntax. Might get difficult to infer the overload though. Tread lightly.
Yes, when you go beyond curried arguments to calls—for example with
receivers—the inference is somewhat limited. It must come from the
expected type, basically. If that's insufficient then you must use fn@
or some other form with explicit type annotations.
Anyway, I think I would prefer one of two paths:
- function calls and methods only (methods being enforced in `typeck`);
- an expanded set of operations containing:
- fields
- function calls
- unary operators like `*_` (hmm, those look odd)
- a series of binary operators (`_ + _ - _`)
- constructors (`(_, _)`, `[_, _]`)
In other words, either allow very little, or be quite general. Seems
like anything in between is confusing.
2. This one is, I think, not OK. It's effectively changing a bunch of
expressions from call-by-value to non-memoizing call-by-need due to a
_ in the neighbourhood. That's too hazardous. IOW I think it needs to
remain:
f(a.b, _) => { let x = a.b; {|y| f(x,y) } }
The counterargument you put forth is "consolidated code path", but ...
I don't think that's sufficient justification. For constants it makes
no difference, but for mutable values and expressions with side
effects it makes a big, scary difference.
I agree it's a change. FWIW, I didn't intend to argue that we should
make this change to achieve a consolidated code path. I think we ought
to decide what the language should do first and let the code work itself
out, of course. I didn't express this well.
Basically the question is whether `_` should be a notation for currying
(as `bind` is today) or a shorthand for closures (as I was proposing).
If we decide it should be currying notation, then I agree the semantics
should stay as they are and the code will just have to have two paths. I
don't really think either way is more hazardous—both are surprising
depending on what you expect `_` to be (Scala, for example, supports `_`
as a shorthand for closures, so `c() + _` does not evaluate `c()`).
I do think there is a case for `_` as closure notation: it's one less
concept. However, I am ok with either way, depending on what people
want. I think if `_` is a currying notation, though, I personally would
prefer to restrict its use to calls rather than allow a wide range of
expressions.
Anyway, let's discuss more, gotta' run...
Niko
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
