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

[Tim Watson]

On 1 August 2011 01:05, Richard O'Keefe <ok@REDACTED> wrote:
>> A -warn(on | off, [Warning]) sounds lovely, but would only work at
>> module level (or as some option passed in to the compiler)
>
> Where did that restriction come from?
> Not from anything *I* wrote.
> I was imitating Prolog style warnings, which take effect from the
> point where they are asserted to the point where they are next set.
> For example,
>        :- style_check(+charset).
>        p(fübär).
>        :- style_check(-charset).
>        p(façade).
> gets a non-portable characters warning for the first clause of p/1
> but not for the second clause.
>

Um, that's lovely but we're talking about Erlang and it doesn't
support that syntax.

>> so how
>> would I do (or override) this for an individual line of code or for a
>> single function?
>
> Switch the warning on (or off) just before the function,
> then switch it off (or on) again just after.
>

Now you're going to have to exercise your patience with me here Mr
O'Keefe, as I've lost you. How do I turn warnings on/off for
individual functions? Was your proposal to introduce the `-warn(....)`
syntax as an attribute that can be applied to a function and if so, is
adding annotations to functions a new feature? I'm not aware this
works today and that's why I chimed in.

> As for single lines of code, crash_if_different/2 means there is no
> use case for such an override.
>

Yes I can see that now.

>> 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]).
>
> This is exactly what I proposed, just spelled differently.
> I don't think the spelling of the style check directives matters much,
> and have no objection to using -pragma here.
>

Agreed - I like `pragma` but likewise I'm not really fussed. My point
was that AFAIK you can't put annotations on functions today and this
would be a new feature - with the annotation info preserved at runtime
in the generated beam if possible.