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

[Gianfranco Alongi]

Have not tried this yet (in the midst of christmas setup) - but try
with code:unstick_dir ?

http://www.erlang.org/doc/man/code.html#unstick_dir-1

/G

On Sat, Dec 24, 2011 at 3:27 AM, Eric Merritt <ericbmerritt@REDACTED> wrote:
> 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
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions