[mercury-users] Erlang backend

[Peter Wang]

2009/2/4 Richard O'Keefe <ok at cs.otago.ac.nz>:
>
> On 4 Feb 2009, at 5:17 pm, Peter Ross wrote:
>
>> On Wed, Feb 4, 2009 at 10:25 AM, Richard O'Keefe <ok at cs.otago.ac.nz>
>> wrote:
>>>
>>> I am informed that
>>> "In R12B, constant terms (for instance, {a,b,c,[e,f,g]} or {a,<<1,2,3>>})
>>> are stored in a constant pool and not reconstructed every time.
>>> That includes binaries. (The same mechanism is used for both
>>> BEAM code and native code.)"
>
> [so that if constant terms were the bottleneck,
>  they are not any more.]
>
>> Do you know if that include constant terms which contain closures?
>>
>> The RTTI includes closures which are the unification and comparison
>> predicates for the given type.
>
> Closures are not constants.
> To a first approximation, if you could write '<<something>> in Scheme,
> the Erlang version of <<something>> is a constant term.

Function references rather than closures.

> I suppose a fun that _happened_ to have no free variables could be
> thought of as a constant.  Can you provide me with some modest
> examples of such terms?

See below for the terms generated for list(T).

> I'm not sure what the interaction of such a feature with hot loading
> should be like.
>
> I've now had four different stories:
> (1) it was because Erlang copied constant terms (it doesn't now).
> (2) it was because Erlang copied constant terms containing binaries
>    (it doesn't now).
> (3) it was because Erlang didn't treat closures as constants.
> (4) it was because Erlang wasn't good at strings.
> I'm getting confused.

(1+2) were true for the non-HiPE compiler, (2) was true for the HiPE compiler.

I'm not sure what (4) is regarding.  We did switch to binaries to represent
strings [except for the special case of RTTI tables, due to (2)].
Partly this was because Mercury string routines tend to expect O(1) indexing,
seeing as that's what you get with the C backends.

If you have a recent Mercury compiler, you can make it generate Erlang code
using "mmc -s erlang -C file.m".

Peter


RTTI for list(T).

l__type_ctor_info_list_1() ->
  V_8_8 = [] ,
  V_9_9 = [{erlang_du_functor , "[|]" , 2 , 1 , 1 , '[|]' ,
[{du_arg_info , {no } , type_var_1()} | [{du_arg_info , {no } ,
pti_l__pti_list_1__pseudo_1()} | [] ] ] , {no } } | V_8_8 ] ,
  {1 , 13 , (fun(V_3_3 , V_2_2 , V_1_1 ) ->
    '__Unify____list_1_0'(V_3_3 , V_2_2 , V_1_1 )
  end), (fun(V_7_7 , V_5_5 , V_4_4 ) ->
    '__Compare____list_1_0'(V_7_7 , V_5_5 , V_4_4 )
  end), "l" , "list" , {etcr_du } , [{erlang_du_functor , "[]" , 0 , 0
, 0 , '[]' , [] , {no } } | V_9_9 ] } .

pti_l__pti_list_1__pseudo_1() ->
  {pseudo , (fun() ->
    {fun l__type_ctor_info_list_1/0 , type_var_1()}
  end)} .

type_var_1() ->
  {pseudo , (fun() ->
    1
  end)} .
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au
--------------------------------------------------------------------------