- Haskell-Cafe - Haskell.org

Re: GHCi, Hugs (was: Mixture ...)
by Ketil Malde 11 Dec '00

11 Dec '00

Koen Claessen <koen(a)cs.chalmers.se> writes: [Dead/dying compilers/interpreter] > I know of nobody who is starting to implement a Haskell > compiler from scratch. What do people think: is this > a worrying situation? Only if the remaining tools are insufficient, IMHO. It is questionable whether the Haskell community is large enough to support the development and maintenance of three compilers and two interpreters. Popular languages like Python and Perl have far fewer implementations, and even C and C++ only really have GCC in the free software world. It's good to have multiple tools, but at least for me, I can't seem to get around to try out tools for the sake of doing it, so I'm stuck on GHC, since it was the first I ran across, and it does an adequate (actually great, but adequate is sufficient) job of it. It'd be good if left-behind tools were using a BSD(-like) licence, in the event that anybody - commercial or otherwise - who wanted to pick them up again, were free to do so. -kzm -- I'm I haven't seen further, it is by standing in the footprints of giants

1 0

RE: Rank-2 polymorphism & type inference
by Simon Peyton-Jones 09 Dec '00

09 Dec '00

| < p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) | < q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) | < | System CT accepts both. No type signature is required. | | The types inferred for p and q are, resp.: | | Forall a,b. [a] -> (b -> Bool, [a]) and | Forall a,b. [a] -> ([a], b -> Bool) That's not the type we wanted, though. We wanted Forall a. [a] -> (Forall b. b->Bool, [a]) and similarly the other one. That's the reason for the type signature on f, which is short for (forall c. c->Bool). If you leave out the type signature then all Haskell compilers are happy. (Of course, this isn't a very useful example, but it's the smallest one that shows up the problem.) Simon

3 3

Announce: Pan release 2000-12-06
by Conal Elliott 08 Dec '00

08 Dec '00

There is a new release of Pan, a Haskell-embedded language and compiler for image synthesis, at http://research.microsoft.com/~conal/Pan I've also updated the Pan gallery with many new images for your enjoyment. The main features of this release, relative to 2000-10-04 are + Anti-aliasing for much smoother-looking images! + Render larger than the view. + ActiveX control for web pages or PowerPoint. + A recently given interactive presentation. Enjoy. - Conal ---- General description --- Pan is an experimental embedded language and compiler for image synthesis and manipulation, based on functional programming. You can get the compiler and do some Haskell programming do make your own effects, or get some of the precompiled effects and twiddle parameters to your heart's content. It's fun! The Pan compiler turns descriptions of images and image effects into efficient machine code for use with the Pan viewer program, web-page embedding (viewable with Internet Explorer 5.5 or later), or as a PhotoShop plug-in. All have automatically generated GUIs for control of the image synthesis/manipulation parameters with real-time redisplay. In the Pan viewer case the parameter settings may be saved into a small file for use later or sharing with others. See the Pan home page at http://research.microsoft.com/~conal/Pan, where you'll find a gallery of sample images and animations, papers on the language and implementation, instructions for use, and the binary and source releases. For now, Pan-generated effects run only on Windows. We welcome help in porting to other platforms. Also, the compiler assumes you have the Microsoft Visual C++, though we think it wouldn't be very hard to support other compilers and again we welcome help. Please let us know what you do with Pan, both trouble you run into and examples you construct with it (conal(a)microsoft.com)

1 0

RE: GHCi, Hugs (was: Mixture ...)
by Simon Peyton-Jones 08 Dec '00

08 Dec '00

| This puzzles me a bit. From talking with people at the | Haskell Workshop, I understood that GHCi would only be an | interactive compiler. | | The disadvantage with that is that compilation time might be | very long. But it was said that that is the price we pay. | | The only advantage I can see with interpreted code is the | fact that it can be compiled (or "processed") much faster. | Will GHCi reach speeds up to Hugs level? It'll definitely be mixed compiled/interpreted. No, compiling won't be nearly as fast as Hugs, but it will, we earnestly hope be "fast enough". Execution should be faster than Hugs; apart from anything else you'll get compiled libraries. | One bad thing with Hugs is that, for large systems, the | loading/processing time gets longer, and, worse, is repeated | every time one loads the system. This is especially bad when | using "runhugs". Hopefully GHCi will work better in that | case! Yes, a lot better. The idea is only to recompile things that have changed. | Another thing that worries me is that Hugs will die. Not | only because I like Hugs a lot, but also that it is yet | another Haskell system that is dying. I think that is a very reasonable concern. I certainly want to see Hugs alive and kicking. Simon

1 0

HaXml question
by Michael Zawrotny 08 Dec '00

08 Dec '00

