Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
While I agree with your general argument, I wonder if you realize that functional dependencies have a strong, general, and elegant mathematical foundation that long predates their use in Haskell? If you want even a brief glimpse, there's s short article at http://en.wikipedia.org/wiki/Functional_dependencies that might give you some ideas. The mathematics of functional dependencies plays an important role in the theory of relational databases. I don't know what you consider as the mathematical foundations for associated types, nor do I know why you consider that to be either more general or more mathematical (whatever that means) but I hope you'll enjoy the material on functional dependencies. I admit I was being unfair on fundeps in calling them less mathematical. Nonetheless, something about their addition to Haskell grates on my mathematical sensitivities. They feel bolted on in a way that associated types don't. Probably this is because of my own bias which leads me to see Haskell as a subset of dependent type theory, and ATs as some kind of sigma type (though I've never tried to make this precise). Barney. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
Mark P Jones wrote:
Ben Franksen wrote:
TREX seems to be generally agreed to be too complicated to implement and
explain.
What evidence do you have for this?
Not much, I have to admit that. It basically seems to be SPJ's opinion, as
he writes in his proposal that he never got around to implementing [TREX]
in GHC. Why not? Mainly because the implementation cost turned out to be
relatively high and further claims his new proposal is considerably
simpler to implement, and [...] it is rather simpler to explain.
I also had the impression from earlier discussions that there are few people
who support the TREX idea. I could be completely wrong, though.
Speaking as somebody who
implemented Trex for Hugs (and who also witnessed Ben Gaster
build an independent implementation), I'd have to disagree
about the first part of this. As I recall, the implementation
was reasonably straightforward, and wasn't any more complicated
than other common type system extensions that I've worked on.
I'm also not sure why you think it is complicated to explain,
but I suppose that's even more subjective.
I did not say, nor did I want to imply, that this is my own opinion. I would
be extremely happy to have TREX in ghc and all the other implementations, I
just fear that it is not going to happen, at least not any time soon. In
fact I am almost completely un-biased as to which record system Haskell
gets, as long as DOES get one and preferably IN MY LIFETIME. I'd give up a
serious amount of expressive power if it brings us nearer to this goal.
Maybe this is just me being short-sighted and egotistical.
One of the most difficult things about the Trex implementation
was finding a syntax that meshed nicely with the rest of the
Haskell syntax. This is likely to be a problem for any record
system extension of Haskell---unless you're prepared to accept
a more unconventional syntax---because many of the symbols that
you might want to use ({, }, ., |, \, for example) have already
been adopted for other purposes. Ah, syntax!
Oh yes, that is indeed quite hard. One more reason for me to a prefer a
simpler system.
Cheers
Ben
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
My rationale for these criteria goes like this: efficient access is necessary if we want to compete with the much simpler record systems in mainstream languages. If records are not as light-weight (syntactically as well as wrt run-time performance) as 'normal' Haskell data types, then people will be reluctant to use them, especially in library APIs. Finally, having to wait for highly experimental additional extensions to be available, tried, and tested, would only help to indefinitely post- pone the introduction of a usable record system. I totally disagree. The great strength of Haskell is that, whenever important design decisions have been made, the primary consideration has not been practicality, but generality and mathematical foundation. When the Haskell committee first started work, many people said lazy evaluation was an academic curiosity: mathematically right, but far too inefficient for real programs. When Haskell adopted type classes, people said they were far too heavy a machinery to solve the relatively simple problems of equality, show and numbers. In each case the more general, abstract approach has shown enormous advantages in the long term. I'm sure the same will be true of associated types, which are a lot more complex than functional dependencies, but also more general, and more mathematical. My criteria for choosing a record system would be: continue with the philosophy which has served Haskell so well up to now. In other words, choose the system which is most general and most mathematically sound; get some kind of implementation working so that we can get some experience with using it; then worry about efficiency later. Barney. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
Dear Fellows, It is obvious that Haskell takes its strength from well implemented abstract concepts that made monadic programming natural and threads cheap. However I believe that some top decisions have been made in the wrong order, which is extremely important now to be aware of when new feature requests gather speed from the new breed of Haskell users - the real programmers. Haskell has jumped into untested water of type classes and had to compromise module system, contrary to ocaml where functor was raised to primary unit of computation. Thus Haskell waved off warranty form mature category theory for the sake of experimenting with fledging type theory. This encouraged somewhat artistic approach in designing the whole syntax so that orthogonality is hard to find and as a result choosing a particular programming style is more cumbersome than type annotations. In my humble opinion the priorities now should be: - moving secondary features from compiler out to optional libraries - redesigning type classes so that they could evolve with minimal effect on core design - revisiting SPJ opinion that functors are an (unpractical and expensive) Ferrari. I would rather paraphrase Henri Ford's every color for a car is good as long as it is black and say that every functional language is good as long as it has ML-style module system. I expressed this opinion here a year ago but as a mere mathematician haven't felt moral right to expect much attention. Recently however may opinion gained a surprising backup form guru Okasaki http://okasaki.blogspot.com/2008/02/ten-years-of-purely-functional-data.html Regards, -Andrzej Jaworski ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
Johannes Waldmann [EMAIL PROTECTED] has asked me to clarify my claims here. But I say: why not to ask Chris Okasaki himself? Manuel Chakravarty has recently published this: http://www.cse.unsw.edu.au/~chak/papers/WC07.html so he might take the question too. From my perspective there are too many language extension proposals like Generic Haskell addressing deriving extensions, Named Instances (http://www.cs.uni-bonn.de/~ralf/hw2001/4.pdf ) and many other I do not care to remember. To my mathematical mind Functor should be made a superclass of Monad before any such extensions were considered. This however costs almost a Ferrari :-) Exactly a Porsche: http://research.microsoft.com/~simonpj/papers/haskell-retrospective/HaskellRetrospective.pdf pages 62 - 64. Regards, -Andrzej Jaworski ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
Barney Hilken wrote: I totally disagree. The great strength of Haskell is that, whenever important design decisions have been made, the primary consideration has not been practicality, but generality and mathematical foundation. When the Haskell committee first started work, many people said lazy evaluation was an academic curiosity: mathematically right, but far too inefficient for real programs. When Haskell adopted type classes, people said they were far too heavy a machinery to solve the relatively simple problems of equality, show and numbers. In each case the more general, abstract approach has shown enormous advantages in the long term. I'm sure the same will be true of associated types, which are a lot more complex than functional dependencies, but also more general, and more mathematical. While I agree with your general argument, I wonder if you realize that functional dependencies have a strong, general, and elegant mathematical foundation that long predates their use in Haskell? If you want even a brief glimpse, there's s short article at http://en.wikipedia.org/wiki/Functional_dependencies that might give you some ideas. The mathematics of functional dependencies plays an important role in the theory of relational databases. I don't know what you consider as the mathematical foundations for associated types, nor do I know why you consider that to be either more general or more mathematical (whatever that means) but I hope you'll enjoy the material on functional dependencies. All the best, Mark ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: [Haskell] Re: Re: RE: Extensible records: Static duck typing
[Redirecting to haskell-cafe]
Ben Franksen wrote:
TREX seems to be generally agreed to be too complicated to implement and
explain.
What evidence do you have for this? Speaking as somebody who
implemented Trex for Hugs (and who also witnessed Ben Gaster
build an independent implementation), I'd have to disagree
about the first part of this. As I recall, the implementation
was reasonably straightforward, and wasn't any more complicated
than other common type system extensions that I've worked on.
I'm also not sure why you think it is complicated to explain,
but I suppose that's even more subjective.
One of the most difficult things about the Trex implementation
was finding a syntax that meshed nicely with the rest of the
Haskell syntax. This is likely to be a problem for any record
system extension of Haskell---unless you're prepared to accept
a more unconventional syntax---because many of the symbols that
you might want to use ({, }, ., |, \, for example) have already
been adopted for other purposes. Ah, syntax!
All the best,
Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
