February 2001 - Haskell-Cafe

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

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 02:04, Ashley Yakeley wrote: >That's easy. Just define 'product' as a function that finds the cartesian >product of any number of lists, and then once you've done that you can >apply it to make the special case of three items like this: > >cartesianProduct a b c = product [a,b,c] > >At least, that's how I would do it. eesh, 'product' is something else in the Prelude. Better call it 'cartprod' or something. -- Ashley Yakeley, Seattle WA

1 0

Re: Please help me
by Ashley Yakeley 08 Feb '01

08 Feb '01

At 2001-02-08 13:49, FAIZAN RAZA wrote: >write a Haskell >function cartesianProduct which when given three lists (to represent three >sets) of integers returns a list of lists of ordered triples. That's easy. Just define 'product' as a function that finds the cartesian product of any number of lists, and then once you've done that you can apply it to make the special case of three items like this: cartesianProduct a b c = product [a,b,c] At least, that's how I would do it. -- Ashley Yakeley, Seattle WA

1 0

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

07 Feb '01

I have some questions about how Haskell's numeric classes might be revamped. Is it possible in Haskell to circumscribe the availability of certain "unsafe" numeric operations such as div, /, mod? If this is not possible already, could perhaps a compiler flag "-noUnsafeDivide" could be added to make such a restriction? 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. Has this been tried and failed? I'm curious as to what problems there might be with such an approach. --PeterD

2 1

Re: Revamping the numeric classes
by andrew＠andrewcooke.free-online.co.uk 07 Feb '01

07 Feb '01

On Wed, Feb 07, 2001 at 11:47:11AM +0100, Ketil Malde wrote: > "Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: [...] > > the problem is that the --majority, I suppose?-- of mathematicians > > tend to overload operators. They use "*" for matrix-matrix > > multiplication as well as for matrix-vector multiplication etc. > Yes, obviously. On the other hand, I think you could get far by > defining (+) as an operator in a Group, (*) in a Ring, and so forth. As a complete newbie can I add a few points? They may be misguided, but they may also help identify what appears obvious only through use... - understanding the hierarchy of classes (ie constanly referring to Fig 5 in the report) takes a fair amount of effort. It would have been much clearer for me to have classes that simply listed the required super classes (as suggested in an earlier post). - even for me, no great mathematician, I found the forced inclusion of certain classes irritating (in my case - effectively implementing arithmetic on tuples - Enum made little sense and ordering is hacked in order to be total; why do I need to define either to overload "+"?) - what's the deal with fmap and map? > Another problem is that the mathematical constructs include properties > not easily encoded in Haskell, like commutativity, associativity, etc. > > > I don't think that it is acceptable for a language like Haskell > > to permit the user to overload predefined operators, like "*". Do you mean that the numeric classes should be dropped or are you talking about some other overloading procedure? Isn't one popular use of Haskell to define/extend it to support small domain-specific languages? In those cases, overloading operatores via the class mechanism is very useful - you can give the user concise, but stll understandable, syntax for the problem domain. I can see that overloading operators is not good in general purpose libraries, unless carefully controlled, but that doesn't mean it is always bad, or should always be strictly controlled. Maybe the programmer could decide what is appropriate, faced with a particular problem, rather than a language designer, from more general considerations? Balance, as ever, is the key :-) [...] > >From experience, I guess there are probably issues that haven't > crossed my mind. :-) This is certainly true in my case - I presumed there was some deep reason for the complex hierarchy that exists at the moment. It was a surprise to see it questioned here. Sorry if I've used the wrong terminology anywhere. Hope the above makes some sense. Andrew -- http://www.andrewcooke.free-online.co.uk/index.html ----- End forwarded message ----- -- http://www.andrewcooke.free-online.co.uk/index.html

2 1

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

07 Feb '01

"Ch. A. Herrmann" <herrmann(a)infosun.fmi.uni-passau.de> writes: > moved to haskell-cafe No, but *now* it is. (Does haskell@ strip Reply-To? Bad list! Bad!) > the problem is that the --majority, I suppose?-- of mathematicians > tend to overload operators. They use "*" for matrix-matrix > multiplication as well as for matrix-vector multiplication etc. Yes, obviously. On the other hand, I think you could get far by defining (+) as an operator in a Group, (*) in a Ring, and so forth. Another problem is that the mathematical constructs include properties not easily encoded in Haskell, like commutativity, associativity, etc. > I don't think that it is acceptable for a language like Haskell > to permit the user to overload predefined operators, like "*". Depends on your definition of overloading. Is there a difference between overloading and instantiating a class? :-) > A cheap solution could be to define a type MathObject and operators like > :*: MathObject -> MathObject -> MathObject > Then, the user can implement: > a :*: b = case (a,b) of > (Matrix x, Matrix y) -> foo > (Matrix x, Vector y) -> bar Yes. If it is useful to have a fine granularity of classes, you can imagine doing: class Multiplicative a b c where (*) :: a -> b -> c now I can do instance Multiplicative (Vector a) (Vector a) (Vector a) where x * y = ... but also scalar multiplication instance Multiplicative a (Vector a) (Vector a) where a * x = .... Also, I think I can define Group a to be Additive a a a => class Group a where -- inherits plus from "Additive" zero :: a instance Group Int where (+) = built_in_int_addition zero = 0::Int Long qualifier lists might be countered by having Classes -- Num, say -- that just serve to include other classes in reasonable collections. Funny mathematical names would - at least to some extent - be avoided by having simple names for the classes actually defining the operators, so that errors will warn you about missing "Multiplicative" rather than Field or Ring or what have you. >From experience, I guess there are probably issues that haven't crossed my mind. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

2 1

(no subject)
by Dylan Thurston 07 Feb '01

07 Feb '01

1 0