[erlang-questions] How about a new warning? Was: Re: trouble with erlang or erlang is a ghetto

Tim Watson watson.timothy@REDACTED
Fri Jul 29 11:30:10 CEST 2011


On 29 July 2011 00:45, Richard O'Keefe <ok@REDACTED> wrote:
> One of the things criticised in the blog entry that we've been responding to was
> that
>        {ok,Foo} = bar(...),
>        {ok,Foo} = ugh(...)
> is too easy to write (when you really meant, say, Foo0, Foo1).
>
> This is a well defined part of the language, and it would not be a good idea to
> ban it.  But how about an optional style warning (and we really need
>        -warn(on | off, [warning...])
> directives) whenever a bound variable appears in a pattern on the left of "="?

We would need to be able to set that warning with a very localised
scope though. What you are intending in such a match might be
*exactly* what the code says - call bar/1 to get a Foo and then call
ugh/2 and match (assert) that the resulting tuple contains exactly the
same Foo. Things like a session id, (ets) table id and so on are
probably examples of this. I won't comment on whether this is good API
design or not.

A -warn(on | off, [Warning]) sounds lovely, but would only work at
module level (or as some option passed in to the compiler) so how
would I do (or override) this for an individual line of code or for a
single function? What about function level attributes? That might get
the scope at which the switch is applied tight enough to be useful:

-pragma(no_warnings, [bound_variable_in_match]).
fwibble_ardvarks() ->
    {ok,Foo} = bar(...),
    {ok,Foo} = ugh(...),
    %% etc....
    Foo.

Harder to implement though, as a bigger change to the compiler I'm
guessing. It would however, open up lots of other possibilities -
imagine how useful function annotations would be for parse_transform
writers, or even at runtime if they were preserved in the generated
beam!

-transactional(required | start_new, [{distributed, false}]).
do_something(Data) ->
    Object = convert(Data),
    mnesia:write(Object).



More information about the erlang-questions mailing list