GHC core representation

[Alastair David Reid]

[This is in reply to Andrew Tolmach's mail to the Haskell list.  He
asked that replies should be sent to ghc-users.]

> Many months after the topic was first raised, there is finally a draft
> document describing a formal external syntax for GHC's "Core"
> intermediate language.

Wow!  This is very cool - it answers so many questions that I
previously had to examine the source code to figure out!

Two meta-comments before I go into detailed comments.

1) GHC documentation tends to have a very short half-life.
   What can be done to minimize this problem?
   For example can the tables of primops in section 4 be automatically
   generated?

2) I haven't seriously hacked on GHC or the the GHC frontend for 
   several years so some of the following comments will be a little
   off.  I'm hoping that people who are more up to date will correct
   me and that their corrections will be useful to anyone like me
   who used to know GHC but have lost track of the details.

OK, onto the detailed comments.

1) GHC identifiers have SrcLocs (filename/linenumber) attached to them.
   It might be useful to be able to pass those into your parser.
   (But what are the SrcLoc's used for in Core code?  Would they be useful?)

2) The names you use for operations all use the somewhat unreadable 
   Z encoding.  I think you should Z-decode these names because:

   1) They're a lot more readable.  e.g., decode "ZLZmZgZR" = "(->)"

   2) It's possible that GHC will get confused if you fail to Z-encode
      a name.  For example, it isn't possible to have the name "Z"
      in Core because GHC encodes the Haskell identifier "Z" as "ZZ".

   From memory, the Z encoding is something like this:

     ZL -> (
     ZR -> )
     Zm -> -
     Zg -> >
     Zl -> <
     Ze -> =
     Zc -> :
     Zp -> .
     Zxxx -> chr(xxx)   where xxx is a sequence of digits

3) The restriction that Main.main have type IO a is unfortunate and, I
   think, unnecessary.  It shouldn't be that hard to change it so that
   its type is more like:

     State# RealWorld -> (# State# RealWorld, Void# #)

4) While explaining namespaces, it'd be convenient to point out that
   you put a % in front of all keywords.

   Hmmm, I guess this is one reason to use Z-encoded names: % is a
   legal Haskell identifier.

5) The @a in datatype declarations threw me for a while.
   Later I saw you using it like BigLambda in an explicitly typed
   lambda calculus and understood what you were doing.  It'd be
   worth making the connection explicit.

6) An alternative way of defining data constructors would be like this:

   %data BinTree :: * -> * = {
      Fork :: %forall a . BinTree a -> BinTree a -> BinTree a;
      Leaf :: %forall a . a -> BinTree a
   }

   That is, specify the actual type of data constructors instead of
   using Haskell datatype declaration syntax.  This makes the language
   a little easier to specify.

   Notice that this syntax is a little more liberal than standard Haskell
   syntax because you could write types like:

   %data Expr :: * -> * = {
     Int :: Int -> Expr Int;
     App :: %forall a, b . Expr (a -> b) -> Expr a -> Expr b;
     Lam :: %forall a, b . Var a -> Expr b -> Expr (a -> b)
   }

   which cannot be expressed using normal Haskell syntax because
   the result types of each constructor are different.  I saw 
   Lennart mention this idea in a talk about 8 years ago and I've 
   always wanted to play with it. :-)

   On the other hand, you might avoid this generalisation in case
   GHC does something weird with it.

7) In section 3.6, you say:

    "Value applications may be of user-defined functions, data constructors
     or primitives.  Application of the latter two sorts need _not_ be
     saturated."

   I think you mean "none of these applications need to be saturated
   although both previously published descriptions of Core required
   that the latter two be saturated."

8) You say that the list of case alternatives "need not be exhaustive,
   even if no default is given; it is a disastrous run-time error if a
   needed case arm is missing."

   1) Just how disastrous?  Is an exception raised or does the RTS crash?
   2) I feel a little uneasy with this design decision.

9) You don't mention the _scc_ operation used for profiling.

10) There's a move on to define %ccall in a more generic way
    that would apply to calling Java functions, .net functions, etc.
    This is bound to result in a change of the "ccall" name. 
    It'd be worth adding a Working note to that effect.

11) The discussion of the terms "unboxed", "heap allocated" and 
    "unlifted" (page 9) doesn't seem quite right.  I believe it is:

    Lifted types must be heap allocated.  Unlifted types may be heap
    allocated (e.g., Array#s) or unboxed (not heap allocated) (e.g., Int#).

12) The discussion of operations on MVar# (page 10) says that they
    take an initial type argument of the form (State# t) for some
    thread "t".  Is this true?  Does "t" not have to be RealWorld#?
    What does it mean if it is not RealWorld#?  

13) Are the CCallable and CReturnable classes still there?  Blech!
    [I'm the one who implemented them - I'd hoped they'd gone by now.]

14) If strings are represented by the "address of a C-format string"
    (section 4.2), how do we represent strings with embedded \0 characters
    in them?

15) dataToTag#, tagToEnum# and getTag# (section 4.4.1) might be used
    to implement the to/fromEnum operations but they may also be
    remnants of GHCi version 0.0 - a metacircular interpreter that
    was in GHC version 0.18 (or thereabouts).  If the latter, someone
    ought to give them a decent burial.

16) You document unsafeCoerce# but not 

       reallyUnsafePtrEq# :: a -> a -> Bool

    did someone finally kill that?

17) decodeDouble# and decodeFloat# are used to extract the exponent
    and mantissa of a floating point number.  Ignoring unboxity,
    it returns an Int (the exponent) and an Integer (the mantissa).
    Representing that as unboxed types, you get (# Int#, Int#, ByteArray# #)
   
18) Section 4.4.8 asks what the relationships are between quotient,
    remainder, div and mod.  This ought to be the same as that specified
    in the Haskell report for their boxed equivalents.

19) Your question about what indexArray# does and what alignment 
    restrictions apply reminds me of a subtlety:

      When indexing into a ByteArr# or a Addr#, is the index
      scaled by the size of the object being read/written (as in C)
      or not?

    I am pretty sure that the index on an Addr# is not scaled (and the
    value of the (Addr# + Int#) combination is subject to exactly the
    same alignment restrictions as imposed by the hardware architecture.

    I don't recall the story for ByteArr# but a ByteArr# object is
    always aligned to the nearest 4 (maybe 8) byte boundary.

20) Section 4.4.15 says that takeMVar# and putMVar# "die" if the MVar is
    empty (respectively, full).

    1) What does "die" mean?
       More generally, how is failure implemented in the primops?
       Do they raise exceptions?  Do they return error codes?
       Do they call exit?  Do they crash the RTS?

    2) Are you sure these ops "die"?  Their unboxed Haskell brethren
       will block the thread under the same circumstances.

21) You repeatedly mention the sequential implementation of the RTS.
    Last time I looked, it wasn't possible to build the RTS with 
    concurrency turned off.  

    If one were to build the GHC RTS with concurrency turned off, I
    think the concurrency primitives should not be available rather
    than providing versions that always/mostly fail.  Or maybe one could 
    implement non-preemptive "concurrency" in much the same way as we
    did in Hugs?  (Not sure I recommend this route - the interactions
    between threads and exception handlers in Hugs are somewhat tricky.)



-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/