- Haskell-Cafe - Haskell.org

RE: Primitive types and Prelude shenanigans
by Simon Marlow 15 Feb '01

15 Feb '01

> (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! It's lumped in with -fno-implicit-prelude, but the extra functionality isn't supported in 4.08.2 (but hopefully will be in 5.00). Cheers, Simon

1 0

RE: Typing units correctly
by Andrew Kennedy 14 Feb '01

14 Feb '01

To be frank, the poster that you cite doesn't know what he's talking about. He makes two elementary mistakes: (a) attempting to encode dimension/unit checking in an existing type system; (b) not appreciating the need for parametric polymorphism over dimensions/units. As others have pointed out, (a) doesn't work because the algebra of units of measure is not free - units form an Abelian group (if integer exponents are used) or a vector space over the rationals (if rational exponents are used) and so it's not possible to do unit-checking by equality-on-syntax or unit-inference by ordinary syntactic unification. Furthermore, parametric polymorphism is essential for code reuse - one can't even write a generic squaring function (say) without it. Best to ignore the poster and instead read the papers that contributors to this thread have cited :-) To turn to the original question, I did once give a moment's thought to the combination of type classes and types for units-of-measure. I don't think there's any particular problem: units (or dimensions) are a new "sort" or "kind", just as "row" is in various proposals for record polymorphism in Haskell. As long as this is tracked through the type system, everything should work out fine. Of course, I may have missed something, in which case I'd be very interested to know about it. - Andrew Kennedy. > -----Original Message----- > From: andrew(a)andrewcooke.free-online.co.uk > [mailto:andrew@andrewcooke.free-online.co.uk] > Sent: Wednesday, February 14, 2001 5:02 PM > To: haskell-cafe(a)haskell.org > Subject: Re: Typing units correctly > > > > Hi, > > I don't know if this is useful, but in response to a link to that > article that I posted on Lambda, someone posted a link arguing that > such an approach (at least in Ada) was impractical. To be honest, I > don't find it very convincing, but I haven't been following this > discussion in detail. It might raise some problems you have not > considered. > > Anyway, if you are interested, it's all at > http://lambda.weblogs.com/discuss/msgReader$818 > > Apologies if it's irrelevant or you've already seen it, > Andrew > > On Mon, Feb 12, 2001 at 01:51:54PM -0500, Dylan Thurston wrote: > [...] > > The papers I could find (e.g., > > http://citeseer.nj.nec.com/kennedy94dimension.html, > "Dimension Types") > > mention extensions to ML. I wonder if it is possible to work within > > the Haskell type system, which is richer than ML's type system. > [...] > > -- > http://www.andrewcooke.free-online.co.uk/index.html >

2 1

A sample revised prelude for numeric classes
by Dylan Thurston 14 Feb '01

14 Feb '01

I've started writing up a more concrete proposal for what I'd like the Prelude to look like in terms of numeric classes. Please find it attached below. It's still a draft and rather incomplete, but please let me know any comments, questions, or suggestions. Best, Dylan Thurston

10 24

Primitive types and Prelude shenanigans
by William Lee Irwin III 13 Feb '01

13 Feb '01

It seems to me that some additional primitive types would be useful, most of all a natural number type corresponding to an arbitrary- precision unsigned integer. Apparently Integer is defined in terms of something else in the GHC Prelude, what else might be needed to define it? Some of my other natural thoughts along these lines are positive reals and rationals, and nonzero integers. Rationals I have an idea that they might be similar to natural numbers and nonzero integers, though the nonzero and positive reals pose some nasty problems (try underflow). Would such machinations be useful to anyone else? Further down this line, I've gone off and toyed with Bool, and discovered GHC doesn't like it much. Is there a particular place within GHC I should look to see how the primitive Boolean type, and perhaps other types are handled? I'd also like to see where some of the magic behind the typing of various other built-in constructs happens, like list comprehensions, tuples, and derived classes. Cheers, Bill

2 3

Re: Revamping the numeric classes
by Dylan Thurston 12 Feb '01

12 Feb '01

Other people have been making great points for me. (I particularly liked the example of Dollars as a type with addition but not multiplication.) One point that has not been made: given a class setup like class Additive a where (+) :: a -> a -> a (-) :: a -> a -> a negate :: a -> a zero :: a class Multiplicative a where (*) :: a -> a -> a one :: a class (Additive a, Multiplicative a) => Num a where fromInteger :: Integer -> a then naive users can continue to use (Num a) in contexts, and the same programs will continue to work.[1] (A question in the above context is whether the literal '0' should be interpreted as 'fromInteger (0::Integer)' or as 'zero'. Opinions?) On Wed, Feb 07, 2001 at 06:27:02PM +1300, Brian Boutel wrote: > * Haskell equality is a defined operation, not a primitive, and may not > be decidable. It does not always define equivalence classes, because > a==a may be Bottom, so what's the problem? It would be a problem, > though, to have to explain to a beginner why they can't print the result > of a computation. Why doesn't your argument show that all types should by instances of Eq and Show? Why are numeric types special? Best, Dylan Thurston Footnotes: [1] Except for the lack of abs and signum, which should be in some other class. I have to think about their semantics before I can say where they belong.

9 30

RE: Revamping the numeric HUMAN ATTITUDE
by Simon Peyton-Jones 12 Feb '01

12 Feb '01

| I'm seeing a bit of this now, and the error messages GHC spits out | are hilarious! e.g. | | My brain just exploded. | I can't handle pattern bindings for | existentially-quantified constructors. | | and | | Couldn't match `Bool' against `Bool' | Expected type: Bool | Inferred type: Bool | The first of these is defensible, I think. It's not at all clear (to me anyway) what pattern bindings for existentially-quantified constructors should mean. The second is plain bogus. GHC should never give a message like that. Which version of the compiler are you using? If you can send a small example I'll try it on the latest compiler. Simon

1 0

Re: A sample revised prelude for numeric classes
by Ashley Yakeley 12 Feb '01

12 Feb '01

At 2001-02-11 14:42, Dylan Thurston wrote: >I've started writing up a more concrete proposal for what I'd like the >Prelude to look like in terms of numeric classes. Please find it >attached below. It's still a draft and rather incomplete, but please >let me know any comments, questions, or suggestions. Apologies if this has been discussed and I missed it. When it comes to writing a 'geek' prelude, what was wrong with the Basic Algebra Proposal found in <ftp://ftp.botik.ru/pub/local/Mechveliani/basAlgPropos/> ? Perhaps it could benefit from multi-parameter classes? -- Ashley Yakeley, Seattle WA

5 5

Re: A sample revised prelude for numeric classes
by Ashley Yakeley 12 Feb '01

12 Feb '01

At 2001-02-11 21:18, Tom Pledger wrote: >The main complication is that the type system needs to deal with >integer exponents of dimensions, if it's to do the job well. Very occasionally non-integer or 'fractal' exponents of dimensions are useful. For instance, geographic coastlines can be measured in km ^ n, where 1 <= n < 2. This doesn't stop the CIA world factbook listing all coastline lengths in straight kilometres, however. More unit weirdness occurs with logarithms. For instance, if y and x are distances, log (y/x) = log y - log x. Note that 'log x' is some number + log (metre). Strange, huh? Interestingly, in C++ you can parameterise types by values. For instance: -- // Mass, Length and Time template <long M,long L,long T> class Unit { public: double mValue; inline explicit Unit(double value) { mValue = value; } }; template <long M,long L,long T> Unit<M,L,T> operator + (Unit<M,L,T> a,Unit<M,L,T> b) { return Unit<M,L,T>(a.mValue + b.mValue); } template <long Ma,long La,long Ta,long Mb,long Lb,long Tb> Unit<Ma+Mb,La+Lb,Ta+Tb> operator * (Unit<Ma,La,Ta> a,Unit<Mb,Lb,Tb> b) { return Unit<Ma+Mb,La+Lb,Ta+Tb>(a.mValue * b.mValue); } // etc. int main() { Unit<0,1,0> oneMetre(1); Unit<0,1,0> twoMetres = oneMetre + oneMetre; Unit<0,2,0> oneSquareMetre = oneMetre * oneMetre; } -- Can you do this sort of thing in Haskell? -- Ashley Yakeley, Seattle WA

4 3

Re: A sample revised prelude for numeric classes
by Ketil Malde 12 Feb '01

12 Feb '01

qrczak(a)knm.org.pl (Marcin 'Qrczak' Kowalczyk) writes: >> Why do you stop at allowing addition on Dollars and not include >> multiplication by a scalar? > Perhaps because there is no good universal type for (*). > Sorry, it would have to have a different symbol. Is this ubiquitous enough that we should have a *standardized* different symbol? Any candidates? >> Having Units as types, with the idea of preventing adding Apples to >> Oranges, or Dollars to Roubles, is a venerable idea, but is not in >> widespread use in actual programming languages. Why not? > It does not scale to more general cases. (m/s) / (s) = (m/s^2), > so (/) would have to have the type (...) => a -> b -> c, which is not > generally usable because of ambiguities. Haskell's classes are not > powerful enough to define full algebra of units. While it may not be in the language, nothing's stopping you from - and some will probably encourage you to - implementing e.g. financial libraries with different data types for different currencies. Which I think is a better way to handle it, since when you want m to be divisible by s is rather application dependent. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

Show, Eq not necessary for Num [Was: Revamping the numeric classes]
by Patrik Jansson 11 Feb '01

11 Feb '01

{I'm diverting this discussion to haskell-cafe.} [I am not sure a more mathematically correct numeric class system is suitable for inclusion in the language specification of Haskell (a library would certainly be useful though). But this is not my topic in this letter.] On Wed, 7 Feb 2001, Brian Boutel wrote: > * Haskell equality is a defined operation, not a primitive, and may not > be decidable. It does not always define equivalence classes, because > a==a may be Bottom, so what's the problem? It would be a problem, > though, to have to explain to a beginner why they can't print the result > of a computation. The fact that equality can be trivially defined as bottom does not imply that it should be a superclass of Num, it only explains that there is an ugly way of working around the problem. Neither is the argument that the beginner should be able to print the result of a computation a good argument for having Show as a superclass. A Num class without Eq, Show as superclasses would only mean that the implementor is not _forced_ to implement Eq and Show for all Num instances. Certainly most instances of Num will still be in both Show and Eq, so that they can be printed and shown, and one can easily make sure that all Num instances a beginner encounters would be such. As far as I remember from the earlier discussion, the only really visible reason for Show, Eq to be superclasses of Num is that class contexts are simpler when (as is often the case) numeric operations, equality and show are used in some context. f :: Num a => a -> String -- currently f a = show (a+a==2*a) If Show, Eq, Num were uncoupled this would be f :: (Show a, Eq a, Num a) => a -> String But I think I could live with that. (In fact, I rather like it.) Another unfortunate result of having Show, Eq as superclasses to Num is that for those cases when "trivial" instances (of Eq and Show) are defined just to satisfy the current class systems, the users have no way of supplying their own instances. Due to the Haskell rules of always exporting instances we have that if the Num instance is visible, so are the useless Eq and Show instances. In the uncoupled case the users have the choice to define Eq and Show instances that make sense to them. A library designer could provide the Eq and Show instances in two separate modules to give the users maximum flexibility. /Patrik Jansson

9 12