- Haskell-Cafe - Haskell.org

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

09 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

RE: GHC Core output
by Andrew Tolmach 08 Feb '01

08 Feb '01

Timothy Docker [mailto:timd@macquarie.com.au] writes: > > > 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? > Not at all. "Core" is an intermediate language used internally by the GHC compiler. It does indeed resemble a reduced Haskell (but with explicit higher-order polymorphic types) and GHC translates full Haskell 98 into it. Currently Core has no rigorously defined external representation, although by setting certain compiler flags, one can get a (rather ad-hoc) textual representation to be printed at various points in the compilation process. (This is usually done to help debug the compiler). What we hope to do is: - provide a formal definition of Core's external syntax; - give a precise definition of its semantics (both static and dynamic); - modify GHC to produce external Core files, if so requested, at one or more useful points in the compilation sequence -- e.g., just before optimization, or just after. - modify GHC to accept external Core files in place of Haskell source files, again at one or more useful points. The first three facilities will let one couple GHC's front-end (parser, type-checker, etc.), and optionally its optimizer, with new back-end tools. Adding the last facility will let one implement new Core-to-Core transformations in an external tool and integrate them into GHC. It will also allow new front-ends to generate Core that can be fed into GHC's optimizer or back end; however, because there are many (undocumented) idiosynracies in the way GHC produces Core from source Haskell, it will be hard for an external tool to produce Core that can be integrated with GHC-produced core (e.g., for the Prelude), and we don't aim to support this.

2 1

RE: Revamping the numeric classes
by Peter Douglass 08 Feb '01

08 Feb '01

Marcin Kowalczyk wrote: > Wed, 7 Feb 2001 16:17:38 -0500, Peter Douglass > <peterd(a)availant.com> pisze: > > > What I have in mind is to remove division by zero as an untypable > > expression. The idea is to require div, /, mod to take > NonZeroNumeric > > values in their second argument. NonZeroNumeric values > could be created by > > functions of type: > > Number a => a -> Maybe NonZeroNumeric > > or something similar. > > IMHO it would be impractical. > The first part of my question (not contained in your reply) is whether it is feasible to disable a developer's access to the "unsafe" numerical operations. Whether or not an individual developer chooses to do so is another matter. > Often I know that the value is non-zero, but it is not > statically determined, If you "know" the value is non-zero before run-time, then that is statically determined. Otherwise, you don't "know" that. > so it would just require uglification by > doing that conversion and then coercing Maybe NonZeroNumeric to > NonZeroNumeric. Ugliness is in the eye of the beholder I suppose. For some applications, every division should be preceded by an explicit test for zero, or the denominator must be "known" to be non-zero by the way in which it was created. Forcing a developer to extract a NonZeroNumeric value from a Maybe NonZeroNumeric value seems equivalent to me. > It's bottom anyway when the value is 0, but bottom > would come from Maybe coercion instead of from quot, so it only gives > a worse error message. > It is possible that the developer writes a function which returns a nonZeroNumeric value which actually has a value of zero. However, the value of requiring division to have a nonZeroNumeric denominator is to catch at compile time the "error" of failing to scrutinize (correctly or incorrectly) for zero. For most commercial software, the quality of run-time error messages is far less important than their absence. > It's so easy to define partial functions that it would not buy much > for making it explicit outside quot. > > Haskell does not have subtypes so a coercion from NonZeroNumeric to > plain Numbers would have to be explicit as well, even if logically > it's just an injection. If one is aiming to write code which cannot fail at run-time, then extra work must be done anyway. The only question is whether the language will support such a discipline. > Everybody assumes that quot has a symmetric > type as in all other languages, but in your proposal quot's arguments > come from completely disjoint worlds. If it is optional but not required that a developer may disable unsafe division, then developers who expect arithmetic to work in the usual way will not be disappointed. > Moreover, 1/0 is defined on IEEE Doubles (e.g. in ghc): infinity. This solution doesn't always help with code safety. Thanks for the response. --PeterD

2 1

Please help me
by FAIZAN RAZA 08 Feb '01

08 Feb '01

Hello Please help me to solve this questions Question Cartesian Product of three sets, written as X x Y x Z is defined as the set of all ordered triples such that the first element is a member of X, the second is member of Y, and the thrid member of set Z. write a Haskell function cartesianProduct which when given three lists (to represent three sets) of integers returns a list of lists of ordered triples. For examples, cartesianProduct [1,3][2,4][5,6] returns [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] Please send me reply as soon as possible Ok I wish you all the best of luck

1 0

RE: Please help me
by Chris Angus 08 Feb '01

08 Feb '01

Faizan, A clue is to use list comprehensions (which are very like ZF set notation) First think how you would define a cartesian product in set notation X x Y x Z = {(x,y,z) | ...} and then think how this is written in list comprehension notation Chris > -----Original Message----- > From: FAIZAN RAZA [mailto:k19990158@192.168.1.4] > Sent: 08 February 2001 13:49 > To: haskell-cafe(a)haskell.org > Subject: Please help me > > > Hello > > > Please help me to solve this questions > > > Question > > Cartesian Product of three sets, written as X x Y x Z is > defined as the set > of all ordered triples such that the first element is a > member of X, the > second is member of Y, and the thrid member of set Z. write a Haskell > function cartesianProduct which when given three lists (to > represent three > sets) of integers returns a list of lists of ordered triples. > > For examples, cartesianProduct [1,3][2,4][5,6] returns > [[1,2,5],[1,2,6],[1,4,5],[1,4,6],[3,2,5],[3,2,6],[3,4,5],[3,4,6]] > > > > Please send me reply as soon as possible > > Ok > > I wish you all the best of luck > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0