From justebelmont at argentina.com Sat Oct 1 14:36:17 2005 From: justebelmont at argentina.com (justebelmont@argentina.com) Date: Sat Oct 1 13:56:34 2005 Subject: [Haskell] nwebie question Message-ID: <20051001181724.365FD4D050D@smtp-out.argentina.com> An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20051001/83c0b4b6/attachment.htm From sebastian.sylvan at gmail.com Sat Oct 1 15:13:07 2005 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Sat Oct 1 14:54:25 2005 Subject: [Haskell] nwebie question In-Reply-To: <20051001181724.365FD4D050D@smtp-out.argentina.com> References: <20051001181724.365FD4D050D@smtp-out.argentina.com> Message-ID: <3d96ac18051001121374a189bd@mail.gmail.com> On 10/1/05, justebelmont@argentina.com wrote: > > > Hi there folks, I'm trying to learn some functional programming in Haskell, > well, at the College, but they don't teach anything, lol, so I have a very > simple question about type creation. > > This is a new type that contains the int and the new infinity number > > data NatInf = Infinity | Num Int > > At this point every seems to be ok, but when I load the file in Hugs, and > then write > > Num 5 (or Infinity) > > the following error appears: > > ERROR ? Cannot find "show" function for: > *** Expression : Num 5 > *** Of type: : NatInf This means that you have not yet specified how you want your new data type to be converted to a string (using the function "show" in the Show type class). Either you write your own implementation instance Show NatInf where show (Num x) = ... show (Infinity) = ... Or you can simply derive a standard one by typing "deriving Show" at the end of your data declaration. data NatInf = Infinity | Num Int deriving Show /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 From frederik at a5.repetae.net Sun Oct 2 09:46:29 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Oct 2 09:27:45 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <20050929181125.GA3176@sefer.org> References: <20050929114914.GB3179@sefer.org> <433BDA67.6060107@mcmaster.ca> <20050929181125.GA3176@sefer.org> Message-ID: <20051002134629.GA5789@a5.repetae.net> I've previously mentioned that I would like to see an 'instance Bounded Double' etc., as part of the standard, which would use 1/0 for maxBound, or the largest possible value (there must be one!) for platforms where that is not possible. I don't see a problem with looking at Double values as if they were bounded by -infinity and +infinity. On Thu, Sep 29, 2005 at 09:11:25PM +0300, Yitzchak Gale wrote: > Hi Jacques, > > Thanks also to you for a most interesting reply. > > This same discussion has taken place on the > discussion list of every modern general-purpose > programming language. > > The same points are always raised and argued, and > the conclusion is always the same: floating point > exceptions should raise exceptions. Programs that > are so sensitive that the tiny overhead makes a > difference should use numeric libraries, unboxed > types, FFI, and the like. > > In Haskell also, it looks like the infrastructure > was already laid in the Control.Exception module. > I hope we will soon be using it. > > I personally would like also to see alternative > functions that return values in the Error monad. > > Regards, > Yitz > > On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: > > The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of > > the most 'stable' definitions of Infinity (in Float at least). > > Throwing an exception is also regarded as a possibility in IEEE 754, but > > it is expected that that is not the default, as experience shows that > > that is a sub-optimal default. Mathematical software (Maple, > > Mathematica, Matlab) have generally moved in that direction. > > > > Almost all hardware implementations of float arithmetic now default to > > IEEE 754 arithmetic. Having the arithmetic do 'something else' involves > > more CPU cycles, so users should generally complain if their system's > > arithmetic differs from IEEE 754 arithmetic without some deep reason to > > do so [there are some; read and understand William Kahan's papers for > > these]. > > > > Jacques > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From lennart at augustsson.net Sun Oct 2 10:35:02 2005 From: lennart at augustsson.net (Lennart Augustsson) Date: Sun Oct 2 10:17:07 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <20051002134629.GA5789@a5.repetae.net> References: <20050929114914.GB3179@sefer.org> <433BDA67.6060107@mcmaster.ca> <20050929181125.GA3176@sefer.org> <20051002134629.GA5789@a5.repetae.net> Message-ID: <433FF016.3060508@augustsson.net> Not all FP representations have infinity, and even if they do, they might only have one infinity. -- Lennart Frederik Eaton wrote: > I've previously mentioned that I would like to see an 'instance > Bounded Double' etc., as part of the standard, which would use 1/0 for > maxBound, or the largest possible value (there must be one!) for > platforms where that is not possible. I don't see a problem with > looking at Double values as if they were bounded by -infinity and > +infinity. > > On Thu, Sep 29, 2005 at 09:11:25PM +0300, Yitzchak Gale wrote: > >>Hi Jacques, >> >>Thanks also to you for a most interesting reply. >> >>This same discussion has taken place on the >>discussion list of every modern general-purpose >>programming language. >> >>The same points are always raised and argued, and >>the conclusion is always the same: floating point >>exceptions should raise exceptions. Programs that >>are so sensitive that the tiny overhead makes a >>difference should use numeric libraries, unboxed >>types, FFI, and the like. >> >>In Haskell also, it looks like the infrastructure >>was already laid in the Control.Exception module. >>I hope we will soon be using it. >> >>I personally would like also to see alternative >>functions that return values in the Error monad. >> >>Regards, >>Yitz >> >>On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: >> >>>The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of >>>the most 'stable' definitions of Infinity (in Float at least). >>>Throwing an exception is also regarded as a possibility in IEEE 754, but >>>it is expected that that is not the default, as experience shows that >>>that is a sub-optimal default. Mathematical software (Maple, >>>Mathematica, Matlab) have generally moved in that direction. >>> >>>Almost all hardware implementations of float arithmetic now default to >>>IEEE 754 arithmetic. Having the arithmetic do 'something else' involves >>>more CPU cycles, so users should generally complain if their system's >>>arithmetic differs from IEEE 754 arithmetic without some deep reason to >>>do so [there are some; read and understand William Kahan's papers for >>>these]. >>> >>>Jacques >> >>_______________________________________________ >>Haskell mailing list >>Haskell@haskell.org >>http://www.haskell.org/mailman/listinfo/haskell >> > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From shae at ScannedInAvian.com Sun Oct 2 17:46:49 2005 From: shae at ScannedInAvian.com (Shae Matijs Erisson) Date: Sun Oct 2 17:28:00 2005 Subject: [Haskell] The Monad.Reader - http://www.haskell.org/tmrwiki/IssueFive Message-ID: <87d5mnioc6.fsf@thunderbird.scannedinavian.com> For issue five, the subjects are a short introduction to Haskell, generating polyominoes, a ray tracer, number parameterized types, practical graph manipulation, and a short introduction to software testing in Haskell. The Monad.Reader is always in need of articles related to Haskell if you want to write an article, contact Shae Erisson! http://www.haskell.org/tmrwiki/IssueFive -- Shae Matijs Erisson - http://www.ScannedInAvian.com/ - Sockmonster once said: You could switch out the unicycles for badgers, and the game would be the same. From petersen at haskell.org Sun Oct 2 22:37:06 2005 From: petersen at haskell.org (Jens Petersen) Date: Sun Oct 2 22:18:24 2005 Subject: [Haskell] Haddock now in Fedora Extras Message-ID: <43409952.10301@haskell.org> I'm pleased to announce that Haddock has now been included in Fedora Extras for a few days. :) (Since Fedora Core 4, yum is configured for Fedora Extras by default, so users just need to run "yum install haddock" as root to install.) Jens From wchogg at lotus.hep.wisc.edu Sun Oct 2 23:00:54 2005 From: wchogg at lotus.hep.wisc.edu (Creighton Hogg) Date: Sun Oct 2 22:42:13 2005 Subject: [Haskell] Alex question In-Reply-To: <20051001181724.365FD4D050D@smtp-out.argentina.com> References: <20051001181724.365FD4D050D@smtp-out.argentina.com> Message-ID: Hi, I've read through the documentation on Alex abit, but since I'm not the sharpest tool in the shed I'm not really seeing the obvious way to take the output file of Alex and make a program that will print out the list of tokens scanned from an input file. I had to do something like this this past week for a class, but that was in Java so I wanted to try it in Haskell as well but I'm stuck at the moment. From frederik at a5.repetae.net Mon Oct 3 08:38:37 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Mon Oct 3 08:19:50 2005 Subject: [Haskell] Literal for Infinity In-Reply-To: <433FF016.3060508@augustsson.net> References: <20050929114914.GB3179@sefer.org> <433BDA67.6060107@mcmaster.ca> <20050929181125.GA3176@sefer.org> <20051002134629.GA5789@a5.repetae.net> <433FF016.3060508@augustsson.net> Message-ID: <20051003123837.GA31530@a5.repetae.net> But they all have a largest and smallest possible value, as I have already indicated. On Sun, Oct 02, 2005 at 04:35:02PM +0200, Lennart Augustsson wrote: > Not all FP representations have infinity, and even if > they do, they might only have one infinity. > > -- Lennart > > Frederik Eaton wrote: > >I've previously mentioned that I would like to see an 'instance > >Bounded Double' etc., as part of the standard, which would use 1/0 for > >maxBound, or the largest possible value (there must be one!) for > >platforms where that is not possible. I don't see a problem with > >looking at Double values as if they were bounded by -infinity and > >+infinity. > > > >On Thu, Sep 29, 2005 at 09:11:25PM +0300, Yitzchak Gale wrote: > > > >>Hi Jacques, > >> > >>Thanks also to you for a most interesting reply. > >> > >>This same discussion has taken place on the > >>discussion list of every modern general-purpose > >>programming language. > >> > >>The same points are always raised and argued, and > >>the conclusion is always the same: floating point > >>exceptions should raise exceptions. Programs that > >>are so sensitive that the tiny overhead makes a > >>difference should use numeric libraries, unboxed > >>types, FFI, and the like. > >> > >>In Haskell also, it looks like the infrastructure > >>was already laid in the Control.Exception module. > >>I hope we will soon be using it. > >> > >>I personally would like also to see alternative > >>functions that return values in the Error monad. > >> > >>Regards, > >>Yitz > >> > >>On Thu, Sep 29, 2005 at 03:13:27PM +0300, Jacques Carette wrote: > >> > >>>The IEEE 754 standard says (fairly clearly) that +1.0 / +0.0 is one of > >>>the most 'stable' definitions of Infinity (in Float at least). > >>>Throwing an exception is also regarded as a possibility in IEEE 754, but > >>>it is expected that that is not the default, as experience shows that > >>>that is a sub-optimal default. Mathematical software (Maple, > >>>Mathematica, Matlab) have generally moved in that direction. > >>> > >>>Almost all hardware implementations of float arithmetic now default to > >>>IEEE 754 arithmetic. Having the arithmetic do 'something else' involves > >>>more CPU cycles, so users should generally complain if their system's > >>>arithmetic differs from IEEE 754 arithmetic without some deep reason to > >>>do so [there are some; read and understand William Kahan's papers for > >>>these]. > >>> > >>>Jacques > >> > >>_______________________________________________ > >>Haskell mailing list > >>Haskell@haskell.org > >>http://www.haskell.org/mailman/listinfo/haskell > >> > > > >_______________________________________________ > >Haskell mailing list > >Haskell@haskell.org > >http://www.haskell.org/mailman/listinfo/haskell > > > From robdockins at fastmail.fm Mon Oct 3 09:15:26 2005 From: robdockins at fastmail.fm (robert dockins) Date: Mon Oct 3 08:56:38 2005 Subject: [Haskell] Alex question In-Reply-To: References: <20051001181724.365FD4D050D@smtp-out.argentina.com> Message-ID: <43412EEE.7060400@fastmail.fm> Which wrapper are you using? I just recently did this for the monad wrapper. It looks a little like this: data Token = EOF | .... alexEOF = return EOF lexAll :: Alex [Token] lexAll = do x <- alexMonadScan case x of EOF -> [] _ -> lexAll >>= return . (:) x lexString :: String -> [Token] lexString str = runAlex str lexAll The basic and posn wrappers have the "alexScanTokens" function which does essentially the same thing. Just slap on hGetContents and show and you're done. Creighton Hogg wrote: > Hi, > I've read through the documentation on Alex abit, but since > I'm not the sharpest tool in the shed I'm not really seeing > the obvious way to take the output file of Alex and make a > program that will print out the list of tokens scanned from > an input file. > I had to do something like this this past week for a class, > but that was in Java so I wanted to try it in Haskell as > well but I'm stuck at the moment. > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From mike at mikeandkellycrowe.com Tue Oct 4 00:01:43 2005 From: mike at mikeandkellycrowe.com (Mike Crowe) Date: Mon Oct 3 23:43:12 2005 Subject: [Haskell] Newbie quick questions Message-ID: <4341FEA7.4010609@mikeandkellycrowe.com> Hi folks, I ran across Haskell at the Great Win32 Computer Language Shootout. A friend approached me with a potential large application to develop. The idea of a language which can reduce time to design and make better code is very intriguing. I was looking at prototyping in Python using wxWindows as the GUI. I see Haskell has wxWindows libraries as well. So, here's some newbie questions I couldn't get from 2-3h on the various web sites: 1) Can I develop a Windows application to sell? Or is Haskell not really geared for that? 2) Say a team wants to develop a larger application, like a CRM system. In "thinking" in functional programming, can a team split up work and implementation and work together? In other words, how easily does Haskell adapt to a team approach? 3) Again, using a CRM tool as an example, what is the advantage to developing an application like this in Haskell vs. any other language? If I really invest the time, can I get this done quicker in Haskell? Sell me on this, please. 3) I'm a very top-down programmer. I like to start at the "big-picture" and work my way down in implementation. Does this adapt to Haskell, or am I missing the point? TIA! Mike From Jon.Fairbairn at cl.cam.ac.uk Tue Oct 4 06:31:11 2005 From: Jon.Fairbairn at cl.cam.ac.uk (Jon Fairbairn) Date: Tue Oct 4 06:12:28 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: Your message of "Tue, 04 Oct 2005 00:01:43 EDT." <4341FEA7.4010609@mikeandkellycrowe.com> Message-ID: <19714.1128421871@cl.cam.ac.uk> On 2005-10-04 at 00:01EDT Mike Crowe wrote: > Hi folks, > > I ran across Haskell at the Great Win32 Computer Language Shootout. A > friend approached me with a potential large application to develop. The > idea of a language which can reduce time to design and make better code > is very intriguing. > 1) Can I develop a Windows application to sell? Or is Haskell not > really geared for that? I don't see any reason why not, though the GUI aspect of Haskell is as well developed as some other aspects of the language. > 2) Say a team wants to develop a larger application, like a CRM system. > In "thinking" in functional programming, can a team split up work and > implementation and work together? In other words, how easily does > Haskell adapt to a team approach? At least as well as any other language. > 3) Again, using a CRM tool as an example, what is the advantage to > developing an application like this in Haskell vs. any other language? > If I really invest the time, can I get this done quicker in Haskell? > Sell me on this, please. Whether you can get it done quicker depends on how long it takes you to "get" functional programming. It's very easy to understand Haskell just well enough to write C programmes in it. It takes a significantly greater effort -- and time -- to get into the appropriate state of mind to write real Haskell programmes. > 3) I'm a very top-down programmer. I like to start at the "big-picture" > and work my way down in implementation. Does this adapt to Haskell, or > am I missing the point? Haskell is very good for this. -- J?n Fairbairn Jon.Fairbairn at cl.cam.ac.uk From duncan.coutts at worcester.oxford.ac.uk Tue Oct 4 06:46:42 2005 From: duncan.coutts at worcester.oxford.ac.uk (Duncan Coutts) Date: Tue Oct 4 06:26:32 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <19714.1128421871@cl.cam.ac.uk> References: <19714.1128421871@cl.cam.ac.uk> Message-ID: <1128422802.10416.54.camel@localhost> On Tue, 2005-10-04 at 11:31 +0100, Jon Fairbairn wrote: > On 2005-10-04 at 00:01EDT Mike Crowe wrote: > > Hi folks, > > > > I ran across Haskell at the Great Win32 Computer Language Shootout. A > > friend approached me with a potential large application to develop. The > > idea of a language which can reduce time to design and make better code > > is very intriguing. > > > 1) Can I develop a Windows application to sell? Or is Haskell not > > really geared for that? > > I don't see any reason why not, though the GUI aspect of > Haskell is as well developed as some other aspects of the > language. Gtk2Hs and wxHaskell both support Windows and both are distributed under the LGPL (or a license very similar to the LGPL) so are suitable for developing proprietary applications. Both libraries are nearing maturity; both are approaching 1.0 releases. http://haskell.org/gtk2hs/ http://wxhaskell.sourceforge.net/ Duncan From john at repetae.net Tue Oct 4 07:51:12 2005 From: john at repetae.net (John Meacham) Date: Tue Oct 4 07:32:41 2005 Subject: [Haskell] strictness of putChar: report incomplete? Message-ID: <20051004115112.GO4005@momenergy.repetae.net> The report does not seem to specify whether putChar _|_ is _|_ or not. (although it might be implied somewhere I didn't see) I orginally noticed this when jhc treated it as so and I considered this a bug since the argument should not be evaluated until the action is actually executed. however, it appears ghc has the same bug, or my reasoning is wrong. not only that, but hugs and ghc disagree with each other. ghc: putChar _|_ -> _|_ putStr _|_ -> valid IO () hugs: putChar _|_ -> valid IO () putStr _|_ -> valid IO () all the IO actions are bottom on execution of course. I believe the hugs behavior is correct and ghc and jhc are wrong, but there were differing opinions on #haskell. John -- John Meacham - ?repetae.net?john? From cgibbard at gmail.com Tue Oct 4 07:54:34 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Tue Oct 4 07:35:44 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <4341FEA7.4010609@mikeandkellycrowe.com> References: <4341FEA7.4010609@mikeandkellycrowe.com> Message-ID: <89ca3d1f0510040454x73d85e67u@mail.gmail.com> I wouldn't really consider any of those a particularly quick question, but I'll give them a shot :) On 04/10/05, Mike Crowe wrote: > Hi folks, > > I ran across Haskell at the Great Win32 Computer Language Shootout. A > friend approached me with a potential large application to develop. The > idea of a language which can reduce time to design and make better code > is very intriguing. > > I was looking at prototyping in Python using wxWindows as the GUI. I > see Haskell has wxWindows libraries as well. > > So, here's some newbie questions I couldn't get from 2-3h on the various > web sites: > > 1) Can I develop a Windows application to sell? Or is Haskell not > really geared for that? Well, of course -- the compilers are free, but there's no reason I can see that you couldn't sell an app that was written in Haskell. You'd need to be careful about the licenses of libraries that you use. I think that binaries produced with GHC are currently linked with libgmp which is under the LGPL, so you may have to be careful there as well. There are a variety of cross platform GUI libraries available. > 2) Say a team wants to develop a larger application, like a CRM system. > In "thinking" in functional programming, can a team split up work and > implementation and work together? In other words, how easily does > Haskell adapt to a team approach? Haskell supports quite a few different abstractions which would let you code things separately. In fact, most Haskell code is referentially transparent, so you usually don't even need the rest of the app to run in order to properly test a particular function (just the dependencies of that function). The type system is very nice at eliminating potential for bugs and helping to document how things fit together. The largest application that I've written personally is a pipeline scheduler and register allocator as part of a compiler for a high level signal processing language. The algorithm was a search and backtracking algorithm, which carried on into the register allocation (if a schedule couldn't be register allocated, it would have to backtrack into the scheduler). A nice thing here is that I didn't have to think of it as such, as all the backtracking occurred automatically, as I used the list monad for nondeterminism. After design of the algorithm which would be used, it only took a couple weeks to implement and test and was around 1000 lines, which was about 1/2 documentation, and ~250 lines of which was a parser generator for an assembly/dependency language, which built a parser based on the opcodes available. I suspect that a similar project in C would be at least 10 times as much code, and would not have been manageable in the time I had. Many things are very elegantly expressed in Haskell. I recommend that you try writing some small applications in it to get a feel for what it's like. > 3) Again, using a CRM tool as an example, what is the advantage to > developing an application like this in Haskell vs. any other language? > If I really invest the time, can I get this done quicker in Haskell? > Sell me on this, please. Haskell has quite a lot of nice features which help in various different ways. I won't even try to list them all for you, but point out a few I find nice. This really takes some exploring on your own in order to find out what is available, and how it might help. Also keep in mind that a lot has been written on the wiki (http://www.haskell.org/hawiki/) and in these mailing lists as to neat ways in which to use Haskell's features. Referential transparency I already mentioned, is incredibly nice to have. It basically consists of the guarantee that functions are completely determined by what values they return for given inputs - there is no hidden global state or side effects. This makes it much easier to prove that programs do what they are supposed to do, as well as to understand the code. The type system itself is marvellous in its ability to control how code is used and catch bugs at compile time, and prove various simple constraints hold on the code. To a very large extent, when programs compile, they also work as intended. Of course there are still bugs involved with using the wrong algorithm, but nothing can really prevent that. The type system catches a large portion of the errors which occur from attempting to fit existing pieces of code together in an unsuitable way. This is incredibly helpful when approaching a large library of existing code and wanting to write a new function based on it. The first thing to do is to look at the type of the function you want to write, and the types of the functions available. Your options in searching for useful code will often be quite restricted by the types which makes your job easier. When state and side effects are needed in Haskell, these things (though not only these things) are treated specially through the use of monads, which are a nice abstraction of both containers and models of computation. The monad being used occurs directly in the types of the functions and values involved, making it clear when it is in use, and preventing abuses. For example, if I have a function of type String -> String, then it cannot launch missiles (or do any IO whatsoever) while computing its result, simply because of its type. If it could possibly do some IO, it would have the type String -> IO String, which is somewhat rarer, and can not be used in the same places as a function of type String -> String. At first, this seems inconvenient, but in general, it helps to structure your program in such a way that makes it easier to reason about and work with. > 4) I'm a very top-down programmer. I like to start at the "big-picture" > and work my way down in implementation. Does this adapt to Haskell, or > am I missing the point? >From my experience, Haskell is quite good at this. You might be interested in type classes, which are effectively a way to express a relation between types in a program, and specify functionality between those types wherever the relation holds. This is how "overloaded" functions work in Haskell. For example, in the standard Prelude which is generally used in every Haskell program, there is the class Eq: class Eq a where (==), (/=) :: a -> a -> Bool -- Minimal complete definition: -- (==) or (/=) x /= y = not (x == y) x == y = not (x /= y) This single-parameter class basically defines the equality testing operations. If "Eq a" holds for some type "a", then it is possible to compare values of that type for equality. When you create types of your own, you get to specify an instance of Eq for your type to say how they should be compared, or write "deriving Eq" at the end of your data or newtype declaration, which will provide a sane default. Typeclasses in general let you specify functionality in an abstract way, and then specify a variety of implementations for that functionality and keep that entirely separate from the code which uses it. In this way, it is possible to provide simple instances when starting out, and provide more sophisticated implementations of the same behaviour later, without rewriting the code which uses it at all. (Just providing an input of a different type is enough.) > > TIA! > Mike hope this is useful - Cale From Malcolm.Wallace at cs.york.ac.uk Tue Oct 4 08:27:07 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 4 08:10:18 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <20051004115112.GO4005@momenergy.repetae.net> References: <20051004115112.GO4005@momenergy.repetae.net> Message-ID: <20051004132707.757dfe7a.Malcolm.Wallace@cs.york.ac.uk> John Meacham writes: > ghc: > putChar _|_ -> _|_ > putStr _|_ -> valid IO () > > hugs: > putChar _|_ -> valid IO () > putStr _|_ -> valid IO () I think it comes down to buffering behaviour doesn't it? Should the character be evaluated when it is added to the output buffer, or when the output buffer is flushed to its destination? It would seem that ghc has an array of true unboxed characters for the buffer, whilst hugs has an array of boxed chars. > I believe the hugs behavior is correct and ghc and jhc are wrong, but > there were differing opinions on #haskell. Wouldn't that impose an unnecessarily burdensome implementation choice? If the Report is silent, then either choice would be permissible. However, I'm inclined to the view that where the Prelude refers to a primitive operation (e.g. primPutChar), that all prims are strict, since by implication they are not implementable in Haskell. Regards, Malcolm From Malcolm.Wallace at cs.york.ac.uk Tue Oct 4 08:46:44 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Tue Oct 4 08:35:05 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <20051004132707.757dfe7a.Malcolm.Wallace@cs.york.ac.uk> References: <20051004115112.GO4005@momenergy.repetae.net> <20051004132707.757dfe7a.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20051004134644.6c4e29cd.Malcolm.Wallace@cs.york.ac.uk> I wrote: > > ghc: > > putChar _|_ -> _|_ > > > > hugs: > > putChar _|_ -> valid IO () > > I think it comes down to buffering behaviour doesn't it? Having reviewed the IRC logs, I see I was talking nonsense. You want to be able to store a closure for (putChar undefined) in a data structure, which seems like a perfectly reasonable thing to do. Provided the IO action is never actually run (after being retrieved from the data structure), the program really ought not to crash. I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc _must_ be wrong. :-) Regards, Malcolm From mike at mikeandkellycrowe.com Tue Oct 4 09:11:20 2005 From: mike at mikeandkellycrowe.com (Mike Crowe) Date: Tue Oct 4 08:52:41 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <89ca3d1f0510040454x73d85e67u@mail.gmail.com> References: <4341FEA7.4010609@mikeandkellycrowe.com> <89ca3d1f0510040454x73d85e67u@mail.gmail.com> Message-ID: <43427F78.4000507@mikeandkellycrowe.com> Thanks, all, especially Cale for the detail. This may be unfair to ask, but is anybody willing to give an example? There are great examples for writing factorials. However, that's not really useful. I'm looking for a real-world example of using the language. Specifically, the first page of About Haskell states: > WOW! I basically wrote this without testing just thinking about my > program in terms of transformations between types. What I'm still missing is how to use this idea of functional programming to tie all this together. Let's say, for example, I want to write a data input system for a database. Consider these two examples: I think I understand how to take the following example (and others in that library) and expand to a complete UI for the data input: http://cvs.sourceforge.net/viewcvs.py/wxhaskell/wxhaskell/samples/wx/Grid.hs?rev=1.6&view=auto I also looked over the examples in http://htoolkit.sourceforge.net/ for writing to a SQL database. So I can see how to save the data. The following example I get for inserting: insertRecords :: Connection -> IO () insertRecords c = do execute c "insert into Test(id,name) values (1,'Test1')" How, though, would I start? If I did this in an imperative language, I might do it like (in Python): def main: if gridCtrl.Show(): # returns True if user exits pressing Save data = gridCtrl.getData() dataBase.insertRecords(data) In Haskell, how would you start this at the top? How would you define a relationship between two modules? If this is more detailed than I should ask in this list, please LMK. Thanks! Mike Cale Gibbard wrote: >I wouldn't really consider any of those a particularly quick question, >but I'll give them a shot :) > >On 04/10/05, Mike Crowe wrote: > > >>Hi folks, >> >>I ran across Haskell at the Great Win32 Computer Language Shootout. A >>friend approached me with a potential large application to develop. The >>idea of a language which can reduce time to design and make better code >>is very intriguing. >> >>I was looking at prototyping in Python using wxWindows as the GUI. I >>see Haskell has wxWindows libraries as well. >> >>So, here's some newbie questions I couldn't get from 2-3h on the various >>web sites: >> >>1) Can I develop a Windows application to sell? Or is Haskell not >>really geared for that? >> >> > >Well, of course -- the compilers are free, but there's no reason I can >see that you couldn't sell an app that was written in Haskell. You'd >need to be careful about the licenses of libraries that you use. I >think that binaries produced with GHC are currently linked with libgmp >which is under the LGPL, so you may have to be careful there as well. >There are a variety of cross platform GUI libraries available. > > > >>2) Say a team wants to develop a larger application, like a CRM system. >>In "thinking" in functional programming, can a team split up work and >>implementation and work together? In other words, how easily does >>Haskell adapt to a team approach? >> >> > >Haskell supports quite a few different abstractions which would let >you code things separately. In fact, most Haskell code is >referentially transparent, so you usually don't even need the rest of >the app to run in order to properly test a particular function (just >the dependencies of that function). The type system is very nice at >eliminating potential for bugs and helping to document how things fit >together. > >The largest application that I've written personally is a pipeline >scheduler and register allocator as part of a compiler for a high >level signal processing language. The algorithm was a search and >backtracking algorithm, which carried on into the register allocation >(if a schedule couldn't be register allocated, it would have to >backtrack into the scheduler). A nice thing here is that I didn't have >to think of it as such, as all the backtracking occurred >automatically, as I used the list monad for nondeterminism. After >design of the algorithm which would be used, it only took a couple >weeks to implement and test and was around 1000 lines, which was about >1/2 documentation, and ~250 lines of which was a parser generator for >an assembly/dependency language, which built a parser based on the >opcodes available. I suspect that a similar project in C would be at >least 10 times as much code, and would not have been manageable in the >time I had. > >Many things are very elegantly expressed in Haskell. I recommend that >you try writing some small applications in it to get a feel for what >it's like. > > > >>3) Again, using a CRM tool as an example, what is the advantage to >>developing an application like this in Haskell vs. any other language? >>If I really invest the time, can I get this done quicker in Haskell? >>Sell me on this, please. >> >> > >Haskell has quite a lot of nice features which help in various >different ways. I won't even try to list them all for you, but point >out a few I find nice. This really takes some exploring on your own in >order to find out what is available, and how it might help. Also keep >in mind that a lot has been written on the wiki >(http://www.haskell.org/hawiki/) and in these mailing lists as to neat >ways in which to use Haskell's features. > >Referential transparency I already mentioned, is incredibly nice to >have. It basically consists of the guarantee that functions are >completely determined by what values they return for given inputs - >there is no hidden global state or side effects. This makes it much >easier to prove that programs do what they are supposed to do, as well >as to understand the code. > >The type system itself is marvellous in its ability to control how >code is used and catch bugs at compile time, and prove various simple >constraints hold on the code. To a very large extent, when programs >compile, they also work as intended. Of course there are still bugs >involved with using the wrong algorithm, but nothing can really >prevent that. The type system catches a large portion of the errors >which occur from attempting to fit existing pieces of code together in >an unsuitable way. > >This is incredibly helpful when approaching a large library of >existing code and wanting to write a new function based on it. The >first thing to do is to look at the type of the function you want to >write, and the types of the functions available. Your options in >searching for useful code will often be quite restricted by the types >which makes your job easier. > >When state and side effects are needed in Haskell, these things >(though not only these things) are treated specially through the use >of monads, which are a nice abstraction of both containers and models >of computation. The monad being used occurs directly in the types of >the functions and values involved, making it clear when it is in use, >and preventing abuses. > >For example, if I have a function of type String -> String, then it >cannot launch missiles (or do any IO whatsoever) while computing its >result, simply because of its type. If it could possibly do some IO, >it would have the type String -> IO String, which is somewhat rarer, >and can not be used in the same places as a function of type String -> >String. At first, this seems inconvenient, but in general, it helps to >structure your program in such a way that makes it easier to reason >about and work with. > > > >>4) I'm a very top-down programmer. I like to start at the "big-picture" >>and work my way down in implementation. Does this adapt to Haskell, or >>am I missing the point? >> >> > >From my experience, Haskell is quite good at this. You might be >interested in type classes, which are effectively a way to express a >relation between types in a program, and specify functionality between >those types wherever the relation holds. This is how "overloaded" >functions work in Haskell. For example, in the standard Prelude which >is generally used in every Haskell program, there is the class Eq: > >class Eq a where > (==), (/=) :: a -> a -> Bool > > -- Minimal complete definition: > -- (==) or (/=) > x /= y = not (x == y) > x == y = not (x /= y) > >This single-parameter class basically defines the equality testing >operations. If "Eq a" holds for some type "a", then it is possible to >compare values of that type for equality. When you create types of >your own, you get to specify an instance of Eq for your type to say >how they should be compared, or write "deriving Eq" at the end of your >data or newtype declaration, which will provide a sane default. > >Typeclasses in general let you specify functionality in an abstract >way, and then specify a variety of implementations for that >functionality and keep that entirely separate from the code which uses >it. In this way, it is possible to provide simple instances when >starting out, and provide more sophisticated implementations of the >same behaviour later, without rewriting the code which uses it at all. >(Just providing an input of a different type is enough.) > > > >>TIA! >>Mike >> >> > >hope this is useful > - Cale > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org//pipermail/haskell/attachments/20051004/2abe5dd1/attachment.htm From duncan.coutts at worcester.oxford.ac.uk Tue Oct 4 09:15:59 2005 From: duncan.coutts at worcester.oxford.ac.uk (Duncan Coutts) Date: Tue Oct 4 08:55:49 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <20051004134644.6c4e29cd.Malcolm.Wallace@cs.york.ac.uk> References: <20051004115112.GO4005@momenergy.repetae.net> <20051004132707.757dfe7a.Malcolm.Wallace@cs.york.ac.uk> <20051004134644.6c4e29cd.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <1128431760.10416.63.camel@localhost> On Tue, 2005-10-04 at 13:46 +0100, Malcolm Wallace wrote: > I wrote: > > > > ghc: > > > putChar _|_ -> _|_ > > > > > > hugs: > > > putChar _|_ -> valid IO () > > > > I think it comes down to buffering behaviour doesn't it? > > Having reviewed the IRC logs, I see I was talking nonsense. > > You want to be able to store a closure for (putChar undefined) in a > data structure, which seems like a perfectly reasonable thing to do. > Provided the IO action is never actually run (after being retrieved > from the data structure), the program really ought not to crash. > > I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc > _must_ be wrong. :-) Looking at GHC's library code we see that it is indeed forcing the char early: hPutChar :: Handle -> Char -> IO () hPutChar handle c = c `seq` do ... Duncan From jgoerzen at complete.org Tue Oct 4 10:31:38 2005 From: jgoerzen at complete.org (John Goerzen) Date: Tue Oct 4 11:49:57 2005 Subject: [Haskell] Haskell Weekly News: October 4, 2005 Message-ID: <20051004143138.GA22322@katherina.lan.complete.org> Haskell Weekly News: October 4, 2005 Greetings, and thanks for reading the 10th issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases The Monad.Reader, Issue 5. Shae Matijs Erisson [3]announced the release of the fifth issue of The Monad.Reader, the online magazine devoted to Haskell. Subjects in this issue include a short introduction to Haskell, generating polyominoes, a ray tracer, number parameterized types, practical graph manipulation, and a short introduction to software testing in Haskell. TMR is available [4]online. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12216 4. http://www.haskell.org/tmrwiki/IssueFive Discussion Quiet or Busy? It's been a quiet week on the Haskell lists, so this week's HWN is a bit sparse. But that's because many Haskellers were at the Haskell workshops at ICFP in Estonia. I expect we'll see some fallout from those workshops on the list in the coming week. Haskell workshop items. Over on the IRC channel [5]logs from September 30, there was a live conversation beginning at 15:36:33 of the "Future of Haskell discussion." Autrijus Tang's journal had several pages of entries, including one [6]providing a nice summary. 5. http://meme.b9.com/cview.html?channel=haskell&date=050930 6. http://use.perl.org/~autrijus/journal/26953 Endian conversion. Joel Reymont asked about converting binary data in a network protocol, and several suggestions were posted in the resulting [7]discussion. 7. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8556 Is putChar strict? John Meacham [8]asked this question, and pointed out that different Haskell compilers/interpreters are behaving in different ways. 8. http://thread.gmane.org/gmane.comp.lang.haskell.general/12224 About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [9]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 9. http://sequence.complete.org/hwn-contrib From lsb at di.uminho.pt Tue Oct 4 05:06:24 2005 From: lsb at di.uminho.pt (Luis Barbosa) Date: Wed Oct 5 00:26:25 2005 Subject: [Haskell] FACS'05: Call for Participation Message-ID: <5b25e6a0ca3332a37d8371b65500198a@di.uminho.pt> [apologies for cross-posting] ------------------------------------------------------------------------ - Please find attached the Call for Participation on FACS'05 2nd International Workshop on Formal Aspects of Component Software to be held at UNU-IIST, Macao, 24-25, October, 2005. The workshop programme, on-line registration and further information on travel and accommodation is available from www.iist.unu.edu/facs05/ ------------------------------------------------------------------------ - -------------- next part -------------- A non-text attachment was scrubbed... Name: CPart.pdf Type: application/pdf Size: 6185 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20051004/f1673cfa/CPart.pdf -------------- next part -------------- ------------------------------------------------------------- Lu?s Soares Barbosa www.di.uminho.pt/~lsb DI - Univ. Minho | Phone: (351) 253 604463 Braga, Portugal | Fax: (351) 253 604471 -------------------------------------------------------------- From jana.sukkarieh at clg.ox.ac.uk Tue Oct 4 15:02:24 2005 From: jana.sukkarieh at clg.ox.ac.uk (Jana Sukkarieh) Date: Wed Oct 5 00:26:27 2005 Subject: [Haskell] Natural Language and Knowledge Representation/Reasoning (CFP) Message-ID: <00f501c5c916$28a56a80$f50016ac@jana> [Apologies for x-postings] NATURAL LANGUAGE AND KNOWLEDGE REPRESENTATION (NL-KR) Special Track at FLAIRS 2006 SECOND CALL FOR PAPERS Holiday Inn Melbourne Oceanfront, Melbourne Beach, FLORIDA, USA MAIN CONFERENCE: 11-12-13 MAY 2006 Special track web page: http://users.ox.ac.uk/~lady0641/Flairs06_NL_KR Main conference web page: http://www.indiana.edu/~flairs06 PURPOSE OF THE NL-KR TRACK We believe the Natural Language Processing (NLP) and the Knowledge Representation (KR) communities have common goals. They are both concerned with representing knowledge and with reasoning, since the best test for the semantic capability of an NLP system is performing reasoning tasks. Having these two essential common grounds, the two communities ought to have been collaborating, to provide a well-suited representation language that covers these grounds. However, the two communities also have difficult-to-meet concerns. Mainly, the semantic representation (SR) should be expressive enough and should take the information in context into account, while the KR should be equipped with a fast reasoning process. The main objection against an SR or a KR is that they need experts to be understood. Non-experts communicate (usually) via a natural language (NL), and more or less they understand each other while performing a lot of reasoning. An essential practical value of representations is their attempt to be transparent. This will particularly be useful when/if the system provides a justification for a user or a knowledge engineer on its line of reasoning using the underlying KR (i.e. without generating back to NL). We all seem to believe that, compared to Natural Language, the existing Knowledge Representation and reasoning systems are poor. Nevertheless, for a long time, the KR community dismissed the idea that NL can be a KR. That's because NL can be very ambiguous and there are syntactic and semantic processing complexities associated with it. However, researchers in both communities have started looking at this issue again. Possibly, it has to do with the NLP community making some progress in terms of processing and handling ambiguity, the KR community realising that a lot of knowledge is already 'coded' in NL and that one should reconsider the way they handle expressivity and ambiguity. This track is an attempt to provide a forum for discussion on this front and to bridge a gap between NLP and KR. A KR in this track has a well-defined syntax, semantics and a proof theory. It should be clear what authors mean by NL-like, based on NL or benefiting from NL (if they are using one). It does not have to be a novel representation. NL-KR TRACK TOPICS For this track, we will invite submissions including, but not limited to: a. A novel NL-like KR or building on an existing one b. Reasoning systems that benefit from properties of NL to reason with NL c. Semantic representation used as a KR : compromise between expressivity and efficiency? d. More Expressive KR for NL understanding (Any compromise?) e. Any work exploring how existing representations fall short of addressing some problems involved in modelling, manipulating or reasoning (whether reasoning as used to get an interpretation for a certain utterance, exchange of utterances or what utterances follow from other utterances) with NL documents f. Representations that show how classical logics are not as efficient, transparent, expressive or where a one-step application of an inference rule require more (complex) steps in a classical environment and vice-versa; i.e. how classical logics are more powerful, etc g. Building a reasoning test collection for natural language understanding systems: any kind of reasoning (deductive, abductive, etc); for a deductive test suite see for e.g. deliverable 16 of the FraCas project (http://www.cogsci.ed.ac.uk/~fracas/). Also, look at textual entailment challenges 1 and 2 h. Comparative results (on a common test suite or a common task) of different representations or systems that reason with NL (again any kind of reasoning). The comparison could be either for efficiency, transparency or expressivity i. Knowledge acquisition systems or techniques that benefit from properties of NL to acquire knowledge already 'coded' in NL j. Automated Reasoning, Theorem Proving and KR communities views on all this NL_KR TRACK PROGRAM COMMITTEE James ALLEN, University of Rochester, USA Patrick BLACKBURN, Institut National de Recherche en Informatique, France Johan BOS, University of Edinburgh, UK Richard CROUCH, Palo Alto Research Centre, USA Maarten DE RIJKE, University of Amsterdam, The Netherlands Anette FRANK, DFKI, Germany Fernando GOMEZ, University of Central Florida, USA Sanda HARABAGIU, University of Texas at Dallas, USA John HARRISON, Intel, USA Jerry HOBBS, Information Sciences Institute, USA Chung Hee HWANG, Raytheon Co., USA Michael KOHLHASE, International University Bremen, Germany Shalom LAPPIN, King's College, UK Carsten LUTZ, Dresden University of Technology, Germany Dan MOLDOVAN, University of Texas at Dallas, USA Jeff PELLETIER, Simon Fraser University, Canada Stephen PULMAN, University of Oxford, UK Lenhart SCHUBERT, University of Rochester, USA John SOWA, VivoMind Intelligence, Inc., USA Jana SUKKARIEH, University of Oxford, UK (Chair) Geoff SUTCLIFFE, Miami University, USA Timothy WILLIAMSON, University of Oxford, UK NL_KR TRACK INVITED SPEAKER John SOWA, VivoMind Intelligence, Inc., US FLAIRS 2006 INVITED SPEAKERS Alan BUNDY, University of Edinburg, Scotland Bob MORRIS, Nasa Ames Research Center, USA Mehran SAHAMI, Standford University and Google, USA Barry SMYTH, University College Dublin, Ireland NL-KR TRACK PROPOSED BY Jana Sukkarieh, University of Oxford, UK email: J.Sukkarieh.94@cantab.net WEB and TECH SUPPORT Simon Dobnik, University of Oxford, UK email: Simon.Dobnik@clg.ox.ac.uk SUBMISSION DETAILS Submissions must arrive no later than 21 November 2005. Only electronic submissions will be considered. Details about submission can be found on : http://users.ox.ac.uk/~lady0641/Flairs06_NL_KR/submission_details.html Selected papers will be considered for publication in a special journal issue of "The journal of Logic and Computation" in the 2nd half of 2006. PROCEEDINGS Printed Proceedings will be published only on demand. Proceedings on CD will be provided to all. IMPORTANT DATES * Submission of papers: 21 November, 2005 * Notification of acceptance: 20 January, 2006 * Final version of the paper is due : 13 February, 2006 * Main Conference: 11-13 May 2006 * Track: max 1 day during the main conference Those interested in running a demo please contact Jana Sukkarieh or Simon Dobnik . From Malcolm.Wallace at cs.york.ac.uk Wed Oct 5 10:08:56 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Wed Oct 5 09:50:46 2005 Subject: [Haskell] ANNOUNCE: cpphs-1.0 Message-ID: <20051005150856.12f44a1b.Malcolm.Wallace@cs.york.ac.uk> cpphs-1.0 --------- Announcing a new release of cpphs, a Haskell re-implementation of the C pre-processor. This release mainly has very minor bugfixes, indicating (I hope) that cpphs has reached a state of reasonable stability and maturity. http:/haskell.org/cpphs Recent Changes: * Add a compatibility script cpphs.compat, allowing cpphs to act as a drop-in replacement for cpp, e.g. ghc -cpp -pgmP cpphs.compat * Place quotes around replacements for special macros __FILE__, __DATE__, and __TIME__. * If no files are specified, read from stdin. * Ignore #! lines (e.g. in scripts) * Parse -D commandline options once only, and consistently with cpp, i.e. -Dfoo means foo=1 * Fix compatibility with preprocessors like hsc2hs, which use non-cpp directives like #def. They are now passed through to the output with a warning to stderr. From simonmar at microsoft.com Wed Oct 5 10:22:29 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Wed Oct 5 10:03:37 2005 Subject: [Haskell] strictness of putChar: report incomplete? Message-ID: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> On 04 October 2005 14:16, Duncan Coutts wrote: > On Tue, 2005-10-04 at 13:46 +0100, Malcolm Wallace wrote: >> I wrote: >> >>>> ghc: >>>> putChar _|_ -> _|_ >>>> >>>> hugs: >>>> putChar _|_ -> valid IO () >>> >>> I think it comes down to buffering behaviour doesn't it? >> >> Having reviewed the IRC logs, I see I was talking nonsense. >> >> You want to be able to store a closure for (putChar undefined) in a >> data structure, which seems like a perfectly reasonable thing to do. >> Provided the IO action is never actually run (after being retrieved >> from the data structure), the program really ought not to crash. >> >> I see that nhc98 and hbc agree with Hugs on this behaviour, so ghc >> _must_ be wrong. :-) > > Looking at GHC's library code we see that it is indeed forcing the > char early: > > hPutChar :: Handle -> Char -> IO () > hPutChar handle c = > c `seq` do > ... Fixed. However, I have a hunch that there are a *lot* of library functions whose strictness isn't completely specified by the report. Basically anything for which the report doesn't give the full code, except of course primitives which usually must be strict. This is only a hunch - I haven't actually gone looking for any. I suspect we get away with it most of the time because the desired strictness is "obvious" and/or the compilers all agree. Arguably, nothing returning IO should ever be strict, but you only have to use pattern matching in the implementation to violate that rule. Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return ()) as interchangeable, which is naughty, and people have occasionally noticed, but the benefits can sometimes be huge. It is this distinction that makes it hard to optimise IO code in a Haskell compiler, though. Cheers, Simon From ross at soi.city.ac.uk Wed Oct 5 10:45:31 2005 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Oct 5 10:26:42 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <20051005144531.GA11301@soi.city.ac.uk> On Wed, Oct 05, 2005 at 03:22:29PM +0100, Simon Marlow wrote: > Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return > ()) as interchangeable, which is naughty, and people have occasionally > noticed, but the benefits can sometimes be huge. What's wrong with identifying them? You're not expecting the monad laws to hold, are you? From simonmar at microsoft.com Wed Oct 5 11:01:09 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Wed Oct 5 10:42:15 2005 Subject: [Haskell] strictness of putChar: report incomplete? Message-ID: <3429668D0E777A499EE74A7952C382D104A5DF70@EUR-MSG-01.europe.corp.microsoft.com> On 05 October 2005 15:46, Ross Paterson wrote: > On Wed, Oct 05, 2005 at 03:22:29PM +0100, Simon Marlow wrote: >> Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; >> return ()) as interchangeable, which is naughty, and people have >> occasionally noticed, but the benefits can sometimes be huge. > > What's wrong with identifying them? You're not expecting the monad > laws to hold, are you? No, of course I don't expect the monad laws to hold :) But the intended meaning of (do _|_; return () :: IO ()) `seq` True is True, not _|_, right? This isn't made explicit in the report, but it's how we all understand the IO monad to work, and perhaps derives from the well-known implementation of (IO a) as (World -> (a,World)). Cheers, Simon From simonmar at microsoft.com Wed Oct 5 11:09:01 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Wed Oct 5 10:50:07 2005 Subject: [Haskell] Making shared libraries with Haskell Message-ID: <3429668D0E777A499EE74A7952C382D104A5DF95@EUR-MSG-01.europe.corp.microsoft.com> On 26 September 2005 08:57, Joel Reymont wrote: > Is the procedure of creating shared libraries with Haskell and > loading them from C described somewhere? > > Is this even possible? It currently isn't possible to build a Unix-style .so from Haskell code using GHC, although there is work in this direction (PIC and shared libraries are supported on MacOS X, and other platforms are in progress). It is possible to build a Windows DLL from Haskell code, although currently all the Haskell code has to reside in a single DLL. Again, this is a restriction we intend to lift in the future. It has been working before, but bitrotted due to fragility and lack of developer resources. Cheers, Simon From joelr1 at gmail.com Wed Oct 5 11:20:47 2005 From: joelr1 at gmail.com (Joel Reymont) Date: Wed Oct 5 11:01:57 2005 Subject: [Haskell] Making shared libraries with Haskell In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DF95@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DF95@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <5C5F3768-9130-4895-8657-5C342D26A96E@gmail.com> Simon, It appears that hs-plugins supports this functionality. I don't care if its bundles or shared libraries so long as I can use Haskell as a DSL in some other program (game engine is what I had in mind). hs- plugins appears to allow this, unless you are telling me it only works on Windows :-). Joel On Oct 5, 2005, at 5:09 PM, Simon Marlow wrote: > It currently isn't possible to build a Unix-style .so from Haskell > code > using GHC, although there is work in this direction (PIC and shared > libraries are supported on MacOS X, and other platforms are in > progress). -- http://wagerlabs.com/idealab From ross at soi.city.ac.uk Wed Oct 5 11:30:19 2005 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Oct 5 11:11:27 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DF70@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DF70@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <20051005153019.GB11301@soi.city.ac.uk> On Wed, Oct 05, 2005 at 04:01:09PM +0100, Simon Marlow wrote: > No, of course I don't expect the monad laws to hold :) > > But the intended meaning of > > (do _|_; return () :: IO ()) `seq` True > > is True, not _|_, right? This isn't made explicit in the report, but > it's how we all understand the IO monad to work, and perhaps derives > from the well-known implementation of (IO a) as (World -> (a,World)). Actually, from a resumption-based semantics of IO, I was expecting _|_, but I see all the implementations get it wrong. From wolfgang at jeltsch.net Wed Oct 5 11:33:53 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Oct 5 11:15:02 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <200510051733.53302.wolfgang@jeltsch.net> Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: > [...] > Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return > ()) as interchangeable, which is naughty, and people have occasionally > noticed, but the benefits can sometimes be huge. It is this distinction > that makes it hard to optimise IO code in a Haskell compiler, though. I think, seq should be a method of a type class. Then we could forbid applying seq to a function, we could forbid applying seq to an IO expression and we could forbid applying seq to expressions of any type with hidden implementation for which we don't want to provide bottom tests. > Cheers, > Simon Best wishes, Wolfgang From wolfgang at jeltsch.net Wed Oct 5 11:36:35 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Oct 5 11:17:41 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <200510051736.35673.wolfgang@jeltsch.net> Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: > [...] > Basically anything for which the report doesn't give the full code, except > of course primitives which usually must be strict. Why must primitives be strict? I wouldn't consider putChar undefined an undefined action. In my opinion, the undefinedness should only come into play when putChar undefined is executed. > [...] Best wishes, Wolfgang From wolfgang at jeltsch.net Wed Oct 5 11:43:28 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Oct 5 11:24:34 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5DF70@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5DF70@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <200510051743.28849.wolfgang@jeltsch.net> Am Mittwoch, 5. Oktober 2005 17:01 schrieb Simon Marlow: > On 05 October 2005 15:46, Ross Paterson wrote: > > On Wed, Oct 05, 2005 at 03:22:29PM +0100, Simon Marlow wrote: > >> Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; > >> return ()) as interchangeable, which is naughty, and people have > >> occasionally noticed, but the benefits can sometimes be huge. > > > > What's wrong with identifying them? You're not expecting the monad > > laws to hold, are you? > > No, of course I don't expect the monad laws to hold :) It's terrible that the monad laws don't hold for the IO *monad*. I suppose, it all has to do with the type of seq being too general. In my opinion, this is a very serious problem since Haskell is a language which is expected to have a sound theoretical foundation. So I think that this problem should be addressed in the future under all circumstances. > [...] Best wishes, Wolfgang From lennart at augustsson.net Wed Oct 5 12:05:19 2005 From: lennart at augustsson.net (Lennart Augustsson) Date: Wed Oct 5 11:46:28 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <200510051733.53302.wolfgang@jeltsch.net> References: <3429668D0E777A499EE74A7952C382D104A5DEC1@EUR-MSG-01.europe.corp.microsoft.com> <200510051733.53302.wolfgang@jeltsch.net> Message-ID: <4343F9BF.50807@augustsson.net> Wolfgang Jeltsch wrote: > Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: > >>[...] > > >>Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; return >>()) as interchangeable, which is naughty, and people have occasionally >>noticed, but the benefits can sometimes be huge. It is this distinction >>that makes it hard to optimise IO code in a Haskell compiler, though. > > > I think, seq should be a method of a type class. Then we could forbid > applying seq to a function, we could forbid applying seq to an IO expression > and we could forbid applying seq to expressions of any type with hidden > implementation for which we don't want to provide bottom tests. I agree with you. And that is how it used to be, but then some people didn't think that was convenient enough so now we are stuck with a seq that (IMHO) stinks. :) -- Lennart From sebastian.sylvan at gmail.com Wed Oct 5 15:44:34 2005 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Oct 5 15:25:39 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <43427F78.4000507@mikeandkellycrowe.com> References: <4341FEA7.4010609@mikeandkellycrowe.com> <89ca3d1f0510040454x73d85e67u@mail.gmail.com> <43427F78.4000507@mikeandkellycrowe.com> Message-ID: <3d96ac180510051244h208bec18w72aa21d2bfc0001b@mail.gmail.com> On 10/4/05, Mike Crowe wrote: > Thanks, all, especially Cale for the detail. > > This may be unfair to ask, but is anybody willing to give an example? > There are great examples for writing factorials. However, that's not really > useful. I'm looking for a real-world example of using the language. > Specifically, the first page of About Haskell states: > WOW! I basically wrote this without testing just thinking about my program > in terms of transformations between types. What I'm still missing is how to > use this idea of functional programming to tie all this together. Let's > say, for example, I want to write a data input system for a database. > Consider these two examples: > > I think I understand how to take the following example (and others in that > library) and expand to a complete UI for the data input: > http://cvs.sourceforge.net/viewcvs.py/wxhaskell/wxhaskell/samples/wx/Grid.hs?rev=1.6&view=auto > > I also looked over the examples in > http://htoolkit.sourceforge.net/ for writing to a SQL > database. So I can see how to save the data. The following example I get > for inserting: > insertRecords :: Connection -> IO () > insertRecords c = do > execute c "insert into Test(id,name) values (1,'Test1')" > > How, though, would I start? If I did this in an imperative language, I > might do it like (in Python): > > def main: > if gridCtrl.Show(): # returns True if user exits > pressing Save > data = gridCtrl.getData() > dataBase.insertRecords(data) > > In Haskell, how would you start this at the top? How would you define a > relationship between two modules? > > If this is more detailed than I should ask in this list, please LMK. > > Thanks! > Mike In general you write a small "shell" of IO code as your base application. This IO code then calls the rest of the (non-IO-)functions and presents the result in some way. As you can see in the source code you linked you can attatch IO actions to events. E.g. set g [on gridEvent := onGrid] So to, for example, trigger a database update when the user presses a button, you would attatch the database-update action to the on click event for that button. You could also use partial application to pass along extra data that this function may need set but [on click := updateDB dbConnection] where dbConnection is some value representing a database connection and then in the function defintion: updateDB dbConn = do ... As you can see onGrid takes two parameters (everything it needs to do what you want it to do) but when you attatch it to the gridEvent you only pass it the first one (the event itself passes the second one). You would most likely want to pass other data to updateDB, such as the data that should be inserted into the table etc. You could e.g. pass the gridcontrol to updateDB and let the updateDB function extract the data from it and insert it into the database. So the main IO code is very imperative in look and feel, except that all data flow is explicit (and perhaps more importantly, that actions are first class citizens). So you could lay out your haskell IO code in much the same way as you would in an imperative language. As an aside. if you're going to use databases, consider using HaskellDB (an SQL "unwrapper"), which allows you type-safe database queries (pretty cool!). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 From sebastian.sylvan at gmail.com Wed Oct 5 15:46:40 2005 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Oct 5 15:27:44 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <3d96ac180510051244h208bec18w72aa21d2bfc0001b@mail.gmail.com> References: <4341FEA7.4010609@mikeandkellycrowe.com> <89ca3d1f0510040454x73d85e67u@mail.gmail.com> <43427F78.4000507@mikeandkellycrowe.com> <3d96ac180510051244h208bec18w72aa21d2bfc0001b@mail.gmail.com> Message-ID: <3d96ac180510051246l5c5ce088t6511b6960d1bf8ef@mail.gmail.com> On 10/5/05, Sebastian Sylvan wrote: > On 10/4/05, Mike Crowe wrote: > > Thanks, all, especially Cale for the detail. > > > > This may be unfair to ask, but is anybody willing to give an example? > > There are great examples for writing factorials. However, that's not really > > useful. I'm looking for a real-world example of using the language. > > Specifically, the first page of About Haskell states: > > WOW! I basically wrote this without testing just thinking about my program > > in terms of transformations between types. What I'm still missing is how to > > use this idea of functional programming to tie all this together. Let's > > say, for example, I want to write a data input system for a database. > > Consider these two examples: > > > > I think I understand how to take the following example (and others in that > > library) and expand to a complete UI for the data input: > > http://cvs.sourceforge.net/viewcvs.py/wxhaskell/wxhaskell/samples/wx/Grid.hs?rev=1.6&view=auto > > > > I also looked over the examples in > > http://htoolkit.sourceforge.net/ for writing to a SQL > > database. So I can see how to save the data. The following example I get > > for inserting: > > insertRecords :: Connection -> IO () > > insertRecords c = do > > execute c "insert into Test(id,name) values (1,'Test1')" > > > > How, though, would I start? If I did this in an imperative language, I > > might do it like (in Python): > > > > def main: > > if gridCtrl.Show(): # returns True if user exits > > pressing Save > > data = gridCtrl.getData() > > dataBase.insertRecords(data) > > > > In Haskell, how would you start this at the top? How would you define a > > relationship between two modules? > > > > If this is more detailed than I should ask in this list, please LMK. > > > > Thanks! > > Mike > > In general you write a small "shell" of IO code as your base > application. This IO code then calls the rest of the > (non-IO-)functions and presents the result in some way. > > As you can see in the source code you linked you can attatch IO > actions to events. E.g. > set g [on gridEvent := onGrid] > > So to, for example, trigger a database update when the user presses a > button, you would attatch the database-update action to the on click > event for that button. > > You could also use partial application to pass along extra data that > this function may need > > set but [on click := updateDB dbConnection] > > where dbConnection is some value representing a database connection > > and then in the function defintion: > > updateDB dbConn = do ... > > As you can see onGrid takes two parameters (everything it needs to do > what you want it to do) but when you attatch it to the gridEvent you > only pass it the first one (the event itself passes the second one). I meant updateDB and click-event and there respectively. Sorry. /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 From collinw at gmail.com Wed Oct 5 15:54:20 2005 From: collinw at gmail.com (Collin Winter) Date: Wed Oct 5 15:35:24 2005 Subject: [Haskell] Newbie quick questions In-Reply-To: <43427F78.4000507@mikeandkellycrowe.com> References: <4341FEA7.4010609@mikeandkellycrowe.com> <89ca3d1f0510040454x73d85e67u@mail.gmail.com> <43427F78.4000507@mikeandkellycrowe.com> Message-ID: <43aa6ff70510051254i20215a4du36dfd505d54b7740@mail.gmail.com> On 10/4/05, Mike Crowe wrote: > This may be unfair to ask, but is anybody willing to give an example? > There are great examples for writing factorials. However, that's not really > useful. I'm looking for a real-world example of using the language. You might be interested in Dazzle [1], which I recently read up on. It's a Bayesian network toolbox written in Haskell and using wxHaskell for the GUI side. The team behind it had a paper [2] accepted to the 2005 Haskell Workshop that details some of the tricks they used to do the GUI integration. Hope this helps. Collin Winter [1] http://www.cs.uu.nl/dazzle/ [2] http://www.cs.uu.nl/dazzle/f08-schrage.pdf From dons at cse.unsw.edu.au Wed Oct 5 20:11:33 2005 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Wed Oct 5 19:52:42 2005 Subject: [Haskell] Making shared libraries with Haskell In-Reply-To: <5C5F3768-9130-4895-8657-5C342D26A96E@gmail.com> References: <3429668D0E777A499EE74A7952C382D104A5DF95@EUR-MSG-01.europe.corp.microsoft.com> <5C5F3768-9130-4895-8657-5C342D26A96E@gmail.com> Message-ID: <20051006001133.GB3803@cse.unsw.EDU.AU> hs-plugins works on unix and windows :) -- Don joelr1: > Simon, > > It appears that hs-plugins supports this functionality. I don't care > if its bundles or shared libraries so long as I can use Haskell as a > DSL in some other program (game engine is what I had in mind). hs- > plugins appears to allow this, unless you are telling me it only > works on Windows :-). > > Joel > > On Oct 5, 2005, at 5:09 PM, Simon Marlow wrote: > > >It currently isn't possible to build a Unix-style .so from Haskell > >code > >using GHC, although there is work in this direction (PIC and shared > >libraries are supported on MacOS X, and other platforms are in > >progress). > > -- > http://wagerlabs.com/idealab > > > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell From simonmar at microsoft.com Thu Oct 6 04:51:01 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Oct 6 04:32:05 2005 Subject: [Haskell] strictness of putChar: report incomplete? Message-ID: <3429668D0E777A499EE74A7952C382D104A5E544@EUR-MSG-01.europe.corp.microsoft.com> On 05 October 2005 17:05, Lennart Augustsson wrote: > Wolfgang Jeltsch wrote: >> Am Mittwoch, 5. Oktober 2005 16:22 schrieb Simon Marlow: >> >>> [...] >> >> >>> Also, GHC's optimiser currently treats (_|_ :: IO a) and (do _|_; >>> return ()) as interchangeable, which is naughty, and people have >>> occasionally noticed, but the benefits can sometimes be huge. It >>> is this distinction that makes it hard to optimise IO code in a >>> Haskell compiler, though. >> >> >> I think, seq should be a method of a type class. Then we could >> forbid applying seq to a function, we could forbid applying seq to >> an IO expression and we could forbid applying seq to expressions of >> any type with hidden implementation for which we don't want to >> provide bottom tests. > > I agree with you. And that is how it used to be, but then > some people didn't think that was convenient enough so now > we are stuck with a seq that (IMHO) stinks. :) Having a seq that works on anything is occasionally very useful for fixing space leaks, and the type class version was kind of ugly and unwieldy. The type class pops up when you use ! in a data declaration, which looks strange. But I agree that polymorphic seq does have some painful side effects. Cheers, Simon From lennart at augustsson.net Thu Oct 6 08:48:40 2005 From: lennart at augustsson.net (Lennart Augustsson) Date: Thu Oct 6 08:29:48 2005 Subject: [Haskell] strictness of putChar: report incomplete? In-Reply-To: <3429668D0E777A499EE74A7952C382D104A5E544@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104A5E544@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <43451D28.4090209@augustsson.net> Simon Marlow wrote: >>I agree with you. And that is how it used to be, but then >>some people didn't think that was convenient enough so now >>we are stuck with a seq that (IMHO) stinks. :) > > > Having a seq that works on anything is occasionally very useful for > fixing space leaks, and the type class version was kind of ugly and > unwieldy. The type class pops up when you use ! in a data declaration, > which looks strange. But I agree that polymorphic seq does have some > painful side effects. Polymorphic seq is not lambda definable, which I dislike. -- Lennart From der_eq at freenet.de Thu Oct 6 14:35:57 2005 From: der_eq at freenet.de (Henning =?ISO-8859-1?Q?G=FCnther?=) Date: Thu Oct 6 14:17:01 2005 Subject: [Haskell] ANNOUNCE: pam-1.0 Message-ID: <1128623757.7618.10.camel@schleppi> pam-0.1 ------- Haskell bindings for pam. Weeeeeee! This is my first release _ever_. I've created it mainly for learning reasons and just want to share it with the haskell community. See http://haskell.org/pam for more information about it. Feedback is very welcome. :) It's very untested yet, so it'll possibly crash, turn your computer into smoke and talk dirty to you. Just don't blame me, I've only written it. From paul_bostonjp at hotmail.co.uk Sat Oct 8 13:36:49 2005 From: paul_bostonjp at hotmail.co.uk (paul boston) Date: Sat Oct 8 13:17:45 2005 Subject: [Haskell] SPJ book - big idea behind supercombinator reduction restriction Message-ID: Simon Peyton Jones's book "The Implementation of Functional Programming Languages", chapter 13 (Supercombinators and Lamba-lifting), page 222, describes a "multi-argument" beta-reduction strategy whereby several free variables of a multi-argument abstraction may be instantiated simultaneously. Then, on page 225 the following sentence appears: "A crucial point in the definition of a supercombinator given above is that a supercombinator reduction only takes place when all the arguments are present." I feel that there's some big idea in the pages between these two references, but I can't quite grasp it. I can appreciate that there are good reasons (e.g. efficiency) to instantiate several variables at once, but I don't quite understand why this restriction is "crucial". Is it crucial just for reasons of efficiency - and in actual fact it's entirely possible, albeit inefficient, to instantiate one variable at a time? Or is it, given that the whole point of supercombinators is to allow compilation to fixed code sequences for the G-machine, that there is a good reason to avoid having these fixed code sequences deal with instantiating one free variable at a time (simplicity of design, or some kind of restriction on the way that G-machine operations work)? Or is there a deeper theoretical reason related to the combinators themselves that has nothing to do with the downstream compilation process? _________________________________________________________________ Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters From benjamin.franksen at bessy.de Mon Oct 10 07:44:19 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Oct 10 07:25:11 2005 Subject: [Haskell] A haddock question Message-ID: <200510101344.19254.benjamin.franksen@bessy.de> Hello, I have a module with a public class plus some instances for public data types. In addition, I use this class inside another module where I declare local (module private) data types and make them instances of the class. I had expected that haddock (I am using 0.7) will list in the documentation only instances of data types that are exported, but instead all instances are listed. Is there a way to persuade haddock to list only instances of data types that are actually visible to the user? Ben From simonmar at microsoft.com Mon Oct 10 08:02:18 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Mon Oct 10 07:43:08 2005 Subject: [Haskell] A haddock question Message-ID: <3429668D0E777A499EE74A7952C382D104AE6006@EUR-MSG-01.europe.corp.microsoft.com> On 10 October 2005 12:44, Benjamin Franksen wrote: > I have a module with a public class plus some instances for public > data types. In addition, I use this class inside another module where > I declare local (module private) data types and make them instances of > the class. I had expected that haddock (I am using 0.7) will list in > the documentation only instances of data types that are exported, but > instead all instances are listed. > > Is there a way to persuade haddock to list only instances of data > types that are actually visible to the user? Haddock's support for instances is somewhat braindead - it just reports all the instances it can find for a given class in the entire set of modules it is processing. In particular, Haddock makes no attempt to tell you how to bring these instances into scope: they might not be available from the module that exports the class, or the type(s), involved in the instance. Haskell makes this quite hard: an instance is available if it is provided by the transitive closure of an imported module. We clearly don't want to report all the available instances in every module's documentation, however. This is exposes to the user From simonmar at microsoft.com Mon Oct 10 08:06:33 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Mon Oct 10 07:47:26 2005 Subject: [Haskell] A haddock question Message-ID: <3429668D0E777A499EE74A7952C382D104AE601C@EUR-MSG-01.europe.corp.microsoft.com> [please excuse premature send.] On 10 October 2005 12:44, Benjamin Franksen wrote: > I have a module with a public class plus some instances for public > data types. In addition, I use this class inside another module where > I declare local (module private) data types and make them instances of > the class. I had expected that haddock (I am using 0.7) will list in > the documentation only instances of data types that are exported, but > instead all instances are listed. > > Is there a way to persuade haddock to list only instances of data > types that are actually visible to the user? Haddock's support for instances is somewhat braindead - it just reports all the instances it can find for a given class in the entire set of modules it is processing. In particular, Haddock makes no attempt to tell you how to bring these instances into scope: they might not be available from the module that exports the class, or the type(s), involved in the instance. Haskell makes this quite hard: an instance is available if it is provided by the transitive closure of an imported module. We clearly don't want to report all the available instances in every module's documentation, however. We probably don't want to document every module from which an instance is available either. Nevertheless, doing one of these two would be "correct". I'm open to suggestions. Benjamin: your example is probably more simple, Haddock probably just shouldn't be exposing those instances if they refer to non-exported types, I just wanted to point out the more general problem. Cheers, Simon From simonpj at microsoft.com Mon Oct 10 08:21:30 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 10 08:02:20 2005 Subject: [Haskell] SPJ book - big idea behind supercombinator reductionrestriction Message-ID: <036EAC76E7F5EC4996A3B3C3657D411603639D41@EUR-MSG-21.europe.corp.microsoft.com> | Is it crucial just for reasons of efficiency - and in actual fact it's | entirely possible, albeit inefficient, to instantiate one variable at a | time? That's exactly right. Simon From wolfgang at jeltsch.net Mon Oct 10 09:17:05 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 10 08:57:56 2005 Subject: [Haskell] A haddock question In-Reply-To: <200510101344.19254.benjamin.franksen@bessy.de> References: <200510101344.19254.benjamin.franksen@bessy.de> Message-ID: <200510101517.05701.wolfgang@jeltsch.net> Am Montag, 10. Oktober 2005 13:44 schrieb Benjamin Franksen: > [...] > Is there a way to persuade haddock to list only instances of data types > that are actually visible to the user? I experienced the same problem and worked around it by enclosing the instance declarations for private data types with #ifndef __HADDOCK__ and #endif. > Ben Best wishes, Wolfgang From jgoerzen at complete.org Mon Oct 10 09:27:34 2005 From: jgoerzen at complete.org (John Goerzen) Date: Mon Oct 10 09:08:33 2005 Subject: [Haskell] ANN: MissingH 0.12.0 (Better binary file support) Message-ID: <20051010132734.GA9681@katherina.lan.complete.org> MissingH 0.12.0 is now available. Changes from 0.11.5 include: * MissingH.IO.Binary can now work with Strings or [Word8], instead of just strings. This support is implemented with a typeclass, so the module is fully backwards-compatible. * MissingH.IO.Binary can now work with any HVIO object, not just Handles. * New support for binary I/O in MissingH.IO.HVIO and HVFS. * Updated BlockIO and Threads.Child to 2005-02-14 versions from Peter. * MissingH.IO.Binary.hBlockCopy optimized to require no conversion of the buffer. * Fixed docs to work with Haddock 0.7 * New module MissingH.Daemon to support detaching from a controlling terminal * New simplegrep.hs example MissingH homepage: http://quux.org/devel/missingh or gopher://quux.org/1/devel/missingh MissingH source and Debian packages are also available from any Debian mirror, such as: http://http.us.debian.org/debian/pool/main/m/missingh (There is approximately a 48-hour delay before new versions appear there.) Currently in development for MissingH 0.13.0: * Native Haskell support for creating and extracting tar files * E-mail mailbox abstraction and implementation for Maildirs and MBOXes -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 From benjamin.franksen at bessy.de Mon Oct 10 09:28:18 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Oct 10 09:09:11 2005 Subject: [Haskell] A haddock question In-Reply-To: <3429668D0E777A499EE74A7952C382D104AE601C@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104AE601C@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <200510101528.18874.benjamin.franksen@bessy.de> On Monday 10 October 2005 14:06, Simon Marlow wrote: > On 10 October 2005 12:44, Benjamin Franksen wrote: > > I have a module with a public class plus some instances for public > > data types. In addition, I use this class inside another module > > where I declare local (module private) data types and make them > > instances of the class. I had expected that haddock (I am using > > 0.7) will list in the documentation only instances of data types > > that are exported, but instead all instances are listed. > > > > Is there a way to persuade haddock to list only instances of data > > types that are actually visible to the user? > > Haddock's support for instances is somewhat braindead - it just > reports all the instances it can find for a given class in the entire > set of modules it is processing. In particular, Haddock makes no > attempt to tell you how to bring these instances into scope: they > might not be available from the module that exports the class, or the > type(s), involved in the instance. > > Haskell makes this quite hard: an instance is available if it is > provided by the transitive closure of an imported module. We clearly > don't want to report all the available instances in every module's > documentation, however. We probably don't want to document every > module from which an instance is available either. Nevertheless, > doing one of these two would be "correct". I'm open to suggestions. > > Benjamin: your example is probably more simple, Haddock probably just > shouldn't be exposing those instances if they refer to non-exported > types, I just wanted to point out the more general problem. Yes, I can see that the general problem is hard to solve. I don't have any suggestions how to change the haddock behavior with instances in general (i.e apart from fixing the obvious bug regarding non-exported data types). One could even argue that haddock isn't the right place to provide a solution and that instead the language itself should be fixed. I know this problem is even harder to solve. To make things worse, I don't even have a concrete proposal for how to do this and still enjoy all the nice features Haskell's type classes provide. But since you brought up the general issue, let me just point out, that the interaction between type classes and the module system is arguably the most problematic aspect of Haskell as it stands. As a programmer (I am not a language designer), this is the point I most often stumble upon. IMO, Haskell's module system is just a bit too weak for "programming in the large". While type classes (with the usual extensions) seem to provide a lot more flexibility and generality, they are burdened with their unfortunate interaction with the module system. Don't get me wrong: Of course it is possible to program large systems in Haskell (witness ghc and a growing number of medium and large size projects). It is just that many of Haskell's great advantages when "programming in the small" do not, IMO, appropriately scale to large systems. Witness to this is the still missing "grand unified data structure library": The problem here is /not/ that there don't exist good implementations. The problem is how to integrate all of them into a common framework, with minimal redundancy between interfaces, and a maximum of re-use. A related problem is Haskell's weak support for abstract data types, at least when constrasted with the ease which with concrete data types can be craeted and used. I think, this is /the/ most important point that should be addressed in some future Haskell2 standard. I vaguely imagine some kind of unification of the concepts type class/instance and module into a new entity that enables the programmer to talk about interfaces and their implementation and at the same time control how names are re-used on the global level (and, ideally, enable some sort of pattern-matching on abstract data types). I have read about proposals to allow 'named' or 'scoped' instances and I believe that there are some interesting ideas. Maybe someone with the right education and experience in language/type system design should review such proposals and see if some coherent whole can be made out of them. Cheers, Ben From benjamin.franksen at bessy.de Mon Oct 10 09:30:55 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Mon Oct 10 09:11:46 2005 Subject: [Haskell] A haddock question In-Reply-To: <200510101517.05701.wolfgang@jeltsch.net> References: <200510101344.19254.benjamin.franksen@bessy.de> <200510101517.05701.wolfgang@jeltsch.net> Message-ID: <200510101530.55593.benjamin.franksen@bessy.de> On Monday 10 October 2005 15:17, Wolfgang Jeltsch wrote: > Am Montag, 10. Oktober 2005 13:44 schrieb Benjamin Franksen: > > [...] > > > > Is there a way to persuade haddock to list only instances of data > > types that are actually visible to the user? > > I experienced the same problem and worked around it by enclosing the > instance declarations for private data types with #ifndef __HADDOCK__ > and #endif. That seems like a good work-around, for the moment. Thanks for the suggestion. Ben From oleg at pobox.com Tue Oct 11 02:04:28 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Tue Oct 11 01:46:49 2005 Subject: [Haskell] getArgs, maxBound, float division: pure functions? Message-ID: <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil> The question of getArgs as a pure function has already been debated on this list back in January: http://www.haskell.org/pipermail/haskell/2005-January/015184.html The topic seems worth revisiting as it expands to a bigger, and perhaps, a bleaker picture. To recap, there were two arguments for getArgs to remain with the IO [String] type: 1. getArgs is the function of the environment and does not have a clear denotation. The value of getArgs may change from one program run to another. 2. The existence of System.Environment.withArgs Regarding argument 1: the value of |maxBound :: Int| is also the function of the environment. Haskell98 Report says [p82, Section 6.4] The finite-precision integer type Int covers at least the range [ - 2^29 , 2^29 - 1 ]. As Int is an instance of the Bounded class, maxBound and minBound can be used to determine the exact Int range defined by an implementation. Thus, the value of |maxBound :: Int| may conceivably change from on program run (under runhugs32 on an AMD64 platform) to another (under runghc64 on the same platform). The Haskell98 Report, in section 6.4.6 defines other implementation-dependent functions: floatRadix, floatDigits, and floatRange. The GHC documentation [ghc6/libraries/base/Prelude.html#t%3ARealFloat] is particularly revealing: floatRadix :: a -> Integer a constant function, returning the radix of the representation (often 2) Some may find the phrase ``constant function that often [sic!] has the value 2'' to be incompatible with the notion of a pure function. Regarding argument 2: the existence of System.Environment.withArgs seems to doom getArgs to remain with the IO type. It cannot be a pure function. The simple extension of the argument points however to inconsistency with the floating-point facility. Haskell98 Report permits an implementation to use IEEE FP for Haskell Floats and Doubles. The Report specifically provides the class RealFrac to give a program access to some aspects of the IEEE FP system. IEEE FP computations are sensitive to the rounding mode, which is observable in pure code. The rounding mode can be changed. The following simple program shows > {-# OPTIONS -fglasgow-exts #-} > -- Tested on GHC 6.4 on on i686/Linux > > module FP where > import Foreign.C > > eps ::Float = 2^^(1-24) > > -- from /usr/include/bits/fenv.h > > type FP_RND_T = CInt -- fenv.h > > eFE_TONEAREST = 0 > eFE_DOWNWARD = 0x400 > eFE_UPWARD = 0x800 > eFE_TOWARDZERO = 0xc00 > > foreign import ccall "fenv.h fegetround" fegetround > :: IO FP_RND_T > > foreign import ccall "fenv.h fesetround" fesetround > :: FP_RND_T -> IO FP_RND_T > > test1 = do > let tf () = 1 + eps/2 > let tfe = tf () > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > > old <- fesetround eFE_UPWARD > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > > fesetround old > putStrLn "Rounding mode and the result" > fegetround >>= print > print $ tf () > print $ tfe > print "Done" that the supposedly pure computation "1 + eps/2" is not, in fact, referentially transparent. Should all floating-point computations be put in the IO monad? Granted, FP addition, among other operations, is not associative; so one may even wonder if FP can be done in any monad at all. OTH, when it comes to IO, the monad laws are usually stretched. From hcar at haskell.org Tue Oct 11 04:51:47 2005 From: hcar at haskell.org (Andres Loeh) Date: Tue Oct 11 04:29:54 2005 Subject: [Haskell] Call for Contributions - HC&A Report (November 2005 edition) Message-ID: <20051011085147.GE562@iai.uni-bonn.de> Dear Haskellers, it is nearly time for the ninth edition of the ================================================================ Haskell Communities & Activities Report http://www.haskell.org/communities/ Submission deadline: 1 November 2005 (please send your contributions to hcar at haskell.org, in plain ASCII or LaTeX format) ================================================================ This is the short story: * If you are working on any project that is in some way related to Haskell, write a short entry and submit it to the me. * If you are interested any project related to Haskell that has not previously been mentioned in the HC&A Report, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities & Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming 6 months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2005 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the beginning of November. They will be compiled into a coherent report which will appear sometime during November. As always, this is a great opportunity to update your webpages, make new releases, announce of even start new projects, or to point at some developments you want every Haskeller to see! As the purpose of the report is to collect recent or current activities, I encourage you to update all existing summaries and reports. I will probably drop any topics that have not had any activity for the past year, i.e., since November 2004, but I would very much prefer you to present an updated description of the topic. Of course, new entries are more than welcome. Reports should generally be kept brief and informative, ranging from a few sentences to a few hundred words, to keep the whole report reasonably sized. Looking forward to your contributions, Andres (current editor) ----------------------------------- topics New suggestions for current hot topics, activities, projects, etc. are welcome - especially with names and addresses of potential contacts, but here is a non-exclusive list of likely topics (see also http://www.haskell.org/communities/topics.html ): General Haskell developments Haskell implementations Haskell extensions Standardization Documentation Libraries Papers and Books Feedback Summaries of discussions in specialist mailing lists Conference reports Community activities Other Haskell information channels (TMR, Sequence, HWN, ...) Announcements Everything that's new or has had new releases Ongoing projects Reports on what's happening behind the scenes Confirmations that projects are still maintained Calls for contributions and contributors Tutorials Tools and Applications Released and unreleased Haskell applications Tools useful for Haskell programmers Experiences with using Haskell for a project Commercial uses of Haskell Even if your topic is not listed in this list, there's a good chance it has a place in the Report. Please get in touch with me. If you want to see an entry that hasn't been there in the past, but you are not the maintainer of the project, then please encourage the maintainers to write an entry/update, or ask permission to write the entry yourself. -------------------------- what should I write? That depends on your topic, but as a general rule, it shouldn't take you long. A simple sentence or two about your use of Haskell could go into the "Individual Haskellers" section. If you're a company, or if you're working on a project using Haskell as the implementation language, a paragraph on that could go into the "Applications" section. A typical summary report about a tool/library/project/application/... would be between 1 and 3 paragraphs of ASCII text (what's it about? major topics and results since the last report? current hot topics? major goals for the next six months?) plus pointers to material for further reading (typically to a home page, or to mailing list archives, specifications and drafts, implementations, meetings, minutes, ...). Browsing through previous editions should give you a good idea of the variety of possibilities, ranging from very brief to extensive. For those who prefer templates to fill in, the report is edited in LaTeX, and an entry template might look something like this: \begin{hcarentry}{} \report{} \status{} \makeheader \FurtherReading \url{} \end{hcarentry} A style file to preview your document using this template is available at http://haskell.org/communities/11-2005/hcar.sty From jgoerzen at complete.org Tue Oct 11 12:45:18 2005 From: jgoerzen at complete.org (John Goerzen) Date: Tue Oct 11 12:26:23 2005 Subject: [Haskell] Haskell Weekly News: October 11, 2005 Message-ID: <20051011164518.GA17343@katherina.lan.complete.org> Haskell Weekly News: October 11, 2005 Greetings, and thanks for reading the 11th issue of HWN, a weekly newsletter for the Haskell community. Each Tuesday, new editions will be posted (as text) to [1]the Haskell mailing list and (as HTML) to [2]The Haskell Sequence. 1. http://www.haskell.org/mailman/listinfo/haskell 2. http://sequence.complete.org/ New Releases * PAM 1.0. Henning Guenther [3]announced version 1.0 of his bindings to the PAM authentication libary. 3. http://article.gmane.org/gmane.comp.lang.haskell.general/12250 * cpphs 1.0. Malcolm Wallace [4]announced the release of cpphs version 1.0. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12233 * MissingH 0.12.0. John Goerzen [5]announced MissingH 0.12.0, which added various enhancements to its binary I/O utilities. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/12257 Calls for Participation * Haskell Communities & Activities Report. Andres Loeh [6]posted a call for contributions to the periodic report. Anyone that's part of a Haskell team, has published Haskell code, written Haskell-related papers or books, etc. is encouraged to submit a short entry about their activities. 6. http://article.gmane.org/gmane.comp.lang.haskell.general/12261 Discussion Papers from the 2005 Haskell Workship. Dimitry Golubovsky [7]noted that papers from the workshop on the ACM site required a login to read. Simon Marlow posted a free link to the papers he co-authored. 7. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8580 IRC for spreading information. John Goerzen [8]wrote about some concerns regarding using IRC for spreading information to the Haskell community, such as happened recently. It received some discussion on #haskell. 8. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8573 Reducing memory usage. Young Hyun began an interesting [9]thread about tracking down mysterious cases of high RAM usage. Several people made suggestions for things to try, including things that would be useful to others. 9. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8637 Memoization. Gerd M [10]wondered why Data.Map was slower than he expected in his program. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8610 Monad Syntax. Tom Hawkins [11]asked about the syntax "| m -> s" in class declarations. Several people explained that this has to do with functional dependencies, an extension to Haskell 98. 11. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8601 Alternatives to hs-plugins. John Goerzen [12]posted a scenario in which hs-plugins would be useful, but where concerns about its portability may render it inappropriate. Nils Anders Danielsson replied with a link to his code that can call Hugs to dynamically evaluate Haskell snippets. 12. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8592 Haskell Toolchain Converting fptools to Darcs. Simon Marlow [13]wrote about his ideas for converting fptools from CVS to Darcs. Several people made suggestions and asked questions. 13. http://news.gmane.org/gmane.comp.version-control.darcs.user About Haskell Weekly News Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [14]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 14. http://sequence.complete.org/hwn-contrib From oleg at pobox.com Tue Oct 11 20:25:24 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Tue Oct 11 20:07:45 2005 Subject: [Haskell] How to zip folds: A library of fold transformers In-Reply-To: <20051006183104.GB595@sleepingsquirrel.org> Message-ID: <20051012002524.7A387ACB2@Adric.metnet.navy.mil> We show how to merge two folds into another fold `elementwise'. Furthermore, we present a library of (potentially infinite) ``lists'' represented as folds (aka streams, aka success-failure-continuation--based generators). Whereas the standard Prelude functions such as |map| and |take| transform lists, we transform folds. We implement the range of progressively more complex transformers -- from |map|, |filter|, |takeWhile| to |take|, to |drop| and |dropWhile|, and finally, |zip| and |zipWith|. Emphatically we never convert a stream to a list and so we never use value recursion. All iterative processing is driven by the fold itself. The implementation of zip also solves the problem of ``parallel loops''. One can think of a fold as an accumulating loop. One can easily represent a nested loop as a nested fold. Representing parallel loop as a fold is a challenge, answered at the end of the message. We need recursive types -- but again, never value recursion. This library is inspired by Greg Buchholz' message on the Haskell-Cafe list and is meant to answer open questions posed at the end of that message http://www.haskell.org/pipermail/haskell-cafe/2005-October/011575.html This message a complete literate Haskell code. > {-# OPTIONS -fglasgow-exts #-} > module Folds where First we define the representation of a list as a fold: > newtype FR a = FR (forall ans. (a -> ans -> ans) -> ans -> ans) > unFR (FR x) = x It has a rank-2 type. The defining equations are: if flst is a value of a type |FR a|, then unFR flst f z = z if flst represents an empty list unFR flst f z = f e (unFR flst' f z) if flst represents the list with the head 'e' and flst' represents the rest of that list >From another point of view, |unFR flst| can be considered a _stream_ that takes two arguments: the success continuation of the type |a -> ans -> ans| and the failure continuation of the type |ans|. The LogicT paper discusses such types in detail, and shows how to find that "rest of the list" flst'. The slides of the ICFP05 presentation by Chung-chieh Shan point out to more related work in that area. But we are here to drop, take, dropWhile, etc. Our functions will take a stream and return another stream, of the |FR a| type, which represents truncated, filtered, etc. source stream. Let us define two sample streams: a finite and an infinite one: > stream1 :: FR Char > stream1 = FR (\f unit -> foldr f unit ['a'..'i']) > stream2 :: FR Int > stream2 = FR (\f unit -> foldr f unit [1..]) and the way to show the stream. This is the only time we convert |FR a| to a list -- so we can more easily show it. > instance Show a => Show (FR a) where > show l = show $ unFR l (:) [] The map function is trivial: > smap :: (a->b) -> FR a -> FR b *> smap f l = FR(\g -> unFR l (g . f)) which can also be written as > smap f l = FR((unFR l) . (flip (.) f)) For example, > test1 = show $ smap succ stream1 Next is the filter function: > sfilter :: (a -> Bool) -> FR a -> FR a > sfilter p l = FR(\f -> unFR l (\e r -> if p e then f e r else r)) > test2 = sfilter (not . (`elem` "ch")) stream1 The function takeWhile is quite straightforward, too > stakeWhile :: (a -> Bool) -> FR a -> FR a > stakeWhile p l = FR(\f z -> unFR l (\e r -> if p e then f e r else z) z) > test3 = stakeWhile (< 'z') stream1 > test3' = stakeWhile (< 10) stream2 As we can see, stakeWhile well applies to an infinite stream. The functions take, drop, dropWhile ask for more complexity. > stake :: (Ord n, Num n) => n -> FR a -> FR a > stake n l = FR(\f z -> > unFR l (\e r n -> if n <= 0 then z else f e (r (n-1))) (const z) n) > test4 = stake 20 stream1 > test4' = stake 5 stream1 > test4'' = stake 11 stream2 > test4''' = (stake 11 . smap (^2)) stream2 The function sdrop shows the major deficiency: we're stuck with the (<=0) test for the rest of the stream. In this case, some delimited continuation operators like `control' can help, in limited circumstances. > sdrop :: (Ord n, Num n) => n -> FR a -> FR a > sdrop n l = FR(\f z -> > unFR l (\e r n -> if n <= 0 then f e (r n) else r (n-1)) (const z) n) > test5 = sdrop 20 stream1 > test5' = sdrop 5 stream1 > test5'' = stake 5 $ sdrop 11 stream2 The function dropWhile becomes straightforward > sdropWhile :: (a -> Bool) -> FR a -> FR a > sdropWhile p l = FR(\f z -> > unFR l (\e r done -> > if done then f e (r done) > else if p e then r done else f e (r True)) (const z) False) > test6 = sdropWhile (< 'z') stream1 > test6' = sdropWhile (< 'd') stream1 > test6'' = stake 5 $ sdropWhile (< 10) stream2 The zip function is the most complex. Here we need a recursive type: an iso-recursive type to emulate the equi-recursive one. > newtype RecFR a ans = RecFR (a -> (RecFR a ans -> ans) -> ans) > unRecFR (RecFR x) = x This is still a newtype: there is no extra consing. I will not pretend that the following is the most perspicuous piece of code: *> szip :: FR a1 -> FR a2 -> FR (a1,a2) *> szip l1 l2 = FR(\f z -> *> let l1' = unFR l1 (\e r x -> unRecFR x e r) (\r -> z) *> l2' = unFR l2 (\e2 r2 e1 r1 -> f (e1,e2) (r1 (RecFR r2))) (\e r-> z) *> in l1' (RecFR l2')) It can be simplified to the following: > szipWith :: (a->b->c) -> FR a -> FR b -> FR c > szipWith t l1 l2 = FR(\f z -> > unFR l1 (\e r x -> unRecFR x e r) (\x -> z) > (RecFR $ > unFR l2 (\e2 r2 e1 r1 -> f (t e1 e2) (r1 (RecFR r2))) (\e r -> z))) > > szip :: FR a -> FR b -> FR (a,b) > szip = szipWith (,) One can easily prove that this function does correspond to zip for all finite streams. The proof for infinite streams requires more elaboration. > test81 = szip stream1 stream1 > test82 = szip stream1 stream2 > test83 = szip stream2 stream1 > test84 = stake 5 $ szip stream2 (sdrop 10 stream2) As one may expect (or not), these tests give the right results *Folds> test83 [(1,'a'),(2,'b'),(3,'c'),(4,'d'),(5,'e'),(6,'f'),(7,'g'),(8,'h'),(9,'i')] *Folds> test84 [(1,11),(2,12),(3,13),(4,14),(5,15)] From zednenem at psualum.com Wed Oct 12 00:05:39 2005 From: zednenem at psualum.com (David Menendez) Date: Tue Oct 11 23:46:27 2005 Subject: [Haskell] getArgs, maxBound, float division: pure functions? In-Reply-To: <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil> Message-ID: oleg@pobox.com writes: > Regarding argument 1: the value of |maxBound :: Int| is also the > function of the environment. Haskell98 Report says [p82, Section > 6.4] > > The finite-precision integer type Int covers at least the range > [ - 2^29 , 2^29 - 1 ]. As Int is an instance of the Bounded class, > maxBound and minBound can be used to determine the exact Int range > defined by an implementation. > > Thus, the value of |maxBound :: Int| may conceivably change from on > program run (under runhugs32 on an AMD64 platform) to another (under > runghc64 on the same platform). I guess we could declare 32- and 64-bit Ints to be distinct types, and then do a system call to get the native Int type. data SomeIntegral = forall a. Integral a => SomeIntegral a nativeInt :: IO SomeIntegral main = case nativeInt of SomeIntegral (_::int) -> print (maxBound :: int) The disadvantage would be the need for polymorphism over the Integral class whenever we wanted native-sized integers. > Regarding argument 2: the existence of System.Environment.withArgs > seems to doom getArgs to remain with the IO type. It cannot be a pure > function. The simple extension of the argument points however to > inconsistency with the floating-point facility. Haskell98 Report > permits an implementation to use IEEE FP for Haskell Floats and > Doubles. The Report specifically provides the class RealFrac to give a > program access to some aspects of the IEEE FP system. IEEE FP > computations are sensitive to the rounding mode, which is observable > in pure code. The rounding mode can be changed. [...] Should all > floating-point computations be put in the IO monad? In principle, you could use seperate types to distinguish floats with different rounding modes, but I imagine this would be difficult or annoying to implement. -- David Menendez From john at repetae.net Wed Oct 12 00:29:56 2005 From: john at repetae.net (John Meacham) Date: Wed Oct 12 00:10:59 2005 Subject: [Haskell] getArgs, maxBound, float division: pure functions? In-Reply-To: References: <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil> Message-ID: <20051012042956.GI21098@momenergy.repetae.net> On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote: > In principle, you could use seperate types to distinguish floats with > different rounding modes, but I imagine this would be difficult or > annoying to implement. I think it would make more sense to have different operations for each rounding mode. That matches the reality of the situation more and you don't want to have to do tons of type conversions when you need to operate on something with different rounding modes. of course, then you could declare several 'newtypes' whose default Num instances were of specific rounding modes too. John -- John Meacham - ?repetae.net?john? From grelck at isp.uni-luebeck.de Tue Oct 11 06:18:22 2005 From: grelck at isp.uni-luebeck.de (Clemens Grelck) Date: Wed Oct 12 00:45:48 2005 Subject: [Haskell] CFP: PAPP 2006 Message-ID: <434B916E.3050202@isp.uni-luebeck.de> --------------------------------------------------------------------- Please accept our apologies if you have received multiple copies. Please feel free to distribute it to those who might be interested. --------------------------------------------------------------------- ---------------------------------------------------------- CALL FOR PAPERS PAPP 2006 Third International Workshop on Practical Aspects of High-level Parallel Programming http://graal.ens-lyon.fr/~abenoit/conf/papp2006.html part of ICCS 2006 The International Conference on Computational Science May 28-31, 2006, University of Reading, UK ---------------------------------------------------------- AIMS AND SCOPE Computational Science applications are more and more complex to develop and require more and more computing power. Parallel and grid computing are solutions to the increasing need for computing power. High level languages offer a high degree of abstraction which ease the development of complex systems. Moreover, being based on formal semantics, it is possible to certify the correctness of critical parts of the applications. Algorithmic skeletons, parallel extensions of functional languages such as Haskell and ML, parallel logic and constraint programming, parallel execution of declarative programs such as SQL queries, etc. have produced methods and tools that improve the price/performance ratio of parallel software, and broaden the range of target applications. The PAPP workshop focuses on practical aspects of high-level parallel programming: design, implementation and optimization of high-level programming languages and tools (performance predictors working on high-level parallel/grid source code, visualisations of abstract behaviour, automatic hotspot detectors, high-level GRID resource managers, compilers, automatic generators, etc.), applications in all fields of computational science, benchmarks and experiments. Research on high-level grid programming is particularly relevant. The PAPP workshop is aimed both at researchers involved in the development of high level approaches for parallel and grid computing and computational science researchers who are potential users of these languages and tools. TOPICS We welcome submission of original, unpublished papers in English on topics including: * high-level models (CGM, BSP, MPM, LogP, etc.) and tools for parallel and grid computing * high-level parallel language design, implementation and optimisation * functional, logic, constraint programming for parallel, distributed and grid computing systems * algorithmic skeletons, patterns and high-level parallel libraries * generative (e.g. template-based) programming with algorithmic skeletons, patterns and high-level parallel libraries * applications in all fields of high-performance computing (using high-level tools) * benchmarks and experiments using such languages and tools PAPER SUBMISSION AND PUBLICATION Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Papers will go through a rigorous reviewing process. Each paper will be reviewed by at least three referees. The accepted papers will be published in the Springer-Verlag Lecture Notes in Computer Science (LNCS) series, as part of the ICCS proceedings. Submission must be done through the ICCS website: http://www.iccs-meeting.org/iccs2006/papers/upload.php We invite you to submit a full paper of 8 pages formatted according to the rules of LNCS, describing new and original results, no later than December 2, 2005. Submission implies the willingness of at least one of the authors to register and present the paper. An early email to Anne.Benoit at ens-lyon.fr with your intention to submit a paper would be greatly appreciated (especially if you have doubts about the relevance of your paper). Accepted papers should be presented at the workshop and extended and revised versions will be published in a special issue of Parallel and Distributed Computing Practices, provided revisions suggested by the referees are made. IMPORTANT DATES December 2, 2005 Full paper due January 31, 2006 Referee reports and notification February 10, 2006 Camera-ready paper due May 2006 Journal version due June 2006 Referee reports July-October 2006 Revision of papers, final notification November 2006 Final paper due PROGRAM COMMITTEE Marco Aldinucci (CNR/Univ. of Pisa, Italy) Olav Beckmann (Imperial College London, UK) Anne Benoit (ENS Lyon, France) Alexandros Gerbessiotis (NJIT, USA) Stephen Gilmore (Univ. of Edinburgh, UK) Clemens Grelck (Univ. of Luebeck, Germany) Christoph Herrmann (Univ. of Passau, Germany) Zhenjiang Hu (Univ. of Tokyo, Japan) Fr?d?ric Loulergue (Univ. Orl?ans, France) Casiano Rodriguez Leon (Univ. La Laguna, Spain) Alexander Tiskin (Univ. of Warwick, UK) ORGANIZERS Dr. Anne BENOIT Laboratoire d'Informatique du Parall?lisme Ecole Normale Sup?rieure de Lyon 46 All?e d'Italie 69364 Lyon Cedex 07 - France Pr. Fr?d?ric LOULERGUE Laboratoire d'Informatique Fondamentale d'Orl?ans Universit? d'Orl?ans B?timent IIIA - Rue L?onard de Vinci - BP6759 45067 Orl?ans Cedex 2 - France From marcello at liacs.nl Tue Oct 11 09:13:04 2005 From: marcello at liacs.nl (M.M. Bonsangue) Date: Wed Oct 12 00:45:49 2005 Subject: [Haskell] FMCO 2005: second call for participation Message-ID: <200510111313.j9BDD4F11370@tin.liacs.nl> Our apologies if you receive multiple copies of this e-mail. ****************** SECOND CALL FOR PARTICIPATION ******************** Fourth International Symposium on Formal Methods for Components and Objects (FMCO 2005) DATES 1 - 4 November 2005 PLACE CWI, Amsterdam, The Netherlands The early registration deadline is about to close (October 15th)! For more information please visit the FMCO web site at http://fmco.liacs.nl/fmco05.html This year's conference program includes: * Eleven outstanding keynote speakers: - Michael Barnett (Microsoft, USA) - Luís Caires (New University of Lisbon, PT) - Dennis Dams (Bell Labs, USA) - Wan Fokkink (Free University, NL) - Orna Grumberg (Technion, ISR) - Joost-Pieter Katoen (RWTH Aachen, DE) - Kung-Kiu Lau (University of Manchester, UK) - Peter O' Hearn (Queen Mary University of London, UK) - Arnd Poetzsch-Heffter (University of Kaiserslautern, DE) - John Reynolds (Carnegie Mellon University, USA) - Davide Sangiorgi (University of Bologna, IT) - Jan van Schuppen (CWI, NL) * Ten selected tutorials For full details see the conference web site http://fmco.liacs.nl/fmco05.html We look forward to see you in Amsterdam. The FMCO 2005 Organizing Committee F.S. de Boer (CWI and LIACS - Leiden University) M.M. Bonsangue (LIACS - Leiden University) S. Graf (Verimag) W.P. de Roever (Kiel University) From lisper at it.kth.se Wed Oct 12 06:04:31 2005 From: lisper at it.kth.se (Bjorn Lisper) Date: Wed Oct 12 05:45:18 2005 Subject: [Haskell] getArgs, maxBound, float division: pure functions? In-Reply-To: <20051012042956.GI21098@momenergy.repetae.net> (message from John Meacham on Tue, 11 Oct 2005 21:29:56 -0700) References: <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil> <20051012042956.GI21098@momenergy.repetae.net> Message-ID: <200510121004.j9CA4Vj6003673@ripper.it.kth.se> John Meacham: >On Wed, Oct 12, 2005 at 12:05:39AM -0400, David Menendez wrote: >> In principle, you could use seperate types to distinguish floats with >> different rounding modes, but I imagine this would be difficult or >> annoying to implement. > >I think it would make more sense to have different operations for each >rounding mode. That matches the reality of the situation more and you >don't want to have to do tons of type conversions when you need to >operate on something with different rounding modes. of course, then you >could declare several 'newtypes' whose default Num instances were of >specific rounding modes too. A student of mine designed a special-purpose, pure functional language for block-oriented matrix computations for his PhD. He was very careful to give the language a good design also regarding floating-point computations. His design choice, as regards rounding, was to allow the compiler to choose rounding mode by default (thus allowing more freedom for optimization), while providing a set of special arithmetic operators, with specified rounding modes, to use when more explicit control is needed. He also proposed a special construct "letctrl ... in e", where the "..." are a list of directives telling how to interpret and evaluate the expression e. One possible directive is "RoundingMode = ..." to set the rounding mode locally in e. Other directives control, for instance, whether optimizations like x*0.0 -> 0.0 are allowed in e, whether to force strict evaluation of all subexpressions (so optimizations cannot affect exceptions), to set allowed miminum accuracy, etc. The language has exception handling (including a "handle" construct to catch exceptions), which also takes care of floating-point exceptions. If Haskell ever gets redesigned to give better support for numerical computations, then I think this work is worth a look. Alas, it is not well-published, but the PhD thesis should be possible to order from the Dept. of Information Technology and Microelectronics at KTH. I also have a few copies to give away of someone is interested. Here's the reference: @PHDTHESIS{npd-phd, AUTHOR = {N. Peter Drakenberg}, TITLE = {Computational Structure and Language Design}, SCHOOL = {Dept.\ of Information Technology and Microelectronics, KTH}, ADDRESS = {Stockholm}, YEAR = {2004}, MONTH = sep, NOTE = {TRITA-IMIT-LECS AVH 04:02} } Björn Lisper From ralfla at microsoft.com Wed Oct 12 06:18:37 2005 From: ralfla at microsoft.com (Ralf Lammel) Date: Wed Oct 12 05:59:30 2005 Subject: [Haskell] getArgs, maxBound, float division: pure functions? Message-ID: <1152E22EE8996742A7E36BBBA7768FEE07544CBB@RED-MSG-50.redmond.corp.microsoft.com> Just for the record, Cobol has a long history of specifying local rounding options. More recently, the options for rounding are elaborated in the context of adding standard arithmetic. http://www.cobolportal.com/j4/files/05-0152.doc Ralf > -----Original Message----- > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Bjorn Lisper > [...] > He was very careful to give > the language a good design also regarding floating-point computations. His > design choice, as regards rounding, was to allow the compiler to choose > rounding mode by default (thus allowing more freedom for optimization), > while providing a set of special arithmetic operators, with specified > rounding modes, to use when more explicit control is needed. > > He also proposed a special construct "letctrl ... in e", where the "..." > are > a list of directives telling how to interpret and evaluate the expression > e. One possible directive is "RoundingMode = ..." to set the rounding mode > locally in e. Other directives control, for instance, whether > optimizations > like x*0.0 -> 0.0 are allowed in e, whether to force strict evaluation of > all subexpressions (so optimizations cannot affect exceptions), to set > allowed miminum accuracy, etc. > > The language has exception handling (including a "handle" construct to > catch > exceptions), which also takes care of floating-point exceptions. From oleg at pobox.com Wed Oct 12 07:32:07 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Wed Oct 12 07:14:26 2005 Subject: [Haskell] Re: How to zip folds: A library of fold transformers In-Reply-To: <20051012002524.7A387ACB2@Adric.metnet.navy.mil> Message-ID: <20051012113207.E1EAFACB2@Adric.metnet.navy.mil> Correction: > We show how to merge two folds into another fold `elementwise'. ... We > need recursive types -- but again, never value recursion. There is no need for recursive types, actually. Higher-rank types are still present, which we need for fold anyway. Introducing recursive types wasn't a good idea anyway, because with recursive types "\x -> x x" becomes typeable and we can easily recover value recursion. The following is an implementation of szipWith (the zip function over two folds) that uses no recursion -- neither in value nor in types. All iterative processing is driven by the folds themselves. I'm afraid the code is a bit less perspicuous than before (although the general idea remained the same): We introduce another higher-rank type (the old FR would have sufficed, too). The bulk of the code is splitting the fold l2 into the head and the "rest of the fold". > newtype FR1 a b = FR1 (forall w. (a->b->w) -> w -> w) > unFR1 (FR1 x) = x > szipWith :: (a->b->c) -> FR a -> FR b -> FR c > szipWith t l1 l2 = > FR(\f z -> > let p str e r = unFR1 (unFR str ssk caseB) (sk e r) z > sk e1 r1 e2 r2 = f (t e1 e2) (r1 r2) > caseB = FR1(\a b -> b) > ssk v fk = FR1(\a _ -> > a v (FR (\s' f' -> > unFR1 fk > (\ v'' x -> s' v'' (unFR x s' f')) > f'))) > in unFR l1 (\e r x -> p x e r) (\r -> z) l2) All the old tests pass. From si at fh-wedel.de Wed Oct 12 09:52:48 2005 From: si at fh-wedel.de (Uwe Schmidt) Date: Wed Oct 12 09:33:37 2005 Subject: [Haskell] ANNOUNCE: Haskell XML Toolbox Version 5.3 Message-ID: <200510121552.49432.si@fh-wedel.de> Haskell XML Toolbox 5.3 I would like to announce a new version of the Haskell XML Toolbox for processing XML. main new features: * a cookbook for using the new arrow programming interface of the toolbox * an integrated Relax NG validator implemented with the arrow interface More information and download: http://www.fh-wedel.de/~si/HXmlToolbox/index.html Please email comments, bugs, etc. to hxmltoolbox@fh-wedel.de Uwe Schmidt -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html From jgoerzen at complete.org Wed Oct 12 16:01:16 2005 From: jgoerzen at complete.org (John Goerzen) Date: Wed Oct 12 15:48:26 2005 Subject: [Haskell] setSocketOption unusable? Message-ID: I'm wanting to set the SO_RCVTIMEO and SO_SNDTIMEO options on a socket from Haskell. socket(7) say that these take a struct timeval ad a parameter. (Other options, such as SO_LONGER, also could have this problem.) In Haskell, we see: setSocketOption :: Socket -> SocketOpt