February 2001 - Haskell-Cafe

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

RE: Haskell Implemetors Meeting
by Simon Peyton-Jones 10 Feb '01

10 Feb '01

GHC transforms Haskell into "Core", which is roughly the second-order lambda calculus, augmented with let(rec), case, and constructors. This is an a small explicitly-typed intermediate language, in contrast to Haskell which is a very large, implicitly typed language. Getting from Haskell to Core is a lot of work, and it might be useful to be able to re-use that work. Andrew's proposal (which he'll post to the Haskell list) will define exactly what "Core" is. Simon | -----Original Message----- | From: Timothy Docker [mailto:timd@macquarie.com.au] | Sent: 05 February 2001 22:16 | To: haskell-cafe(a)haskell.org | Subject: Haskell Implemetors Meeting | | | | > We agreed that it would be a Jolly Good Thing if GHC could | > be persuaded to produce GHC-independent Core output, | > ready to feed into some other compiler. For example, | > Karl-Filip might be able to use it. | > ANDREW will write a specification, and implement it. | | A quick question. What is meant by "Core output"? Subsequent posts | seem to suggest this is some "reduced Haskell", in which full Haskell | 98 can be expressed. Am I completely off beam here? | | Tim Docker | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

2 1

Re: 'Convertible' class?
by Dylan Thurston 09 Feb '01

09 Feb '01

You make some good arguments. Thanks. Let me ask about a few of them. On Thu, Feb 08, 2001 at 04:06:24AM +0000, Marcin 'Qrczak' Kowalczyk wrote: > Wed, 7 Feb 2001 15:43:59 -0500, Dylan Thurston <dpt(a)math.harvard.edu> pisze: > > > class Convertible a b where > > convert :: a -> b > > > > So, e.g., fromInteger and fromRational could be replaced with > > convert. (But if you did the same thing with toInteger and toRational > > as well, you run into problems of overlapping instances. > > ... > And convert cannot be a substitute for fromIntegral/realToFrac, > because it needs a definition for every pair of types. Right. Those could still be defined as appropriately typed versions of 'convert . convert'. > You can put Num a in some instance's context, but you can't > put Convertible Integer a. It's because instance contexts must > constrain only type variables, which ensures that context reduction > terminates (but is sometimes overly restrictive). There is ghc's > flag -fallow-undecidable-instances which relaxes this restriction, > at the cost of undecidability. Ah! Thanks for reminding me; I've been using Hugs, which allows these instances. Is there no way to relax this restriction while maintaining undecidability? Best, Dylan Thurston

1 1