RE: [Template-haskell] Release
| As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). Yes, that's a good idea. | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: It's all to do with Tim's "two-level types" scheme, but I do agree with you that it seems more trouble than its worth. Tim: how vigorously do you want to defend this? If not, can we let Ian remove the parameterisation? Simon | -----Original Message----- | From: template-haskell-admin@haskell.org [mailto:template-haskell- | admin@haskell.org] On Behalf Of Ian Lynagh | Sent: 08 April 2003 13:17 | To: template-haskell@haskell.org | | | As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). | | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: | | class ToDec a where | to_dec :: a -> Dec | | instance ToDec Dec where | to_dec = id | | class ToExp a where | to_exp :: a -> Exp | | instance ToExp Exp where | to_exp = id | | instance (ToExp e, ToDec d) => Foo (Match p e d) where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Which I'd much rather be able to write as | | instance Foo Match where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Previous discussions about this have all petered out before reaching a | conclusion, but I haven't seen anyone actually stand up and defend the | parameterised types, and it's hard to see how they could be useful | without everything being parameterised anyway. Can we get rid of them? | Please? Or at least have an explanation of why not... | | Hmmm, or maybe I should be asking for them to be extended to cover all | the types to make it easier to have a type of reification that annotates | the tree with type and strictness information. I'd still have the | problem above, but at least more things would be possible. | | Anyway, I'm confused, but sitting in the middle is just driving me mad! | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell
"Simon Peyton-Jones"
| The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this:
It's all to do with Tim's "two-level types" scheme, but I do agree with you that it seems more trouble than its worth.
Tim: how vigorously do you want to defend this? If not, can we let Ian remove the parameterisation?
I'd be in favour of removing it, too. Moreover, I would like to propose the following: * 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). * Get rid of the intriguing (but IMHO impractical) idea of using mnemonics of a particular length for variants data types. Example: we have "Mat" and "Mtch" as well as "Rhs" and "Rihs", where the four letter variant is in the Q monad. The distinction between "Mat" and "Match" etc will vanish once we get rid of the two-level type scheme. Then we can just have "Match" and "MatchQ" together with "Rhs" and "RhsQ" and so on. The rational for the change is that such sophisticated naming schemes may be easy to remember for the inventor, but other people just always have to look the names up in the definition. Cheers, Manuel
On Wed, Apr 09, 2003 at 04:27:58PM +1000, Manuel M T Chakravarty wrote:
* 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 made this change last night, and also a corresponding change to the datastructures so there is now a more uniform approach. I believe from discussions with Manuel off-list that this is what he had in mind, but I apologise if I got confused. Having seen the result of this Simon and Tim don't seem to be too happy with it. Personally I'm not really fussed one way or the other, especially as I think we should be trying to use them as little as possible anyway. Manuel I assume is for it, unless I have misunderstood him. Thanks Ian
Ian Lynagh
On Wed, Apr 09, 2003 at 04:27:58PM +1000, Manuel M T Chakravarty wrote:
* 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 made this change last night, and also a corresponding change to the datastructures so there is now a more uniform approach. I believe from discussions with Manuel off-list that this is what he had in mind, but I apologise if I got confused.
Having seen the result of this Simon and Tim don't seem to be too happy with it. Personally I'm not really fussed one way or the other, especially as I think we should be trying to use them as little as possible anyway. Manuel I assume is for it, unless I have misunderstood him.
I think the new naming scheme is *much* better, because it is simple and straightforward. BTW, my proposal on #haskell to replace "DotDot" by "Range" was meant seriously. Cheers, Manuel
My objectio to this is that at makes pattern matching particularly heayywight. Especially when yo get to deeply nested patterns. If each constructor has 6 or 7 letters rather than 3, things get really dense. I'd rather have a few inconsistent constructors than long names any day. Tim At 10:24 PM 5/22/2003 +0100, Ian Lynagh wrote:
On Wed, Apr 09, 2003 at 04:27:58PM +1000, Manuel M T Chakravarty wrote:
* 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 made this change last night, and also a corresponding change to the datastructures so there is now a more uniform approach. I believe from discussions with Manuel off-list that this is what he had in mind, but I apologise if I got confused.
Having seen the result of this Simon and Tim don't seem to be too happy with it. Personally I'm not really fussed one way or the other, especially as I think we should be trying to use them as little as possible anyway. Manuel I assume is for it, unless I have misunderstood him.
Thanks Ian
participants (4)
-
Ian Lynagh -
Manuel M T Chakravarty -
Simon Peyton-Jones -
Tim Sheard