- Haskell - Haskell.org

Re: [Haskell] comment on language shootout
by JP Bernardy 18 Jun '04

18 Jun '04

--- Gour <gour(a)mail.inet.hr> wrote: > Any comment from some experienced Haskell programmer > about the latest > language shootout published on: > > http://shootout.alioth.debian.org/index.php > regarding Haskell (ghc-6.2.1) score? I would have liked to re-implement some of the benchmarks, some of them should not be looked at by non-haskell programmers, that would give them an awfulidea of what the language looks like/how it should be used. I haven't found where to submit though. BTW, regex matching might be regarded as a bit biased toward ghc :) Cheers, JP. > > > __________________________________ > Do you Yahoo!? > Take Yahoo! Mail with you! Get it on your mobile > phone. > http://mobile.yahoo.com/maildemo > __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail

1 0

closure of coercions with classes
by Matthew Fluet 18 Jun '04

18 Jun '04

[Apologies for the slightly long setup. The guts of the question is: can one use the class system to code up the reflexive, transitive closure of a set of dynamic (but contextually implied) coercions? I'm coming to the conclusion that the answer is no, but I'm interested in a good explaination of why things don't work out.] Imagine an extension of the ST monad that gives nested scope [1]; that is, I add the following: blockST :: (forall s2. ST (s1, s2) a) -> ST s1 a liftST :: ST s1 a -> ST (s1, s2) a The first encapsulates the nested scope much as runST encapsulates the entire computation; the second imports computations from the outer scope to the inner scope. Now suppose I want to write a function that pairs the contents of two references into a new reference; furthermore, the function should be polymorphic in the scope of each of the input references, the output reference, and the final computation. That is, I'd like the type to be: pair :: STRef s1 a -> STRef s2 b -> ST s4 (STRef s3 (a, b)) The simplest definition clearly doesn't have enough polymorphism. If I write: pair v w = do a <- readSTRef v b <- readSTRef w newSTRef (v, w) then the function has the type: pair :: STRef s a -> STRef s b -> ST s (STRef s (a, b)) Now, there is no way to write pair with liftST terms that will result in sufficient polymorphism over scopes. For example, if I write: pair v w = do a <- readSTRef v b <- liftST (readSTRef w) liftST (liftST (newSTRef (v, w))) then the function has the type: pair :: STRef ((s1, s2), s3) a -> STRef (s1, s2) b -> ST (((s1, s2), s3), s4) (STRefr1 (a, b)) which isn't as general as I would like, as it imposes a particular order on the nested scopes. The only requirement is that scopes of the input refs and the output refs are nested inside the scope of the resulting computation. I can abstract the liftST applications and pass evidence that witnesses the correct scope nesting: pair :: (ST s1 a -> ST s4 a) -> (ST s2 a -> ST s4 b) -> (ST s3 (STRef s3 (a, b)) -> ST s4 (STRef s3 (a, b))) -> STRef s1 a -> STRef s2 b -> ST s4 (STRef s3 (a, b) pair lift1 lift2 lift3 v w = do a <- lift1 (readSTRef v) b <- lift2 (readSTRef w) lift3 (newSTRef (v, w)) Since evidence is really assembled from liftST terms, it is parametric in the return type. So, it make sense to give pair the more general type: pair :: (forall c. ST s1 c -> ST s4 c) -> (forall c. ST s2 c -> ST s4 c) -> (forall c. ST s3 c -> ST s3 c) -> STRef s1 a -> STRef s2 b -> ST s4 (STRef s3 (a, b)) Now, for the most part, it is obvious how to construct this evidence. My driving question is whether or not there is a way of moving it to the class system. That is, can some variation of the following be made to work: class AutoLiftST s1 s2 where autoLiftST :: ST s1 a -> ST s2 b instance AutoLiftST s1 (s1, s2) where autoLiftST = liftST pair :: (AutoLiftST s1 s4) -> (AutoLiftST s2 s4) -> (AutoLiftST s3 s4) -> STRef s1 a -> STRef s2 b -> ST s4 (STRef s3 (a, b)) pair v w = do a <- autoLiftST (readSTRef v) b <- autoLiftST (readSTRef w) autoLiftST (newSTRef (v, w)) where I could then write: test :: ST s0 (STRef s0 (Integer, Integer)) test = blockST (do v <- newSTRef 1 blockST (do w <- newSTRef 2 blockST (gpair v w))) and have the appropriate instances be derived/inferred. Note that this is basically boils down to choosing the appropriate elements from the reflexive, transitive closure of the liftST's implied by each blockST. Clearly, blindly throwing in reflexive and transitive instances of AutoLiftST leads to overlapping and undecidable instances. (OTOH, if one anticipates that blockST and liftST are operationally identity functions, then all of the instances of autoLiftST correspond to identity functions, and it doesn't matter which instance is chosen.) I've experimented with a few different attempts, but in the best case succeeded only in exhausting stack space while searching for satisfying instances. My gut feeling is that the search space is just too unconstrained; I'd be just as happy to hear a good explaination of exactly _what_ aspect of the problem makes it difficult, if not impossible. Finally, note that the type of liftST and the tuple type are just one way of connecting the inner and outer scopes. I'd actually prefer to dispense with liftST and make the evidence part of blockST. In explicit evidence style: blockST :: (forall s2. (forall b. ST s1 b -> ST s2 b) -> ST s2 a) -> ST s1 a while in the implicit evidence style: blockST :: (forall s2. AutoLiftST s1 s2 => ST s2 a) -> ST s1 a Now the atomic coercions are all implicitly introduced in the body of a blockST by the AutoLiftST s1 s2 class constraint. This leads to the interesting situation where _all_ AutoLiftST instances are of variables. On the other hand, it seem clear that within a nesting of blockST, we accumulate the constraints (AutoLiftST s1 s2, AutoLiftST s2 s3, ..., AutoLiftST sn-1 sn) and it is "obvious" how to compose AutoLiftST si sj for i <= j. [1] John Launchbury and Amr Sabry. Monadic State: Axiomatization and Type Safety. ICFP'97.

2 1

comment on language shootout
by Gour 18 Jun '04

18 Jun '04

Any comment from some experienced Haskell programmer about the latest language shootout published on: http://shootout.alioth.debian.org/index.php regarding Haskell (ghc-6.2.1) score? Sincerely, Gour -- Gour | gour(a)mail.inet.hr Registered Linux User | #278493 GPG Public Key | 8C44EDCD

4 3

Convert Expressions to....
by Scott West 18 Jun '04

18 Jun '04

Hello all, I was just wondering if anyone had any ideas on how I could create an expression type to produce strings of some sort. So say I have something like (Exp a) `oper` (Exp b), is there a way I could perform some operation on each left/right expression, and then on the whole expression? What I'm ultimately seeking is a way to turn expressions into mathML, or some similar sort of formatting. Thanks for any help you can provide! Regards, Scott

1 0

RE: [Haskell] comment on language shootout
by Simon Marlow 18 Jun '04

18 Jun '04

On 18 June 2004 13:50, Gour wrote: > Any comment from some experienced Haskell programmer about the latest > language shootout published on: > > http://shootout.alioth.debian.org/index.php > > regarding Haskell (ghc-6.2.1) score? I submitted improved versions for some of the benchmarks. My feeling is that the #1 reason for ghc being slower is usually Strings. To really do better we need a good PackedString library combined with PackedString I/O. I believe the current PackedString library is underperforming quite a bit - it's on my queue of things to look into. Cheers, Simon

1 0

Space behaviour & hyperseq
by Arjan van IJzendoorn 18 Jun '04

18 Jun '04

Hello Haskellers, I supervise a student who uses Haskell for simulating neural nets. A lot of computation goes on there and the program cannot handle as many iterations as we would like. We have improved performance by a factor of more than ten by putting strictness annotations in all data types. But the problem is that there are lists within these data structures and they are not strict. By using a trick I have now found that making the whole program state strict the program gets a much better looking heap profile. The trick I use is by writing a function hyperseq and then applying it before the next iterations begins: hyperseq x y = if x==x then y else error "this is very unlikely" This is very expensive and I chose to apply the function only once every 100 iterations. This gives reasonable performance. Two questions remain: 1) Is there a more efficient definition of hyperseq that does not traverse the data structure twice? The "show" function traverses the structure once but I found it to be much slower. 2) In this application the uses of lazy evaluation are rare and easily eliminated (zip xs [1..] and so on); is there some hidden GHC option that evaluates everything strictly? I realise that this would invalidate optimisations relying on certain laws but I just wonder how difficult this would be. Somebody must have given this a thought at one point. Cheers, Arjan