This question is probably a bit low-brow compared to the normal discussions of type systems, rank-2 polymorphism... Anyway, here goes nothing. I'm working on getting up to speed on haskell in general and HaXml in particular. I read through the ICFP paper that came with the distribution, but it was a bit dense for a beginner. Is there anything out there that is more oriented towards people who are less fluent in haskell? I think that my problem may be a lack of understanding of the whole idea of what combinators are and how they work. What I would like to do is something like the Xtract tool that comes with HaXml, but to select an element based on the path criteria specified (as Xtract already does), but that also satisfies an arbitrary predicate function that I would specify (e.g. a function that normalizes case and then tests for equality, regexp match, etc.). If anybody can help out on either front, I would greatly appreciate it. Thanks, Mike

1 0

Re: Mixture of Integer and Float arithmetic without "fromIntegral"?
by Christian Lescher 07 Dec '00

07 Dec '00

> OK, OK, I've just added -fno-monomorphism-restriction to GHC. Great! Will there also be a similar option for Stg Hugs? Christian

1 0

RE: Mixture of Integer and Float arithmetic without "fromIntegral "?
by Simon Peyton-Jones 07 Dec '00

07 Dec '00

OK, OK, I've just added -fno-monomorphism-restriction to GHC. Simon | -----Original Message----- | From: Malcolm Wallace [mailto:Malcolm.Wallace@cs.york.ac.uk] | Sent: 07 December 2000 10:28 | To: haskell-cafe(a)haskell.org | Subject: Re: Mixture of Integer and Float arithmetic without | "fromIntegral"? | | | > > module Defs where | > > | > > n = 3 | > > x = 12.3 | > > | > > test = ceiling (x / n) | > | > There are people (including me) who think that the monomorphism | > restriction rule, which makes the above definitions without type | > signatures monomorphic and thus defaulted to concrete types, should | > be removed. | | If you want to experiment with an implementation that do not enforce | the monomorphism restriction, try nhc98. It happily infers the types | | n :: Num a => a | x :: Fractional a => a | | for the toplevel definitions shown. I don't think anyone has ever | complained about this feature. | | Regards, | Malcolm | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe |

1 0

Mixture of Integer and Float arithmetic without "fromIntegral"?
by Christian Lescher 07 Dec '00

07 Dec '00

When defining expressions with arithmetic operations on a mixture of Integers and Floats (except literals), an explicit conversion by "fromIntegral" for the Integers is necessary, for example: ceiling (fromIntegral n / x) Is it possible to do the "fromInteger" conversion automatically? What's the best way to do it? (overloading of operators, etc.?) Christian

4 6

RE: Rank-2 polymorphism & type inference
by Carlos Camarao de Figueiredo 06 Dec '00

06 Dec '00

Hello. < class C t where op :: t -> Bool < instance C [t] where op x = True < < p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) < q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) < <The definitions of p and q differ only in the order of the components in <the pair on their right-hand sides. And yet: < < ghc and "Typing Haskell in Haskell" reject p, but accept q; < Hugs rejects q, but accepts p; < hbc rejects both p and q; < nhc98 ... (Malcolm, can you fill in the blank for us!). System CT accepts both. No type signature is required. The types inferred for p and q are, resp.: Forall a,b. [a] -> (b -> Bool, [a]) and Forall a,b. [a] -> ([a], b -> Bool) You can run the attached "encoded" program (in which 'op' is overloaded, instead of having its type annotated in a type class) in CTinH (http://www.dcc.ufmg.br/~camarao/CT/CTinH.tar.gz) Type inference in system CT is explained in a paper available at http://www.dcc.ufmg.br/~camarao/CT/CT.ps.gz (see also homepage at http://www.dcc.ufmg.br/~camarao/CT) Carlos

1 0

RE: Rank-2 polymorphism & type inference
by Mark P Jones 06 Dec '00

06 Dec '00

Johan Nordlander and I have been looking at these interesting examples, and would like to offer another entertaining variation to the collection: class C t where op :: t -> Bool instance C [t] where op x = True p y = (let f :: c -> Bool; f x = op (y >> return x) in f, y ++ []) q y = (y ++ [], let f :: c -> Bool; f x = op (y >> return x) in f) The definitions of p and q differ only in the order of the components in the pair on their right-hand sides. And yet: ghc and "Typing Haskell in Haskell" reject p, but accept q; Hugs rejects q, but accepts p; hbc rejects both p and q; nhc98 ... (Malcolm, can you fill in the blank for us!). The type signature for f forces context reduction to take place, and the results of this depend on whether or not the type of y is known, which in turn depends on which component of the pair the type checker analyzes first. I'm sure we will all continue to ponder this for some time to come ... All the best, Mark & Johan

2 1