We welcome initiatives like this and are positive to revisit this. A proposal for something closer to *with* in Elixir looks interesting.
See more initial comments below: On Tue, Oct 13, 2020 at 3:42 PM Fred Hebert <[email protected]> wrote: > > On Fri, Dec 7, 2018 at 6:28 AM Kenneth Lundin <[email protected]> wrote: > >> EEP-0049 Value-based Error handling mechanisms >> >> - We don't like a language construct which is hard coded to support >> ok,{ok,Result}, {error,Reason}. >> - the use of underscore _ <~ to mean a match with ok is not a hit, it >> will make programs harder to read >> - We are against the introduction of *unwrapexprs* that cannot be >> used everywhere where expressions are allowed. >> - The *unwrapexpr* changes the scoping rules and can not be used in >> nested expressions and not outside begin ... end. >> >> It is perfectly possible to use throw and try catch to replace or >> simplify deeply-nested case ... end expressions in the same way as the >> proposed language extension does. >> ... >> Summary >> >> - We say no to the proposed language extensions. We don't think they >> are general enough and we also see some problems with them. >> - The same effect can be achieved safely with the current language >> using throw, try...catch. >> - Encouraging ok, {ok,Result}, {error,Reason} as results from >> functions can be done in other ways, for example through library >> functions. >> These values should not be special to the *language*. >> - We also want to thank the author for a very well thought through >> and well documented proposal which has triggered us to think about >> possible >> solutions in this area. We really appreciate the effort. >> >> /Kenneth, Erlang/OTP Ericsson >> > I'd like to come back and revisit this. > > I won't re-expand on my disdain for try...catch based control-flow for > common cases, but I was wondering what would the opinion of the OTP team be > if I were to re-work the proposal towards a less *opinionated* approach > to this control flow, something possibly more in line with Elixir's with. > > Currently the simplest way to transform this proposal is probably to allow > the pattern on the left-hand-side of <~ to be any pattern, and only escape > the begin...end construct as a short-circuit return: > > begin > {ok, X} = exp(), % hard crash if it doesn't match > {ok, X} <~ exp(), % if it fails, begin...end returns the value of the > non-matching term > ... > end > The above feels like the right direction where {ok,Result} and {error, Reason} has no hard coded interpretation in the language. > > > This gets rid of the _ <~ rhs() magic syntax, drops prescriptiveness of ok > | {ok, T} | {error, R} returns, but maintains high-level control flow > that doesn't risk transforming non-local returns into values (which forces > rewriting unrelated code to work nicely with high-level conditional flows > and clashes with value-based error handling) and establishing a sort of > conditional pipeline. It does lose some of the safety mentioned in the > original proposal, but we can't maintain that safety without normalizing > acceptable good or error values, which the OTP team has mentioned not > wanting to do at the language level. > > Of course the logical expansion of it is going for: > > case > begin > {ok, X} = exp(), % hard crash if it doesn't match > {ok, Y} <~ exp(), % if it fails, begin...end returns the value of the > non-matching term > ... > end > of > {ok, Good} -> ...; > {error, Reason} -> ...; > end > > which brings in whether a proposal rework that goes for something closer > to Elixir's with <https://www.openmymind.net/Elixirs-With-Statement/> > would be interesting. > > Let me know if there's interest and I can rework things. I keep feeling > the pain of complex validation flows time and time again there, > particularly whenever there is one single good path and many bad paths > possible for each validation step. > > Yes, there is interest and I think it would be good to exchange ideas even before there is a complete reworked EEP. /Kenneth, Erlang/OTP Ericsson
_______________________________________________ eeps mailing list [email protected] http://erlang.org/mailman/listinfo/eeps
