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

[Ulf Wiger]

…or simply add the -nostick flag to the command line.

BR,
Ulf W

On 24 Dec 2011, at 10:31, Gianfranco Alongi wrote:

> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions