RE: [Template-haskell] Release
| | `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? S
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
On Tue, May 27, 2003 at 03:20:52PM +0100, Ian Lynagh wrote: [ reformatted and cut down a bit ]
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).
Lit, Pat, Exp, Body, Stmt, Range, Dec, Foreign, Con, Type
have a unique first letter so we can use that as a suffix
[ for constructors and smart constructors ]
rather than the full type.
How's that for a compromise?
Does silence mean everyone is happy with this? Or have you all just given up caring? :-) Thanks Ian
On Friday, May 30, 2003, at 03:45 AM, Ian Lynagh wrote:
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).
Lit, Pat, Exp, Body, Stmt, Range, Dec, Foreign, Con, Type
have a unique first letter so we can use that as a suffix [ for constructors and smart constructors ] rather than the full type.
How's that for a compromise?
Does silence mean everyone is happy with this?
Or have you all just given up caring? :-)
I'm happy with the proposal :). Although now that 6.0 is out, is the syntax still going to be changed? -- % Andre Pang : just.your.average.bounty.hunter
On Tue, May 27 2003, Simon Peyton-Jones wrote:
What I'm missing is why the dumb constructors must all have a suffix.
For the sake of consistency, if for nothing else. If you have a naming scheme you should use it all the way or else people get confused and irritated.
It's a big data type. You have to look at it, don't you?
Yes, but only often in the begining. As you use it more you'll need to look at it more seldom. If the names are choosen wisely and consistently you will also be able to "guess" the names with quite some precision. If you have special names for some constructs however, things get a lot more messy. /Hampus -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: d00ram@dtek.chalmers.se "Det är aldrig försent att ge upp"
Hampus Ram
For the sake of consistency, if for nothing else. If you have a naming scheme you should use it all the way or else people get confused and irritated.
Yes, but only often in the begining. As you use it more you'll need to look at it more seldom. If the names are choosen wisely and consistently you will also be able to "guess" the names with quite some precision. If you have special names for some constructs however, things get a lot more messy.
I agree with this. If I can figure out all the names from one or two simple rules and the vocabulary, then I only need to remember the heuristic, and it can be easily applied to vocabulary that is not currently known, or added later. Emacs is a good anti-example of this, eg. current-buffer vs. buffer-list You never know whether you should try a subject-verb or verb-subject name. -- Shae Matijs Erisson - I've tried to teach people autodidactism, but it seems they always have to discover it for themselves. #haskell on irc.freenode.net - We Put the Funk in Funktion
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?
Yes, certainly, but the question is how often one has to look at the documentation. While the names for the constructors are quite easy to learn (because they will have something to do with the constructs they represent), subtle differences like suffixes or not will be a constant factor of confusion for the user. I would like to vote for longer names and as few exceptions as at all possible, please. One letter type suffixes are okay with me, if they are enough to completely disambiguate the constructors. Best, Andres
participants (6)
-
Andre Pang -
Andres Loeh -
Hampus Ram -
Ian Lynagh -
Shae Matijs Erisson -
Simon Peyton-Jones