On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
The most immediate and painful stumbling block in Haskell 98 is that numeric literals, like 3, turn into (Prelude.fromInt 3), where "Prelude.fromInt" really means "the fromInt from the standard Prelude" regardless of whether the standard Prelude is imported scope.
Some while ago I modified GHC to have an extra runtime flag to let you change this behaviour. The effect was that 3 turns into simply (fromInt 3), and the "fromInt" means "whatever fromInt is in scope". The same thing happens for - numeric patterns - n+k patterns (the subtraction is whatever is in scope) - negation (you get whatever "negate" is in scope, not Prelude.negate)
For the idea for numeric literals I had in mind (which is so radical I don't intend to seek much, if any help in implementing it other than general information), even this is insufficient. Some analysis of the value of the literal would need to be incorporated so that something like the following happens: literal "0" gets mapped to zero :: AdditiveMonoid t => t literal "1" gets mapped to one :: MultiplicativeMonoid t => t literal "5" gets mapped to (fromPositiveInteger 5) literal "-9" gets mapped to (fromNonZeroInteger -9) literal "5.0" gets mapped to (fromPositiveReal 5.0) literal "-2.0" gets mapped to (fromNonZeroReal -2.0) literal "0.0" gets mapped to (fromReal 0.0) etc. A single fromInteger or fromIntegral won't suffice here. The motivation behind this is so that some fairly typical mathematical objects (multiplicative monoid of nonzero integers, etc.) can be directly represented by numerical literals (and primitive types). I don't for a minute think this is suitable for general use, but I regard it as an interesting (to me) experiment. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
(Of course, this is not Haskell 98 behaviour.) I think I managed to forget to tell anyone of this flag. And to my surprise I can't find it any more! But several changes I made to make it easy are still there, so I'll reinstate it shortly. That should make it easy to define a new numeric class structure.
It certainly can't hurt; even if the code doesn't help directly with my dastardly plans, examining how the handling of overloaded literals differs will help me understand what's going on. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
So much for numerics. It's much less obvious what to do about booleans. Of course, you can always define your own Bool type. But we're going to have to change the type that if-then-else uses, and presumably guards too. Take if-then-else. Currently it desugars to case e of True -> then-expr False -> else-expr but your new boolean might not have two constructors. So maybe we should simply assume a function if :: Bool -> a -> a -> a and use that for both if-then-else and guards.... I wonder what else?
I had in mind that there might be a class of suitable logical values corresponding to the set of all types suitable for use as such. As far as I know, the only real restriction on subobject classifiers for logical values is that it be a pointed set where the point represents truth. Even if it's not the most general condition, it's unlikely much can be done computationally without that much. So since we must be able to compare logical values to see if they're that distinguished truth value: \begin{pseudocode} class Eq lv => LogicalValue lv where definitelyTrue :: lv \end{pseudocode}
From here, ifThenElse might be something like:
\begin{morepseudocode} ifThenElse :: LogicalValue lv => lv -> a -> a -> a ifThenElse isTrue thenValue elseValue = case isTrue == definitelyTrue of BooleanTrue -> thenValue _ -> elseValue \end{morepseudocode} or something on that order. The if/then/else syntax is really just a combinator like this with a mixfix syntax, and case is the primitive, so quite a bit of flexibility is possible given either some "hook" the mixfix operator will use or perhaps even means for defining arbitrary mixfix operators. (Of course, a hook is far easier.) The gains from something like this are questionable, but it's not about gaining anything for certain, is it? Handling weird logics could be fun. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote: [interesting example using otherwise in a pattern guard elided]
And we'll get warnings from the pattern-match compiler. So perhaps we should guarantee that (if otherwise e1 e2) = e1.
I'm with you on this, things would probably be too weird otherwise. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
You may say that's obvious, but the point is that we have to specify what can be assumed about an alien Prelude.
There is probably a certain amount of generality that would be desirable to handle, say, Dylan Thurston's prelude vs. the standard prelude. I'm willing to accept compiler hacking as part of ideas as radical as mine. Some reasonable assumptions: (1) lists are largely untouchable (2) numeric monotypes present in the std. prelude will also be present (3) tuples probably won't change (4) I/O libs will probably not be toyed with much (monads are good!) (5) logical values will either be a monotype or a pointed set class (may be too much to support more than a monotype) (6) relations (==), (<), etc. will get instances on primitive monotypes (7) Read and Show probably won't change much (8) Aside from perhaps Arrows, monads probably won't change much (Arrows should be able to provide monad compatibility) (9) probably no one will try to alter application syntax to operate on things like instances of class Applicable (10) the vast majority of the prelude changes desirable to support will have to do with the numeric hierarchy These are perhaps not a terribly useful set of assumptions. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
Matters get even more tricky if you want to define your own lists. There's quite a lot of built-in syntax for lists, and type checking that goes with it. Last time I thought about it, it made my head hurt. Tuples are even worse, because they constitute an infinite family.
The only ideas I have about lists are maybe to reinstate monad comprehensions. As far as tuples go, perhaps a derived or automagically defined Functor (yes, I know it isn't derivable now) instance and other useful instances (e.g. AdditiveMonoid, PointedSet, other instances where distinguished elements etc. cannot be written for the infinite number of instances required) would have interesting consequences if enough were cooked up to bootstrap tuples in a manner polymorphic in the dimension (fillTuple :: Tuple t => (Natural -> a) -> t a ?, existential tuples?) Without polytypism or some other mechanism for defining instances on these infinite families of types, achieving the same effect(s) would be difficult outside of doing it magically in the compiler. Neither looks easy to pull off in any case, so I'm wary of these ideas. On Wed, Feb 14, 2001 at 02:19:39PM -0800, Simon Peyton-Jones wrote:
The bottom line is this. a) It's desirable to be able to substitute a new prelude b) It's not obvious exactly what that should mean c) And it may not be straightforward to implement
It's always hard to know how to deploy finite design-and-implementation resources. Is this stuff important to a lot of people? If you guys can come up with a precise specification for (b), I'll think hard about how hard (c) really is.
I think Dylan Thurston's proposal is probably the best starting point for something that should really get support. If other alternatives in the same vein start going around, I'd think supporting them would also be good, but much of what I have in mind is probably beyond reasonable expectations, and will probably not get broadly used. Cheers, Bill