On 10/03, Raimo Niskanen wrote:
The use I have in mind for matching 'ok' explicitly is simply that when you
write your code you know that the return value should be 'ok', and you want
to guard yourself from future mistakes where you e.g change the called
function to a not as equivalent as you thought.
Also for the code reader it is nice to know that there is no value
discarded here, and for the final value that you do not have to look up
the called function to know that the function you just wrote will only
return 'ok'.
Yes, that's a fair requirement.
So I am just for basic narrowing of possibilities...
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.
Nono, that, and all the above, are just my personal opinions. Not the
OTP
opinion. And that remark was a general one along Adam Lindberg's line
that I also like the explicitness in Erlang, and this EEP hides the {ok,_}
and {error,_} patterns, which sacrifices explicitness for convenience.
I think the convenience of the programming pattern that becomes possible
is really useful, though.
I'm curious what the next steps are. If the overall feeling is "nice but
not nice enough", I'd rather see the EEP rejected than left to linger
for many years, as seems to be the case with multiple EEPs in the past,
so at least I know where to stand.
I accidentally jumped out of line when answering here...
A few internal meetings are coming up before there can be any OTP opinions.
Understood !
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
