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