[ ghc-Bugs-865518 ] The Impossible Happened
Bugs item #865518, was opened at 2003-12-24 14:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=865518group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: The Impossible Happened Initial Comment: Loading package base ... linking ... done. Prelude :set -package wx Loading package haskell98 ... linking ... done. Loading package lang ... linking ... done. Loading package concurrent ... linking ... done. Loading package QuickCheck ... linking ... done. Loading package util ... linking ... done. Loading package data ... linking ... done. Loading package wxcore ... linking ... C:\Prog\ghc\wxhaskell-0.4\bin\..\lib/wxcore.o: unknown symbol `_GHCziShow_toLowe r_closure' ghc.exe: panic! (the `impossible' happened, GHC version 6.2): can't load package `wxcore' Please report it as a compiler bug to glasgow-haskell- [EMAIL PROTECTED], or http://sourceforge.net/projects/ghc/. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=865518group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: ANNOUNCE: GHC version 6.2
On Tue, Dec 16, 2003 at 02:05:14PM -, Simon Marlow wrote: The (Interactive) Glasgow Haskell Compiler -- version 6.2 And, for Christmas, we at Debian bring you sackful of debs! For x86, alpha, hppa, ia64 and powerpc there are packages for unstable in the main Debian archive (these will move into testing early in the new year). apt-get update; apt-get install ghc6 ghc6-prof ghc6-doc as normal, with ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc providing the extra bits for those who want them. For x86 I've also compiled for stable and uploaded to Isaac's Haskell Experimental repository. To use it add this line to /etc/apt/sources.list: deb http://www.syntaxpolice.org/haskell-experimental/ stable/ and install as above. Unfortunately things aren't quite back to normal after the recent Debian break-in, so sparc and s390 builds haven't been done yet. Also, only x86, sparc and ia64 are registerised builds. I'll try a powerpc registerised build when I can log in to a suitable machine again. Hope you're all enjoying yourselves! Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC version 6.2
Ian Lynagh [EMAIL PROTECTED] writes: The (Interactive) Glasgow Haskell Compiler -- version 6.2 And, for Christmas, we at Debian bring you sackful of debs! Fantastic! Actually, I already downloaded them a couple of days ago, but thought to wait with the thanks until the announcement. *THANKS!* Both for the developers and for the packagers, who take the pain of providing Woody packages, too! Merry Christmas! Feri. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Haskell naming conventions
On Dec 24, 2003, at 2:29 AM, Sean L. Palmer wrote: It occurs to me that Haskell would be quite a bit easier for OO and traditional programmers to grasp if Haskell would actually use the correct, or at least more commonly used, names for things. I don't think changing a few keywords will have any significant impact; the differences between Haskell and Java run much, much deeper. So it makes me wonder why the use of the data keyword... wouldn't it make more sense to say: type Maybe a = Nothing | Just a No, it wouldn't. There is a difference between a `type' and a `datatype': a datatype is a special kind of type which comes equipped with a set of functions---the data constructors---which interact nicely with pattern-matching so that one can determine exhaustiveness and non-ambiguity of matches. Types in general, for example the Double type, do not satisfy these conditions. Likewise with class, type class, and instance: class Eq a where (==) :: a - a - Bool That actually declares a type class, not a class. According to the normal rules of English, every `type class' is necessarily a `class', isn't it? So why the use of the keyword class? Is it done merely to confuse C++ and Java programmers? Yikes! The secret is out! ;) The concept of type class in Haskell apparently roughly corresponds to the concept of interface in Java. So why not call it interface? Haskell type classes are older than Java. Perhaps you should petition Sun instead? Instance is also confusing: instance Eq Integer where a == b = a `integerEq` b That actually declares that Integer is a type, not an instance in the traditional use of the word. No, that Integer is a type is a necessary precondition of this instance declaration. The declaration rather says that Integer belongs to the type class Eq. The choice of the syntax `instance' here probably arises from the idea that a type class is relation (predicate) on types; many people say that, for example, (x,y) `is an instance of' the relation R if x R y. A C++ programmer would probably use the word subclass instead of instance. Not really. Up above you already compared type classes to Java interfaces. It follows that a Haskell instance T of class C rather corresponds to a Java class T which implements an interface C. Then consider how different a meaning return has in Haskell than it does in C. ;) return was probably chosen precisely because of what it suggests by analogy with C's return. Of course there are big differences, but can you think of a better name? Does anyone else think this is a problem? I think any difficulties stemming from Haskell's choice of keywords are dwarfed by the differences stemming from Haskell's semantics. If so, is it fixable? Haskell is much too old to be changing its surface syntax. Of course, you can always change GHC's input grammar, fork it, call it Haskell++ and see if anybody will use it. :) Or use Template Haskell. I guess from reading the many tutorials and FAQ's, that I'm in the same boat as everybody else. I consider myself a pretty bright boy, I've learned all kinds of other programming languages, from asm to forth to basic, pascal, C, C++, java, and C#... but this Haskell business, has me almost stumped. The standard response is: It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. -- Edsger Dijkstra, How do we tell truths that might hurt? http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html I mean, I understand the basic ideas pretty easily enough, but there seems to be such syntactical wierdness that to understand how to program in Haskell above the level of toy programs requires one to revisit every single design decision that went into making the language and its libraries, and grasp everything along the way, not only its function but also its peculiar nomenclature, and usually two different ways to say the same thing (maybe more). Only after following this long tortuous path will one ever be able to actually write useful programs. IMO, there really isn't much `syntactical weirdness' in Haskell; it has a pretty accessible syntax and first-time programming students appear to exhibit largely the same problems with Haskell syntax as they would in other languages (forgotten parentheses, etc.). What you are really complaining about is Haskell's semantics, but you don't realize it yet. If Haskell (or any language of this style) is ever to gain a larger following, it would probably be wise to accomodate the existing programmer knowledge base a little more. I believe that the same core language, with cleaner design, different keywords, maybe different operators, would probably be readily accepted. I believe you are very mistaken on that count. Is Howard Dean sure to win the American election if he starts speaking with a
How to make reading an array from disk more efficient
Hi, I have some code (http://www.acooke.org/andrew/ReadTest.hs) that reads data from a file (an image in ppm format; example data (256*256 pixels) at http://www.acooke.org/andrew/test.ppm) and stores it in an array of Word8 values. The aim is to read a file that contains 5000 * 5000 * 3 Word8 values. I think this should take under 100Mb of memory, if the Array implementation is efficient. However, when I run the code on a file of that size it looks like it will need several days to complete. This seems rather slow - the GIMP can read the same file maybe 30 seconds). How do I make the Haskell code faster while keeping it flexible? My requirements are: - machine limited to 1Gb memory - display status bar - the possibility to filter the pixel stream so that the image is subsampled (see everyN in the code) - the possibility to filter the pixel strean so that a subsection of the image is selected. All that is possible in the code I have now, but it's slow. Thanks, Andrew -- personal web site: http://www.acooke.org/andrew personal mail list: http://www.acooke.org/andrew/compute.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How to make reading an array from disk more efficient
(1) use unboxed arrays, otherwise you're wasting too much space with pointers. that is, unless you need laziness on the elements, which i don't think you do based on your list (2) (maybe) use imperative arrays; this will help you ensure that everything is being evaluated quickly. On Wed, 24 Dec 2003, andrew cooke wrote: Hi, I have some code (http://www.acooke.org/andrew/ReadTest.hs) that reads data from a file (an image in ppm format; example data (256*256 pixels) at http://www.acooke.org/andrew/test.ppm) and stores it in an array of Word8 values. The aim is to read a file that contains 5000 * 5000 * 3 Word8 values. I think this should take under 100Mb of memory, if the Array implementation is efficient. However, when I run the code on a file of that size it looks like it will need several days to complete. This seems rather slow - the GIMP can read the same file maybe 30 seconds). How do I make the Haskell code faster while keeping it flexible? My requirements are: - machine limited to 1Gb memory - display status bar - the possibility to filter the pixel stream so that the image is subsampled (see everyN in the code) - the possibility to filter the pixel strean so that a subsection of the image is selected. All that is possible in the code I have now, but it's slow. Thanks, Andrew -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How to make reading an array from disk more efficient
Thanks. I should have added that I will only use the array for reading once it's created. I don't mind whether creating is lazy or eager (it's currently eager because I was fighting a space leak, but I think that was down to some other error). I don't fully understand how either of the suggestions you make will speed up creation, though (I guess allocating less memory is faster). I'm looking for a factor of tens of thousands improvement. But I will try what you suggest. Cheers, Andrew PS Thanks for the very speedy reply and thanks to whoever maintains the list archive for updating the archive for each message (I'm pretty sure it used to be made daily, which was a nuisance if you wanted to forward URLs to interesting discussions). Hal Daume III said: (1) use unboxed arrays, otherwise you're wasting too much space with pointers. that is, unless you need laziness on the elements, which i don't think you do based on your list (2) (maybe) use imperative arrays; this will help you ensure that everything is being evaluated quickly. -- personal web site: http://www.acooke.org/andrew personal mail list: http://www.acooke.org/andrew/compute.html ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: How to make reading an array from disk more efficient
one other thing you might find useful is to read it imperatively and then use unsafeFreezeArray (i think that's the name) to get a pure array out of it. since all you'll be doing is reading, this should work nicely for you. On Wed, 24 Dec 2003, andrew cooke wrote: Thanks. I should have added that I will only use the array for reading once it's created. I don't mind whether creating is lazy or eager (it's currently eager because I was fighting a space leak, but I think that was down to some other error). I don't fully understand how either of the suggestions you make will speed up creation, though (I guess allocating less memory is faster). I'm looking for a factor of tens of thousands improvement. But I will try what you suggest. Cheers, Andrew PS Thanks for the very speedy reply and thanks to whoever maintains the list archive for updating the archive for each message (I'm pretty sure it used to be made daily, which was a nuisance if you wanted to forward URLs to interesting discussions). Hal Daume III said: (1) use unboxed arrays, otherwise you're wasting too much space with pointers. that is, unless you need laziness on the elements, which i don't think you do based on your list (2) (maybe) use imperative arrays; this will help you ensure that everything is being evaluated quickly. -- Hal Daume III | [EMAIL PROTECTED] Arrest this man, he talks in maths. | www.isi.edu/~hdaume ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GHC version 6.2
On Tue, Dec 16, 2003 at 02:05:14PM -, Simon Marlow wrote: The (Interactive) Glasgow Haskell Compiler -- version 6.2 And, for Christmas, we at Debian bring you sackful of debs! For x86, alpha, hppa, ia64 and powerpc there are packages for unstable in the main Debian archive (these will move into testing early in the new year). apt-get update; apt-get install ghc6 ghc6-prof ghc6-doc as normal, with ghc6-hopengl, ghc6-threaded-rts and ghc6-libsrc providing the extra bits for those who want them. For x86 I've also compiled for stable and uploaded to Isaac's Haskell Experimental repository. To use it add this line to /etc/apt/sources.list: deb http://www.syntaxpolice.org/haskell-experimental/ stable/ and install as above. Unfortunately things aren't quite back to normal after the recent Debian break-in, so sparc and s390 builds haven't been done yet. Also, only x86, sparc and ia64 are registerised builds. I'll try a powerpc registerised build when I can log in to a suitable machine again. Hope you're all enjoying yourselves! Ian ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: ANNOUNCE: GHC version 6.2
Ian Lynagh [EMAIL PROTECTED] writes: The (Interactive) Glasgow Haskell Compiler -- version 6.2 And, for Christmas, we at Debian bring you sackful of debs! Fantastic! Actually, I already downloaded them a couple of days ago, but thought to wait with the thanks until the announcement. *THANKS!* Both for the developers and for the packagers, who take the pain of providing Woody packages, too! Merry Christmas! Feri. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: looking for data structure advice
Hi
Sorry to take so long: I've spent a week watching paint dry, so I can
confirm that this is more interesting.
Jon Cast wrote:
Conor McBride [EMAIL PROTECTED] wrote:
snip
I've always been a little bothered by the MonadPlus class: zero and
plus are associated (no pun intended) in my mind with monoidal
structure. Is there more to MonadPlus than a clumsy workaround for
the lack of quantified constraints?
Yes. For every functor m with a MonadPlus instance, m () has /two/
monoids, (mzero, mplus) and (return (), ()). MonadPlus is thus no
more a workaround than the category Field; MonadPlus is simply a way to
specify that a functor has two monoid-like structures, one more exact
than the other, together with the expectation that the two monoids are
related in a manner similar to the relationship of the two
(more-or-less-) groups that make up a field.
That's a fair point. As these fieldy things are two monoids plus
distributive laws, they deserve special recognition. Do they have a name
(semirings, or something?).
Generally speaking, (return (), ()) seems to be just one instance of
the fact that if m is a monad and x is a monoid wrt (zero, plus), say,
then (m x) is also a monoid wrt (return zero, liftM2 plus). It's the
ability to push application under m (with appropriate laws) which
makes this possible: monads are just one structure which allows this
to happen.
A non-monadic example: [IO Int] has
{zero = [], plus = (++),
one = return (return 0), times = liftM2 (liftM2 (+))}
with distributive laws etc, but ([] . IO) is not monadic.
If we could have quantified constraints, e.g.
(Monad m, forall x. Monoid (m x))
wouldn't that be better than having Monad-specific monoids?
No. Consider the monad Writer (IO ()). The Writer monad wants a Monoid
instance, and the most natural such instance is often (return (), ()).
OTOH, this monad is always wrong in the cases where, currently, you
would use mplus. So you can't just replace MonadPlus with Monoid; you
need to be more specific about your choice of monoid than can be
accounted for by a single class.
snip
This is basically an unfortunate consequence of some design choices in
the class system, rather than a good thing per se. Pragmatically, it's
really annoying, at least to me, that I can't classify both of these
monoid structures as monoids, in order to use monoid-generic operators
(e.g. flattening) on either. I can't help thinking that newtype offers
a better workaround than making the monoidal aspect of MonadPlus not a
Monoid. But I would prefer to have some way to be more specific about
choice of monoid (indeed of instance, generally) in some localized way.
Merry Christmas
Conor
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Perspectives on learning and using Haskell
[switching to Haskell-cafe] At 19:37 23/12/03 +0100, Tomasz Zielonka wrote: On Tue, Dec 23, 2003 at 05:26:20PM +, Graham Klyne wrote: [1] http://www.ninebynine.org/Software/Learning-Haskell-Notes.html Thanks, that was a nice reading :) Thanks! (If by any chance there's anything here that might be useful for the Wiki, anyone may feel free to plunder it.) I have some comments: 8. Your explanation of Functor excludes many useful Functors which are rather not collections. For example, every monad (like IO) can be a Functor if you take fmap = Monad.liftM. For [] and Maybe this would give the same operation as in their normal instances. That's an interesting perspective that I wasn't aware of... I need to think about that. Meanwhile, I've added your observation to my notes. [later] It now seems to me that (some?) Monads are kinds of Functors, generalized to handle the no value case, and also composition. This also had me thinking about sequence: is there a generalization to arbitrary monads that rearranges the monadic structure? 11 and 18. If you define an instance of Monad for ((-) e) then return (putStrLn Hello!) 'x' is a proper IO () value. Probably still not sensible ;) Ah, I think I see your point. It would apply where monads are nested, right? Special treatment of 'return' could be helpful, but I am afraid that it could also make it look special, like a return keyword in C. I certainly wouldn't argue for special treatment _in the language_, but OTOH, I think it might be helpful if compiler diagnostics hinted at the possibility when a type error is detected in a form like return x y. #g Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Perspectives on learning and using Haskell
On Wed, Dec 24, 2003 at 10:39:33AM +, Graham Klyne wrote: It now seems to me that (some?) Monads are kinds of Functors, generalized to handle the no value case, and also composition. This also had me thinking about sequence: is there a generalization to arbitrary monads that rearranges the monadic structure? Perhaps looking into Category Theory could be enlightening for both of us - terms Monad and Functor where both taken from there. 11 and 18. If you define an instance of Monad for ((-) e) then return (putStrLn Hello!) 'x' is a proper IO () value. Probably still not sensible ;) Ah, I think I see your point. It would apply where monads are nested, right? Exactly. Special treatment of 'return' could be helpful, but I am afraid that it could also make it look special, like a return keyword in C. I certainly wouldn't argue for special treatment _in the language_, but OTOH, I think it might be helpful if compiler diagnostics hinted at the possibility when a type error is detected in a form like return x y. Agreed. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
