[eeps] EEP ???: Value-Based Error Handling Mechanisms
Loïc Hoguin
essen@REDACTED
Wed Oct 3 15:33:20 CEST 2018
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
More information about the eeps
mailing list