On 10/03/2018 01:24 PM, Fred Hebert wrote:
I guess an empty pattern is not possible?
begin
Whom <~ id({ok,"world"}),
<~ io:format("Hello, ~p!\n", [Whom])
end
It would be possible. There's a unary '+' and '-' prefix operator, and I
figure it should be possible to declare '<~' both as infix and prefix.
begin
A + B,
+ 5,
A <~ B,
<~ B,
end
It does look a bit odd, but I do not think there is any case where it
would be syntactically or grammatically ambiguous to use.
I think we'd be trading one kind of magic feeling (`_` can be used for
both `{ok, _}` and `ok`) for another one (a unary unbind operator), but
there would certainly be a clearer semantic distinction between `ok` and
`{ok, _}`.
I just hadn't considered keeping the same operator both as infix and
unary, but I'm certainly open to the idea.
What would be left to decide is whether introducing the operator would
replace the currently proposed '_ <~ Exp' matching on 'ok' semantics or
supplement it. I think it would make sense to replace it for that case
wholesale.
What troubles me about this `_ <~ Exp` is that it changes the meaning of
`_` in this context. `_ = Expr` matches everything, I would therefore
expect `_ <~ Exp` to work for every valid expression, that is `ok | {ok,
_}`.
But then some confusion can also arise if you're going to use `_Var`
(where _Var is not defined), which will not behave the way it does in
every other context since it won't work for `ok` (while `_` would in my
expectations).
The unary does not help much, it can indicate that `ok` is expected, but
doesn't make `_` or `_Var` any more obvious.
I think you may well have an unresolvable conflict there as far as
consistency is concerned. You might as well require the developer to
write an explicit an `ok | {ok, _}` on the left side, at least there
won't be any surprises. And if you do this, then `_` can be used to
accept both `ok` and `{ok, _}`, however infrequent.
This simplifies greatly the reading of <~ since it now succeeds when `ok
| {ok, _}`, fails gracefully when `error | error_tuple()` and crashes
when any other value. On top of that the left-hand side may result in a
badmatch if variables were already defined.
And if you're writing it explicitly there's little against accepting `ok
| ok_tuple()` either.
Cheers,
--
Loïc Hoguin
https://ninenines.eu
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
