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 renaming 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 Lit Pat (Match) (Clause) Exp Body Stmt Range Dec Foreign Con (Module) Type 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. Thanks Ian