On 12/04/2018 11:50 PM, Martin Bjorklund wrote:
Hi,
Michael Truog <[email protected]> wrote:
I know this is a bit after most comments have occurred, but it seems
ok since a decision hasn't been made yet. I like the change to the
begin/end, even though it attaches some magic interpretation of an ok
2-tuple and an error 2-tuple.
I don't like it, for that particular reason.
Trying to make the begin/end change
more complex to handle other return values for Success/Error
conditions (perhaps by adding type specifications to the syntax)
doesn't seem like a good direction
How about something like:
begin
{ok, A} =~ do_something(),
{true, B} =~ do_something_else(A),
ok =~ at_last(B)
end
where =~ means that if the RHS value doesn't match the LHS expression,
the RHS value is returned from the begin ... end expression.
So if do_something_else() above returns false, the begin ... end would
return false.
Yes, that approach is more generic and seems like a better fit into
Erlang. The operator choice may be better as ~= instead of =~ because
the main existing asymmetric operator (focusing on the comparison
operators) in Erlang is /= which matches the phrase "doesn't equal",
with ~= matching "approximately equal". Either way, it is a good way of
avoiding the magic and the absence of the <- makes sense because nothing
is really being unwrapped like a list element is in a list comprehension.
But even with this, I'm not sure the benefits are worth the added
complexity of the language.
The alternative is the approach with functions that have a list of
anonymous functions. The begin/end syntax addition helps to avoid the
additional GC usage (less data required) and should be better for type
specification, so the addition seems like it can be justified, from my
point-of-view.
Best Regards,
Michael
/martin
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
