Compiler crash with abstract modules...

[Richard Carlsson]

Mark Scandariato wrote:
> But even
> 
>     foo(N, <<V:N/unit:8>>) -> V.
> 
> is illegal.

You're right - moving the this-argument first wouldn't work either.
But the parameterized-module version *ought* to work (regardless of
how it is done under the hood), since the scope of the variable is
supposed to be the whole module. So it should be fixed, somehow.

	/Richard

> Richard Carlsson wrote:
> 
>> Mark Scandariato wrote:
>>
>>> Interesting crash when compiling the following snippet:
>>>
>>> %%%----------------------
>>> -module(foo, [N]).
>>> -compile(export_all).
>>>
>>> bug(<<V:N/unit:8>>) -> V.
>>> %%%----------------------
>>>
>>> This is equivalent to:
>>> %%%----------------------
>>> -module(foo).
>>> -compile(export_all).
>>>
>>> bug(<<V:N/unit:8>>, {foo, N}) -> V.
>>> %%%----------------------
>>>
>>> Which would normally just complain that "variable 'N' is unbound".
>>
>>
>>
>> Yes, this is a problem with the current implementation, which
>> expands the parameterized code just as you show; this means that
>> the variable N becomes bound too late to be used as an argument
>> to the binary-pattern (but in the case of the parameterized code,
>> we have already assured the compiler that N is bound, so it
>> happily passes it on to the backend, which crashes). For various
>> reasons (mainly efficiency), though, the THIS-variable needs to
>> be the last passed argument. The best solution for now is to
>> rewrite the code as
>>
>> nobug(B) ->
>>     case B of
>>     <<V:N/unit:8>> -> V
>>     end.
>>
>> (until we can get the compiler to do this by itself). Probably
>> we should meanwhile complain about N being unbound.
>>
>>     /Richard
>>
>