[Template-haskell] Release

Ian Lynagh igloo@earth.li
Tue, 27 May 2003 15:20:52 +0100

On Tue, May 27, 2003 at 03:19:17PM +0100, Simon Peyton-Jones wrote:
> | 
> | `Bind'/`bind' has the same number of characters as
> | `LetE'/`letE' and `Switch'/`switch' has even one more
> | character than `CaseE'/`caseE'.
> Indeed.  It's the *other* constructors in Exp I'm worried about.
> | I still think the number one priority is to have no
> | exceptions in the naming scheme.
> In a large data type like Exp you are sure to have to refer to the
> constructor list to find out what they are all called.  There's Var,
> App, Tup, Cond... and (LetE or Bind) and (CaseE or Switch).  You have to
> look to see what they are.
> I'm agree 100% that the smart constructors should be derived
> systematically.  So if we can't have 'let' for the smart constructor,
> then we can't use 'Let' for the dumb constructor either.  What I'm
> missing is why the dumb constructors must all have a suffix. 
> | Sorry for being stubborn on this, but I just don't see the
> | advantage of saving one character if that risks that people
> | have to refer to the documentation more often (or at least
> | get a compiler error before they remember again that they
> | are dealing with an exception).
> I agree with that.  What I'm missing is why adding 'E' to the end of
> each Exp constructor will reduce the number of looks at documentation.
> It's a big data type. You have to look at it, don't you?

A discussion on IRC with Manuel and Shae produced the suggestion of

Typ -> Type (Unrelated to the discussion at hand)
RHS -> Body
DotDot -> Range
Program -> Module (Unrelated to the discussion at hand)

and merging Tag into Type (giving e.g. a TupleType Int constructor).

The non-leaf datatypes are then


The parenthesised ones have only 1 constructor with the same name as the
type so excluding them from having the type name or inital suffixed
seems reasonable.

The remainder have a unique first letter so we can use that as a suffix
rather than the full type.

Lit is a sort of half-leaf datatype - its constructors take arguments
unlike, say, "data Strict = IsStrict | NotStrict", but they are just
ground types. I've put it in the list for now at least.

So, under this scheme, e.g.:

data Exp 
  = VarE String
  | ConE String
  | LitE Lit
  | AppE Exp Exp
  | ...

data Pat
  = LitP Lit
  | VarP String
  | TupP [Pat]
  | ...

data Lit
  = CharL Char             
  | StringL String             
  | IntegerL Integer
  | ...

data Type = ForallT [String] Cxt Type
         | VarT String
         | ConT String
         | TupleT Int
         | ArrowT
         | ListT
         | AppT Type Type

and leaf datatypes would continue to be unmarked, e.g.

data Callconv = CCall | StdCall

How's that for a compromise between the concise names Tim and Simon want
and the consistent naming everyone else seems to prefer (I think I've
seen 5 people say they prefer the new names over the old (including
Manuel) between this list and IRC, which perhaps reinforces Manuel's
point about expert-users vs normal-users)?

One possible issue is the effect of future addendums (and other GHC
extensions). The FFI has added the need for a Foreign datatype and
happily F was available.