[erlang-questions] The Core Erlang AST via cerl.erl and Sequence returns from functions

[Eric Merritt]

Richard,

 Just a quick follow up. How do you actually debug modules in the
standard libraries? The debugger refuses to step into sticky dirs, of
which kernel and stardard lib are.

Thanks,
Eric

On Wed, Dec 21, 2011 at 5:09 PM, Eric B Merritt <ericbmerritt@REDACTED> wrote:
> Richard,
>
>  Thanks, Its good to know that its not me misunderstanding things. I
> will see if I can dig into the compiler here in the next couple of days
> and submit a patch to the patches list.
>
> Eric
>
> On Wed, 2011-12-21 at 21:45 +0100, Richard Carlsson wrote:
>> On 2011-12-21 17:36, Eric Merritt wrote:
>> > Guys,
>> >
>> > I am currently targeting the Erlang VM for a custom language via core
>> > erlang as defined in cerl.erl on R15B. I have run into an interesting
>> > issue. In a Let form (cerl:c_let) if I have a sequence of c_vars on
>> > the Variable arguement and c_apply (on a function that returns a
>> > c_values) in the Argument argument then the erlang compiler exits with
>> > an 'error'. However, if I have a c_values directly as the Argument
>> > argument the compiler will compile the form. Either I am understanding
>> > something incorrectly or this is a bug in the cerl compiler. I am
>> > hoping one of the folks that is knowledgeable on the subject can help
>> > out. In short the following works:
>> >
>> >      cerl:c_let([cerl:c_var(x0), cerl:c_var(x1)],
>> > cerl:c_values([cerl:c_int(0), cerl:c_int(1)]), cerl:c_atom(foo))
>> >
>> > while this does not:
>> >
>> >      <define a function that returns cerl:c_values([cerl:c_int(0),
>> > cerl:c_int(1)])>
>> >
>> >      cerl:c_let([cerl:c_var(x0), cerl:c_var(x1)],
>> > cerl:c_apply(cerl:c_fname(my_fun, 0), []), cerl:c_atom(foo)).
>>
>> Intuitively (and without consulting the source code or my old papers on
>> Core Erlang), I'd say that the latter should work. However, the OTP
>> compiler doesn't try to be complete with respect to all possible Core
>> Erlang programs - it only bothers to implement what's needed to handle
>> code that's first been translated from (full) Erlang. So if you start
>> generating arbitrary but legal Core Erlang, you may run into corner
>> cases (in this case, it seems that multiple return values aren't handled
>> as they ought to be). See if you can find the problem in the compiler -
>> as Calvin's dad used to say, "it builds character". :-)
>>
>>      /Richard
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>