5 6

MathUI workshop: deadline extension
by Paul Libbrecht 18 Jun '04

18 Jun '04

:please distribute: :call for papers: workshop on Mathematical User Interfaces ---------------------------- Sept 18th 2004, Bialowezia, Poland at the Third Mathematical Knowledge Management Conference http://www.activemath.org/~paul/MathUI/ SCOPE The impact of mathematical knowledge management on user interfaces is only begininning to show. In interactive proof construction, some systems are able to suggest suitable theorems to apply to subgoals by harvesting online libraries; in computer algebra, folding/unfolding and automatic completion of terms helps the user with the input of complex expressions. Paradigms on how to use third-party software from within a preferred GUI are emerging and promise to innovate the notion of mathematical workspace. This workshop wants to focus on novel aspects of UI brought forward by the developments in MKM. It would like to bring together researchers and practioneers working with contemporary mathematical user-interfaces, including, but not limited to: - mathematical knowledge presentation - interactivity with mathematical objects - interactive simulations - mathematical objects input and manipulations. - access to mathematical knowledge INVITED TALK The workshop has invited Joris van der Hoeven for a talk about TeXMacs, an open-source WYSYWYG editor for mathematical publications. SUBMISSIONS AND DATES - Presentation proposals should be accompanied with an article or other presentation (for example a video or a mock-up GUI). Proceedings shall be online. - Either: - Submit your presentation proposal until June 30th - Or submit an abstract of your presentation (10 lines to half-a-page) until June 30th and a revised version until July 31st - Expect an answer on August 20th - Enjoy the workshop on Sept 18th PROGRAMME COMMITTEE Paul Cairns UCL Interaction Center, University College London, Great Britain Olga Caprotti Research Institute for Symbolic Computation, Linz, Austria Hanane Naciri Projet Lemme, INRIA Sophia Antipolis, France Norbert Kajler Ecole Nationale Supérieure des Mines de Paris, France Paul Libbrecht (organizer) Competence Center for E-Learning, DFKI GmbH, Saarbrücken, Germany Robert Miner Design Science Inc., Long Beach, California, USA MORE INFORMATION Host Conference: Mathematical Knowledge Management 2004 http://www.mizar.org/MKM2004/ More information can be read from the workshop's web-page http://www.activemath.org/~paul/MathUI/

1 0

Annoying naming clashes
by Ben.Yu＠combined.com 18 Jun '04

18 Jun '04

Hi, when writing haskell code. It is so annoying that name clashes keep happening. I have to be careful about the data constructor names, about the class names, about the class member names. I understand that we can use class to achieve some overloading effect. However, it does not help with data constructors. And, what's more important, it looks like Haskell does not allow two classes sharing methods of the same name. And that is something I deemed the most annoying. No matter how powerful type class is compared to Java interfaces, the naming problem just makes it so inconvinient. I'm a programmer who can be so easily affected by ethetics of the program. And when I have to keep worrying about "should I use this name? it may have been used in a similar class", the precious peace in mind is gone. As a novice haskell programmer, I might be missing something here though. If somebody can kindly give me some instruction of how to work with names, appreicate it a lot! Ben. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.

12 22

ANNOUNCING: The Haskell Bookstore
by John Meacham 18 Jun '04

18 Jun '04

The Haskell bookstore is now open :) The bookstore is an attempt to publish out-of-print books, scientific papers, and technical documentation relating to Haskell and Functional Programming in general which is not otherwise available in print. At the moment, the shop has * Simon Peyton Jones and David Lester's book on functional language implementation * The FFI specification. more titles shall be forthcoming. I am doing this as a non-profit venture, mainly because I really want some of these books in print :) So the cost is simply the printing cost plus expenses which will hopefully keep things afordable for everyone interested. the bookstore is at http://www.cafeshops.com/haskell_books and a wiki page describing it and allowing people to add to a wishlist and faq is at http://haskell.org/hawiki/HaskellBookstore I am always looking for new material, so any aid in tracking down copyright holders or orignal TeX files for anything desired would be apreciated. Plus, improving the documentation such as the GHC manual and FFI spec is doubleplusgood, as I can regularly pull down the cvs versions and keep the books up to date with the latest developments and good documentation benefits the community as a whole. Please let me know as soon as possible if anyone has any trouble with a printed version, as this is print-on-demand, I can incorporate changes to future editions right away. Oh, and I can't really afford to be sued, so if you think I am infringing on your copyright, send me a note before breaking out the lawyers and I will be happy to work something out :) John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

Monadic Loops
by Vivian McPhail 18 Jun '04

18 Jun '04

Hi, I've implemented a Neural Net simulator which needs to repeat a training loop many times. For this I used a while function: while test body = do (cond,res) <- body if (test cond) then do rs <- while test body return (res:rs) else return [res] However, when I run the program, the interpreter falls over after a few thousand iterations, running out of space. I think that this is because the Monadic implementation of the while loop actually nests functions of type (a -> M b) and there is a maximum ?stack size. Is there a better way to implement (possibly infinite) loops in Haskell?

7 6