- Haskell-Cafe - Haskell.org

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

14 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 13 Feb '01

13 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 13 Feb '01

13 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

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

11 Feb '01

Brian Boutel <brian(a)boutel.co.nz> writes: >> 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. > There is nothing trivial or ugly about a definition that reflects > reality and bottoms only where equality is undefined. I think there is. If I design a class and derive it from Num with (==) is bottom, I am allowed to apply to it functions requiring a Num argument, but I have no guarantee it will work. The implementor of that function can change its internals (to use (==)), and suddenly my previously working program is non-terminating. If I defined (==) to give a run time error, it'd be a bit better, but I'd much prefer the compiler to tell me about this in advance. > Of course, if you do not need to apply equality to your "numeric" type > then having to define it is a waste of time, but consider this: It's not about "needing to apply", but about finding a reasonable definition. > - Having a class hierarchy at all (or making any design decision) > implies compromise. I think the argument is that we should move Eq and Show *out* of the Num hierarchy. Less hierarchy - less compromise. > - The current hierarchy (and its predecessors) represent a reasonable > compromise that meets most needs. Obviously a lot of people seem to think we could find compromises that are more reasonable. > - Users have a choice: either work within the class hierarchy and > accept the pain of having to define things you don't need in order > to get the things that come for free, Isn't it a good idea to reduce the amount of pain? > or omit the instance declarations and work outside the hierarchy. In > that case you will not be able to use the overloaded operator > symbols of the class, but that is just a matter of concrete syntax, > and ultimately unimportant. I don't think syntax is unimportant. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

5 10

Mondrian question
by Bill Halchin 10 Feb '01

10 Feb '01

Hello, Is this the right place to ask Mondrian questions? I will assume so. Is Mondrian only meant to work with .NET?? If so, what good is it as an Internet scripting language? I.e. what good is it as a language if it only runs in Microsoft's .NET environment?? I tried to download but I found I would have to have Win2000 installed. I want to run on Linux. Regards, Bill Halchin _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

Re: Revamping the numeric classes
by Ketil Malde 10 Feb '01

10 Feb '01

Dylan Thurston <dpt(a)math.harvard.edu> writes: > On Wed, Feb 07, 2001 at 01:57:41PM -0500, Dylan Thurston wrote: > > ... One point that has not been made: given a class > > setup like > > <deleted> > > then naive users can continue to use (Num a) in contexts, and the same > > programs will continue to work. > I take that back. Instance declarations would change, so this isn't > a very conservative change. Would it be a terribly grave change to the language to allow leaf class instance declarations to include the necessary definitions for dependent classes? E.g. class foo a where f :: ... class (foo a) => bar a where b :: ... instance bar T where f = ... b = ... -kzm -- If I haven't seen further, it is by standing in the footprints of giants

4 5