[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