<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 27, 2018 at 9:44 AM Raimo Niskanen <<a href="mailto:raimo%2Beeps@erlang.org">raimo+eeps@erlang.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Nov 26, 2018 at 04:36:04PM -0500, Fred Hebert wrote:<br>
> Hi Raimo,<br>
> <br>
> any idea if this is due for some OTP committee discussion any time soon?<br>
<br>
I'll remind them...<br>
/ Raimo<br></blockquote><div><br></div><div>The OTP Technical Committee had a meeting where we discussed this EEP a while ago and unfortunately the notes from this has been somewhat delayed. But they will be published as soon as possible. <br></div><div>Maybe this thread can take a pause until they are published.<br><br></div><div>/Kenneth <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
> <br>
> On Wed, Oct 3, 2018 at 3:10 AM Raimo Niskanen <<a href="mailto:raimo%2Beeps@erlang.org" target="_blank">raimo+eeps@erlang.org</a>> wrote:<br>
> <br>
> > On Tue, Oct 02, 2018 at 10:27:02PM -0400, Fred Hebert wrote:<br>
> > > On 10/02, Raimo Niskanen wrote:<br>
> > > >I somehow feel a need to be able to distinguish between ok and {ok,_}.<br>
> > > ><br>
> > > >In your example for Reducing Nesting, Mnesia, the<br>
> > > ><br>
> > > > _ <~ disk_log:sync(...)<br>
> > > ><br>
> > > >is not exactly equivalent to<br>
> > > ><br>
> > > > case disk_log:sync(...) of<br>
> > > > ok -> this;<br>
> > > > {error,Reason} -> that<br>
> > > > end<br>
> > > ><br>
> > > >since if disk_log:sync/1 would return {ok,_} that would be allowed after<br>
> > > >the rewrite to use <~ but case clause before.<br>
> > > ><br>
> > ><br>
> > > That is correct. In the case of `_ <~ Exp` the more equivalent match<br>
> > > expression would be:<br>
> > ><br>
> > > case disk_log:sync(...) of<br>
> > > ok -> this;<br>
> > > {ok, _} -> this;<br>
> > > {error,Reason} -> that<br>
> > > end<br>
> > ><br>
> > > >I think being able to narrow possibilities in the code is a good thing,<br>
> > but<br>
> > > >I have not found a good way to squeeze it into this language extension.<br>
> > > >But I would like to be able to somehow specify to allow ok but not<br>
> > {ok,_}<br>
> > > >as a success value...<br>
> > ><br>
> > > Essentially, a flat `ok` is made similar to `{ok, <null>}` by the<br>
> > > pattern: it is really trying to say "unpack the good value", whatever it<br>
> > > is.<br>
> > ><br>
> > > You can allow `{ok, _}` but not `ok` by matching on `_Ignored <~ Exp`<br>
> > > since that binds a variable and 'ok' can't make that possible, but there<br>
> > > is indeed no way to say "I need this to be `ok` with no actual value<br>
> > > bound and also make sure nothing is returned aside from ok". This one<br>
> > > specific case would require you to use a case expression as you<br>
> > > currently would today.<br>
> > ><br>
> > > To make a distinction between these, I think would involve one of the<br>
> > > following:<br>
> > ><br>
> > > - ask for an explicit pattern (`{ok, _} <~ Exp` vs. `_ <~ Exp`, which<br>
> > > means you can create invalid syntactic cases by using `{error, _} <~<br>
> > > Exp`)<br>
> > > - allow the `<-` operator for exact matches (contains the caveats<br>
> > > explained in earlier posts)<br>
> > > - introduce some prefix operator<br>
> > > - introduce a new kind of pattern to mean "No value returned", which is<br>
> > > basically a terrible idea for a functional language IMO.<br>
> > ><br>
> > > I don't think any of these are nice enough either, at least compared to<br>
> > > the convenience of being able to handle `ok` as a positive return value<br>
> > > in general. Might as well use a case expression for these.<br>
> ><br>
> > Agreed. Handling 'ok' as a positive return value is essential.<br>
> ><br>
> > ><br>
> > > The problem goes away entirely if `ok` is not possible to use with the<br>
> > > construct (you have to extract a value), but my guess is that this would<br>
> > > instead encourage people in the community to use `{ok, undefined}` as<br>
> > > return values to fit with nicer workflows.<br>
> ><br>
> > Agreed.<br>
> ><br>
> > ><br>
> > > A quick search yields 17 functions in all of OTP that currently use this<br>
> > > possible return value in a signature:<br>
> > ><br>
> > > $ ack -r '[^{]ok.*\|.*{ok,' | grep '\.erl' | wc -l<br>
> > > 17<br>
> > ><br>
> > > 2 of them are in test suites, at least 5 of them are using signatures<br>
> > > with over 3 variants of `ok | {ok, _} | {ok, _, _} | {ok, _, _, _}`<br>
> > > which wouldn't work anyway, and one of them is a false positive on the<br>
> > > regex.<br>
> > ><br>
> > > Of the 11 left, the most notable one is possibly ssl:close/2 (and ~3-4<br>
> > > variants) where the function can be used both to close the socket and to<br>
> > > downgrade it to a non-ssl connection. I would argue that the proper<br>
> > > thing would have been to have a 'downgrade' function, but this isn't<br>
> > > what's at stake here.<br>
> ><br>
> > Right.<br>
> ><br>
> > ><br>
> > > In any case, the pattern is likely rare in terms of possible producing<br>
> > > sites, but I couldn't say how it goes as far as call-sites are<br>
> > > concerned.<br>
> ><br>
> > The use I have in mind for matching 'ok' explicitly is simply that when you<br>
> > write your code you know that the return value should be 'ok', and you want<br>
> > to guard yourself from future mistakes where you e.g change the called<br>
> > function to a not as equivalent as you thought.<br>
> ><br>
> > Also for the code reader it is nice to know that there is no value<br>
> > discarded here, and for the final value that you do not have to look up<br>
> > the called function to know that the function you just wrote will only<br>
> > return 'ok'.<br>
> ><br>
> > So I am just for basic narrowing of possibilities...<br>
> ><br>
> > I guess an empty pattern is not possible?<br>
> ><br>
> > begin<br>
> > Whom <~ id({ok,"world"}),<br>
> > <~ io:format("Hello, ~p!\n", [Whom])<br>
> > end<br>
> ><br>
> > ><br>
> > > ><br>
> > > >An interesting EEP. A bit over-magical as Adam Lindberg thought - the<br>
> > > >relation to {ok,_} and {error,_} feels rather hidden in the <~ operator.<br>
> > > >But I do not have a better suggestion. :-/<br>
> > > ><br>
> > ><br>
> > > Alright. Is this basically the EEP being turned down, or more of a<br>
> > > general remark, though?<br>
> ><br>
> > Nono, that, and all the above, are just my personal opinions. Not the OTP<br>
> > opinion. And that remark was a general one along Adam Lindberg's line<br>
> > that I also like the explicitness in Erlang, and this EEP hides the {ok,_}<br>
> > and {error,_} patterns, which sacrifices explicitness for convenience.<br>
> ><br>
> > I think the convenience of the programming pattern that becomes possible<br>
> > is really useful, though.<br>
> ><br>
> > ><br>
> > > I'm curious what the next steps are. If the overall feeling is "nice but<br>
> > > not nice enough", I'd rather see the EEP rejected than left to linger<br>
> > > for many years, as seems to be the case with multiple EEPs in the past,<br>
> > > so at least I know where to stand.<br>
> ><br>
> > I accidentally jumped out of line when answering here...<br>
> ><br>
> > A few internal meetings are coming up before there can be any OTP opinions.<br>
> ><br>
> > --<br>
> ><br>
> > / Raimo Niskanen<br>
> > _______________________________________________<br>
> > eeps mailing list<br>
> > <a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
> > <a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
> ><br>
<br>
-- <br>
<br>
/ Raimo Niskanen, Erlang/OTP, Ericsson AB<br>
_______________________________________________<br>
eeps mailing list<br>
<a href="mailto:eeps@erlang.org" target="_blank">eeps@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/eeps" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/eeps</a><br>
</blockquote></div></div>