Editing Yhc/Erlang/Proof of concept (section)

===Haskell objects===
This section describes Erlang data structures used to represent objects visible to Haskell programs.

====Functions====
Each Haskell (or, more precisely, Yhc Core) function is translated to corresponding Core Erlang function. Names of functions are not generally preserved. Functions that are exported (expected to be called by Erlang code) keep their names with module name stripped off (remember that Yhc Core file is linked from multiple individual Core files), and some characters replaced (such as primes as they are used in Core Erlang to quote atom names) with underscores. Functions not to be exported are given unique numeric identifiers prepended with dot (.) to form valid Erlang atom names. Thus, for example the <hask>Prelude.map</hask> function is translated from this Yhc Core representation:

<haskell>
Prelude;map v22178 v22179_f =
    let v22179 = _f_ v22179_f
    in let v22179_c = _f_ v22179
       in case v22179_c of
              Prelude;[] -> Prelude;[]
              (Prelude;:) v22180 v22181 ->
                  (Prelude;:) (v22178 v22180) (Prelude;map v22178 v22181)

</haskell>

to this Core Erlang representation:

<code>
'.56'/2 =
  fun (_v22178,_v22179_f) ->
    let <_v22179> =
      <call 'hserl':'force'(_v22179_f)>
      in let <_v22179_c> =
      <call 'hserl':'force'(_v22179)>
      in case <_v22179_c> of
      <{'@dt','.EOL'}> when 'true' ->
        {'@dt','.EOL'}
      <{'@dt','.CONS',_v22180,_v22181}> when 'true' ->
        {'@dt','.CONS',{'@ap',_v22178,1,[_v22180|[]]},
          {'@ap',{'hs_test1','.56'},2,[_v22178|[_v22181|[]]]}}
    end
</code>

The code above also shows how some other Haskell objects are represented in Core Erlang.

The function interface shown above (with arity in Core Erlang equal to arity in Yhc Core) is used for saturated calls. For partial and oversaturated function applications, however a slower but more flexible [http://en.wikipedia.org/wiki/Currying curried] interface (of arity 1) is provided:

<code>
'.56_c'/1 =
  fun (_v22178) ->
    fun (_v22179_f) ->
      call 'hs_test1':'.56'(_v22178,_v22179_f)
</code>

This function, if applied to one argument, returns another function of one argument, which in turn calls the "target" function with both arguments.

Names of curried functions are formed by appending ''_c'' to the name of the target function.

====Forcing evaluation of Haskell expressions====
Non-function Haskell objects are represented using Erlang tuples, tagged with the first member, an atom. The [http://darcs.haskell.org/yhc/src/translator/erlang/00proof/hserl.erl runtime support module] (written in Erlang) provides the <code>force/1</code> function that is called every time a Haskell expression needs to be evaluated (see example of the <hask>map</hask> function above when <code>hserl:force</code> is called upon a case scrutinee variable. For expressions already evaluated, and further unreducible, <code>force/1</code> returns its argument as supplied, but otherwise it will actually evaluate its argument, and return a computed value.

====Thunks====
Thunks, or delayed function calls, are tagged with atom ''@ap''. Below, possible types of thunks, and their evaluation logic are discussed.

General structure of an application thunk is as follows:

<code>
{'@ap', Func, Arity, Args}
</code>

''Func'' may be a 2-tuple directly identifying a function, or some expression that may evaluate to a function. ''Arity'' is usually 1 for partial and oversaturated applications, otherwise it is an arity of a function involved in a saturated call. ''Args'' is a list (in Erlang sense) of arguments.

* Saturated application (''Arity'' == length (''Args'')): <code>erlang:apply</code> is called upon ''Func'' and ''Args''; result is forced again.

* Oversaturated application (''Arity'' == 1, length (''Args'') > ''Arity''): ''Func'' is applied to the head of ''Args'', the result is applied to the remainder of ''Args'', etc. (known as [http://www.haskell.org/~simonmar/papers/eval-apply.pdf Eval-Apply] evaluation strategy). Only curried versions of functions may be involved (of arity 1); thus partial application is simply impossible.

* Partial/oversaturated application of n-ary function: should not occur.

====CAFs====
CAFs (nullary functions) are tagged with atom ''@caf'' and structured as follows:

<code>
{'@caf', Module, Function}
</code>

''Module'' and ''Function'' are atoms.

If a CAF is part of function application, it is called first, and whatever is returned, is evaluated again (this may be another CAF, or a function). Once an actual function is obtained from CAF's evaluation, the application is processed as described above.

====Data constructors====
Data constructors are renamed similarly to functions, but no curried forms are created because all applications of data constructors in Yhc Core are saturated; the compiler creates necessary wrappers for partial applications itself. Certain data constructors are given sensible identifiers, such as:

* <hask>Prelude.:</hask> is renamed to ''.CONS'';
* <hask>Prelude.[]</hask> is renamed to ''.EOL'';
* Tuple constructors are renamed to ''.TUP''<code>n</code>, where <code>n</code> is number of '''commas''' (so 2-tuple is ''.TUP1'').

Applications of data constructors are Erlang tuples tagged with atom ''@dt''. Arguments of a data constructor do not form a list, but rather are all included in the tuple.

Applications of data constructors are non-strict on all their arguments, and <code>hserl:force</code> applied to an application of a data constructor returns the same application.

====Special cases====
Erlang list objects are wrapped in Erlang tuples tagged with ''@lst'' when passed to Haskell functions as values. The <code>hserl:force</code> function lazily converts such lists into Haskell lists such as:

<code>
 force ({'@lst', []}) -> {'@dt', '.EOL'};
 force ({'@lst', [H|T]}) -> {'@dt', '.CONS', H, {'@lst', T}};
</code>

Another function, <code>hserl:hslist</code>, does the opposite: converts a Haskell list (must be finite) to an Erlang list.