May 2003 - template-haskell

RE: [Template-haskell] Release
by Simon Peyton-Jones 30 May '03

30 May '03

| I'm happy with the proposal :). Although now that 6.0 is out, is the | syntax still going to be changed? Oh yes, it's too early to start fixing TH just because it's out. In the sterling tradition of GHC (H98 subset aside) I think we are free to change the defn of TH! The user base is small enough and motivated enough to move with us. S

1 0

RE: [Template-haskell] Release
by Simon Peyton-Jones 30 May '03

30 May '03

| > How's that for a compromise? | | Does silence mean everyone is happy with this? | | Or have you all just given up caring? :-) I'd prefer not to suffix the Exp constructors (using something instead of Let to avoid the keyword conflict), but it seems I'm in a minority, so I'll beat a strategic retreat. The rest looks fine. Simon

1 0

RE: [Template-haskell] Release
by Simon Peyton-Jones 30 May '03

30 May '03

| | `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

6 6

RE: [Template-haskell] Release
by Simon Peyton-Jones 27 May '03

27 May '03

| The Maybe module defines one datatype. THSyntax defines | many. One problem is that constructors of some of these | data types clash. For examples both Exp and Pat have | variables and literals. Fair enough. Let's use 'P' for Pat, and nothing for Exp. Thus Var and VarP or PVar. I.e. leave Exp, the heaviest hitter of all, unannotated. Would that serve? Then the only oddities are 'Let' and 'Case' because the lower-case smart constructors (only) clash with the Haskell keywords. Is that a good enough reason to add 'E' to every constructor (concrete and smart)? My nose says 'no' but yours may differ. For these, I think Let/letE and Case/caseE are not so bad. An alternative would be to use Bind and Switch instead. this isn't a big deal in the end. I'm quite willing to be over-ruled. Simon

2 1

RE: [Template-haskell] Pattern matching against lists.
by Simon Peyton-Jones 26 May '03

26 May '03

Right. Then you need the magic names "GHC.Base::" etc. As Derek Ekins says, the thing to do is to write it quoted and then print; you'll then see the magic names. Tim and I are ruminating about this stuff. We're planning a way to let you name global things like (:) just by saying '(:) rather than with magic strings where you have to know about GHC.Base. But that won't arrive for a month or two Meanwhile this should get you unglued Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Hampus Ram | Sent: 26 May 2003 14:52 | To: template-haskell(a)haskell.org | Subject: Re: [Template-haskell] Pattern matching against lists. | | On Mon, May 26 2003, Simon Peyton-Jones wrote: | > | > reading through THSyntax.hs I can find no way of matching against | > | > lists when creating functions. Is there something obvious that I've | > | > missed or is this something that is relly missing? | > | > [d| f (x:xs) = x |] | | Nothing, except that I needed to create pattern matching functions of | different lengths (so I need to construct them with the datatypes). I | tried conPat with just ":" and "[]" and that didn't work. I also tried | reifying declarations to see "behind the scenes", but reification does | seldom work for me... The solution was of course to use GHC.base:: and | GHC.base:[] and now everything works. One should perhaps not be too | quick to ask for help :) | | (btw. the new names are much better than the old) | | /Hampus | | -- | Homepage: http://www.dtek.chalmers.se/~d00ram | E-mail: d00ram(a)dtek.chalmers.se | | "Det är aldrig försent att ge upp" | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] Pattern matching against lists.
by Simon Peyton-Jones 26 May '03

26 May '03

2 1

RE: [Template-haskell] Release
by Simon Peyton-Jones 26 May '03

26 May '03

| > > * Use a naming scheme for the functions that avoids having | > > to suffix some with "E" or "D" and some not. Example: we | > > have "cond", but "letE". Better *uniformly* use a single | > > suffix for all functions of the same class; eg, "condExp" | > > and "letExp" (or "condE" and "letE" if you desperately | > > want to save letters). I'm sorry that I didn't respond to this at the time. I agree with the first sentence, but I had not absorbed the full glory of making every single constructor three or four characters longer. Like Tim, I don't think this is a good plan. We don't say JustMaybe and NothingMabye. Instead, we just choose constructor names that don't clash within a particular module. (Between unrelated modules, we can rely on qualified names etc.) My suggestion for resolving the occasional clash (and there were only a handful) would be to change the constructor name. For example, we have a let form in Exp and in Stmt. Let's just give one a different name. The Stmt type is much less used than the Exp type. Perhaps 'Bind', 'Let', 'NoBind' and 'Par' are a bit cryptic because Stmts are so much less common, so perhaps 'LetStmt' or 'StmtLet' would indeed be a good choice. Similarly for Foreign, the constructor 'ImportForeign' or 'ForImport' seems good; plain 'Import' is rather cryptic. But for the big hitters, Exp, RHS, Dec, Pat, Typ, my personal preference would be for short constructor names. Manuel, it sounds as though you disagree with this? I would like to see the type 'Typ' change to 'Type', though! Changing DotDot to Range is fine with me. A process question, though: TH is for everyone, and Ian L is doing us all a service by doing work on the design and implementation. So he gets a big vote. Please do not take this as having a "don't fiddle" subtext. I for one am really grateful for your help. Simon

3 2

Pattern matching against lists.
by Hampus Ram 24 May '03

24 May '03

Hi, reading through THSyntax.hs I can find no way of matching against lists when creating functions. Is there something obvious that I've missed or is this something that is relly missing? /Hampus -- Homepage: http://www.dtek.chalmers.se/~d00ram E-mail: d00ram(a)dtek.chalmers.se "Det är aldrig försent att ge upp"

2 1

RE: [Template-haskell] Release
by Simon Marlow 23 May '03

23 May '03

> On Fri, May 23, 2003 at 11:26:31AM +0100, Simon Peyton-Jones wrote: > > My suggestion would be to back out Ian's changes until we evolve a > > consensus. The consensus may ultimately turn out to be > exactly what Ian > > has done, but it's probably sensible to avoid the risk of TH users > > having to make a double change. > > > > Renewed apologies for not bleating earlier about this. > > > > ok with you, Ian? (It's easy to re-apply the patch later, > so there's no > > danger of losing the work if we end up adopting it.) > > How about backing it out in the 6.0 branch but leaving the HEAD as-is? > > The reason being that I also rearranged some bits, added a few type > signatures and things so I think it would be easier to re-rename from > the current HEAD. Also wouldn't have to worry about merging with any > changes between now and concensus. > > TH users would then be strongly advised to use the 6.0 branch until > things settle down. Done; 6.0 will have the original names. Cheers, Simon

1 0

RE: [Template-haskell] Release
by Simon Peyton-Jones 23 May '03

23 May '03

My suggestion would be to back out Ian's changes until we evolve a consensus. The consensus may ultimately turn out to be exactly what Ian has done, but it's probably sensible to avoid the risk of TH users having to make a double change. Renewed apologies for not bleating earlier about this. ok with you, Ian? (It's easy to re-apply the patch later, so there's no danger of losing the work if we end up adopting it.) Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Simon Marlow | Sent: 23 May 2003 09:34 | To: Simon Peyton-Jones; Tim Sheard; Ian Lynagh; Manuel M T Chakravarty | Cc: template-haskell(a)haskell.org | Subject: RE: [Template-haskell] Release | | | > | > > * Use a naming scheme for the functions that avoids having | > | > > to suffix some with "E" or "D" and some not. Example: we | > | > > have "cond", but "letE". Better *uniformly* use a single | > | > > suffix for all functions of the same class; eg, "condExp" | > | > > and "letExp" (or "condE" and "letE" if you desperately | > | > > want to save letters). | > | > I'm sorry that I didn't respond to this at the time. I agree with the | > first sentence, but I had not absorbed the full glory of making every | > single constructor three or four characters longer. Like Tim, I don't | > think this is a good plan. We don't say JustMaybe and NothingMabye. | > Instead, we just choose constructor names that don't clash within a | > particular module. (Between unrelated modules, we can rely | > on qualified names etc.) | | We need to decide what naming scheme is going to be in GHC 6.0. I | already merged through Ian's renaming changes, so the current situation | is that GHC 6.0 has the longer names. Time is short, so I could just | back out to the previous story if there's no concensus. | | Cheers, | Simon | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1