So it looks like we're stuck at pretty much the same proposals for the class system. a) standardize on MPTC and FDs using rules from CHR paper. b) don't standardize anything, and wait for ATs to take over c) punt---standardize the library and exact form of FD for that library, but no more, or map out some longer timeline for this issue. For a while I thought (a) was the clear choice. The theory has been worked out, we have a lot of experience using them, and key libraries depend on them. However, not everyone is convinced by (a) because of the fear of too early standardization. We may end up with a lot of code that uses a feature that will eventually be deprecated. There are perhaps three counterarguments to this point of view: - We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code. - It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in fact there is (or will be) some automatic way of translating FD code to AT code. - It may not be all bad for a future Haskell standard to include both ATs and FDs. Certainly more complicated, but I haven't seen any evidence that these features interfere with eachother. Are there any merits to these counterarguments? More generally, our discussion about the class system seems to be stalled. How should we to come to a decision? --- Stephanie
On 5/11/06, Stephanie Weirich
a) standardize on MPTC and FDs using rules from CHR paper.
- We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code.
In my opinion, this one holds the greatest weight. The current mass of
*useful* and *used* code that is written with and requires FDs is
possibly the most important consideration of all.
Given that FD *syntax* is well-defined, I see no reason not to
standardize it. It remains, however, to decide on what level of
*minimum* termination support Haskell' will insist upon. The CHR paper
(with the confluence improvements by Claus) is currently the most
promising option, and has an implementation (another important
consideration) in GHC.
--
Taral
Hi all, Stephanie wrote:
So it looks like we're stuck at pretty much the same proposals for the class system.
a) standardize on MPTC and FDs using rules from CHR paper. b) don't standardize anything, and wait for ATs to take over c) punt---standardize the library and exact form of FD for that library, but no more, or map out some longer timeline for this issue.
For what it's worth, I think b) would be very unfortunate, unless we end up in the even more unfortunate situation of the Haskell' process stalling, so that ATs have taken over by the time we're done.
For a while I thought (a) was the clear choice. The theory has been worked out, we have a lot of experience using them, and key libraries depend on them.
That's what it seemed like to me too. But admittedly mainly from a spectator position.
However, not everyone is convinced by (a) because of the fear of too early standardization. We may end up with a lot of code that uses a feature that will eventually be deprecated. There are perhaps three counterarguments to this point of view:
- We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code.
- It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in fact there is (or will be) some automatic way of translating FD code to AT code.
- It may not be all bad for a future Haskell standard to include both ATs and FDs. Certainly more complicated, but I haven't seen any evidence that these features interfere with eachother.
Are there any merits to these counterarguments?
There's certainly merit to the first, and likely to the second too, from what I've seen. (Don't know about the third: as a matter of principle, I don't like a situation with two (or more) similar language features essentially addressing the same need.) Here's another argument along the lines of the first two. If MPTCs and some form of FDs/ATs are not standardized, people who want to comply with the standard will in many cases have to resort to cumbersome workarounds (loss of abstraction and hence effectively lots of code duplication). Migrating such code to use MPTCs and FDs/ATs is likely going to be a lot more work than, say, migrating code that uses FDs to use ATs instead, or migrating it to use some slightly different version of either. Indeed, this task might well be automatable. And why would one want to migrate such code once MPTCs/ATs get standardized? Well, if nothing else, to make it more maintainable, and for libraries to make them work smoothly in the new setting. The other thing that could happen, of course, is that people simply stick with GHC and ignore the standard. And then a lot of the Haskell' effort would have been in vain. Bottom line: At this point I am not overly worried about too early standardization for MPTCs + FDs (or whatever). I am worried about the no-standardization option. If someone has really good arguments for why early standardization is likely to create a legacy nightmare, while no standardization wouldn't, please speak up! Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
Hello Stephanie, Thursday, May 11, 2006, 5:45:15 PM, you wrote:
- We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code.
are you sure about *lots* ? i seen only 3-4 ones (monad transformers, collections, may be arrays, my streams) and think that all these libraries can be redesigned without any problems once in several years. that is really important is that CLIENTS of these libraries don't need to be changed
- It may be that all uses of MPTCs/FDs may be subsumed by ATs, and in fact there is (or will be) some automatic way of translating FD code to AT code.
i think that is not necessary considering that i said above
- It may not be all bad for a future Haskell standard to include both ATs and FDs. Certainly more complicated, but I haven't seen any evidence that these features interfere with eachother.
language should be orthogonal, i.e. include only one way to implement each feature. otherwise, it becomes too large
Are there any merits to these counterarguments?
More generally, our discussion about the class system seems to be stalled. How should we to come to a decision?
i think the same - goal of discussion should be developing of proposal/proposals in this area for Haskell' committee. any other directions of discussion, while very important for future of Haskell language, should be somewhat limited or moved to cafe list. i propose the following structure of discussions: 1. initial proposal 2. critique 3. correction of proposal and going to 2nd step 4. final proposal or abandoning this proposal making several concurrent proposals on the same topic would be great because concurrency motivates to make better things and because ideas can be easily borrowed by proposals from each other -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
- We're already in that state. There *is* a lot of Haskell code that uses FDs, it's just not Haskell 98 code. Whenever ATs take over, we'll still have to deal with this code.
are you sure about *lots* ? i seen only 3-4 ones (monad transformers, collections, may be arrays, my streams) and think that all these libraries can be redesigned without any problems once in several years.
OK, here's an example where I use functional dependencies: http://141.57.11.163/cgi-bin/cvsweb/tool/src/Challenger/Partial.hs?rev=1.23 class ( Show p, ToDoc i, Reader b, ToDoc b, Measure p i b ) => Partial p i b | p i -> b where ... -- (*) containing two methods that don't use all type variables. (That's why I think I need the FD.) How would this look without FD? With ATs? Is there an altogether better design for this? Where I still would not need to change the client code? (*) A funny visual aspect of FDs is the absurd syntax. On the left of "|", the whitespace is (type arg) application, but on the right, it suddenly denotes sequencing (tupling) Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Hello Johannes, Friday, May 12, 2006, 4:18:29 PM, you wrote:
=> Partial p i b | p i -> b where ... -- (*)
(*) A funny visual aspect of FDs is the absurd syntax. On the left of "|", the whitespace is (type arg) application, but on the right, it suddenly denotes sequencing (tupling)
i also don't like this - it's really confusing. "p,i->b" will be better approach -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Johannes Waldmann wrote:
class ( Show p, ToDoc i, Reader b, ToDoc b, Measure p i b ) => Partial p i b | p i -> b where ... -- (*)
(*) A funny visual aspect of FDs is the absurd syntax. On the left of "|", the whitespace is (type arg) application, but on the right, it suddenly denotes sequencing (tupling)
I think it's fine. The "p i b" on the left is effectively a tuple also. It could be a tuple---i.e. the MPTC syntax could be "Partial (p,i,b)" and it would still make sense. The class declaration syntax is totally screwy anyway. Functional dependencies are constraints, and should be grouped with the typeclass constraints, but instead they're on opposite sides of the head. Plus the => implication is backwards. And the method declarations are also constraints. We oughta have class Partial p i b where Foo p (p,i) -> b grok :: p -> i -> b or class Partial p i b | Foo p, p i -> b where grok :: p -> i -> b or something. But I'm not proposing anything of the sort. I'm in favor of standardizing the syntax we've got. Syntax changes are disruptive, and I don't think they're justified unless they free useful syntax for another use, which this wouldn't. -- Ben
Ben Rudiak-Gould wrote:
=> Partial p i b | p i -> b where ... -- (*)
I think it's fine. The "p i b" on the left is effectively a tuple also.
The problem is that "Partial p i b" is application, while "p i" is not. Also, "p i" (on the right) denotes a set, not a tuple. I think this syntax is unnecessarily clever. But I agree that changing it might not be clever either. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------
Johannes Waldmann wrote:
Ben Rudiak-Gould wrote:
=> Partial p i b | p i -> b where ... -- (*)
I think it's fine. The "p i b" on the left is effectively a tuple also.
The problem is that "Partial p i b" is application, while "p i" is not.
That's just it: I don't think "Partial p i b" is an application. The typeclass language is a logic language. "((Partial p) i) b" is illegal. (Well, GHC accepts it, but I think that's a side effect of the way the parser works. Hugs rejects it.) -- Ben
| So it looks like we're stuck at pretty much the same proposals for the | class system. ... | More generally, our discussion about the class system seems to be | stalled. How should we to come to a decision? I summarise my view of the state of play in the message below, which I see I did not circulate to all of haskell-prime at the time. My suggestion is this: * Specify MPTCs in the main language * Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs). * A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever I think it's probably too early even to have an Appendix describing ATs. I'd be surprised if the experience of implementing and using them doesn't have impact on their design. The other alternative I can see is to delay the whole process until we know more (a year or two), but I can see that is unattractive. Simon | -----Original Message----- | From: Simon Peyton-Jones | Sent: 04 May 2006 14:36 | To: chak@cse.unsw.edu.au | Cc: Martin Sulzmann; Stephanie Weirich; Ross Paterson; isaac jones; Ravi Nanavati; Andres Loeh; | John Launchbury; Simon Peyton-Jones | Subject: RE: Class System current status | | | I don't think I ever argued that we put ATs in Haskell'. I am arguing | | that we should not put FDs in. | | I think Haskell' MPTC situation is clarifying in my mind as follows | | 1) We definitely want MPTCs | | 2) MPTCs without either FDs or ATs or CHRs are not very useful. | | 3) ATs are shaping up to be a better *programming* notation than FDs, in the same way that FDs are | better than CHRs. This isn't an issue of expressiveness; it concerns ease of inference and ease of | programming. | | 4) However, we have lots of experience of programming with, and implementing FDs; but virtually | none about ATs. The situation might be very different in a year's time, when we have an AT | implementation, and some experience of use. | | | I take (3) to be somewhat controversial. We have little evidence to go on, so far. Nevertheless I'd be | interested to know if (as of today) anyone would positively prefer a language of FDs compared to one | with ATs. | | | All this makes me think that it will be hard to reach a satisfying conclusion in a few months. Perhaps | this isn't the moment to force a conclusion. An alternative might be to punt the whole issue into a | (longer-timescale) Blessed Appendix. (I don't think that the rest of the language depends much on | this, although certain libraries do.) | | Simon
Hello Simon, Friday, May 12, 2006, 8:05:25 PM, you wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever
i agree with that and even feel that this proposal reflect viewpoint of most of us (of course, i may be wrong). moreover, my own proposal is essentially the same, only from practical viewpoint - use FDs today but be ready to reimplement these libs several years later using some new extension. so the developer will decide whether he prefer to have maximum features or maximum compatibility moreover, i think that idea of Appendixes can be used to allow many other extensions be somewhat standard but not required in each and every compiler. this includes GADT, concurrency, TH, TRex and many other things -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Simon Peyton-Jones wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever
Simon, Why is an Appendix is better than just a footnote in the Standard that says "we aren't sure, one way or the other, whether FDs will stay in the language for ever." Why do we need this extra structure? I'm worried that this extra structure could be confusing. In particular, if someone says "this program is pure Haskell'" what will that mean? In practice, will it be clear whether pure Haskell' includes the Appendix? --Stephanie
Hi all, Stephanie wrote:
Simon,
Why is an Appendix is better than just a footnote in the Standard that says "we aren't sure, one way or the other, whether FDs will stay in the language for ever." Why do we need this extra structure?
I'm worried that this extra structure could be confusing. In particular, if someone says "this program is pure Haskell'" what will that mean? In practice, will it be clear whether pure Haskell' includes the Appendix?
I agree with this. If there is a need to make it clear that some features are particularly likely to change, I can't see why that cannot be achieved in the main body of the report. Through a foot note, or through a highlighted paragraph of some kind. I worry that tearing apart closely related topics is going to be difficult as well as resulting in a confusing and somewhat unstructured report. The appendix idea has also been mentioned in other contexts, specifically for records, and I don't like it there either for the same reasons. Best, /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
Stephanie Weirich:
Simon Peyton-Jones wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever
Simon,
Why is an Appendix is better than just a footnote in the Standard that says "we aren't sure, one way or the other, whether FDs will stay in the language for ever." Why do we need this extra structure?
IMHO the right thing is to decouple finalising an FD/AT appendix from finalising the main body of Haskell'. This is clearly more easily realised when the delayed material is out-of-line. Manuel
On 2006-05-13, Manuel M T Chakravarty
Stephanie Weirich:
Simon Peyton-Jones wrote:
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever
Simon,
Why is an Appendix is better than just a footnote in the Standard that says "we aren't sure, one way or the other, whether FDs will stay in the language for ever." Why do we need this extra structure?
IMHO the right thing is to decouple finalising an FD/AT appendix from finalising the main body of Haskell'. This is clearly more easily realised when the delayed material is out-of-line.
Meh. I'd really like a revised numeric prelude to be able to use MPTCs with FDs. -- Aaron Denney -><-
Hello Aaron, Monday, May 15, 2006, 12:27:43 AM, you wrote:
IMHO the right thing is to decouple finalising an FD/AT appendix from finalising the main body of Haskell'. This is clearly more easily realised when the delayed material is out-of-line.
Meh. I'd really like a revised numeric prelude to be able to use MPTCs with FDs.
other well-known uses of FDs are also in the heart of core Haskell libs - collections, monad transformers, streams -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
On 2006-05-15, Bulat Ziganshin
Hello Aaron,
Monday, May 15, 2006, 12:27:43 AM, you wrote:
IMHO the right thing is to decouple finalising an FD/AT appendix from finalising the main body of Haskell'. This is clearly more easily realised when the delayed material is out-of-line.
Meh. I'd really like a revised numeric prelude to be able to use MPTCs with FDs.
other well-known uses of FDs are also in the heart of core Haskell libs - collections, monad transformers, streams
Sure, it's just I question how core those are. The math stuff pretty much needs to be built in, especially considering things like defaulting, and syntactic sugar. -- Aaron Denney -><-
Simon Peyton-Jones:
| So it looks like we're stuck at pretty much the same proposals for the | class system. ... | More generally, our discussion about the class system seems to be | stalled. How should we to come to a decision?
I summarise my view of the state of play in the message below, which I see I did not circulate to all of haskell-prime at the time.
My suggestion is this:
* Specify MPTCs in the main language
* Specify FDs in an Appendix (with some reasonably conservative interpretation of FDs).
* A Haskell' implementation should implement the Appendix, and programmers can write programs against it. But we are advertising specifically that we aren't sure, one way or the other, whether FDs will stay in the language for ever
I think it's probably too early even to have an Appendix describing ATs. I'd be surprised if the experience of implementing and using them doesn't have impact on their design.
The other alternative I can see is to delay the whole process until we know more (a year or two), but I can see that is unattractive.
A variation on this proposal is that we actually delay issuing the appendix. More precisely, * Specify MPTCs in the main language. * Finalise Haskell' without an FD/AT appendix. * Take our time to find out exactly how we want to do type level programming (with FDs, or ATs, or both). Once we know, we add an appendix on type-level programming. This moves the MPTC dilemma out of the critical path for Haskell' as a whole, but avoids that we have to rush the FD/AT issue. Manuel
| -----Original Message----- | From: Simon Peyton-Jones | Sent: 04 May 2006 14:36 | To: chak@cse.unsw.edu.au | Cc: Martin Sulzmann; Stephanie Weirich; Ross Paterson; isaac jones; Ravi Nanavati; Andres Loeh; | John Launchbury; Simon Peyton-Jones | Subject: RE: Class System current status | | | I don't think I ever argued that we put ATs in Haskell'. I am arguing | | that we should not put FDs in. | | I think Haskell' MPTC situation is clarifying in my mind as follows | | 1) We definitely want MPTCs | | 2) MPTCs without either FDs or ATs or CHRs are not very useful. | | 3) ATs are shaping up to be a better *programming* notation than FDs, in the same way that FDs are | better than CHRs. This isn't an issue of expressiveness; it concerns ease of inference and ease of | programming. | | 4) However, we have lots of experience of programming with, and implementing FDs; but virtually | none about ATs. The situation might be very different in a year's time, when we have an AT | implementation, and some experience of use. | | | I take (3) to be somewhat controversial. We have little evidence to go on, so far. Nevertheless I'd be | interested to know if (as of today) anyone would positively prefer a language of FDs compared to one | with ATs. | | | All this makes me think that it will be hard to reach a satisfying conclusion in a few months. Perhaps | this isn't the moment to force a conclusion. An alternative might be to punt the whole issue into a | (longer-timescale) Blessed Appendix. (I don't think that the rest of the language depends much on | this, although certain libraries do.) | | Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org//mailman/listinfo/haskell-prime
participants (9)
-
Aaron Denney -
Ben Rudiak-Gould -
Bulat Ziganshin -
Henrik Nilsson -
Johannes Waldmann -
Manuel M T Chakravarty -
Simon Peyton-Jones -
Stephanie Weirich -
Taral