- Haskell-Cafe - Haskell.org

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

RE: GHC Core Language
by Andrew Tolmach 07 Feb '01

07 Feb '01

[moving to haskell-cafe] > From: matt hellige [mailto:matt@immute.net] > a quick question re: ghc's Core language... is it still very similar > to the abstract syntax given in, for example, santos' "compilation by > transformation..." (i think it was his dissertation?) and > elsewhere, or > has it changed significantly in the last couple of years? i only ask > because i know the language used in that paper is somewhat > different from > the Core language given in peyton jones and lester's > "implementing functional > languages" from 92, and includes type annotations and so on. > > m > The current Core language is still quite similar to what is described in Santos' work; see SL Peyton Jones and A Santos, "A transformation-based optimiser for Haskell," Science of Computer Programming 32(1-3), pp3-47, September 1998. http://research.microsoft.com/Users/simonpj/papers/comp-by-trans-scp.ps.gz But there have been some noticeable changes; for example, function arguments are no longer required to be atomic. A more recent version of Core is partially described (omitting types) in SL Peyton Jones & S Marlowe, "Secrets of the Glasgow Haskell Compiler Inliner," IDL'99. http://research.microsoft.com/Users/simonpj/papers/inline.ps.gz

1 0

Re: Revamping the numeric classes
by Ch. A. Herrmann 07 Feb '01

07 Feb '01

moved to haskell-cafe Ketil> E.g. way back, I wrote a simple differential equation solver. Ketil> Now, the same function *could* have been applied to vector Ketil> functions, except that I'd have to decide on how to implement Ketil> all the "Num" stuff that really didn't fit well. Ideally, a Ketil> nice class design would infer, or at least allow me to Ketil> specify, the mathematical constraints inherent in an Ketil> algorithm, and let my implementation work with any data Ketil> satisfying those constraints. 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. Therefore, a quick solution that implements groups, monoids, Abelian groups, rings, Euclidean rings, fields, etc. will not be sufficient. I don't think that it is acceptable for a language like Haskell to permit the user to overload predefined operators, like "*". 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 -- Christoph Herrmann E-mail: herrmann(a)fmi.uni-passau.de WWW: http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html

1 0

RE: binary files in haskell
by Simon Marlow 06 Feb '01

06 Feb '01

> > How about this slightly more general interface, which works > with the new > > FFI libraries, and is trivial to implement on top of the > primitives in > > GHC's IOExts: > > > > hPut :: Storable a => Handle -> a -> IO () > > hGet :: Storable a => Handle -> IO a > > What about endianess? In which format are Floats or even just Bools > stored? For a file which probably shall be read from > different machines > this is not clear at all. The behaviour is defined by the Storable instances for each type. The endianness for writing say an Int32 would be the same as the host architecture, for instance. If you want to work with just bytes, you can always just use hPut and hGet at type Word8. Overloading with Storable gives you more flexibility, since if you have a way to serialise an object in memory for passing to a foreign function, you also have a way to store it in binary format in a file (modulo problems with pointers, of course). In the long term, we'll want to be able to serialise more than just Storable objects (c.f. the other overloaded binary I/O libraries out there), and possibly make the output endian-independent - but after all there's no requirement that Haskell's Int has the same size on all implementations, so there's no guarantee that binary files written on one machine will be readable on another, unless they only use explicitly sized types or Integer. Perhaps these should be called hPutStorable and hGetStorable so as not to prematurely steal the best names. > I think John is right that there needs to be a primitive interface for > just writing bytes. You can then build anything more > complicated on top > (probably different high-level ones for different purposes). > > I just see one problem with John's proposal: the type Byte. It is > completely useless if you don't have operations that go with it; > bit-operations and conversions to and from Int. The FFI > already defines > such a type: Word8. So I suggest that the binary IO library > explicitely > reads and writes Word8's. yup, that's what I had in mind. Cheers, Simon

2 1

Re: binary files in haskell
by malcolm-haskell＠cs.york.ac.uk 06 Feb '01

06 Feb '01

John Meacham wrote: > I wrote up a proposal for a binary file IO mechanism to be added > as a 'blessed addendum' to the standard at best and as a commonly > implmented extension (in hslibs) at least.. I have looked at your proposal. If you would like it to be widely available, you will need to write an implementation of the library, or find someone who can write it for you. Type signatures are great as documentation, but they are not directly executable. :-) Regards, Malcolm

1 0

Haskell Implemetors Meeting
by Timothy Docker 05 Feb '01

05 Feb '01

> 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

1 0

Knight
by Christoph M. 04 Feb '01

04 Feb '01

Hi ! Yes, I meant the Knight's Tour problem. Could anybody post me a solve of this problem in haskell ? Thanks a lot, Christoph

2 1