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
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
