Compiler crash with abstract modules...

[Mark Scandariato]

But even

	foo(N, <<V:N/unit:8>>) -> V.

is illegal.

I assumed it had to do with the fact that order of paremeter evaluation isn't 
guaranteed. (Unless I'm mistaken.)

Mark.

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
>