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 -> SocketOption -> Int -> IO () Now, there are SocketOption constructors (RecvTimeOut and SendTimeOut) for what I want. But there is no way to give it a proper timeval (and yes, I checked the source.) setSocketOption definately wants an Int, and is passing the length of the Int to setsockopt(2) as well, so it appears to me that there is absolutely no way to correctly specify SO_RCVTIMEO or SO_SNDTIMEO through Haskell's socket layer. Is that correct? If so, how can we fix it? -- John From ijones at syntaxpolice.org Wed Oct 12 18:39:34 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Wed Oct 12 18:20:15 2005 Subject: [Haskell] Interest in helping w/ Haskell standard Message-ID: <87ek6qfjh5.fsf@syntaxpolice.org> At the end of the Haskell Workshop at ICFP, we had the traditional "Future of Haskell" discussion (chaired by Andres Loeh). One of the main topics was the perceived need of a new standard, because the Haskell 98 standard is quite old already, and Haskell has evolved in the meantime, leading to a situation where almost none of the actually existing Haskell programs is according to the 98 standard. No clear opinion was visible on what form a new standard would take. There was, however, considerable support for the idea to standardize an incremental and moderate extension to Haskell 98 (working name "Haskell 06" or "Industrial Haskell"). This effort would then be separate from discussion about the Real Next Version (dubbed "Haskell 2"). John Launchbury asked for a show of hands of those who would be interested in helping out with the "Haskell 06" standard. I think "helping" means "willing to spend a non-trivial amount of time". That is, it's pretty well expected that most Haskellers will be willing to contribute to discussion on the mailing lists, but we're trying to get a list of those who want to take it to the next level. If you raised your hand, or if you think this describes you, please email John Launchbury at john@galois.com. peace, Isaac Jones & Andres Loeh From sebastian.sylvan at gmail.com Wed Oct 12 18:49:46 2005 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Wed Oct 12 18:30:29 2005 Subject: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <87ek6qfjh5.fsf@syntaxpolice.org> References: <87ek6qfjh5.fsf@syntaxpolice.org> Message-ID: <3d96ac180510121549u38d825b3u63bd2f3b96a9cdc0@mail.gmail.com> On 10/13/05, Isaac Jones wrote: > At the end of the Haskell Workshop at ICFP, we had the traditional > "Future of Haskell" discussion (chaired by Andres Loeh). One of the > main topics was the perceived need of a new standard, because the > Haskell 98 standard is quite old already, and Haskell has evolved in > the meantime, leading to a situation where almost none of the actually > existing Haskell programs is according to the 98 standard. No clear > opinion was visible on what form a new standard would take. There was, > however, considerable support for the idea to standardize an > incremental and moderate extension to Haskell 98 (working name > "Haskell 06" or "Industrial Haskell"). This effort would then be > separate from discussion about the Real Next Version (dubbed "Haskell > 2"). > > John Launchbury asked for a show of hands of those who would be > interested in helping out with the "Haskell 06" standard. I think > "helping" means "willing to spend a non-trivial amount of time". That > is, it's pretty well expected that most Haskellers will be willing to > contribute to discussion on the mailing lists, but we're trying to get > a list of those who want to take it to the next level. If you raised > your hand, or if you think this describes you, please email John > Launchbury at john@galois.com. > I'm wondering what "incremental and moderate" extension means? Does it mean "completely backwards compatible" or can it mean completely new features including ones which subsume existing ones (I'm specifically interested in seeing SPJ's records proposal included, and a new module system). I'd also like to point out the haskell wiki page: http://www.haskell.org/hawiki/HaskellOhSix Which already contain some desired features. Perhaps a running summary of "definate", "maybe", and "not until Haskell 2" features could be kept there as discussions progress? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 From ijones at syntaxpolice.org Wed Oct 12 19:14:50 2005 From: ijones at syntaxpolice.org (Isaac Jones) Date: Wed Oct 12 18:55:31 2005 Subject: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <3d96ac180510121549u38d825b3u63bd2f3b96a9cdc0@mail.gmail.com> (Sebastian Sylvan's message of "Thu, 13 Oct 2005 00:49:46 +0200") References: <87ek6qfjh5.fsf@syntaxpolice.org> <3d96ac180510121549u38d825b3u63bd2f3b96a9cdc0@mail.gmail.com> Message-ID: <87r7aqe39x.fsf@syntaxpolice.org> (Trimming CC list. Maybe we should take this to haskell-cafe?) Sebastian Sylvan writes: (snip quotes) > I'm wondering what "incremental and moderate" extension means? > Does it mean "completely backwards compatible" or can it mean > completely new features including ones which subsume existing ones > (I'm specifically interested in seeing SPJ's records proposal > included, and a new module system). I was intentionally not addressing that question, because it's pretty much The Question. I certainly don't know the answer; just trying to figure out who wants to get involved, as a first step. I think everyone is agreed, though, that any process is going to be a very open one. peace, isaac From john at repetae.net Wed Oct 12 20:00:40 2005 From: john at repetae.net (John Meacham) Date: Wed Oct 12 19:41:48 2005 Subject: [Haskell] PROPOSAL: class aliases Message-ID: <20051013000040.GD14100@momenergy.repetae.net> = Class Aliases = This is a proposal for a language extension which will hopefully mitigate the issues holding back evolution of the standard prelude as well as provide useful class abstraction capabilities in general. It's main goals are to * remove the false tension between the granularity of a class hierarchy and its practical usability. * Allow one to modify a class hierarchy while retaining 100% backwards compatibility with a class API. with a specific use being able to replace the prelude's numeric hierarchy while retaining full haskell 98 compatibility, including the fact that libraries that only know about haskell 98 will have their instances automatically propagated to the new class hierarchy (and vice versa), so switching over can be fully incremental. * allow one to provide simple and advanced interfaces to a class hierarchy, much as one can do with function libraries. * it incidentally allows certain things that have been requested on the list as 'nice to have' but not world shattering. * not interfere with separate compilation and be describable by a straightforward source->source translation. feel free to skip the next section if you know the issues involved in replacing the numeric hierarchy of the prelude transparently :) This specification is meant to be informal but precise and complete. if any of the translation rules are unclear, then let me know. == The Problem == Many alternate preludes have been proposed, however to date none have gained popularity beyond the extensions to the standard libraries provided by fptools. Since as a general rule, the haskell community only likes to standardize changes that have been actively used and implemented already (a very good policy) this makes evolution of the standard problematic. Although it is easy enough to provide new functions and datatypes, providing wrapper routines with the old interfaces to allow incremental use of a new prelude or any library. there is no way to hide the fact that you changed a class hierarchy. if you split a class into two, every instance has to change, even if the split is irrelevant to a given datatype. Furthermore, depending on how you split or join classes, many type signatures will have to be rewritten. Since Haskell projects tend to be amalgamations of many different libraries and code from previous projects, this makes using alternate preludes with anything larger than a toy project unpossible. The problem is compounded when you consider the fact that we ideally want multiple competing preludes or certainly different versions of the same one. Imagine a library that provides a handy new Numeric datatype. the writer of the library only knows about the main prelude and doesn't concern himself with the various experimental preludes out there so declares an instance for Num. Bill comes along and realizes he needs an instance for the new Prelude so declares it an instance of ExperimentalNum, Phil, who also uses the library and the new experimental prelude needs to declare his own ExperimentalNum instance. suddenly Bill's and Phil's libraries cannot be combined by Susan who just wants to get work done and needs both Bill's and Phil's libraries. The basic issue is that you end up with a quadratic number of instances for every datatype combined with every alternative prelude and it is not clear who should be providing these instances. every library writer should not need to know about every alternate prelude out there and vice versa. Not only that but most of the instances will be very redundant, ExperimentalNum and Num most likely provide many of the same operations, you should only need to declare an instance for one and have it automatically propegated to the other. == The Extension == In haskell, you may create abstract data types, where you are free to change the internal representation without affecting the visible interface, you may create function impedance matching libraries, providing alternate interfaces to the same functionality. however, there is no way to abstract your class hiearchy. there is no way to hide your class layout in such a way you can change it behind the scenes, once a sizable codebase is built up expecting a certain class layout, there is no incremental migration path to something better. This extension allows the creation of class aliases, or effectively different views of the class hierarchy. this allows library writers to change the class hierarchy under the hood without affecting the visible interface as well as providing cleaner interfaces to begin with, hiding unimportant implementation details of how the classes are laid out from regular users, while providing the more advanced interfaces to power users. This extension may be carried out completely in the front end via a source->source translation and does not inhibit separate compilation. given > class Foo a where > foo :: a -> Bool > foo x = False > > class Bar b where > bar :: Int -> b -> [b] We allow new constructs of this form (the exact syntax is flexible of course): > class alias (Foo a, Bar a) => FooBar a where > foo = ... what this does is declare 'FooBar a' as an alias for the two constraints 'Foo a' and 'Bar a'. This affects two things. FooBar a may appear anywhere a class constraint may appear otherwise, it's meaning is simply (Foo a, Bar a) and the expansion may be carried out as a simple macro replacement, like type synonyms. The other thing is that one may declare instances of FooBar. > instance FooBar Int where > foo x = x > 0 > bar n x = replicate n x this expands to: > instance Foo Int where > foo x = x > 0 > > instance Bar Int where > bar n x = replicate n x The meaning of declaring a type an instance of a class alias is that it declares the type an instance of each class that makes up the alias, distributing the method definitions to their respective classes, using the default methods declared in the class alias if available, otherwise using the default methods of the underlying class. This also may be carried out as a simple translation in the front end. let us look at a more concrete example: the current Num class in the Prelude is (more or less) this > class Num a where > (+), (*) :: a -> a -> a > (-) :: a -> a -> a > negate :: a -> a > fromInteger :: Integer -> a ideally we would want to split it up like so (but with more mathematically precise names): > class Additive a where > (+) :: a -> a -> a > zero :: a > > class Additive a => AdditiveNegation where > (-) :: a -> a -> a > negate :: a -> a > x - y = x + negate y > > class Multiplicative a where > (*) :: a -> a -> a > one :: a > > class FromInteger a where > fromInteger :: Integer -> a now this presents some problems: * people using the new prelude have to write the ungainly (FromInteger a, AdditiveNegation a, Multiplicative a) and declare separate instances for all of them. * if at some point a HasZero class is separated out then everyone needs to modify their instance declarations. * Num still must be declared if you want it to work with old prelude functions, containing completely redundant information. * all the problems mentioned in the second section above about alternate preludes in general. these can be solved with the changing of Num into a class alias. > class alias (Addititive a, AdditiveNegation a, > Multiplicative a, FromInteger a) => Num a where > one = fromInteger 1 > zero = fromInteger 0 > negate x = zero - x now, all of the above problems are solved. You may use the short 'Num a' notation for numbers, if a HasZero class is split out then it doesn't matter because declaring something a (Num a) will propagate your methods to it properly. declaration of an instance for Num will automatically create instances for all the other classes, declaring separate instances for each of the other classes will give you the equivalent of an instance for Num. people writing libraries need not concern themselves with the alternate prelude or the haskell 98 one, they can pretend the other doesn't exist and their instance declarations will automatically create appropriate instances in the alternate prelude. == Another Example == This example is unrelated to creating an alternate prelude but shows how this extension is a useful abstraction tool in general. imagine we want to create a great lattice class library. I mean, a super really flexible one. > class Lattice a where > meet :: a -> a -> a > join :: a -> a -> a of course, you want to be able to express lattices with a distinguished top and bottom. > class Lattice a => BoundedLattice a where > top :: a > bottom :: a > meets :: [a] -> a > joins :: [a] -> a > meets xs = foldl meet top xs > joins xs = foldl join bottom xs hmm.. but then you realize you might want semi lattices.. so you change it too > class SemiLatticeMeet a where > meet :: a -> a -> a > > class SemiLatticeJoin a where > join :: a -> a -> a > > > class (SemiLatticeMeet a,SemiLatticeJoin a) => BoundedLattice a where > top :: a > bottom :: a > meets :: [a] -> a > joins :: [a] -> a > meets xs = foldl meet top xs > joins xs = foldl join bottom xs but then you realize you might want bounded semilattices so you come up with the following. your final super flexible lattice class. > class BoundedAbove a where > top :: a > > class BoundedBelow a where > bottom :: a > > class SemiLatticeMeet a where > meet :: a -> a -> a > > class SemiLatticeJoin a where > join :: a -> a -> a > > > meets :: (BoundedAbove a,SemiLatticeMeet a) => [a] -> a > meets xs = foldl meet top xs > > joins :: (BoundedBelow a,SemiLatticeJoin a) => [a] -> a > joins xs = foldl join bottom xs notice two things beyond the points mentioned above: 1. You have pissed off all your users... they just wanted to declare a simple bounded lattice and now they have to type a whole lot of crud to do so. refer to the docs several times to see how you named things and know some non-trivial things about lattices. 2. creating a simple bounded lattice instance for Bool requires writing 4 instances, none of which actually say 'BoundedLattice'! not very intuitive or flexible. 3. you can no longer make meets and joins members of a type class, meaning you cannot create optimized versions of them for certain types which most definitely exist and are important for many applications of lattices. you have traded flexibility in one direction for flexibility in another. of course, you could do something like > class (BoundedBelow a, SemiLatticeJoin a) => BoundedBelowJoinable a where > joins :: [a] -> a but things are already getting absurd. no user is going to type BoundedBelowJoinable constantly when they just want a lattice. there is a fundamental weakness in haskell here in that it creates a false tension between these two types of flexibility, this is compounded by the inability to change type classes without changing your interface so it is hard to tweak things if it turns out you chose something non-ideally. now, lets look at the above with class aliases. > class SemiLatticeMeet a where > meet :: a -> a -> a > > class SemiLatticeJoin a where > join :: a -> a -> a > > class alias (SemiLatticeMeet a, SemiLatticeJoin a) => Lattice a > > class BoundedAbove a where > top :: a > > class BoundedBelow a where > bottom :: a > > class alias (BoundedAbove a, BoundedBelow a) => Bounded a > > > class (BoundedBelow a, SemiLatticeJoin a) => BoundedBelowJoinable a where > joins :: [a] -> a > joins xs = foldl join bottom xs > > class (BoundedAbove a, SemiLatticeMeet a) => BoundedAboveMeetable a where > meets :: [a] -> a > meets xs = foldl meet top xs > > class alias (BoundedBelow a, BoundedAbove a, SemiLatticeMeet a, > SemiLatticeJoin a,BoundedBelowJoinable a, > BoundedAboveJoinable b) => BoundedLattice a this looks complicated but you really wanted to write a super-ultra fancy lattice class. But from a library users point of view it is great: The library user simply need to declare > instance BoundedLattice Bool where > top = True > bottom = False > meet = (&&) > join = (||) and _all_ of the above classes are filled in properly. someone else can write > instance Lattice Integer where > join = max > meet = min while a power user is free to declare his SemiLattices or BoundedAboveMeetables or whatever. this is a great benefit IMHO. There has always been a false tension between the granularity of your class hierarchy and its practical usability. this extension gets rid of that tension. == Notes == * class aliases are also able to introduce new superclass constraints, such as in the Num example we also want to enforce a (Eq a, Show a) superclass constraint. the interpretation is straightforward, Num in type signatures expands as if those were part of the alias and when declaring instances the existence of instances for the superclasses are checked, but not filled in automatically. I didn't show an example so as to not confuse the basic idea and because I have not come up with a syntax I am happy with. (suggestions welcome) * How these interact with other type class extensions would have to be figured out. it shouldn't present an issue and I think even if class aliases needed to be restricted to single parameter type classes (unlikely) then they would still be useful. * deciding what to display in error messages is an issue. but no more complicated than deciding whether to show a type synonym or an underlying type. a heuristic like show the most general constraint that can be expressed with the names in scope should suffice. * although it is basically a source->source translation, in practice it could not be carried out by a preprocessor because all the names needed would not be in scope and we would want to propagate the class alias information in the 'hi' files (or equivalent) of the compiler. * I had an earlier supertyping proposal you might know about, I feel this is a much better proposal even though it doesn't fully subsume my supertyping proposal, I feel it solves the problems it was meant to solve in a cleaner and easier to implement way. * You may wonder why for the num example I put Additive a in the class alias even though it was already a superclass of AdditiveNegation. that is because class aliases do not change the meaning of superclasses, you need to explicitly list a class if you want instance declarations to propagate methods to it. superclasses are checked just like normal in class aliases. * incidental but not earth-shattering benefits include being able to declare an instance for a class and all its superclasses at once, smarter defaults when you are combining related classes, and much nicer type signatures by being able to create your own aliases for common combinations of classes. -- John Meacham - ?repetae.net?john? From flippa at flippac.org Wed Oct 12 20:14:19 2005 From: flippa at flippac.org (Philippa Cowderoy) Date: Wed Oct 12 19:56:11 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: On Wed, 12 Oct 2005, John Meacham wrote: > ideally we would want to split it up like so (but with more mathematically > precise names): > Might it also be reasonable to provide less mathematical names for some classes, and possibly allow users to let the compiler know which ones they find more readable? A lot of users would find Mappable more intuitive than Functor for example, and the improved error messages might make it more practical to call fmap map again. -- flippa@flippac.org Ivanova is always right. I will listen to Ivanova. I will not ignore Ivanova's recomendations. Ivanova is God. And, if this ever happens again, Ivanova will personally rip your lungs out! From john at repetae.net Wed Oct 12 20:35:56 2005 From: john at repetae.net (John Meacham) Date: Wed Oct 12 20:17:02 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <20051013003556.GE14100@momenergy.repetae.net> On Thu, Oct 13, 2005 at 01:14:19AM +0100, Philippa Cowderoy wrote: > On Wed, 12 Oct 2005, John Meacham wrote: > > >ideally we would want to split it up like so (but with more mathematically > >precise names): > > > > Might it also be reasonable to provide less mathematical names for some > classes, and possibly allow users to let the compiler know which ones they > find more readable? A lot of users would find Mappable more intuitive than > Functor for example, and the improved error messages might make it more > practical to call fmap map again. class aliases help this too :) class alias Functor m => Mappable m oh.. or class alias (Monad m, Functor m) => Monad' m where fmap = liftM now you can just change your instance Monad to instance Monad' and you get your functor instance for free.. I hadn't thought about that one. (which has bugged me a lot before) John -- John Meacham - ?repetae.net?john? From bortzmeyer at nic.fr Thu Oct 13 03:24:30 2005 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu Oct 13 03:05:17 2005 Subject: [Haskell] Re: Interest in helping w/ Haskell standard In-Reply-To: <87ek6qfjh5.fsf@syntaxpolice.org> References: <87ek6qfjh5.fsf@syntaxpolice.org> Message-ID: <20051013072430.GA17362@nic.fr> On Wed, Oct 12, 2005 at 03:39:34PM -0700, Isaac Jones wrote a message of 30 lines which said: > One of the main topics was the perceived need of a new standard, As someone who is not an academic researcher and not a student in CS, I would like to express a personal opinion; we don't need a new standard. To me, Haskell needs more libraries, more users (which means more debugging and more documentations), more implementations, of course more real applications (darcs did a lot of the success of Haskell), so we can read their code, push sysadmins to install Haskell, etc. Most functional programming languages have been killed by the "CS effect": the fact that most users are more interested in exploring new areas of computer science than in producing code. Lisp and ML were killed by the explosion of many different and incompatible versions. I am not interested in Haskell++ or OOHaskell or anything like that. If people want to standardize things, their time could be, IMHO, best spent by standardizing libraries (I just recently discovered that Text.Regex is not standard and my programs do not run under hugs). From cp-lab at unipv.it Wed Oct 12 11:26:13 2005 From: cp-lab at unipv.it (Computational Philosophy Laboratory - Univ. of Pavia) Date: Thu Oct 13 04:07:58 2005 Subject: [Haskell] i-C&P 2006 France Message-ID: <434D2B15.5010508@unipv.it> CALL FOR PAPERS - Deadline November 18, 2005 --------------------------------------------------------------- i-C&P 2006 quick link COMPUTERS & PHILOSOPHY, an International Conference Le Mans University, Laval, France, 3-5 May, 2006 Chair: C.T.A. SCHMIDT Colin.Schmidt@univ-lemans.fr e-mail --------------------------------------------------------------- http://www.iut-laval.univ-lemans.fr/i-CaP_2006/ IMPORTANT DATES (check conference url for up-to-date information) Friday November 18 th 2005 Submission deadline for extended abstracts (1000 wds.) 3-5 May 2006, Conference in Laval France GENERAL INFORMATION >From Wednesday 3rd to Friday 5th May 2006 The International Conference on COMPUTERS & PHILOSOPHY will be held at Le Mans University in Laval (near Rennes, France). Overview: Those interested in the study of philosophical problems and related technological applications are encouraged to participate. Philosophical, epistemological, theological and anthropological stances on the construction and use of machines are of relevance to the conference. Within the framework of the programme, we are looking forward to the contributions of some eminent thinkers: USA Daniel DENNETT, Philosophy, Tufts USA Rodney BROOKS, Robotics, MIT Italy Lorenzo MAGNANI, Logic & Philosophy, Pavia UK Margaret BODEN, Art. Intelligence, Cognitive Sc. & Philosophy, Sussex Canada Daniel VANDERVEKEN, Logic & Language, UQTR Thailand Darryl MACER, UNESCO Reg. Adviser for Soc.& Human Sc. in Asia-Pacific UK Noel SHARKEY, Computation & Robotics, Sheffield Please see web site for full details; programme, topics, accommodation, registration as well as detailed information on plenary session talks. RELEVANT RESEARCH AREAS In addition to main-stream areas of research -Philosophy of Artificial Intelligence, Intelligent Robotics, Cognitive Science, Computer Ethics- we are looking for cross-cultural studies on the place of machines in society, as well as the following: 1. Evolution & Technologies a.. Evolutionary Computation and Evolutionary Language Development b.. Information Systems and the Philosophy of Design c.. Biologically-Incorporated Intelligence; the Use of Organic Components for Robotics d.. Bio-computation, Bio-Robotics, Artificial Life & Meaning e.. Robotics (Humanoid, Cognitive, Epigenetic, "Autonomous", Service, etc.) f.. Humanoid Hosts and Guides for Museums, Galleries and Virtual Reality Environments 2. Pragmatics & Comp. Linguistics a.. Speech Acts and the Limits of Machine-embedded Use of Dialogue b.. Obstacles to Parsing (Accents, Intonations, Emotional States, etc.) c.. Relations, Reference and Communicability d.. Artificial Affectivity in (non-)Dialogical Settings e.. All Language, Meaning and Dialogue Issues 3. Minds and Intentionality a.. Evocative Objects and Presumed Intelligence a.. Personification of Artefacts b.. Other Minds Theories and Simulating Co-intentionality c.. The Mind/Body Problem in Cognitive Science d.. European Versions (and Anti-theses) of the Intentional Stance 4. Culture & Adaptability a.. All Anthropological Views on Computers and Robots b.. Context-embedded Computer Learning c.. In-class Robotic Teachers, Vulgarisation and (non-)Acceptance Issues d.. The Pros and Cons of Computer-Mediated Communication & Learning e.. Virtual Reality & Digitally-supported Personalities f.. Post-modernism and Fiction related to Machines and Individuals 5. History, Ethics & Theology a.. Issues arising from the Automation of Thought b.. Designing Users' Beliefs, Beliefs Designing Machines, Religious Deontology c.. Robo-Ethics, Moral Agents, Spirituality of Machines, Technological Souls d.. The Impacts of Intelligent Computers and Robotics on Society throughout History e.. Cognitive Epistemology or Science as Applied Technology Other a.. Transdisciplinary attempts to link Philosophy, Computing and/or Robotics b.. cf. full scientific programme and printable version of the Call for Papers at quick link For further information about the conference, please consult the i-C&P 2006 website or contact the Chair for the complete version of the Call for Papers and related information. VENUE Laval is known to be a city of character for its history, art and culture. Located on the Mayenne River in beautiful Western France (see film at http://www.lamayenne.fr/front.aspx?sectionId=3D452&publiId=3D3996&controlle r =3DVi= e wpublication ), it offers all the amenities of a large city while maintaining a small town feel. SCIENTIFIC COMMITTEE General Chair: Colin T. Schmidt, Communication, Philosophy & Cognition, Le Mans University, France Local Organisations Chair: Xavier Dubourg, Computer Science & Learning, Le Mans University & Director of the Laval Technological Institute, France Honorary Chair: Francis Jacques, Emeritus Professor of Philosophy, Sorbonne University, France Varol Akman, Philosophy and Computer Science, Bilkent University, Turkey Jean Caelen, Cognition and Interaction, CNRS/Grenoble University, France Raja Chatila, Robotics, CNRS/Toulouse University, France Nathalie Colineau, Language & Multi-modality, CSIRO, Australia Roberto Cordeschi, Computation & Communication, Salerno University, Italy Liu Gang, Information & Philosophy, Inst. of Philosophy, Chinese Acad. of Soc. Sciences, China Deborah G. Johnson, Technology and Ethics, University of Virginia, USA Fr=E9d=E9ric Kaplan, Artificial Intelligence, SONY CSL =AD Paris Nik Kasabov, Computer and Information Sciences, Auckland University, New Zealand Oussama Khatib, Robotics & Artificial Intelligence, Stanford University, USA Boicho Kokinov, Cognitive Science, New Bulgarian University, Sofia, Bulgaria Felicitas Kraemer, Philosophy & Intentionality, Bielefeld University, Germany Jean Lass=E8gue, Philosophy, CNRS/Ecole Normale Sup=E9rieur Paris, France Ping Li, Cognitive Science & Philosophy of Science, Sun Yat-sen University, China Daniel Luzzati, Linguistics, Le Mans University, France M.C. Manes Gallo, Info. & Communication Sciences, Bordeaux University, France Anne Nicolle, Computer Science & Interdisciplinarity, CNRS/University of Caen, France Teresa Numerico, Communication, Salerno University, Italy James Moor, Philosophy, Dartmouth College, USA Bernard Moulin, Computer Science, Laval University, Canada Denis Vernant, Logic & Philosophy, Grenoble University, France Ming Xie, Robotics, Nanyang Technological University, Singapore LOCAL CONTACT POINT Tel +33 2 43 59 49 20 & Dr. Colin Schmidt (Chair) Computers & Philosophy, an International Conference i-C&P 2006 Computer Science Laboratory LIUM CNRS FRE 2730 Le Mans University France Phone: +33 2 43 59 49 25 Fax: +33 2 43 59 49 28 E-mail: Colin.Schmidt@lium.univ-lemans.fr Conference: quick link From arias at radioreykjavik.net Wed Oct 12 13:34:33 2005 From: arias at radioreykjavik.net (Arias) Date: Thu Oct 13 04:08:00 2005 Subject: [Haskell] Network Exception Message-ID: <434D4929.4060206@radioreykjavik.net> Hi, My name Iv?n Arias, I'm trying to connect to a server using the Network library, the code that I'm using is something like this: --- BEGIN --- module Main where import System.IO import Network main = withSocketsDo $ do handle <- connectTo "localhost" ( PortNumber 8080 ) hClose handle --- END --- It compiles correctly, but when I try to run this code, it throws an exception at connectTo. The exception's message is: - getServiceEntry: does not exists (No such service entry) Do somebody know why this happens and how to fix it? Thanks From bortzmeyer at nic.fr Thu Oct 13 04:35:23 2005 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu Oct 13 04:16:05 2005 Subject: [Haskell] Re: Network Exception In-Reply-To: <434D4929.4060206@radioreykjavik.net> References: <434D4929.4060206@radioreykjavik.net> Message-ID: <20051013083523.GA26215@nic.fr> On Wed, Oct 12, 2005 at 07:34:33PM +0200, Arias wrote a message of 25 lines which said: > It compiles correctly, but when I try to run this code, it throws an > exception at connectTo. The exception's message is: Which compiler? I get a "does not exist" with ghc if the host does not listen on the given port. Did you check with telnet ("telnet localhost 8080")? Your code seems to work for me. From antti-juhani at kaijanaho.info Thu Oct 13 04:42:31 2005 From: antti-juhani at kaijanaho.info (Antti-Juhani Kaijanaho) Date: Thu Oct 13 04:23:23 2005 Subject: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <3d96ac180510121549u38d825b3u63bd2f3b96a9cdc0@mail.gmail.com> References: <87ek6qfjh5.fsf@syntaxpolice.org> <3d96ac180510121549u38d825b3u63bd2f3b96a9cdc0@mail.gmail.com> Message-ID: <434E1DF7.8020405@kaijanaho.info> Sebastian Sylvan wrote: > I'm wondering what "incremental and moderate" extension means? I don't know what others mean by it, but for me, it implies standardizing existing practice, with possibly some conservative redesign to get rid of any hysterical warts. This is, BTW, what the C89 standard did for C, and it was a highly successful standard. -- Antti-Juhani From cgibbard at gmail.com Thu Oct 13 05:08:23 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Thu Oct 13 04:49:03 2005 Subject: [Haskell] Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard In-Reply-To: <20051013072430.GA17362@nic.fr> References: <87ek6qfjh5.fsf@syntaxpolice.org> <20051013072430.GA17362@nic.fr> Message-ID: <89ca3d1f0510130208r680b8680l@mail.gmail.com> Well, what we already have is a lot of language extensions with varying degrees of support across implementations. GHC is somewhat of a standard in and of itself, and one thing that standardisation efforts bring is a record of what exactly GHC is doing, thus allowing for more and better implementations. Also, Haskell is only as good as it is now because it has been changing, and many options and smart ideas have been explored at each step. I'd personally like to see Haskell grow in all directions - both in practicality and in language features/abstraction. Not every change has to break everything, but sometimes breaking things is worth it if the language comes out better. In basically every case, implementations will almost certainly be able to provide backwards compatibility modes for incompatible changes, at least until things are largely switched over. There are a variety of unsatisfying things about the H98 standard which should be dealt with if Haskell is to be the best language it can be. Dealing with them is a good idea in my opinion (though in many cases it might be better to do this with Haskell 2, depending on what people think). There are some potential extensions I've been discussing lately with Stefan Ljungstrand, one of which is for fixing the issue that, for example Set cannot be made an instance of Functor or Monad, which may turn into concrete proposals sometime soon. Other proposals, like John Meacham's recent class aliasing proposal would be useful in cleaning up the class hierarchy in the Prelude, and making it feel less like all the good infix identifiers are stolen. Also, many people have complained, myself included, about Functor not being a superclass of Monad, and join not being included as a class method of Monad (with default instances going between join and bind). Future proposals aside, the language that people are programming in today is not Haskell 98. Multiparameter typeclasses and functional dependencies are common. I use newtype deriving fairly often (together with monad transformers), and that's not standard. Class methods are not allowed to have types which are typeclass restricted in H98, which, regardless of how often it's actually used, is kind of silly not to allow. Arbitrary rank polymorphism isn't in Haskell 98, which means that things like Control.Monad.ST aren't possible. GADTs are new, but they're a great idea and already in use in major projects such as Pugs. Concurrent and Parallel Haskell aren't standard. I'm sure I've missed things too. Standardising these extensions which people use will help document them in one place rather than a variety of papers, and will help existing code be more portable. If done right, there's no reason that Haskell has to lose users over further standardisation, and cleaning up of previous standards. Transitions can be made smoother by providing backwards compatibility in the implementations for at least a limited amount of time, with warnings to note deprecated usage of the language. New standards shouldn't serve as forks of the language, but as continuations of it. - Cale Gibbard On 13/10/05, Stephane Bortzmeyer wrote: > On Wed, Oct 12, 2005 at 03:39:34PM -0700, > Isaac Jones wrote > a message of 30 lines which said: > > > One of the main topics was the perceived need of a new standard, > > As someone who is not an academic researcher and not a student in CS, > I would like to express a personal opinion; we don't need a new > standard. To me, Haskell needs more libraries, more users (which means > more debugging and more documentations), more implementations, of > course more real applications (darcs did a lot of the success of > Haskell), so we can read their code, push sysadmins to install > Haskell, etc. > > Most functional programming languages have been killed by the "CS > effect": the fact that most users are more interested in exploring new > areas of computer science than in producing code. Lisp and ML were > killed by the explosion of many different and incompatible versions. I > am not interested in Haskell++ or OOHaskell or anything like that. > > If people want to standardize things, their time could be, IMHO, best > spent by standardizing libraries (I just recently discovered that > Text.Regex is not standard and my programs do not run under hugs). > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > From simonmar at microsoft.com Thu Oct 13 05:42:24 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Thu Oct 13 05:23:09 2005 Subject: [Haskell] RE: [Haskell-cafe] Interest in helping w/ Haskell standard Message-ID: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> On 12 October 2005 23:50, Sebastian Sylvan wrote: > (I'm specifically interested in seeing SPJ's records proposal > included, and a new module system). Highly unlikely, IMHO. A new revision of the Haskell standard is not the place for testing new research, rather it's a clear specification of existing well-understood language features. If you want a new record system, or a new module system, now is the time to start designing and implementing them ready for the next standardisation process. Cheers, Simon From wolfgang at jeltsch.net Thu Oct 13 06:08:27 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Thu Oct 13 05:49:09 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <200510131208.27953.wolfgang@jeltsch.net> Am Donnerstag, 13. Oktober 2005 02:00 schrieb John Meacham: > [...] At a first look, this looks really nice. > We allow new constructs of this form (the exact syntax is flexible of > course): > > > class alias (Foo a, Bar a) => FooBar a where > > foo = ... > > what this does is declare 'FooBar a' as an alias for the two constraints > 'Foo a' and 'Bar a'. This affects two things. Wouldn't it be better to write it this way: class alias (Foo a, Bar a) = FooBar a where ... (Foo a, Bar a) => FooBar a normally means that a type is an instance of Foo and Bar if it is an instance of FooBar but in the case of aliases, a type is also an instance of FooBar if it is an instance of Foo and Bar. > [...] Best wishes, Wolfgang From arias at elleondeoro.com Thu Oct 13 06:18:44 2005 From: arias at elleondeoro.com (Arias) Date: Thu Oct 13 05:59:42 2005 Subject: [Haskell] Re: Network Exception In-Reply-To: <20051013083523.GA26215@nic.fr> References: <434D4929.4060206@radioreykjavik.net> <20051013083523.GA26215@nic.fr> Message-ID: <434E3484.4000804@elleondeoro.com> I'm using GHC version 6.4.1. In the port 8080 I have apache listening, so the server and port is correct. I send the code to a pair of friends, one of them said that it works, the other one had the same matter than me, both using the GHC compiler version 6.4. PD: Excuse my english x) Stephane Bortzmeyer escribi?: >On Wed, Oct 12, 2005 at 07:34:33PM +0200, > Arias wrote > a message of 25 lines which said: > > > >>It compiles correctly, but when I try to run this code, it throws an >>exception at connectTo. The exception's message is: >> >> > >Which compiler? I get a "does not exist" with ghc if the host does not >listen on the given port. Did you check with telnet ("telnet localhost >8080")? Your code seems to work for me. > >_______________________________________________ >Haskell mailing list >Haskell@haskell.org >http://www.haskell.org/mailman/listinfo/haskell > > > > > From john at repetae.net Thu Oct 13 06:22:50 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 06:03:58 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <200510131208.27953.wolfgang@jeltsch.net> References: <20051013000040.GD14100@momenergy.repetae.net> <200510131208.27953.wolfgang@jeltsch.net> Message-ID: <20051013102250.GL21098@momenergy.repetae.net> On Thu, Oct 13, 2005 at 12:08:27PM +0200, Wolfgang Jeltsch wrote: > > We allow new constructs of this form (the exact syntax is flexible of > > course): > > > > > class alias (Foo a, Bar a) => FooBar a where > > > foo = ... > > > > what this does is declare 'FooBar a' as an alias for the two constraints > > 'Foo a' and 'Bar a'. This affects two things. > > Wouldn't it be better to write it this way: > > class alias (Foo a, Bar a) = FooBar a where ... > > (Foo a, Bar a) => FooBar a normally means that a type is an instance of Foo > and Bar if it is an instance of FooBar but in the case of aliases, a type is > also an instance of FooBar if it is an instance of Foo and Bar. Yeah, I totally agree. it would also reduce confusion with superclasses and emphasises the fact that the two sides are equivalent everywhere. (except instance heads) although perhaps > class alias FooBar a = (Foo a, Bar a) where ... since the new name introduced usually appears to the left of an equals sign. This also solves the problems of where to put new supertype constraints. > class alias FooBar a = Show a => (Foo a, Bar a) where ... should do nicely. if nothing better comes along I will update my copy of the proposal with this new syntax... John -- John Meacham - ?repetae.net?john? From bortzmeyer at nic.fr Thu Oct 13 06:29:09 2005 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu Oct 13 06:09:51 2005 Subject: [Haskell] Re: Network Exception In-Reply-To: <434E3484.4000804@elleondeoro.com> References: <434D4929.4060206@radioreykjavik.net> <20051013083523.GA26215@nic.fr> <434E3484.4000804@elleondeoro.com> Message-ID: <20051013102909.GA6690@nic.fr> On Thu, Oct 13, 2005 at 12:18:44PM +0200, Arias wrote a message of 35 lines which said: > In the port 8080 I have apache listening, so the server and port is > correct. Excuse me but I prefer actual tests to claims. "telnet localhost 8080". (Apache may be listening only on the public IP address, for instance.) > the other one had the same matter than me, both using the GHC > compiler version 6.4. I tried with ghc 6.4 (FreeBSD and Debian) and it worked. From Malcolm.Wallace at cs.york.ac.uk Thu Oct 13 06:31:57 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Oct 13 06:15:41 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> John Meacham writes: > = Class Aliases = > > This is a proposal for a language extension which will hopefully mitigate > the issues holding back evolution of the standard prelude as well as provide > useful class abstraction capabilities in general. I like your proposal a lot. Do you have an implementation of it in jhc? > > class Foo a where > > foo :: a -> Bool > > foo x = False > > > > class Bar b where > > bar :: Int -> b -> [b] > > > class alias (Foo a, Bar a) => FooBar a where > > foo = ... > > bar = ... One thought: how will class aliases interact with type inference? e.g. if a declaration contains only a call to 'foo', should we infer the constraint Foo a, or FooBar a? Can there ever be a situation where choosing the more specific dictionary could leave us without a 'bar' method at some later point in the computation? (cf. up-casting and down-casting in OO languages). If I declare a function baz :: Bar a => ... and then pass it a value which actually has a FooBar dictionary rather than just a Bar, will the implementation be able to find the right offset in the dictionary for the 'bar' method? How? (I know jhc eliminates dictionaries at compile-time, but other implementations do not.) Regards, Malcolm From loeh at iai.uni-bonn.de Thu Oct 13 06:46:21 2005 From: loeh at iai.uni-bonn.de (Andres Loeh) Date: Thu Oct 13 06:24:14 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20051013104621.GA17162@iai.uni-bonn.de> > One thought: how will class aliases interact with type inference? > e.g. if a declaration contains only a call to 'foo', should we infer > the constraint Foo a, or FooBar a? Can there ever be a situation where > choosing the more specific dictionary could leave us without a 'bar' > method at some later point in the computation? (cf. up-casting and > down-casting in OO languages). > > If I declare a function > > baz :: Bar a => ... > > and then pass it a value which actually has a FooBar dictionary rather > than just a Bar, will the implementation be able to find the right > offset in the dictionary for the 'bar' method? How? (I know jhc > eliminates dictionaries at compile-time, but other implementations > do not.) The way I understand the proposal, there are no FooBar dictionaries ever. John said that this can be translated by a source-to-source translation, so internally, a FooBar dictionary *is* a Foo and a Bar dictionary. How much static checking can be done before desugaring the code? Will it be possible to give sensible error messages, or will those mention the "internal" classes that the alias is supposed to hide? Cheers, Andres From Malcolm.Wallace at cs.york.ac.uk Thu Oct 13 06:48:17 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Oct 13 06:30:02 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013104621.GA17162@iai.uni-bonn.de> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> <20051013104621.GA17162@iai.uni-bonn.de> Message-ID: <20051013114817.19eed66f.Malcolm.Wallace@cs.york.ac.uk> Andres Loeh writes: > The way I understand the proposal, there are no FooBar dictionaries > ever. John said that this can be translated by a source-to-source > translation, so internally, a FooBar dictionary *is* a Foo and a > Bar dictionary. Ah yes, I was misled by the syntax, which suggested a superclass relationship, and therefore a combined dictionary. I see now the improved syntax proposal which makes the absence much clearer. Regards, Malcolm From john at repetae.net Thu Oct 13 06:56:50 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 06:37:49 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013104621.GA17162@iai.uni-bonn.de> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> <20051013104621.GA17162@iai.uni-bonn.de> Message-ID: <20051013105649.GM21098@momenergy.repetae.net> On Thu, Oct 13, 2005 at 12:46:21PM +0200, Andres Loeh wrote: > > One thought: how will class aliases interact with type inference? > > e.g. if a declaration contains only a call to 'foo', should we infer > > the constraint Foo a, or FooBar a? Can there ever be a situation where > > choosing the more specific dictionary could leave us without a 'bar' > > method at some later point in the computation? (cf. up-casting and > > down-casting in OO languages). > > > > If I declare a function > > > > baz :: Bar a => ... > > > > and then pass it a value which actually has a FooBar dictionary rather > > than just a Bar, will the implementation be able to find the right > > offset in the dictionary for the 'bar' method? How? (I know jhc > > eliminates dictionaries at compile-time, but other implementations > > do not.) > > The way I understand the proposal, there are no FooBar dictionaries > ever. John said that this can be translated by a source-to-source > translation, so internally, a FooBar dictionary *is* a Foo and a > Bar dictionary. This is correct. perhaps 'class synonym' might be a better name? FooBar a and (Foo a,Bar a) are actually equivalent as if it were replaced via a textual macro substitution. the only place they are treated differently is in instance heads as declaring an instance for an alias will declare instances for all of its components. > > How much static checking can be done before desugaring the code? Will > it be possible to give sensible error messages, or will those mention > the "internal" classes that the alias is supposed to hide? A simple implementation would mention all the 'internal' classes. but ghc already knows to replace [Char] with String, it could do something similar looking for when a bunch of constraints can be simplified into a shorter alias and printing that. It also might be useful to have a pragma for the Haskell 98 names saying error messages should always be in terms of them when possible in haskell 98 mode so people learning from haskell 98 books arn't confused. perhaps something looking at the current names in scope could also be done, like if you only have the aliased names in scope, print errors in terms of those rather than the internal ones. How much this will be an issue in practice we will have to see. we might have to experiment some to find the best method for producing error messages. John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Oct 13 06:59:06 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 06:40:03 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013114817.19eed66f.Malcolm.Wallace@cs.york.ac.uk> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013113157.11dbe3c7.Malcolm.Wallace@cs.york.ac.uk> <20051013104621.GA17162@iai.uni-bonn.de> <20051013114817.19eed66f.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20051013105906.GN21098@momenergy.repetae.net> On Thu, Oct 13, 2005 at 11:48:17AM +0100, Malcolm Wallace wrote: > Andres Loeh writes: > > > The way I understand the proposal, there are no FooBar dictionaries > > ever. John said that this can be translated by a source-to-source > > translation, so internally, a FooBar dictionary *is* a Foo and a > > Bar dictionary. > > Ah yes, I was misled by the syntax, which suggested a superclass > relationship, and therefore a combined dictionary. I see now the > improved syntax proposal which makes the absence much clearer. Yeah, that has confused several people already. I wish I used the new syntax in my original post, it really makes more sense. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Thu Oct 13 07:21:41 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 13 07:02:23 2005 Subject: [Haskell] PROPOSAL: class aliases Message-ID: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> | This is a proposal for a language extension which will hopefully mitigate the | issues holding back evolution of the standard prelude as well as provide | useful class abstraction capabilities in general. A short summary would be "type synonyms for class constraints". You'd definitely want the syntax to look as much like a type synonym decl as possible. I've considered this before, but never done anything about it because superclasses are so close. Specifically, what is the difference between (i) class (C a, D a) => CD a and (ii) class alias CD a = (C a, D a) Note that (i) is Haskell 98. * In both cases one can write f :: (CD a) => ... instead of the more voluminous f :: (C a, D a) * However with (i), for each type T one must write instance C T where { ...meths for C... } instance D T where { ...meths for D... } instance CD T where {} whereas with (ii) one can write instance CD T where { ...meths for C... ...meths for D... } I believe that this latter is the sole difference. Am I right? [Implementation aspects aside.... with (i) GHC will pass one dictionary CD containing a pair of dictionaries, one for C and one for D.] If so, than rather than invent a whole new mechanism, why not simply extend the existing superclass mechanism to allow a single instance decl to declare instances for several classes? For example, one add to Haskell 98 the following: an instance declaration for a class CD with superclasses C and D may give the instances for its superclasses C and D [One could quibble about details. E.g Should the class decl for CD *say* whether the instance decl *must* contain decls for the superclass methods? Or can one vary it on a instance-by-instance basis, which might be more flexible?] Anyway, my main point it: would a smaller change not suffice? Simon From benjamin.franksen at bessy.de Thu Oct 13 07:46:14 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Thu Oct 13 07:26:56 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013102250.GL21098@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> <200510131208.27953.wolfgang@jeltsch.net> <20051013102250.GL21098@momenergy.repetae.net> Message-ID: <200510131346.14530.benjamin.franksen@bessy.de> On Thursday 13 October 2005 12:22, John Meacham wrote: > On Thu, Oct 13, 2005 at 12:08:27PM +0200, Wolfgang Jeltsch wrote: > > > We allow new constructs of this form (the exact syntax is > > > flexible of > > > > > > course): > > > > class alias (Foo a, Bar a) => FooBar a where > > > > foo = ... > > > > > > what this does is declare 'FooBar a' as an alias for the two > > > constraints 'Foo a' and 'Bar a'. This affects two things. > > > > Wouldn't it be better to write it this way: > > > > class alias (Foo a, Bar a) = FooBar a where ... > > > > (Foo a, Bar a) => FooBar a normally means that a type is an > > instance of Foo and Bar if it is an instance of FooBar but in the > > case of aliases, a type is also an instance of FooBar if it is an > > instance of Foo and Bar. > > Yeah, I totally agree. it would also reduce confusion with > superclasses and emphasises the fact that the two sides are > equivalent everywhere. (except instance heads) > > although perhaps > > > class alias FooBar a = (Foo a, Bar a) where ... > > since the new name introduced usually appears to the left of an > equals sign. This also solves the problems of where to put new > supertype constraints. Using '=' instead of '=>', you could even leave out the 'alias': class FooBar a = (Foo a, Bar a) where ... Ben From benjamin.franksen at bessy.de Thu Oct 13 07:52:59 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Thu Oct 13 07:33:40 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <200510131352.59854.benjamin.franksen@bessy.de> On Thursday 13 October 2005 13:21, Simon Peyton-Jones wrote: > If so, than rather than invent a whole new mechanism, why not simply > extend the existing superclass mechanism to allow a single instance > decl to declare instances for several classes? For example, one add > to Haskell 98 the following: > an instance declaration for a class CD with superclasses C and D > may > give the instances for its superclasses C and D > > [One could quibble about details. E.g Should the class decl for CD > *say* whether the instance decl *must* contain decls for the > superclass methods? Or can one vary it on a instance-by-instance > basis, which might be more flexible?] I just want to mention Robert Will's proposal for "delayed method definitions"; see http://www.stud.tu-ilmenau.de/~robertw/dessy/fun/ sections 4.3.1 and 4.3.2, which is quite similar to yours. Cheers, Ben From S.M.Kahrs at kent.ac.uk Thu Oct 13 07:57:10 2005 From: S.M.Kahrs at kent.ac.uk (S.M.Kahrs) Date: Thu Oct 13 07:37:53 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: Your message of "Thu, 13 Oct 2005 12:21:41 BST." <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051013113751.BF4B93243C0@www.haskell.org> > I've considered this before, but never done anything about it because > superclasses are so close. Specifically, what is the difference between > > (i) class (C a, D a) => CD a > and > (ii) class alias CD a = (C a, D a) The difference is that (i) is, in a sense, generative - because you still have to declare a type to be an instance of CD even if it is one of both C and D. That is not only inconvenient it can even create problems, for modular program development, as class instances always cross module boundaries [which is a wart]. So if there are two different modules in your project needing a type to be an instance of CD, you need to find a single place where to put that instance declaration. Frankly, as long as there is no way to limit the scope of an instance it would probably even make sense to treat method-less classes as class synonyms anyway, i.e. ones that do not require instances. Though ways of limiting the scope of class instances is probably a change quite a few people would like to see, so such a change would inhibit a move in that direction in the future. Stefan Kahrs From sebastian.sylvan at gmail.com Thu Oct 13 08:09:55 2005 From: sebastian.sylvan at gmail.com (Sebastian Sylvan) Date: Thu Oct 13 07:50:36 2005 Subject: [Haskell] Re: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <3d96ac180510130509q7c236f9cl23fb4f5da22f02b9@mail.gmail.com> On 10/13/05, Simon Marlow wrote: > On 12 October 2005 23:50, Sebastian Sylvan wrote: > > > (I'm specifically interested in seeing SPJ's records proposal > > included, and a new module system). > > Highly unlikely, IMHO. A new revision of the Haskell standard is not > the place for testing new research, rather it's a clear specification of > existing well-understood language features. > I can certainly understand this point of view. I am (as primarily a user and not a language designer) perhaps too eager to get my hands on cool new stuff :-) > If you want a new record system, or a new module system, now is the time > to start designing and implementing them ready for the next > standardisation process. Okay then. Consider this my contribution to the discussion. First of all I would like to urge the people who do end up working on this to seriously consider replacing H98's records system. I may be wrong but the impression I get is that enough people dislike the current system enough to warrant a replacement. And to me it seems to be a pretty much "slam-dunk" case that the proposal is *a lot* better than what we current have. On the module system. You may consider this a proposal. There have been discussions on this mailing lists about it but let me recap the main gist of it. Conservatively extend the current ghc hierarchical module system by allowing you to re-export modules "qualified". So you could write module GTK (..., qualified module GTK.Button as Button, ...) where Then the user could just import GTK and get all of the contents of GTK.Button imported qualifed as Button automatically. This allow libraries written using the current hierarchcical system to work without any changes, while new libraries can use the new feature (I'm guessing GTK2HS would benefit a lot from this, getting rid of all the ugly "buttonNew"-style functions). /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 From john at repetae.net Thu Oct 13 08:51:36 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 08:32:39 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051013125136.GO21098@momenergy.repetae.net> On Thu, Oct 13, 2005 at 12:21:41PM +0100, Simon Peyton-Jones wrote: > | This is a proposal for a language extension which will hopefully > mitigate the > | issues holding back evolution of the standard prelude as well as > provide > | useful class abstraction capabilities in general. > > A short summary would be "type synonyms for class constraints". You'd > definitely want the syntax to look as much like a type synonym decl as > possible. > I've considered this before, but never done anything about it because > superclasses are so close. Specifically, what is the difference between Actually I think it is pretty orthogonal to superclasses, class aliases are about composing classes, not building hierarchies. > > (i) class (C a, D a) => CD a > and > (ii) class alias CD a = (C a, D a) > > Note that (i) is Haskell 98. > > * In both cases one can write > f :: (CD a) => ... > instead of the more voluminous > f :: (C a, D a) > > * However with (i), for each type T one must write > instance C T where { ...meths for C... } > instance D T where { ...meths for D... } > instance CD T where {} > > whereas with (ii) one can write > instance CD T where { ...meths for C... > ...meths for D... } > > I believe that this latter is the sole difference. Am I right? No, there are a number of differences that allow class aliases to be used for true class abstraction rather than just a shortcut to writing instances. > If so, than rather than invent a whole new mechanism, why not simply > extend the existing superclass mechanism to allow a single instance decl > to declare instances for several classes? For example, one add to > Haskell 98 the following: > an instance declaration for a class CD with superclasses C and D > may > give the instances for its superclasses C and D this does not actually solve the problems mentioned in the proposal. in particular, (CD a) => a and (C a,D a) => a are distinct types. this means that you cannot use the aliases as abreviations or alternate names, which is a very nice side effect. with fine grained class hierarchies, type signatures get big fast. having a shorthand is very nice. but worse, it ruins the symmetry. declaring an instance for CD a will create instances for (C a,D a) but declaring instances for C a and D a will not create one for CD. A key point of my design is that you can declare instances in the new Num hierarchy, or in the haskell 98 one, and the instances will be propagated both directions. things get much more complicated when you realize that you might want more than just 2 views of the same hierarchy and there is not a clear order among them. if you constantly have to remember to declare instances for the old haskell 98 classes too then there is really no benefit. Another illustrative example is one that combines aliases with superclasses. class alias Num a = Show a => (Additive a, Multiplicative a) now, Show is a superclass, but Num is an alias for Additive and Multiplicative. if we declare something an instance of Num, we are declaring instances for precisely Additive and Multiplicative. but not Show, there must already be an existing instance for Show since it is a superclass and not part of the alias, if this distinction were not made then several bad things happen: it is obvious you cannot emulate the old haskell 98 behavior and thus cannot get true abstraction. declaring an instance for Num where you left out 'show' would rather than give an error as it should, use the default method for show (which is undefined). this is definitly what you don't want for Show, but it might be what you want for an alternate class with a useful default. with the superclass method you mentioned, how do we control exactly which classes we are creating instances for? all the way up the hierarchy back to the base? just one level? neither rules gives us what we want and if we put that explicitly in the instance declaration we ruin the whole point of class abstraction. (plus, it seems like the wrong place to put it anyway). An instance for a class alias always and exactly declares instances for each of its components and nothing else and is orthogonal to the superclass hierarchy. Another key way in which it is different is that it is truely a composition of classes rather than a ordering on them. with a superclass relationship, classes are forced to build on top of one another, you cannot have mutual recursion between class default methods.. for instance, consider this useful little alias: class alias EqOrd a = (Eq a, Ord a) where a == b = compare a b == EQ now you can declare something as an EqOrd and just provide a 'compare' method and it will derive everything else including the Eq methods. notice that the default method is declared the wrong way in the class hierachy. this is a very handy thing, but is actually necessary to create the abstraction benefits we want. if we look at the Num example from my previous proposal: > class (Addititive a, AdditiveNegation a, > Multiplicative a, FromInteger a) => Num a where > one = fromInteger 1 > zero = fromInteger 0 > negate x = zero - x notice that one and zero are given definitons in terms of fromInteger, if these defaulting methods could not be done, then a standard haskell 98 instance for Num could not create proper instances for Additive and Multiplicative. we would basically be forced to only extend the class hierarchy by creating subsets of the current hierarchy, we could not add functions at the 'base' and expect them to get defined properly. Also, it should be noted that while I am using the Num hierarchy as an example, I think this is much more generally useful than just rewriting the prelude. the Lattice example I gave is right out of my toolbox and my anoyances with it are part of what motivated me to write this. > Anyway, my main point it: would a smaller change not suffice? I do not think it suffices. We could extend the supertyping relationship some more to make it suitable, but I think we will end up with the exact same proposal but with different terminology :) John -- John Meacham - ?repetae.net?john? From flippa at flippac.org Thu Oct 13 08:58:50 2005 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu Oct 13 08:39:34 2005 Subject: [Haskell] RE: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: On Thu, 13 Oct 2005, Simon Marlow wrote: > On 12 October 2005 23:50, Sebastian Sylvan wrote: > >> (I'm specifically interested in seeing SPJ's records proposal >> included, and a new module system). > > Highly unlikely, IMHO. A new revision of the Haskell standard is not > the place for testing new research, rather it's a clear specification of > existing well-understood language features. > In that context, how well-understood is the combination of impredicative types via boxy types and a proper existential quantifier at the moment? It's certainly something that has many uses in an industrial context. -- flippa@flippac.org Society does not owe people jobs. Society owes it to itself to find people jobs. From simonpj at microsoft.com Thu Oct 13 09:43:18 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Oct 13 09:24:00 2005 Subject: [Haskell] PROPOSAL: class aliases Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116036B66B3@EUR-MSG-21.europe.corp.microsoft.com> John Replying just to you to avoid spamming everyone. | in particular, | | (CD a) => a and (C a,D a) => a are distinct types. this means that | you cannot use the aliases as abreviations or alternate names, which is | a very nice side effect. with fine grained class hierarchies, type | signatures get big fast. having a shorthand is very nice. I don't agree. What do you mean by "distinct types"? In H98 both of these are ok: f :: CD a => ty f = ...code... g :: (C a, D a) => ty g = f and f :: (C a, D a) => ty f = ...code... g :: (CD a) => ty g = f That is, the two types are interchangeable. | Another illustrative example is one that combines aliases with | superclasses. | | class alias Num a = Show a => (Additive a, Multiplicative a) | | now, Show is a superclass, but Num is an alias for Additive and | Multiplicative. Yes, this part really confused me. I didn't understand what it meant. Here's my attempt to summarise what I think you are proposing. (This summary might be useful to add to your note.) (1a) If I have f :: Num a => ... then I can use any of the class ops of Show, Additive, Multiplicative in the body of f. (1b) Dually, a call of f can be satisfied if (Show, Additive, Multiplicative) are all available (or Num of course). (2a) I can declare an instance of Num * either by giving separate instances for Show, Additive, Multiplicative; * or by giving a separate instance for Show, and an instance for Num itself (2b) If a type T is an instance of Additive, then it's an error to also give a Num instance, even if the instance only gives the methods for Multiplicative. (3) In the class decl for Num I can override the default methods for Additive, Multiplicative. These new default methods will be used (only) if I give an instance decl for Num. Here, (1a,b) are satisfied by H98 superclasses, whereas (2a) and (3) are not. Are there any points I've missed in this list? Simon From u.stenzel at web.de Thu Oct 13 09:58:09 2005 From: u.stenzel at web.de (Udo Stenzel) Date: Thu Oct 13 09:46:58 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051013135809.GA1585@web.de> Simon Peyton-Jones wrote: > I've considered this before, but never done anything about it because > superclasses are so close. Specifically, what is the difference between > > (i) class (C a, D a) => CD a > and > (ii) class alias CD a = (C a, D a) > > Note that (i) is Haskell 98. I was about to suggest almost exactly the same. In particular, John's proposal could be decomposed into three parts: 1. Allow instance declarations to define methods of superclasses. These are simply converted into the appropriate instance declarations for the superclasses. 2. Allow class declarations to give defaults for methods in superclasses. Together with (1) they are used in the obvious way. 3. Allow empty instance declarations to be implicitly generated. As a nice side effect, (1) and (2) together would allow us to cleanly get rid of the fmap/liftM annoyance: *> class Functor f where { fmap :: ... } *> class Functor m => Monad m where { fmap = liftM } I'm not sure about (3). I think, to effectively make Foo a synonym for Bar, we'd need: *> class Foo a => Bar a *> instance Foo a => Bar a If the instance for every type were allowed, Foo and Bar would be indistinguishable from true synonyms. Further, if classes with no methods have no use currently, this "universal instance" could be compiler generated whenever a class without methods is declared. Or the empty class may be treated as a synonym, if that's simpler. Does this make any sense? Udo. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org//pipermail/haskell/attachments/20051013/bdf6f63a/attachment.bin From jmaessen at alum.mit.edu Thu Oct 13 10:18:24 2005 From: jmaessen at alum.mit.edu (Jan-Willem Maessen) Date: Thu Oct 13 09:59:05 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: On Oct 12, 2005, at 8:00 PM, John Meacham wrote: > [longish proposal for class aliases] > Very nicely done, by the way. > == Notes == > > * class aliases are also able to introduce new superclass > constraints, such as > in the Num example we also want to enforce a (Eq a, Show a) > superclass > constraint. the interpretation is straightforward, Num in type > signatures > expands as if those were part of the alias and when declaring > instances the > existence of instances for the superclasses are checked, but not > filled in > automatically. I didn't show an example so as to not confuse the > basic idea > and because I have not come up with a syntax I am happy with. > (suggestions > welcome) > It sounds like there may be a simpler initial extension lurking under this, see below. > ... > * I had an earlier supertyping proposal you might know about, I > feel this is > a much better proposal even though it doesn't fully subsume my > supertyping > proposal, I feel it solves the problems it was meant to solve in > a cleaner > and easier to implement way. > Having read the previous proposal, I'm inclined to agree. I feel like I can explain this one in a couple of minutes, and the listener will be able to figure out most of the subtleties without additional help. > * You may wonder why for the num example I put Additive a in the > class alias > even though it was already a superclass of AdditiveNegation. that is > because class aliases do not change the meaning of superclasses, > you need > to explicitly list a class if you want instance declarations to > propagate > methods to it. superclasses are checked just like normal in class > aliases. > This is the one possible exception to that. Again, see below. > * incidental but not earth-shattering benefits include being able to > declare an instance for a class and all its superclasses at once, > smarter defaults when you are combining related classes, and much > nicer type signatures by being able to create your own aliases for > common combinations of classes. > It seems to me this is a simpler extension here which might serve at least as a conceptual stepping-stone to full class aliases---the ability to declare an instance for a class and all its superclasses at once. Given that ability, class aliases actually look like a relatively simple extension. One final thing which would be nice is the ability to define instances of superclass methods in a subclass declaration. But this takes things in a different direction entirely. -Jan-Willem Maessen > > -- > John Meacham - ?repetae.net?john? > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > From arias at elleondeoro.com Thu Oct 13 10:54:31 2005 From: arias at elleondeoro.com (Arias) Date: Thu Oct 13 10:35:11 2005 Subject: [Haskell] Re: Network Exception Message-ID: I've tryed to connect using the telnet and it connects properly, I've try also with another servers/ports and it allways throws the exception > On Thu, Oct 13, 2005 at 12:18:44PM +0200, > Arias wrote > a message of 35 lines which said: > > > In the port 8080 I have apache listening, so the server and port is > > correct. > > Excuse me but I prefer actual tests to claims. "telnet localhost > 8080". (Apache may be listening only on the public IP address, for > instance.) > > > the other one had the same matter than me, both using the GHC > > compiler version 6.4. > > I tried with ghc 6.4 (FreeBSD and Debian) and it worked. > > > From govereau at eecs.harvard.edu Thu Oct 13 13:41:14 2005 From: govereau at eecs.harvard.edu (Paul Govereau) Date: Thu Oct 13 13:21:52 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <20051013174114.GA21172@eecs.harvard.edu> On Oct 12, John Meacham wrote: > > [...] > > > class Num a where > > (+), (*) :: a -> a -> a > > (-) :: a -> a -> a > > negate :: a -> a > > fromInteger :: Integer -> a > > ideally we would want to split it up like so (but with more mathematically > precise names): > > > class Additive a where > > (+) :: a -> a -> a > > zero :: a > > > > class Additive a => AdditiveNegation where > > (-) :: a -> a -> a > > negate :: a -> a > > x - y = x + negate y > > > > class Multiplicative a where > > (*) :: a -> a -> a > > one :: a > > > > class FromInteger a where > > fromInteger :: Integer -> a > > [...] > > > class alias (Addititive a, AdditiveNegation a, > > Multiplicative a, FromInteger a) => Num a where > > one = fromInteger 1 > > zero = fromInteger 0 > > negate x = zero - x This class alias isn't 100% backwards compatible, because the original Num class doesn't have a zero method. For instance, if I had written this function in my program: zero :: Num a => a zero = fromInteger 0 Then, after swapping in the new alias, Num, the compiler would probably complain that I have multiple definitions for zero. Perhaps there could be a mechanism for hiding class methods as well? e.g. class alias (Addititive a without zero, -- remove zero AdditiveNegation a, Multiplicative a, FromInteger a) => Num a where ... I am not sure this could still be done with a source-to-source translation, but perhaps it is worth considering. Of course, if we allow union and subtraction, then why not addition, intersection, complement (ok, maybe not complement). Paul From carette at mcmaster.ca Thu Oct 13 14:12:16 2005 From: carette at mcmaster.ca (Jacques Carette) Date: Thu Oct 13 13:52:48 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013174114.GA21172@eecs.harvard.edu> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013174114.GA21172@eecs.harvard.edu> Message-ID: <434EA380.3000804@mcmaster.ca> Paul Govereau wrote: > Of course, if we >allow union and subtraction, then why not addition, intersection, >complement (ok, maybe not complement). > > Class definitions (including constraints and defaults) are essentially (syntactic) theory signatures (as in Institutions, from Goguen, Burstall, and later many others). And, as Oleg has pointed out some months back, Haskell's classes have a close relationship to Ocaml's Functor and Modules. Learning from what they have learned: 1) theory signatures form a category, and have 'natural' operations defined on them. Addition, intersection, union, subtraction are amongst them, as is renaming. They are all very useful operations on specifications, so they ought to be available on class definitions as well. 2) A recent proposal to extend the language of Modules, co-authored by a certain Paul Goverau (see http://www.eecs.harvard.edu/~nr/pubs/els-abstract.html) advocates something quite similar for ML! I firmly believe that there is a translation of all of the proposals in the above (via Oleg's work) into equivalent proposals for Haskell. Which I would certainly like to see happen. I would recommend making sure that all the transformations available in Specware (http://www.specware.org/) be reviewed as well. They overlap A LOT with the ones in (2) above, but I do not think the coverage is complete. Jacques From john at repetae.net Thu Oct 13 17:04:55 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 16:45:58 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013174114.GA21172@eecs.harvard.edu> References: <20051013000040.GD14100@momenergy.repetae.net> <20051013174114.GA21172@eecs.harvard.edu> Message-ID: <20051013210455.GS21098@momenergy.repetae.net> On Thu, Oct 13, 2005 at 01:41:14PM -0400, Paul Govereau wrote: > On Oct 12, John Meacham wrote: > > > > [...] > > > > > class Num a where > > > (+), (*) :: a -> a -> a > > > (-) :: a -> a -> a > > > negate :: a -> a > > > fromInteger :: Integer -> a > > > > ideally we would want to split it up like so (but with more mathematically > > precise names): > > > > > class Additive a where > > > (+) :: a -> a -> a > > > zero :: a > > > > > > class Additive a => AdditiveNegation where > > > (-) :: a -> a -> a > > > negate :: a -> a > > > x - y = x + negate y > > > > > > class Multiplicative a where > > > (*) :: a -> a -> a > > > one :: a > > > > > > class FromInteger a where > > > fromInteger :: Integer -> a > > > > [...] > > > > > class alias (Addititive a, AdditiveNegation a, > > > Multiplicative a, FromInteger a) => Num a where > > > one = fromInteger 1 > > > zero = fromInteger 0 > > > negate x = zero - x > > This class alias isn't 100% backwards compatible, because the original > Num class doesn't have a zero method. For instance, if I had written > this function in my program: > > zero :: Num a => a > zero = fromInteger 0 > > Then, after swapping in the new alias, Num, the compiler would > probably complain that I have multiple definitions for zero. You would use the module system to hide these extra methods.. like your prelude lookalike will have module Prelude(Num(negate,(-),(+),(*),fromInteger), ...) where and NewPrelude would export everything. > Perhaps there could be a mechanism for hiding class methods as well? > e.g. > > class alias (Addititive a without zero, -- remove zero > AdditiveNegation a, > Multiplicative a, > FromInteger a) => Num a where ... > > I am not sure this could still be done with a source-to-source > translation, but perhaps it is worth considering. Of course, if we > allow union and subtraction, then why not addition, intersection, > complement (ok, maybe not complement). no need, the module system lets us hide what we need to to keep compatability and is not tied to the alias itself, which is good because some people might want to use one and zero with Num and import the appropriate module to let them do that. John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Oct 13 18:33:15 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 18:14:13 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <200510131346.14530.benjamin.franksen@bessy.de> References: <20051013000040.GD14100@momenergy.repetae.net> <200510131208.27953.wolfgang@jeltsch.net> <20051013102250.GL21098@momenergy.repetae.net> <200510131346.14530.benjamin.franksen@bessy.de> Message-ID: <20051013223315.GC29815@momenergy.repetae.net> On Thu, Oct 13, 2005 at 01:46:14PM +0200, Benjamin Franksen wrote: > Using '=' instead of '=>', you could even leave out the 'alias': > > class FooBar a = (Foo a, Bar a) where ... true. for the purposes of discussion I think I will keep using the 'alias' so it is clearer what is going on. but if it were actually implemented we could decide whether we want it or not. John -- John Meacham - ?repetae.net?john? From john at repetae.net Thu Oct 13 18:40:32 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 18:21:36 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <20051013224032.GD29815@momenergy.repetae.net> On Thu, Oct 13, 2005 at 10:18:24AM -0400, Jan-Willem Maessen wrote: > >* incidental but not earth-shattering benefits include being able to > > declare an instance for a class and all its superclasses at once, > > smarter defaults when you are combining related classes, and much > > nicer type signatures by being able to create your own aliases for > > common combinations of classes. > > > > It seems to me this is a simpler extension here which might serve at > least as a conceptual stepping-stone to full class aliases---the > ability to declare an instance for a class and all its superclasses > at once. Given that ability, class aliases actually look like a > relatively simple extension. Yeah, see my response to SPJ for why this doesn't quite solve all the problems mentioned. the gist of the main one is how do you control which instances you are creating? surely you don't want someone declaring an instance of Num to fill in Eq and Show with defaults (bottom and a different kind of bottom respectivly), but there are often cases where you _do_ want the defaults. if you only have it fill in non-existing instances then importing a module could silently change the behavior of code as it might bring in an instance for something you wanted to use the default methods for. All in all, it seems like a can of worms and implementing full class aliases is of roughly the same amount of work. there are a few other issues mentioned in my other reply. > > One final thing which would be nice is the ability to define > instances of superclass methods in a subclass declaration. But this > takes things in a different direction entirely. I am not sure what you mean by this? -- John Meacham - ?repetae.net?john? From zednenem at psualum.com Thu Oct 13 19:09:06 2005 From: zednenem at psualum.com (David Menendez) Date: Thu Oct 13 18:49:49 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013135809.GA1585@web.de> Message-ID: Udo Stenzel writes: > Simon Peyton-Jones wrote: > > I've considered this before, but never done anything about it > > because superclasses are so close. Specifically, what is the > > difference between > > > > (i) class (C a, D a) => CD a > > and > > (ii) class alias CD a = (C a, D a) > > > > Note that (i) is Haskell 98. > > I was about to suggest almost exactly the same. In particular, John's > proposal could be decomposed into three parts: > > 1. Allow instance declarations to define methods of superclasses. > These are simply converted into the appropriate instance > declarations for the superclasses. > > 2. Allow class declarations to give defaults for methods in > superclasses. Together with (1) they are used in the obvious way. > > 3. Allow empty instance declarations to be implicitly generated. > > > As a nice side effect, (1) and (2) together would allow us to cleanly > get rid of the fmap/liftM annoyance: > > *> class Functor f where { fmap :: ... } > *> class Functor m => Monad m where { fmap = liftM } This can also get us into trouble. Consider, class Functor f where fmap :: ... class Functor m => Monad m where { fmap = liftM; ... } class Functor d => Comonad d where { fmap = liftD; ... } The Id functor is an instance of Monad and Comonad; what happens to the fmap definition? > If the instance for every type were allowed, Foo and Bar would be > indistinguishable from true synonyms. Further, if classes with no > methods have no use currently, this "universal instance" could be > compiler generated whenever a class without methods is declared. Or > the empty class may be treated as a synonym, if that's simpler. Does > this make any sense? I don't know that method-less classes have *no* value. You could use them to make additional claims about a type. For example, class Monoid m where { ... } class CommutativeMonoid m where {} The idea being that instances of CommutativeMonoid satisfy additional laws. -- David Menendez | "In this house, we obey the laws | of thermodynamics!" From john at repetae.net Thu Oct 13 20:53:15 2005 From: john at repetae.net (John Meacham) Date: Thu Oct 13 20:34:12 2005 Subject: [Haskell] PROPOSAL: class aliases (revised) In-Reply-To: <20051013000040.GD14100@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: <20051014005315.GG29815@momenergy.repetae.net> I have revised the proposal and put it on the web here: http://repetae.net/john/recent/out/classalias.html changes include a new, clearer syntax, some typo fixes, and a new section describing how class aliases interact with superclasses. I will update that web page with any new devolpments. John -- John Meacham - ?repetae.net?john? From oleg at pobox.com Thu Oct 13 22:13:02 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Thu Oct 13 21:55:19 2005 Subject: [Haskell] How to zip folds: A library of fold transformers In-Reply-To: <20051012224050.GA16647@lotus.bostoncoop.net> Message-ID: <20051014021302.47CDCACB2@Adric.metnet.navy.mil> Dylan Thurston wrote: > > 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 > > Presumably you noticed that this is isomorphic to the representation > of a list in lambda calculus, right? Sorry I didn't point out the previous discussion and relevant work: http://www.haskell.org/pipermail/haskell-cafe/2005-July/010875.html http://pobox.com/~oleg/ftp/Computation/Continuations.html#cdr-fstream especially the reference therein: Corrado Boehm and Alessandro Berarducci: Automatic Synthesis of Typed Lambda-Programs on Term Algebras From ajb at spamcop.net Thu Oct 13 23:45:12 2005 From: ajb at spamcop.net (ajb@spamcop.net) Date: Thu Oct 13 23:25:51 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051013234512.t24o4ksg8swkock4@webmail.spamcop.net> G'day all. Quoting Simon Peyton-Jones : > I've considered this before, but never done anything about it because > superclasses are so close. Specifically, what is the difference between > > (i) class (C a, D a) => CD a > and > (ii) class alias CD a = (C a, D a) > > Note that (i) is Haskell 98. To be a true typeclass synonym, there would also be an implied default instance: class (C a, D a) => CD a instance (C a, D a) => CD a ...and this is not Haskell 98. Cheers, Andrew Bromage From bulatz at HotPOP.com Fri Oct 14 03:11:16 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Fri Oct 14 03:51:29 2005 Subject: [Haskell] Re: [Haskell-cafe] Re: Interest in helping w/ Haskell standard In-Reply-To: <20051013072430.GA17362@nic.fr> References: <87ek6qfjh5.fsf@syntaxpolice.org> <20051013072430.GA17362@nic.fr> Message-ID: <9783997461.20051014111116@HotPOP.com> Hello Stephane, Thursday, October 13, 2005, 11:24:30 AM, you wrote: SB> As someone who is not an academic researcher and not a student in CS, SB> I would like to express a personal opinion; we don't need a new SB> standard. To me, Haskell needs more libraries, more users (which means SB> more debugging and more documentations), more implementations, of SB> course more real applications (darcs did a lot of the success of SB> Haskell), so we can read their code, push sysadmins to install SB> Haskell, etc. i put just the same opinion 1-2 months ago :))) but i got answer that current Haskell standard are too restrictive and ALL real programs use extensions. we need to standartize these de facto used extensions in order to simplify constructing of libraries and teaching language in universities/courses. we must explicitly declare the language really used in 2005, which is far away from the language used in 1998 -- Best regards, Bulat mailto:bulatz@HotPOP.com From bulatz at HotPOP.com Fri Oct 14 03:27:20 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Fri Oct 14 03:51:37 2005 Subject: [Haskell] Re[2]: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <3d96ac180510130509q7c236f9cl23fb4f5da22f02b9@mail.gmail.com> References: <3429668D0E777A499EE74A7952C382D104B5884E@EUR-MSG-01.europe.corp.microsoft.com> <3d96ac180510130509q7c236f9cl23fb4f5da22f02b9@mail.gmail.com> Message-ID: <984961548.20051014112720@HotPOP.com> Hello Sebastian, Thursday, October 13, 2005, 4:09:55 PM, you wrote: >> > (I'm specifically interested in seeing SPJ's records proposal >> > included, and a new module system). SS> First of all I would like to urge the people who do end up working on SS> this to seriously consider replacing H98's records system. I may be yes, it is a common viewpoint, afaik. the only problem is what this new record system was never really implemented, partially because it is not backward-compatible with H98, partially because Simons are not very like such syntax sugar extensions, they prefer "real semantic beasts" :) so, this proposal is a bit out of luck :))) -- Best regards, Bulat mailto:bulatz@HotPOP.com From dthurston at barnard.edu Wed Oct 12 18:40:50 2005 From: dthurston at barnard.edu (Dylan Thurston) Date: Fri Oct 14 04:03:09 2005 Subject: [Haskell] How to zip folds: A library of fold transformers In-Reply-To: <20051012002524.7A387ACB2@Adric.metnet.navy.mil> References: <20051006183104.GB595@sleepingsquirrel.org> <20051012002524.7A387ACB2@Adric.metnet.navy.mil> Message-ID: <20051012224050.GA16647@lotus.bostoncoop.net> On Tue, Oct 11, 2005 at 05:25:24PM -0700, oleg@pobox.com wrote: > 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 Presumably you noticed that this is isomorphic to the representation of a list in lambda calculus, right? Peace, Dylan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org//pipermail/haskell/attachments/20051012/0c57645e/attachment.bin From simonpj at microsoft.com Fri Oct 14 04:26:27 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 14 04:07:06 2005 Subject: [Haskell] RE: [Haskell-cafe] Interest in helping w/ Haskell standard Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116036B6B86@EUR-MSG-21.europe.corp.microsoft.com> | In that context, how well-understood is the combination of impredicative | types via boxy types and a proper existential quantifier at the moment? | It's certainly something that has many uses in an industrial context. Stephanie Weirich, Dimitrios Vytiniotis, and I are currently re-writing our paper about type inference for impredicative polymorphism. I don't think there's any difficulty with existentials, at least when they are wrapped in a data constructor (which is the way GHC deals with existentials at the moment). We'll have a draft done in a couple of weeks. (Until then the paper on my home page is still approximately right.) http://research.microsoft.com/%7Esimonpj/papers/boxy Can you elaborate on what you had in mind in your last sentence above? Simon From ashley at semantic.org Fri Oct 14 06:38:19 2005 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Oct 14 06:21:18 2005 Subject: [Haskell] Re: PROPOSAL: class aliases References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: In article <20051013000040.GD14100@momenergy.repetae.net>, John Meacham wrote: > This is a proposal for a language extension which will hopefully mitigate the > issues holding back evolution of the standard prelude as well as provide > useful class abstraction capabilities in general. I've certainly been wanting a solution to this problem for a long time. Haskell needs to get past the Prelude compatibly. I've already explored a lot of ways the classes might be improved with HBase, but right now it's a whole other world incompatible with the standard Prelude. Basically if it lets me do Functor => Idiom => Monad, and still compile earlier code, I'm for it. -- Ashley Yakeley, Seattle WA From ashley at semantic.org Fri Oct 14 06:41:21 2005 From: ashley at semantic.org (Ashley Yakeley) Date: Fri Oct 14 06:31:49 2005 Subject: [Haskell] Re: PROPOSAL: class aliases References: <20051013000040.GD14100@momenergy.repetae.net> Message-ID: In article , Philippa Cowderoy wrote: > A lot of users would find Mappable more intuitive than > Functor for example, and the improved error messages might make it more > practical to call fmap map again. And Simon PJ can at last rename Monad "WarmFuzzyThing"... -- Ashley Yakeley, Seattle WA From afie at cs.uu.nl Fri Oct 14 08:50:45 2005 From: afie at cs.uu.nl (Arjan van IJzendoorn) Date: Fri Oct 14 08:31:28 2005 Subject: [Haskell] Dazzle sources Message-ID: <4F42B7D7-B90A-4E79-9EDF-B30A6C3A2AC9@cs.uu.nl> Hello everyone, After the Dazzle presentation at the Haskell workshop, several people have asked us whether the source code is available. There is the possibility of commercialising Dazzle at some point in the future and for that reason we don't want to give away all our algorithms. However, the diagram editor part of Dazzle is something we would like to share with the community. Already Malcolm Wallace has been using this as a basis for another editor and has made some really nice improvements and generalisations. We plan to make an open-source project out of the diagram editor because we think that that is the part people will be most interested in. Here are some of the features of the diagram editor that will be called Blobs: - editing diagrams - arcs with "via points", in other words polylines - saving to and reading from file, XML format (using HaXml) - unlimited undo & redo (using the PersistentDocument library) - printing a diagram - save a diagram to JPG/PNG - labels at nodes and arcs - resizing a diagram - based on wxHaskell and can therefore run on Windows, Linux and Mac OS X - the XTC library (eXtended and Typed Controls) will be included - and much more Our plan is to set up a project website, a version management system and to reintegrate Dazzle with Malcolm's extended Blobs. Once we feel people can start using it, we will make an official announcement. Regards, the Dazzle team (Martijn Schrage & Arjan van IJzendoorn) From wolfgang at jeltsch.net Fri Oct 14 10:05:47 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Oct 14 09:46:28 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013102250.GL21098@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> <200510131208.27953.wolfgang@jeltsch.net> <20051013102250.GL21098@momenergy.repetae.net> Message-ID: <200510141605.48038.wolfgang@jeltsch.net> Am Donnerstag, 13. Oktober 2005 12:22 schrieb John Meacham: > [...] > although perhaps > > > class alias FooBar a = (Foo a, Bar a) where ... > > since the new name introduced usually appears to the left of an equals > sign. Yes, exactly. > This also solves the problems of where to put new supertype constraints. > > > class alias FooBar a = Show a => (Foo a, Bar a) where ... > > should do nicely. What is the difference between this and the following: class alias FooBar a = (Show a, Foo a, Bar a) where ... > [...] Best wishes, Wolfgang From simonpj at microsoft.com Fri Oct 14 11:35:24 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 14 11:16:02 2005 Subject: [Haskell] GADTs and GHC Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116036B7183@EUR-MSG-21.europe.corp.microsoft.com> Dear Haskell folk One of the interesting things about ICFP was the number of times GADTs came up, either in papers or in discussions in the breaks. Francois's invited talk was very inspiring, and that was just the beginning. Stephanie and Dimitrios and I are now busy revising our wobbly-types GADT paper (which is implemented in GHC, but never published http://research.microsoft.com/%7Esimonpj/papers/gadt/index.htm). We have a *far* simpler story now... but that means it'll reject some programs that would be accepted by the earlier version. We don't think this loss of expressiveness is important, but we'd like to check. Hence this message: If you use GADTs, would you to send us your GADT code, so we can check that we can still compile it? (A secondary reason for asking is that it'd be interesting just to see the way you are using GADTs.) If you send your code just to me, I'll collect it. You could a) send a complete Haskell program, which should compile and run b) send a Haskell module, or collection of modules, which should compile, but which isn't a complete program c) send a Haskell module using GADTs, but lacking the support modules that would enable it to compile d) send Omega code, which GHC won't understand, but which demonstrates some cunning use of GADTs All of these would be useful, even (c) and (d) --- we can eyeball the code. As a bonus, in the case of (a) or (b) I'll add your code to GHC's regression suite, so that all future releases will guarantee to run your code. [Or at least if not it'll be deliberate!] Tell me if you'd like this; it'll become visible in GHC's CVS repository. Thanks Simon From wolfgang at jeltsch.net Fri Oct 14 12:04:32 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Oct 14 11:45:10 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013135809.GA1585@web.de> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> <20051013135809.GA1585@web.de> Message-ID: <200510141804.32715.wolfgang@jeltsch.net> Am Donnerstag, 13. Oktober 2005 15:58 schrieb Udo Stenzel: > [...] > Further, if classes with no methods have no use currently, this "universal > instance" could be compiler generated whenever a class without methods is > declared. This does mean that you want to treat classes without methods special, doesn't it? I think, that it is generally not a good thing to have special treatment for a specific case. > [...] > Udo. Best wishes, Wolfgang From wolfgang at jeltsch.net Fri Oct 14 12:07:18 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Oct 14 11:48:03 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116036B66B3@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D4116036B66B3@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <200510141807.18449.wolfgang@jeltsch.net> Am Donnerstag, 13. Oktober 2005 15:43 schrieb Simon Peyton-Jones: > John > > Replying just to you to avoid spamming everyone. Hmm, you did write to the list as well... > [...] > I don't agree. What do you mean by "distinct types"? In H98 both of > these are ok: > > f :: CD a => ty > f = ...code... > > g :: (C a, D a) => ty > g = f This is not okay. Hugs gives this error message (with ty = a): Cannot justify constraints in explicitly typed binding *** Expression : g *** Type : (C a, D a) => a *** Given context : (C a, D a) *** Constraints : CD a > [...] Best wishes, Wolfgang From rturk at science.uva.nl Fri Oct 14 14:26:31 2005 From: rturk at science.uva.nl (Remi Turk) Date: Fri Oct 14 14:05:26 2005 Subject: [Haskell] PROPOSAL: class aliases (revised) In-Reply-To: <20051014005315.GG29815@momenergy.repetae.net> References: <20051013000040.GD14100@momenergy.repetae.net> <20051014005315.GG29815@momenergy.repetae.net> Message-ID: <20051014182631.GA715@localhost.lan> On Thu, Oct 13, 2005 at 05:53:15PM -0700, John Meacham wrote: > I have revised the proposal and put it on the web here: > > http://repetae.net/john/recent/out/classalias.html > > changes include a new, clearer syntax, some typo fixes, and a new > section describing how class aliases interact with superclasses. > > I will update that web page with any new devolpments. > > John Hi, it sounds like a great idea. And as I don't really have anything more fundamental to say about it, I'll invoke Wadlers Law now: What about > class Eq a => alias Num a = (Additive a, Multiplicative a) or perhaps > class alias Eq a => Num a = (Additive a, Multiplicative a) instead of > class alias Num a = Eq a => (Additive a, Multiplicative a) "If Eq a, then Num a is an alias for ..." Groeten, Remi -- Nobody can be exactly like me. Even I have trouble doing it. From u.stenzel at web.de Sat Oct 15 06:32:57 2005 From: u.stenzel at web.de (Udo Stenzel) Date: Sat Oct 15 06:16:15 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <200510141804.32715.wolfgang@jeltsch.net> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> <20051013135809.GA1585@web.de> <200510141804.32715.wolfgang@jeltsch.net> Message-ID: <20051015103256.GB7798@web.de> Wolfgang Jeltsch wrote: > This does mean that you want to treat classes without methods special, doesn't > it? Not quite, I'm actually not sure if I want this, I just noted that it was possible. :) As David Menendez pointed out, empty classes probably aren't that useless. Anyway, not treating empty classes specially and just making the universal instance explicit may be enough. Foo is declared an alias for Bar by writing: class Foo a => Bar a instance Foo a => Bar a The latter is not Haskell98, but a harmless extension. Doing it this way "feels better" than introducing new syntax and semantics, at least to me. Udo. -- "Don't you know that alcohol for a young man is nothing but slow poison?" "Slow poison, eh? Well, I'm not in any hurry." -- gefunden auf http://c2.com/cgi-bin/wiki?SlowPoison -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org//pipermail/haskell/attachments/20051015/1b4fec71/attachment.bin From flippa at flippac.org Sat Oct 15 14:20:07 2005 From: flippa at flippac.org (Philippa Cowderoy) Date: Sat Oct 15 14:00:55 2005 Subject: [Haskell] RE: [Haskell-cafe] Interest in helping w/ Haskell standard In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116036B6B86@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D4116036B6B86@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: On Fri, 14 Oct 2005, Simon Peyton-Jones wrote: > > | In that context, how well-understood is the combination of > impredicative > | types via boxy types and a proper existential quantifier at the > moment? > | It's certainly something that has many uses in an industrial context. > > Stephanie Weirich, Dimitrios Vytiniotis, and I are currently re-writing > our paper about type inference for impredicative polymorphism. I don't > think there's any difficulty with existentials, at least when they are > wrapped in a data constructor (which is the way GHC deals with > existentials at the moment). We'll have a draft done in a couple of > weeks. (Until then the paper on my home page is still approximately > right.) > http://research.microsoft.com/%7Esimonpj/papers/boxy > > Can you elaborate on what you had in mind in your last sentence above? > If you manage to avoid explicit boxing as required currently, you can swap out an existing type for an existential type covering a typeclass with minimal code modifications - which is wonderful for refactoring. More generally, they work rather nicely with typeclasses and avoid the need to keep track of whether you're dealing with the boxed existential type or a type that's an instance of the relevant class. -- flippa@flippac.org Performance anxiety leads to premature optimisation From frederik at a5.repetae.net Sun Oct 16 07:40:40 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Oct 16 07:21:15 2005 Subject: [Haskell] reader-like IO, parents of threads Message-ID: <20051016114040.GA1472@a5.repetae.net> Hi, I'm trying to get MonadReader-like functionality in the IO monad. It doesn't appear possible implement it with the interfaces that Haskell98 or GHC provide. I'm looking for something like "thread-local variables". The interface could be something like this: newTLRef :: a -> IO (TLRef a) withTLRef :: TLRef a -> a -> IO b -> IO b readTLRef :: TLRef a -> IO a writeTLRef :: TLRef a -> a -> IO () modifyTLRef :: TLRef a -> (a -> a) -> IO () This would have a lot of uses. I am aware of the "Implicit Configurations" paper by Kiselyov and Shan, but a solution such as theirs which requires modifying the type signatures of all intermediate function calls is not suitable. I want to be able to say "run algorithm A using database D" without requiring all of the functions in algorithm A to know that databases are somehow involved. One way to look at it is that I am seeking something like the type-based approach, but easier and with less explicit syntax; another way to look at it is that I am seeking something like a global IORef based approach, but more safe. An implementation based on ThreadId-keyed maps is almost workable: data TLRef a = TLR a (MVar (Map ThreadId a)) The problem with this is that while it is possible to find out the ThreadId of the current thread, it doesn't appear to be possible to get the ThreadId of the parent thread, which would be needed for values to be properly inherited. Is there a way around this? Will there ever be standard support for either finding the thread id of the parent of the current thread, or for something like the thread-local references I have proposed? Thanks, Frederik From frederik at a5.repetae.net Sun Oct 16 15:53:23 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Sun Oct 16 15:34:00 2005 Subject: [Haskell] reader-like IO, parents of threads In-Reply-To: <20051016114040.GA1472@a5.repetae.net> References: <20051016114040.GA1472@a5.repetae.net> Message-ID: <20051016195323.GA22342@a5.repetae.net> John Meacham suggested that I should be a little more clear about the semantics I'm seeking. Also, apparently it isn't possible to implement writeTLRef/modifyTLRef with the data structure I gave: > data TLRef a = TLR a (MVar (Map ThreadId a)) (the first argument is a default value, the second is a map storing the values in each thread. The MVar is for safe concurrent access) Without those functions, it looks a little more like the Reader monad I'm comparing it to. - What happens on fork? The child thread effectively gets a "copy" of each TLRef in its parent. They have the same values, but modifying them using withTLRef has no effect on the values in other threads. - Can you pass a TLRef to a different thread? Yes, but the value it holds will not be the same when it is dereferenced in a different thread. The problem with writeTLRef is that if a child thread looks up the default value for an unbound reference by looking up the value in its parent, but after calling forkIO the parent changes the value with writeTLRef, then the child thread will get the wrong value. It is supposed to only see the value which was stored in the reference at the point where forkIO was called. Also, for this reason, I think withTLRef would have to be implemented by creating a separate thread with forkIO and waiting for it to finish. This would avoid overwriting a value which other child threads might still need to access. Note that an e.g. "myParentThreadId" function isn't enough - what is needed is a parentThreadId :: ThreadId -> IO (Maybe ThreadId) which can look up the parent of an arbitrary thread. Alternatively, if 'forkIO' supported hooks to run before and/or after forking, then a 'parentThreadId' function could be implemented from that. Frederik On Sun, Oct 16, 2005 at 04:40:40AM -0700, Frederik Eaton wrote: > Hi, > > I'm trying to get MonadReader-like functionality in the IO monad. It > doesn't appear possible implement it with the interfaces that > Haskell98 or GHC provide. I'm looking for something like "thread-local > variables". The interface could be something like this: > > newTLRef :: a -> IO (TLRef a) > withTLRef :: TLRef a -> a -> IO b -> IO b > readTLRef :: TLRef a -> IO a > writeTLRef :: TLRef a -> a -> IO () > modifyTLRef :: TLRef a -> (a -> a) -> IO () > > This would have a lot of uses. I am aware of the "Implicit > Configurations" paper by Kiselyov and Shan, but a solution such as > theirs which requires modifying the type signatures of all > intermediate function calls is not suitable. I want to be able to say > "run algorithm A using database D" without requiring all of the > functions in algorithm A to know that databases are somehow involved. > One way to look at it is that I am seeking something like the > type-based approach, but easier and with less explicit syntax; another > way to look at it is that I am seeking something like a global IORef > based approach, but more safe. > > An implementation based on ThreadId-keyed maps is almost workable: > > data TLRef a = TLR a (MVar (Map ThreadId a)) > > The problem with this is that while it is possible to find out the > ThreadId of the current thread, it doesn't appear to be possible to > get the ThreadId of the parent thread, which would be needed for > values to be properly inherited. > > Is there a way around this? Will there ever be standard support for > either finding the thread id of the parent of the current thread, or > for something like the thread-local references I have proposed? > > Thanks, > > Frederik > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From jbw at macs.hw.ac.uk Sat Oct 15 03:53:25 2005 From: jbw at macs.hw.ac.uk (Joe Wells) Date: Mon Oct 17 04:17:53 2005 Subject: [Haskell] Research Job: Compositional Analysis for Mobility & Concurrency @ Heriot-Watt U., Scotland, UK Message-ID: <87r7anusga.fsf@colinux.macs.hw.ac.uk> Research Position ULTRA group (Useful Logics, Types, Rewriting, and their Automation) Computer Science Department School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh, Scotland, UK The HTML version of this job posting can be found at: http://www.macs.hw.ac.uk/~jbw/position-ad.html Description of the Position A research position is available working on modular reasoning and compositional analysis for computer systems and software with special interest in mobility and concurrency at Heriot-Watt University [1] working with Joe Wells [2]. The position is in the ULTRA (Useful Logics, Types, Rewriting, and their Automation) group [3] in the Computer Science Department [4] in the School of Mathematical and Computer Sciences [5] at Heriot-Watt University in Edinburgh [6], the capital of Scotland [7]. The position involves collaboration with the EC, EPSRC, NATO, and NSF-funded Church Project [8] as well as various contacts in the European Global Computing community. The research will include collaboration on the Poly* [9] polymorphic retargetable type system for process and mobility calculi, but is not limited to that topic. It will be helpful if the researcher is competent in 1 or more of the following knowledge areas which are likely to be used in the project. * Formal calculi for reasoning about the meaning of computer systems (including computer programs), especially those dealing with aspects of (a) concurrency and (b) mobility, but also those dealing with aspects of (c) modules, linking, and loading, (d) resource usage, (e) components, (f) staged compilation, (g) classes and objects, etc. * Analysis of systems represented in formal calculi. * Constraint solving and unification. * Type systems, especially those with features similar to intersection and union types. * Programming languages good for use for any of the above. The duration of the position is from 6 months to 1.5 years, depending on the circumstances of the researcher, with possible extensions up to 3 years total depending on salary, experience, performance, and funding. Applications to spend a shorter period (e.g., the sabbatical leave of an established academic) will be considered. The initial salary will be commensurate with qualifications and experience in the range from 22289 GBP to 30002 GBP per year. The position is available immediately. It is preferred that before starting the researcher will have completed a Ph.D. in a relevant discipline within Computer Science. Very good Ph.D. students elsewhere who want to spend part of their studies visiting Heriot-Watt will be considered. Applicants from outside the European Economic Area (EEA) will be considered. The researcher will probably collaborate on 1 or more of the following activities. The specific activities will be matched to the strengths of the researcher. * Designing new type systems for compositional (modular) analysis of systems that may involve one or more aspects of mobility, concurrency, and modularity, as well as other features such as resource awareness, components, run-time code generation, objects, etc. * Designing analysis algorithms for the new type systems. * Designing theories (e.g., "calculi") for reasoning about the meaning of computer systems with some of the features mentioned above. * Making software systems incorporating the new type systems, algorithms, and calculi. * Writing scientific reports on the work done. References 1. http://www.hw.ac.uk/ 2. http://www.macs.hw.ac.uk/~jbw/ 3. http://www.macs.hw.ac.uk/ultra/ 4. http://www.macs.hw.ac.uk/cs/ 5. http://www.macs.hw.ac.uk/ 6. http://www.geo.ed.ac.uk/home/tour/edintour.html 7. http://www.geo.ed.ac.uk/home/scotland/scotland.html 8. http://www.church-project.org/ 9. http://www.macs.hw.ac.uk/DART/software/PolyStar/FAQ.html Contact Information Informal inquiries should be directed to Joe Wells at: web: http://www.macs.hw.ac.uk/~jbw/ e-mail: jbw@macs.hw.ac.uk fax: +44 131 451 3327 Formal applications should be directed to the Heriot-Watt Human Resources Office at: web: http://www.hw.ac.uk/hr/ e-mail: hr@hw.ac.uk (responses will usually be by paper mail, telephone, or fax) voice mail: +44 131 451 3475 fax: +44 131 451 3475 minicom: +44 131 451 8212 post: Human Resources Office Lord Balerno Building Heriot-Watt University EDINBURGH EH14 4AS GREAT BRITAIN Applying for the Position Please use the reference code 142/05/L to help prevent your application from getting mixed up. Please convert Microsoft Word documents to a public, standard, and non-proprietary format. The best format is PDF, because some of our staff will encounter difficulties with HTML or PostScript. To formally apply for this position, please do as many as possible of the items in the following list by 2005-11-11. The first 2 are absolutely necessary and the 3rd is quite important. If you expect trouble meeting the deadline, please ask Joe Wells what to do. * Cause 3 recommendation letters to be sent by their writers. Do not send the letters with your application. (If someone tells you the letters are not needed yet or that less than 3 are needed, this is a mistake. We want to see the letters before choosing who to interview.) * Send the following yourself: + your complete curriculum vitae, and + contact details for the 3 people writing your recommendation letters. * Get the Heriot-Watt Human Resources Office to send you an "application pack". (This contains an application form, an equal opportunities monitoring form, information for applicants with disabilities, and some additional information about Heriot-Watt and the position.) * Fill out and return by post the application form and the equal opportunities monitoring form. If your curriculum vitae is well constructed, then some information requested will be redundant, so just write "see c.v." in those blanks, but please return the application form anyway. Although the application form requests only the addresses of 2 references, please follow the instructions above instead and supply 3. * Optionally, also send either of the following: + a brief statement about why your research accomplishments and interests are a good match for the position, and + up to 3 relevant publications of yours. * It is helpful to inform Joe Wells that you are applying so that he knows to ask our human resources office for your application materials. It is helpful to send copies to Joe Wells of any electronic files you submit. * Anyone who might need a work permit if hired (usually someone who is not a citizen of an EEA country) should also do the following. In addition to possibly being e-mailed or faxed, each letter of reference should also be sent by post on official-looking headed stationery paper and should include details on your whereabouts over the last two years. A work permit application also needs copies of any degree certificates, so it is a good idea to send those also at the same time as you send the rest of your application. Work permit applications can take quite some time for the UK's Home Office to process, so please avoid delays. For your information, it is helpful if the writers of reference letters provide details of: * the capacity in which they know the candidate, * the candidate's skills, abilities and performance in relation to the post applied for, * the candidate's employment record including details of the candidate's role and service dates, * their view of the candidate's suitability for the post as a whole, in light of the attached details and their knowledge of the candidate's experience and abilities, * any further relevant information which would assist us in making an appointment. From simonpj at microsoft.com Mon Oct 17 07:21:00 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 17 07:01:29 2005 Subject: [Haskell] RE: GADTs and GHC Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160370E8C3@EUR-MSG-21.europe.corp.microsoft.com> Dear Hakellions PS: In my message about uses of GADTs I asked | ... | d) send Omega code, which GHC won't understand, but which | demonstrates some cunning use of GADTs | All of these would be useful, even (c) and (d) --- we can eyeball the code. I should have also asked you to send examples of Chameleon code. http://www.comp.nus.edu.sg/~sulzmann/chameleon/ that uses GADTs. (Actually Chameleon does a lot more besides GADTs. For example, it has an interesting type debugger.) Simon From wolfgang at jeltsch.net Mon Oct 17 09:04:17 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 17 08:44:47 2005 Subject: [Haskell] multiple occurence of the same type variable in instance head Message-ID: <200510171504.17655.wolfgang@jeltsch.net> Hello, the following is not Haskell 98: class C a instance C (a,a) Well, GHC allows this with the -fglasgow-exts flag. Surprisingly, I cannot find a section in the GHC User's Guide which states that -fglasgow-exts can be used to allow this kind of instance declarations. Well, in the section on undecidable instances (7.4.4.3), one can read: Note that instance heads may contain repeated type variables. For example, this is OK: instance Stateful (ST s) (MutVar s) where ... But one has to note that in this expample, the different occurences of s aren't in the same type. Furthermore, multiple occurences of the same type variable cannot result in undecidability (as far as I understand). The above-mentioned statement talks about the things that are allowed *without* -fallow-undecidable-instances, and premises that multiple occurences of a type variable are okay. So am I missing something? Best wishes, Wolfgang From wolfgang at jeltsch.net Mon Oct 17 09:16:59 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 17 08:57:32 2005 Subject: [Haskell] really undecidable instances? Message-ID: <200510171516.59588.wolfgang@jeltsch.net> Hello, what ist the problem with instance declarations like the following: instance C Int a => D Char [a] Why are such declarations only allowed with -fallow-undecidable-instances in GHC? How can they result in undecidability? Best wishes, Wolfgang From wolfgang at jeltsch.net Mon Oct 17 09:23:35 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 17 09:04:03 2005 Subject: [Haskell] instance C (a -> a) Message-ID: <200510171523.36013.wolfgang@jeltsch.net> Lieber Herr Bachmann, instance-Deklarationen der Form instance C (a -> a) sind tats?chlich nicht konform zum Haskell-98-Standard, ebensowenig instance C (a,a) und dergleichen, was hei?t, dass diese Einschr?nkung nichts mit dem Funktionstyp zu tun hat. Generell darf ein und dieselbe Typvariable nicht mehrfach im Kopf der instance-Deklaration vorkommen. Allerdings erlaubt Hugs98, wie ich vermutet hatte, derartige Konstruktionen, wenn man die Haskell-98-Kompatibilit?t ausschaltet (Kommandozeilen-Parameter -98). Auch der Glasgow Haskell Compiler unterst?tzt solche Sachen. Viele Gr??e Wolfgang Jeltsch From simonpj at microsoft.com Mon Oct 17 09:57:44 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Oct 17 09:38:15 2005 Subject: [Haskell] really undecidable instances? Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160370EB4F@EUR-MSG-21.europe.corp.microsoft.com> This one can't. But it's hard to formulate a general rule. -fallow-undecidable-instances simply says that you, the programmer, take responsibility for termination. Without the flag, GHC uses a simple but sometimes over-conservative rule Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 14:17 | To: Haskell ML | Subject: [Haskell] really undecidable instances? | | Hello, | | what ist the problem with instance declarations like the following: | | instance C Int a => D Char [a] | | Why are such declarations only allowed with -fallow-undecidable-instances in | GHC? How can they result in undecidability? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From wolfgang at jeltsch.net Mon Oct 17 10:39:59 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 17 10:20:27 2005 Subject: [Haskell] instance C (a -> a) In-Reply-To: <200510171523.36013.wolfgang@jeltsch.net> References: <200510171523.36013.wolfgang@jeltsch.net> Message-ID: <200510171639.59497.wolfgang@jeltsch.net> Sorry, this mail was not intended for the list. :-( Best wishes, Wolfgang From wolfgang at jeltsch.net Mon Oct 17 11:12:25 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Mon Oct 17 10:52:52 2005 Subject: [Haskell] really undecidable instances? In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160370EB4F@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D41160370EB4F@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <200510171712.25456.wolfgang@jeltsch.net> Am Montag, 17. Oktober 2005 15:57 schrieben Sie: > This one [That is the instance declaration instance C Int a => D Char [a].] > can't. But it's hard to formulate a general rule. > -fallow-undecidable-instances simply says that you, the programmer, take > responsibility for termination. Without the flag, GHC uses a simple but > sometimes over-conservative rule > > Simon [Could you please put citations at the top of the respective mail?] Section 7.4.4.3 of the GHC User's guide says about the restrictions for ensuring decidability: These restrictions ensure that context reduction terminates: each reduction step removes one type constructor. But as far as I can see, in my example there is also one type constructor removed. Why isn't this allowed then? Best wishes, Wolfgang From paul_bostonjp at hotmail.co.uk Mon Oct 17 13:42:59 2005 From: paul_bostonjp at hotmail.co.uk (paul boston) Date: Mon Oct 17 13:23:27 2005 Subject: [Haskell] Excessive sharing and GHC Message-ID: Questions prompted by the "Excessive Sharing" section, page 405, of SPJ's "The Implementation of Functional Programming". This section gives 2 variations of a power list function, semantically equivalent, but with different space behaviours. Paraphrasing, given a caller of "length (powerListXXX [1..20])", the powerListBad version gobbles more and more space as execution proceeds, whilst the powerListGood version runs in a small amount of constant space. Confirmed under GHC 6.2.2 with -O2. powerListBad [] = [[]] powerListBad (x:xs) = pxs ++ map ((:) x) pxs where (x:xs) pxs = powerListBad xs powerListGood [] = [[]] powerListGood (x:xs) = powerListGood xs ++ map ((:) x) (powerLIstGood xs) Clearly, in this instance GHC is not transforming either of these definitions into the other. But are there other compile time transformations performed by GHC that might result in more (excessive) sharing, in particular the creation of new common sub-expressions such as pxs? If not, is that a deliberate design decision? Since I guess the "excessive" bit of excessive sharing probably can't be determined until run-time, would it be practical for the run-time system to do something about it? For example, once the run-time system notices that the graph size has breached a certain threshold it begins to decouple references to "reduced" but bulky sections of the graph, forcing them to be recomputed (from the original expression) at a later time. _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee® Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From john at repetae.net Mon Oct 17 19:01:41 2005 From: john at repetae.net (John Meacham) Date: Mon Oct 17 18:42:27 2005 Subject: [Haskell] ANNOUNCE: JRegex library Message-ID: <20051017230141.GQ29815@momenergy.repetae.net> JRegex is a library that provides interfaces to both PCRE (perl comptatable regular expressions) and Posix regular expressions. it also provides an operator (=~) which is similar, but much more powerful than the perl operator. In addition, the syntax uses extensible type classes so you may extend it with any regular expression or list matching types and the ability to match lists of any type (not just chars). for an example, here is the output of several calls to =~ just used at different types: -- return number of times the regex matches print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: Int) => 2 -- returns the first matching expression print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: String) => "fooobar" -- returns the string before the first match, the matching string, and the string after the first match print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: (String,String,String)) => ("hello","fooobar","bobfoobarbad") -- returns true if there is a match at all and false otherwise print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: Bool) => True -- always returns (). useful with the (=~~) monadic operator print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: ()) => () -- returns all matching substrings print ("hellofooobarbobfoobarbad" =~ "fo*bar" :: [String]) => ["fooobar","foobar"] -- returns an array off all matching parenthesised substrings in the regex for first match print ("hellofooobarbobfoobaaarbad" =~ "f(o*)b(a+r)" :: Array Int String) => array (0,2) [(0,"fooobar"),(1,"ooo"),(2,"ar")] -- returns an array off all matching parenthesised substrings in the regex for all matches print ("hellofooobarbobfoobaaarbad" =~ "f(o*)b(a+r)" :: [Array Int String]) => [array (0,2) [(0,"fooobar"),(1,"ooo"),(2,"ar")],array (0,2) [(0,"foobaaar"),(1,"oo"),(2,"aaar")]] here is its homepage: http://repetae.net/john/computer/haskell/JRegex/ I released a different version of this library in the past, but this version has been cleaned up, moved to a proper spot in the libraries, and is cabalized. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Tue Oct 18 03:31:19 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 18 03:11:45 2005 Subject: [Haskell] Excessive sharing and GHC Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160370EF85@EUR-MSG-21.europe.corp.microsoft.com> | Clearly, in this instance GHC is not transforming either of these | definitions into the other. But are there other compile time transformations | performed by GHC that might result in more (excessive) sharing, in | particular the creation of new common sub-expressions such as pxs? If not, | is that a deliberate design decision? GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag). GHC only does very limited common sub-expression elimination, which again is very beneficial usually but can have bad behaviour. It's not general CSE which is why it didn't kick in in the program you gave. | Since I guess the "excessive" bit of excessive sharing probably can't be | determined until run-time, would it be practical for the run-time system to | do something about it? For example, once the run-time system notices that | the graph size has breached a certain threshold it begins to decouple | references to "reduced" but bulky sections of the graph, forcing them to be | recomputed (from the original expression) at a later time. I don't know anyone who has tried to make this work. Sounds pretty tricky. Simon From simonpj at microsoft.com Tue Oct 18 04:24:05 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue Oct 18 04:04:32 2005 Subject: [Haskell] really undecidable instances? Message-ID: <036EAC76E7F5EC4996A3B3C3657D41160370F16C@EUR-MSG-21.europe.corp.microsoft.com> It's all very delicate. I believe, though I am not certain, that in the absence of functional dependencies, removing at least one type constructor might be an example of a rule that is sufficient to ensure termination. There are lots of such rules. Alas none known to me capture all cases. Functional dependencies make things much worse. Suppose you have instance C Int a => D Char [a] which looks safe enough. But now class C x y | x -> y instance D Char [b] => C Int [[b]] and now we loop. There's a paper on my home page explaining why functional dependencies are tricky (co-authored with Martin Sulzmann, Peter Stuckey and Gregory Duck). Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 16:12 | To: Haskell ML | Subject: Re: [Haskell] really undecidable instances? | | Am Montag, 17. Oktober 2005 15:57 schrieben Sie: | > This one | | [That is the instance declaration instance C Int a => D Char [a].] | | > can't. But it's hard to formulate a general rule. | > -fallow-undecidable-instances simply says that you, the programmer, take | > responsibility for termination. Without the flag, GHC uses a simple but | > sometimes over-conservative rule | > | > Simon | | [Could you please put citations at the top of the respective mail?] | | Section 7.4.4.3 of the GHC User's guide says about the restrictions for | ensuring decidability: | | These restrictions ensure that context reduction terminates: each reduction | step removes one type constructor. | | But as far as I can see, in my example there is also one type constructor | removed. Why isn't this allowed then? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From waldmann at imn.htwk-leipzig.de Tue Oct 18 05:58:15 2005 From: waldmann at imn.htwk-leipzig.de (Johannes Waldmann) Date: Tue Oct 18 05:38:40 2005 Subject: [Haskell] really undecidable instances? In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160370F16C@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D41160370F16C@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <4354C737.9060906@imn.htwk-leipzig.de> Simon Peyton-Jones wrote: > It's all very delicate. I believe, though I am not certain, that in the > absence of functional dependencies, removing at least one type > constructor might be an example of a rule that is sufficient to ensure > termination. There are lots of such rules. Alas none known to me > capture all cases. Of course they couldn't - because of undecidability of termination (of term rewriting, or Prolog-like programs). But then, there are a lot of (nontrivially) decidable subcases, and consequently there are quite a few automated methods for termination proofs, see http://www.lri.fr/%7Emarche/termination-competition/2005/ Would it be interesting to "beef up" the termination analysis in ghc a bit, using some of those methods? But then, the current solution is just use "-fundecidable.." and the see if the type checker (apparently) loops. This might still be more efficient than invoking a larger machinery that would prove (non)termination because after the proof you'd still have to invest the time into doing the rewrite sequence. Best regards, -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ ------- From simonmar at microsoft.com Tue Oct 18 06:47:29 2005 From: simonmar at microsoft.com (Simon Marlow) Date: Tue Oct 18 06:27:57 2005 Subject: [Haskell] reader-like IO, parents of threads Message-ID: <3429668D0E777A499EE74A7952C382D104BDEBF9@EUR-MSG-01.europe.corp.microsoft.com> It seems that you can do this as long as you provide your own version of forkIO, but not if you want to use the built-in forkIO. One could argue that getting the parent ThreadId is something that should be supported natively by forkIO, and I might be inlined to agree. Unfortunately there are some subtleties: currently a ThreadId is represented by a pointer to the thread itself, which causes the thread to be kept alive. This has implications not only for space leaks, but also for reporting deadlock: if you have a ThreadId for a thread, you can send it an exception with throwTo at any time, and hence the runtime can never determine that the thread is deadlocked so it will never get the NonTermination exception. Perhaps we need two kinds of ThreadId: a weak one for use in Maps, and a strong one that you can use with throwTo. But then building a Map in which some elements can be garbage collected is a bit tricky (it can be done though; see our old Memo table implementation in fptools/hslibs/util/Memo.hs). Cheers, Simon On 16 October 2005 20:53, Frederik Eaton wrote: > John Meacham suggested that I should be a little more clear about the > semantics I'm seeking. Also, apparently it isn't possible to implement > writeTLRef/modifyTLRef with the data structure I gave: > >> data TLRef a = TLR a (MVar (Map ThreadId a)) > (the first argument is a default value, the second is a map storing > the values in each thread. The MVar is for safe concurrent access) > > Without those functions, it looks a little more like the Reader monad > I'm comparing it to. > > - What happens on fork? The child thread effectively gets a "copy" of > each TLRef in its parent. They have the same values, but modifying > them using withTLRef has no effect on the values in other threads. > > - Can you pass a TLRef to a different thread? Yes, but the value it > holds will not be the same when it is dereferenced in a different > thread. > > The problem with writeTLRef is that if a child thread looks up the > default value for an unbound reference by looking up the value in its > parent, but after calling forkIO the parent changes the value with > writeTLRef, then the child thread will get the wrong value. It is > supposed to only see the value which was stored in the reference at > the point where forkIO was called. > > Also, for this reason, I think withTLRef would have to be implemented > by creating a separate thread with forkIO and waiting for it to > finish. This would avoid overwriting a value which other child threads > might still need to access. > > Note that an e.g. "myParentThreadId" function isn't enough - what is > needed is a > > parentThreadId :: ThreadId -> IO (Maybe ThreadId) > > which can look up the parent of an arbitrary thread. > > Alternatively, if 'forkIO' supported hooks to run before and/or after > forking, then a 'parentThreadId' function could be implemented from > that. > > Frederik > > On Sun, Oct 16, 2005 at 04:40:40AM -0700, Frederik Eaton wrote: >> Hi, >> >> I'm trying to get MonadReader-like functionality in the IO monad. It >> doesn't appear possible implement it with the interfaces that >> Haskell98 or GHC provide. I'm looking for something like >> "thread-local variables". The interface could be something like this: >> >> newTLRef :: a -> IO (TLRef a) >> withTLRef :: TLRef a -> a -> IO b -> IO b >> readTLRef :: TLRef a -> IO a >> writeTLRef :: TLRef a -> a -> IO () >> modifyTLRef :: TLRef a -> (a -> a) -> IO () >> >> This would have a lot of uses. I am aware of the "Implicit >> Configurations" paper by Kiselyov and Shan, but a solution such as >> theirs which requires modifying the type signatures of all >> intermediate function calls is not suitable. I want to be able to say >> "run algorithm A using database D" without requiring all of the >> functions in algorithm A to know that databases are somehow involved. >> One way to look at it is that I am seeking something like the >> type-based approach, but easier and with less explicit syntax; >> another way to look at it is that I am seeking something like a >> global IORef based approach, but more safe. >> >> An implementation based on ThreadId-keyed maps is almost workable: >> >> data TLRef a = TLR a (MVar (Map ThreadId a)) >> >> The problem with this is that while it is possible to find out the >> ThreadId of the current thread, it doesn't appear to be possible to >> get the ThreadId of the parent thread, which would be needed for >> values to be properly inherited. >> >> Is there a way around this? Will there ever be standard support for >> either finding the thread id of the parent of the current thread, or >> for something like the thread-local references I have proposed? >> >> Thanks, >> >> Frederik >> _______________________________________________ >> 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 frederik at a5.repetae.net Tue Oct 18 14:12:13 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue Oct 18 13:52:41 2005 Subject: [Haskell] reader-like IO, parents of threads In-Reply-To: <3429668D0E777A499EE74A7952C382D104BDEBF9@EUR-MSG-01.europe.corp.microsoft.com> References: <3429668D0E777A499EE74A7952C382D104BDEBF9@EUR-MSG-01.europe.corp.microsoft.com> Message-ID: <20051018181213.GA13196@a5.repetae.net> What about adding support for hooks in forkIO? These could be useful for other things as well. Pthreads could be said to have this functionality: -- Function: int pthread_atfork (void (*PREPARE)(void), void (*PARENT)(void), void (*CHILD)(void)) `pthread_atfork' registers handler functions to be called just before and just after a new process is created with `fork'. The PREPARE handler will be called from the parent process, just before the new process is created. The PARENT handler will be called from the parent process, just before `fork' returns. The CHILD handler will be called from the child process, just before `fork' returns. As well as: -- Function: void pthread_cleanup_push (void (*ROUTINE) (void *), void *ARG) `pthread_cleanup_push' installs the ROUTINE function with argument ARG as a cleanup handler. From this point on to the matching `pthread_cleanup_pop', the function ROUTINE will be called with arguments ARG when the thread terminates, either through `pthread_exit' or by cancellation. If several cleanup handlers are active at that point, they are called in LIFO order: the most recently installed handler is called first. Of course, 'fork' has a bit of a different meaning in pthreads. I don't know if there is support for handlers which are run when a new thread is created. (Pthreads also has support for "thread-specific data": -- Function: int pthread_setspecific (pthread_key_t KEY, const void *POINTER) `pthread_setspecific' changes the value associated with KEY in the calling thread, storing the given POINTER instead. If there is no such key KEY, it returns `EINVAL'. Otherwise it returns 0. -- Function: void * pthread_getspecific (pthread_key_t KEY) `pthread_getspecific' returns the value currently associated with KEY in the calling thread. If there is no such key KEY, it returns `NULL'. ) Regards, Frederik On Tue, Oct 18, 2005 at 11:47:29AM +0100, Simon Marlow wrote: > It seems that you can do this as long as you provide your own version of > forkIO, but not if you want to use the built-in forkIO. > > One could argue that getting the parent ThreadId is something that > should be supported natively by forkIO, and I might be inlined to agree. > Unfortunately there are some subtleties: currently a ThreadId is > represented by a pointer to the thread itself, which causes the thread > to be kept alive. This has implications not only for space leaks, but > also for reporting deadlock: if you have a ThreadId for a thread, you > can send it an exception with throwTo at any time, and hence the runtime > can never determine that the thread is deadlocked so it will never get > the NonTermination exception. Perhaps we need two kinds of ThreadId: a > weak one for use in Maps, and a strong one that you can use with > throwTo. But then building a Map in which some elements can be garbage > collected is a bit tricky (it can be done though; see our old Memo table > implementation in fptools/hslibs/util/Memo.hs). > > Cheers, > Simon > > On 16 October 2005 20:53, Frederik Eaton wrote: > > > John Meacham suggested that I should be a little more clear about the > > semantics I'm seeking. Also, apparently it isn't possible to implement > > writeTLRef/modifyTLRef with the data structure I gave: > > > >> data TLRef a = TLR a (MVar (Map ThreadId a)) > > (the first argument is a default value, the second is a map storing > > the values in each thread. The MVar is for safe concurrent access) > > > > Without those functions, it looks a little more like the Reader monad > > I'm comparing it to. > > > > - What happens on fork? The child thread effectively gets a "copy" of > > each TLRef in its parent. They have the same values, but modifying > > them using withTLRef has no effect on the values in other threads. > > > > - Can you pass a TLRef to a different thread? Yes, but the value it > > holds will not be the same when it is dereferenced in a different > > thread. > > > > The problem with writeTLRef is that if a child thread looks up the > > default value for an unbound reference by looking up the value in its > > parent, but after calling forkIO the parent changes the value with > > writeTLRef, then the child thread will get the wrong value. It is > > supposed to only see the value which was stored in the reference at > > the point where forkIO was called. > > > > Also, for this reason, I think withTLRef would have to be implemented > > by creating a separate thread with forkIO and waiting for it to > > finish. This would avoid overwriting a value which other child threads > > might still need to access. > > > > Note that an e.g. "myParentThreadId" function isn't enough - what is > > needed is a > > > > parentThreadId :: ThreadId -> IO (Maybe ThreadId) > > > > which can look up the parent of an arbitrary thread. > > > > Alternatively, if 'forkIO' supported hooks to run before and/or after > > forking, then a 'parentThreadId' function could be implemented from > > that. > > > > Frederik > > > > On Sun, Oct 16, 2005 at 04:40:40AM -0700, Frederik Eaton wrote: > >> Hi, > >> > >> I'm trying to get MonadReader-like functionality in the IO monad. It > >> doesn't appear possible implement it with the interfaces that > >> Haskell98 or GHC provide. I'm looking for something like > >> "thread-local variables". The interface could be something like this: > >> > >> newTLRef :: a -> IO (TLRef a) > >> withTLRef :: TLRef a -> a -> IO b -> IO b > >> readTLRef :: TLRef a -> IO a > >> writeTLRef :: TLRef a -> a -> IO () > >> modifyTLRef :: TLRef a -> (a -> a) -> IO () > >> > >> This would have a lot of uses. I am aware of the "Implicit > >> Configurations" paper by Kiselyov and Shan, but a solution such as > >> theirs which requires modifying the type signatures of all > >> intermediate function calls is not suitable. I want to be able to say > >> "run algorithm A using database D" without requiring all of the > >> functions in algorithm A to know that databases are somehow involved. > >> One way to look at it is that I am seeking something like the > >> type-based approach, but easier and with less explicit syntax; > >> another way to look at it is that I am seeking something like a > >> global IORef based approach, but more safe. > >> > >> An implementation based on ThreadId-keyed maps is almost workable: > >> > >> data TLRef a = TLR a (MVar (Map ThreadId a)) > >> > >> The problem with this is that while it is possible to find out the > >> ThreadId of the current thread, it doesn't appear to be possible to > >> get the ThreadId of the parent thread, which would be needed for > >> values to be properly inherited. > >> > >> Is there a way around this? Will there ever be standard support for > >> either finding the thread id of the parent of the current thread, or > >> for something like the thread-local references I have proposed? > >> > >> Thanks, > >> > >> Frederik > >> _______________________________________________ > >> 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 > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > From jgoerzen at complete.org Tue Oct 18 14:17:33 2005 From: jgoerzen at complete.org (John Goerzen) Date: Tue Oct 18 13:58:09 2005 Subject: [Haskell] Haskell Weekly News: October 18, 2005 Message-ID: <20051018181733.GA15641@katherina.lan.complete.org> Haskell Weekly News: October 18, 2005 Greetings, and thanks for reading the 12th 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 * Decimal arithmetic library. Jeremy Shaw [3]announced the "premature release" of his new Decimal arithmetic library, which is designed for cases where binary floating point is not acceptable, such as money. 3. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8734 * JRegex. John Meacham [4]announced JRegex, a library that interfaces to both PCRE and Posix regular expressions. 4. http://article.gmane.org/gmane.comp.lang.haskell.general/12340 * Haskell XML Toolbox 5.3. Uwe Schmidt [5]announced version 5.3 of the Haskell XML Toolbox. The main changes in this release are improvements to the arrow system. 5. http://article.gmane.org/gmane.comp.lang.haskell.general/12271 Requests for Participation Future Haskell Standard. Isaac Jones [6]posted a request for participation in the formation of the next standardized version of Haskell. 6. http://article.gmane.org/gmane.comp.lang.haskell.cafe/8646 HCAR Clarification. Last week's HWN story on the Haskell Communities & Activities Report (HCAR) had some misleading wording. Participation in this report is open to all, and submissions are encouraged from everyone. Discussion Haskell mentioned on Slashdot. Haskell was [7]mention on Slashdot. The post was refering to [8]an article about optimizing development for fun and had [9]pugs as its example. 7. http://developers.slashdot.org/article.pl?sid=05/10/09/1831219&tid=156 8. http://www.oreillynet.com/pub/wlg/7996 9. http://www.pugscode.org/ ZLib bindings. Joel Reymont [10]asked about code for handling GZip files. Henning Thielemann suggested the code in Darcs. Malcom Wallace pointed out code in qforeign, and John Goerzen mentioned the pure-Haskell implementation in MissingH. 10. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8759 GADTs. Bulat Ziganshin began a [11]discussion asking for resources on GADTs. Several people posted links to helpful resources. 11. http://thread.gmane.org/gmane.comp.lang.haskell.cafe/8708 Class aliases. John Meacham began a long [12]discussion by proposing class aliases, a language extension to solve problems of multiple implementations of the same concept in different libraries. 12. http://thread.gmane.org/gmane.comp.lang.haskell.general/12276 About Haskell Weekly News Thanks to Josef Svenningsson for contributing material towards this week's HWN. Want to continue reading HWN? Please help us create new editions of this newsletter. Please see the [13]contributing information, or send stories to hwn -at- complete -dot- org. There is also a Darcs repository available. 13. http://sequence.complete.org/hwn-contrib From john at repetae.net Tue Oct 18 17:45:26 2005 From: john at repetae.net (John Meacham) Date: Tue Oct 18 17:26:12 2005 Subject: [Haskell] Excessive sharing and GHC In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160370EF85@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D41160370EF85@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051018214526.GC32555@momenergy.repetae.net> On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote: > GHC tries not to create space leaks, but does not guarantee not to. In > particular, the full laziness transformation is so beneficial most of > the time that, even though it can create a space leak GHC still does it > (unless you turn it off with a flag). I was thinking it would be nice if one could put a pragma on CAFs that basically made ghc treat them as WHNF so it would float them inward as far as possible including inside lambdas. in particular, constant strings that are created (cheaply) from efficient internal representations should not be held onto in their inefficient form. it might even be worth it to have a pragma that made ghc think they were duplicatable too, so it would float them all the way to each of their uses, duplicating the expression as necessary just to make sure it is never held onto more than needed. John -- John Meacham - ?repetae.net?john? From daan at cs.uu.nl Tue Oct 18 18:01:07 2005 From: daan at cs.uu.nl (Daan Leijen) Date: Tue Oct 18 17:38:08 2005 Subject: [Haskell] Excessive sharing and GHC In-Reply-To: <20051018214526.GC32555@momenergy.repetae.net> References: <036EAC76E7F5EC4996A3B3C3657D41160370EF85@EUR-MSG-21.europe.corp.microsoft.com> <20051018214526.GC32555@momenergy.repetae.net> Message-ID: <435570A3.3010404@cs.uu.nl> John Meacham wrote: > On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote: >> GHC tries not to create space leaks, but does not guarantee not to. In >> particular, the full laziness transformation is so beneficial most of >> the time that, even though it can create a space leak GHC still does it >> (unless you turn it off with a flag). > > I was thinking it would be nice if one could put a pragma on CAFs that > basically made ghc treat them as WHNF so it would float them inward as > far as possible including inside lambdas. in particular, constant > strings that are created (cheaply) from efficient internal > representations should not be held onto in their inefficient form. What about adding a unit argument? That would do the trick without pragmas. All the best, -- Daan > it might even be worth it to have a pragma that made ghc think they > were duplicatable too, so it would float them all the way to each of their > uses, duplicating the expression as necessary just to make sure it is > never held onto more than needed. > > John > From john at repetae.net Tue Oct 18 18:02:30 2005 From: john at repetae.net (John Meacham) Date: Tue Oct 18 17:43:28 2005 Subject: [Haskell] Excessive sharing and GHC In-Reply-To: <435570A3.3010404@cs.uu.nl> References: <036EAC76E7F5EC4996A3B3C3657D41160370EF85@EUR-MSG-21.europe.corp.microsoft.com> <20051018214526.GC32555@momenergy.repetae.net> <435570A3.3010404@cs.uu.nl> Message-ID: <20051018220230.GD32555@momenergy.repetae.net> On Wed, Oct 19, 2005 at 12:01:07AM +0200, Daan Leijen wrote: > John Meacham wrote: > >On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote: > >>GHC tries not to create space leaks, but does not guarantee not to. In > >>particular, the full laziness transformation is so beneficial most of > >>the time that, even though it can create a space leak GHC still does it > >>(unless you turn it off with a flag). > > > >I was thinking it would be nice if one could put a pragma on CAFs that > >basically made ghc treat them as WHNF so it would float them inward as > >far as possible including inside lambdas. in particular, constant > >strings that are created (cheaply) from efficient internal > >representations should not be held onto in their inefficient form. > > What about adding a unit argument? That would do the trick without pragmas. I believe that full-lazyness will still take the body of the routine and float it to the top as a CAF. as in if we have foo () = fromPackedString big_string then the (fromPackdString big_string) will be floated out by the standard full lazyness transform (as I understand it) John -- John Meacham - ?repetae.net?john? From john at repetae.net Tue Oct 18 18:46:56 2005 From: john at repetae.net (John Meacham) Date: Tue Oct 18 18:27:41 2005 Subject: [Haskell] reader-like IO, parents of threads In-Reply-To: <20051018181213.GA13196@a5.repetae.net> References: <3429668D0E777A499EE74A7952C382D104BDEBF9@EUR-MSG-01.europe.corp.microsoft.com> <20051018181213.GA13196@a5.repetae.net> Message-ID: <20051018224656.GF32555@momenergy.repetae.net> On Tue, Oct 18, 2005 at 07:12:13PM +0100, Frederik Eaton wrote: > (Pthreads also has support for "thread-specific data": > > -- Function: int pthread_setspecific (pthread_key_t KEY, const void > *POINTER) > `pthread_setspecific' changes the value associated with KEY in the > calling thread, storing the given POINTER instead. > > If there is no such key KEY, it returns `EINVAL'. Otherwise it > returns 0. > > -- Function: void * pthread_getspecific (pthread_key_t KEY) > `pthread_getspecific' returns the value currently associated with > KEY in the calling thread. > > If there is no such key KEY, it returns `NULL'. in gcc you can create (faster) thread local storage with the __thread keyword. as in __thread int foo; means that foo will be local to each thread. John -- John Meacham - ?repetae.net?john? From simonpj at microsoft.com Wed Oct 19 03:43:26 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 19 03:23:48 2005 Subject: [Haskell] Excessive sharing and GHC Message-ID: <036EAC76E7F5EC4996A3B3C3657D411603747B96@EUR-MSG-21.europe.corp.microsoft.com> | > >I was thinking it would be nice if one could put a pragma on CAFs that | > >basically made ghc treat them as WHNF so it would float them inward as | > >far as possible including inside lambdas. in particular, constant | > >strings that are created (cheaply) from efficient internal | > >representations should not be held onto in their inefficient form. I think the way to do this is to explain to GHC that unpackCString :: String# -> [Char] is a "cheap" function; that is, applications of it can safely be duplicated. There's no pragma to do this to an arbitrary at present, but it'd be a sensible sort of pragma to have. I wonder if it would make any difference in practice. Simon From gelbukh at cicling.org Wed Oct 19 05:01:56 2005 From: gelbukh at cicling.org (Alexander Gelbukh) Date: Wed Oct 19 11:10:41 2005 Subject: [Haskell] CFP: CICLing-2006 -- Computational Linguistics, Springer LNCS, February, Mexico -- one week reminder Message-ID: CICLing-2006 7th International Conference on Intelligent Text Processing and Computational Linguistics February 19-25, 2006 Mexico City, Mexico Endorsed by the ACL www.CICLing.org/2006 PUBLICATION: LNCS: Springer Lecture Notes in Computer Science. SUBMISSION DEADLINE: Abstract: October 17, late submissions can be considered; Main text: October 24, 2005 (for registered abstracts). MODALITIES: Full paper: 12 pages, short paper: 4 pages. KEYNOTE SPEAKERS: Nancy Ide, Rada Mihalcea, 2 more to be announced, see website. EXCURSIONS: Ancient pyramids, Monarch butterflies, great cave and colonial city, and more. All tentative. See photos on www.CICLing.org. AWARDS: Best paper, best presentation, best poster, best demo. +------------------------------------------------------- | Topics +------------------------------------------------------- Computational linguistics research: Comp. Linguistics theories and formalisms, Knowledge representation, Comp. morphology, syntax, semantics, Discourse models, Machine translation, text generation, Statistical methods, corpus linguistics, Lexical resources; Intelligent text processing and applications: Information retrieval, question answering, Information extraction, Text mining, Document categorization and clustering, Automatic summarization, Natural language interfaces, Spell-checking; and all related topics. +------------------------------------------------------- | Schedule (tentative) +------------------------------------------------------- Sunday, Wednesday, Saturday: full-day excursions; Monday, Tuesday, Thursday, Friday: talks; Monday: Welcome party & poster session. See website. ==================================================== See complete CFP and contact on www.CICLing.org/2006 ==================================================== We send you this CFP in good faith of its usefulness for you. If you do not want to receive any new messages, please let us know replying to this message. We deeply apologize for any inconvenience. From mai99dgf at studserv.uni-leipzig.de Wed Oct 19 14:20:10 2005 From: mai99dgf at studserv.uni-leipzig.de (Georg Martius) Date: Wed Oct 19 13:59:50 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set Message-ID: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> Hi folks, I was really annoyed by the fact that for Data.Map and Data.Set are no Read instances declared, but Show instances are! I believe there should be some kind of unwritten rule that in the standart lib the Show and Read instances come pairwise and are fully compatible. Anyway since there was no response to S. Alexander Jacobson post [1], I decided to write these instances at least for GHC in the style of the other instances in GHC.Read. For the {a,b,...} syntax I have used a modified version of @list@ from GHC.Read Is there a chance of having this in the libs? Cheers, Georg [1] http://www.haskell.org//pipermail/haskell/2005-February/015380.html import qualified Data.Map as Map import qualified Data.Set as Set import Text.Read import qualified Text.Read.Lex as L import GHC.Read instance (Ord k, Read k, Read e) => Read (Map.Map k e) where readPrec = do elements <- set (readPair readPrec readPrec) return $ Map.fromList elements -- ^ @(readPrec p1 p2)@ parses a pair of things with the syntax @a:=b@ -- where @a@ is parsed by @p1@, -- and @b@ is parsed by @p2@ readPair :: ReadPrec a -> ReadPrec b -> ReadPrec (a,b) readPair reada readb = do a <- reset reada L.Symbol ":=" <- lexP b <- reset readb return (a,b) instance (Ord a, Read a) => Read (Set.Set a) where readPrec = do elements <- set (readPrec) return $ Set.fromList elements set :: ReadPrec a -> ReadPrec [a] -- ^ @(set p)@ parses a list of things parsed by @p@, -- using the curly-braces syntax. set readx = parens ( do L.Punc "{" <- lexP (setRest False +++ setNext) ) where setRest started = do L.Punc c <- lexP case c of "}" -> return [] "," | started -> setNext _ -> pfail setNext = do x <- reset readx xs <- setRest True return (x:xs) -- ---- Georg Martius, Tel: (+49 34297) 89434 ---- ------- http://www.flexman.homeip.net --------- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20051019/da97b2ea/attachment.bin From frederik at a5.repetae.net Wed Oct 19 17:42:57 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed Oct 19 17:23:20 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set In-Reply-To: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> References: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> Message-ID: <20051019214257.GA7250@a5.repetae.net> On Wed, Oct 19, 2005 at 08:20:10PM +0200, Georg Martius wrote: > Hi folks, > > I was really annoyed by the fact that for Data.Map and Data.Set are no Read > instances declared, but Show instances are! I believe there should be some > kind of unwritten rule that in the standart lib the Show and Read instances > come pairwise and are fully compatible. I've been annoyed by this too. I wrote my own instances at one point. Frederik From maeder at tzi.de Thu Oct 20 04:18:23 2005 From: maeder at tzi.de (Christian Maeder) Date: Thu Oct 20 03:58:42 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set In-Reply-To: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> References: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> Message-ID: <435752CF.9050003@tzi.de> Georg Martius wrote: > Anyway since there was no response to S. Alexander Jacobson post [1], I > decided to write these instances at least for GHC in the style of the other > instances in GHC.Read. Who feels responsible for including something into Data.Set and Data.Map (recently I've proposed a change for Set.intersection and others also made suggestions)? The Read instances should be in "their" modules (to avoid "orphans"). But Set and Map should also remain "portable"! > import GHC.Read This module isn't even listed under http://www.haskell.org/ghc/docs/latest/html/libraries/index.html Cheers Christian Simon, clicking on any module does not work, currently Not Found The requested URL /ghc/docs/latest/html/libraries/base/Control.Arrow.html was not found on this server. Apache/2.0.46 (Red Hat) Server at www.haskell.org Port 80 From maeder at tzi.de Thu Oct 20 04:24:11 2005 From: maeder at tzi.de (Christian Maeder) Date: Thu Oct 20 04:04:30 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set In-Reply-To: <435752CF.9050003@tzi.de> References: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> <435752CF.9050003@tzi.de> Message-ID: <4357542B.7030702@tzi.de> Christian Maeder wrote: > Simon, clicking on any module does not work, currently > > Not Found > > The requested URL > /ghc/docs/latest/html/libraries/base/Control.Arrow.html was not found on > this server. > Apache/2.0.46 (Red Hat) Server at www.haskell.org Port 80 Sorry, it works now after I cleared my cache. From Malcolm.Wallace at cs.york.ac.uk Thu Oct 20 06:16:42 2005 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Oct 20 05:59:58 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set In-Reply-To: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> References: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> Message-ID: <20051020111642.7bb2e218.Malcolm.Wallace@cs.york.ac.uk> Georg Martius writes: > I was really annoyed by the fact that for Data.Map and Data.Set are no Read > instances declared, but Show instances are! I believe there should be some > kind of unwritten rule that in the standart lib the Show and Read instances > come pairwise and are fully compatible. FWIW, earlier versions of Haskell had a single class Text with methods for both showing and reading, so it was harder to ignore their complementary roles. Regards, Malcolm From event at mail.in.tu-clausthal.de Fri Oct 21 03:26:48 2005 From: event at mail.in.tu-clausthal.de (event@mail.in.tu-clausthal.de) Date: Fri Oct 21 03:20:55 2005 Subject: [Haskell] FM'06: CFP Message-ID: <20051021072648.GY24862@in.tu-clausthal.de> ========================================================================= FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS 21 - 27 August 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ ANNOUNCEMENT AND CALL FOR SUBMISSIONS FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, http://www.fmeurope.org, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Submissions are welcomed in the form of original papers on research and industrial experience, proposals for workshops and tutorials, entries for the exhibition of software tools and projects, and reports on ongoing doctoral work. FM'06 welcomes all aspects of formal methods research, both theoretical and practical. We are particularly interested in the experience of applying formal methods in practice. The broad topics of interest of this conference are: * Tools for formal methods: tool support and software engineering, environments for formal methods. * Theoretical foundations: specification and modelling, refining, static analysis, model-checking, verification, calculation, reusable domain theories. * Formal methods in practice: experience with introducing formal methods in industry, case studies. * Role of formal methods: formal methods in hardware and system design, method integration, development process. TECHNICAL PAPERS Full papers should be submitted via the web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Accepted papers will be published in the Symposium Proceedings, to appear in Springer's Lecture Notes in Computer Science series, http://www.springeronline.com/lncs . Submitted papers should have not been submitted elsewhere for publication, should be in Springer's format, (see Springer's web site), and should not exceed 16 pages including appendices. A prize for the best technical paper will be awarded at the symposium. INDUSTRIAL USAGE REPORTS One day will be dedicated to sharing the experience -- both positive and negative -- with using formal methods in industrial environments. The Industry Day is organized by ForTIA, the Formal Techniques Industry Association, http://www.fortia.org . This year's Industry Day investigates the use of formal methods in security and trust. Invited papers on organizational and technical issues will be presented. Inquiries should be directed to the Industry Day Chairs; see the web site for details. WORKSHOPS We welcome proposals for one-day or one-and-a-half-day workshops related to FM'06. In particular, but not exclusively, we encourage proposals for workshops on various application domains. Proposals should be directed to the Workshop Chair. TUTORIALS We are soliciting proposals for full-day or half-day tutorials. The tutorial contents can be selected from a wide range of topics that reflect the conference themes and provide clear utility to practitioners. Each proposal will be evaluated on importance, relevance, timeliness, audience appeal and past experience and qualification of the instructors. Proposals should be directed to the Tutorial Chair. POSTER AND TOOL EXHIBITION An exhibition of both research projects and commercial tools will accompany the technical symposium, with the opportunity of holding scheduled presentations of commercial tools. Proposals should be directed to the Poster and Tools Exhibition Chair. DOCTORAL SYMPOSIUM For the first time, FM'06 will feature a doctoral symposium. Students are invited to submit work in progress and to defend it in front of "friendly examiners". Participation for students who are accepted will be subsidized. Submissions should be directed to the Doctoral Symposium Chair. SUBMISSION DATES Technical Papers, Workshops, Tutorials: Friday, February 24, 2006 Posters and Tools, Doctoral Symposium: Friday, May 26, 2006 NOTIFICATION DATES Technical Papers: Friday, April 28, 2006 Workshops, Tutorials: Friday, March 10, 2006 Posters and Tools, Doctoral Symposium: Friday, June 9, 2006 ORGANIZATION General Chair: Emil Sekerinski (McMaster) Program Chairs: Jayadev Misra (U. Texas, Austin), Tobias Nipkow (TU Munich) Workshop Chair: Tom Maibaum (McMaster) Tutorial Chair: Jin Song Dong (NUS) Tools and Poster Exhibition Chair: Marsha Chechik (U. Toronto) Industry Day Chairs: Volkmar Lotz (SAP France), Asuman Suenbuel (SAP US) Doctoral Symposium Chair: Augusto Sampaio (U. Pernambuco) Sponsorship Chair: Juergen Dingel (Queens U.) PROGRAM COMMITTEE Jean-Raymond Abrial (ETH Zurich) Alex Aiken (Stanford U.) Keijiro Araki (Kyushu U.) Ralph Back (Abo Akademi) Gilles Barthe (INRIA) David Basin (ETH Zurich) Ed Brinksma (U. Twente) Michael Butler (U. Southampton) Rance Cleaveland (U. Stony Brook) Jorge Cuellar (Siemens) Werner Damm (U. Oldenburg) Frank de Boer (U. Utrecht) Javier Esparza (U. Stuttgart) Jose Fiadeiro (U. Leicester) Susanne Graf (VERIMAG) Ian Hayes (U. Queensland) Gerard Holzmann (JPL) Cliff Jones (U. Newcastle) Gary T. Leavens (Iowa State U.) Rustan Leino (Microsoft) Xavier Leroy (INRIA) Dominique Mery (LORIA) Carroll Morgan (UNSW) David Naumann (Stevens) E.-R. Olderog (U. Oldenburg) Paritosh Pandya (TIFR) Sriram Rajamani (Microsoft) John Rushby (SRI) Steve Schneider (U. Surrey) Vitaly Shmatikov (U. Texas, Austin) Bernhard Steffen (U. Dortmund) P.S. Thiagarajan (NUS) Axel van Lamsweerde (U. Louvain) Martin Wirsing (LMU Munich) Pierre Wolper (U. Liege) LOCAL ORGANIZATION Publicity: Wolfram Kahl, Alan Wassyng, Jeff Zucker Tools, Posters, Book Exhibition: Spencer Smith Social Events: Ridha Khedri Local Arrangements:: William Farmer, Mark Lawford Events Co-ordinator: Ryszard Janicki ------------------------------------------------------------------------ This e-mail was delivered to you by event@in.tu-clausthal.de, what is a moderated list runned by Computational Intelligence Group of Clausthal University of Technology, Germany. All event announcements sent through this list are also listed in our conference planner at http://cig.in.tu-clausthal.de/index.php?id=planner. In the case of any requests, questions, or comments, do not hesitate and contact event-owner@in.tu-clausthal.de ASAP. ****************************************************** * CIG does not take any responsibility for validity * * of content of messages sent through this list. * ****************************************************** Computational Intelligence Group Department of Computer Science Clausthal University of Technology Germany http://cig.in.tu-clausthal.de/ From nhn at Cs.Nott.AC.UK Fri Oct 21 14:59:30 2005 From: nhn at Cs.Nott.AC.UK (Henrik Nilsson) Date: Fri Oct 21 14:41:53 2005 Subject: [Haskell] TFP2006: call for papers Message-ID: <43593A92.6000708@cs.nott.ac.uk> Apologies for multiple copies. /Henrik -- Henrik Nilsson School of Computer Science and Information Technology The University of Nottingham nhn@cs.nott.ac.uk This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- TFP 2006 Seventh Symposium on Trends in Functional Programming Nottingham, UK, 19 - 21 April, 2006 http://www.cs.nott.ac.uk/~nhn/TFP2006 Co-located with Types 2006 CALL FOR PAPERS The Symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming languages, focusing on providing a broad view of current and future trends in Functional Programming. It aspires to be a lively environment for presenting the latest research results through acceptance by extended abstracts. A formal post-symposium refereeing process then selects the best papers presented at the symposium for publication in a high-profile volume. TFP 2006 is going to be held in Nottingham, UK, 19 - 21 April. Note that this is significantly earlier in the year than past TFPs that generally were held in August - September. TFP 2006 is co-located with Types 2006 (18 - 21 April). Previous TFP symposia were held in Scotland in 2002 and 2003, as successors to the successful series of Scottish Functional Programming Workshops, in Munich, Germany in 2004, and in Tallinn, Estonia in 2005 (co-located with ICFP and GPCE). For further general information about TFP, see http://www.tifp.org/. SCOPE OF THE SYMPOSIUM The Symposium recognises that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five categories of paper. High-quality papers are solicited in any of these categories: Research Papers: leading-edge, previously unpublished research work Position Papers: on what new trends should or should not be Project Papers: descriptions of recently started new projects Evaluation Papers: what lessons can be drawn from a finished project Overview Papers: summarising work with respect to a trendy subject Papers must be original, and not submitted for simultaneous publication in any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or more experience-oriented. Also applications of functional programming techniques to other languages may be considered. Papers on the following subject areas are particularly welcome: o dependently typed functional programming o validation and verification of functional programs o debugging for functional languages o functional programming and security o functional programming and mobility o functional programming and formally motivated computing o functional languages for telecommunications applications o functional languages for embedded systems o functional programming applied to global computing o functional GRIDs o functional languages for reasoning about imperative/object-oriented programs o interoperability with imperative programming languages o any new emerging trend in the functional programming area If you are in doubt on whether your paper is within the scope of TFP, please contact the TFP 2006 program chair, Henrik Nilsson, nhn@cs.nott.ac.uk. BEST STUDENT PAPER AWARD TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. To acknowledge this, a prize for the best student paper is awarded each year. CO-LOCATION WITH TYPES 2006 TFP 2006 is co-located with Types 2006 (to be held 18 - 21 April). To take advantage of the synergies offered by these two complementary events, we will invite a number of joint keynote speakers, hold joint sessions on topics of mutual interest, such as dependently typed functional programming, and run common social events. The schedule will be arranged so that participants may freely move between parallel sessions of the two events. SUBMISSION Acceptance to the symposium will be based upon extended abstracts of between 6 and 10 pages. Accepted abstracts are to be completed to full papers before the symposium for publication in the local symposium proceedings. Important dates: Deadline for abstract submission: 17 February, 2006 Notification of acceptance: 27 February, 2006 Registration deadline: 17 March, 2006 Camera-ready copy of full paper: 24 March, 2006 The submission must clearly indicate to which category it belongs: research, position, project, evaluation or overview paper. It should also indicate whether the main author or authors are research students. Abstracts and full papers must be written in English. Papers for the symposium proceedings must adhere to the formatting instructions using the provided on the TFP 2006 site. Papers must not exceed 16 pages; papers in some categories may comprise considerably fewer pages. POST SYMPOSIUM REFEREEING AND PUBLICATION In addition to the local symposium proceedings, we intend to continue the TFP tradition of publishing a high-quality subset of contributions in the Intellect series on Trends in Functional Programming. Revised papers will be refereed after the symposium to the normal conference standards and a subset of the best papers over all categories will be selected for publication. Papers will be judged on their contribution to the research area, with appropriate criteria applied to each category of paper. Papers submitted for publication by Intellect must follow formatting and any other instructions provided by the Programme Chair. For TFP 2005, in order to enhance the quality of student submissions, a process where student papers were given extra feedback was tried out. A similar process might be put in place for this TFP, contingent on the outcome of that trial. ORGANISATION Symposium Chair: Marko van Eekelen, Radboud University Nijmegen, NL Programme Chair: Henrik Nilsson, University of Nottingham, UK Treasurer: Greg Michaelson, Heriot-Watt University, UK Local Arrangements: Joel Wright, University of Nottingham, UK PROGRAMME COMMITTEE: The programme committee is currently being assembled. The current members of the TFP Advisory Committee are: o Sharon Curtis, Oxford Brookes University o Gaetan Hains, Université d'Orléans o John Hughes, Chalmers University o Kevin Hammond, University of St Andrews o Hans-Wolfgang Loidl, Ludwig-Maximilians-Universität München o Rita Loogen, Philipps-Universität Marburg o Greg Michaelson, Heriot-Watt University o John O'Donnell, University of Glasgow o Ricardo Pena, Universidad Complutense de Madrid, o Phil Trinder, Heriot-Watt University o Marko van Eekelen, University of Nijmegen SPONSORS We are actively looking for additional TFP sponsors, who may help to subsidise attendance by research students, for example. If you or your organisation might be willing to sponsor TFP, or if you know someone who might be willing to do so, please do not hesitate to contact the Symposium chair: Marko van Eekelen. Your students will be grateful! From camior at gmail.com Fri Oct 21 19:22:31 2005 From: camior at gmail.com (David Sankel) Date: Fri Oct 21 19:02:46 2005 Subject: [Haskell] Read Instances for Data.Map and Data.Set In-Reply-To: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> References: <200510192020.17463.mai99dgf@studserv.uni-leipzig.de> Message-ID: On 10/19/05, Georg Martius wrote: > I was really annoyed by the fact that for Data.Map and Data.Set are no Read > instances declared, but Show instances are! I believe there should be some > kind of unwritten rule that in the standart lib the Show and Read instances > come pairwise and are fully compatible. If there was this unwritten rule, should there not be other rules designed to ensure that reads and shows with interacting types are compatible? For example, I could imagine a type that would read and show on it's own, but a map of these objects wouldn't read and show correctly. I'm not suggesting this, but a possible solution would be to use parenthesis around every type and disallow a type to show to unmatched internal parenthesis. Regards, David From ashley at semantic.org Mon Oct 24 05:15:59 2005 From: ashley at semantic.org (Ashley Yakeley) Date: Mon Oct 24 04:59:16 2005 Subject: [Haskell] Re: getArgs, maxBound, float division: pure functions? References: <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil> Message-ID: In article <20051011060428.B7BC8ACB2@Adric.metnet.navy.mil>, oleg@pobox.com wrote: > To recap, there were two arguments for getArgs to remain with the > IO [String] type: As was argued earlier, it seems the correct thing would be to retype "main": main :: [String] -> IO () or main :: (?args :: [String]) => IO () or type ReturnCode = Int main :: [String] -> IO ReturnCode I sometimes dream of an approach where all system services are provided by implicit parameters supplied to "main": main :: (?stdin :: Handle, ?stdout :: Handle, ?stderr :: Handle, ?filesystem :: FileSystem, ?internets :: [InternetConnection], ?gettime :: IO UTCTime, ... ) => [String] -> IO ReturnCode Of course, this would make a bit more sense if there were a mechanism for applying type contexts to modules, so that they applied to all declared type signatures. -- Ashley Yakeley, Seattle WA From hcar at haskell.org Tue Oct 25 12:05:07 2005 From: hcar at haskell.org (Andres Loeh) Date: Tue Oct 25 11:41:54 2005 Subject: [Haskell] REMINDER: Contributions to the HC&A Report (November 2005 edition) Message-ID: <20051025160506.GH14855@iai.uni-bonn.de> Dear Haskellers, the deadline for the November 2006 edition of the Haskell Communities and Activities Report is only a few days away -- but this is still enough time to make sure that the report contains a section on *your* project, on the interesting stuff that you've been doing; using or affecting Haskell in some way. Many projects that have been included in former reports have not yet updated their entries. Please have a look at http://haskell.org/communities/topics.html and at the May 2005 edition for reference. * Has your project been listed in previous Reports, but is not yet updated? Please write a short update! * Are you no longer working on a project that was included in the Report? Write up what you are working on instead, and tell me if someone else has picked up the project. * Is some project you have heard about not included in any previous Report? Please let me know ... There is still time to write a completely new entry, on a new compiler, tool, library, company, user group, idea, ... -- as long as there is a connection to the Haskell language, there is a place for it in the Report! Submissions are due by next Tuesday, that is Tuesday, 01 November 2005. Please mail your entries to , in plain text or pseudo-(La)TeX format. More information can be found in the original Call for Contributions at http://www.haskell.org/pipermail/haskell/2005-October/016575.html I look forward to receiving your contributions. Thanks a lot, Andres (current editor) -- Haskell Communities and Activities Report (http://haskell.org/communities) 11/2005 edition submission deadline: 01 November 2005 From robdockins at fastmail.fm Tue Oct 25 18:26:57 2005 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Oct 25 18:07:00 2005 Subject: [Haskell] [mini-announce] Attribute grammars in happy Message-ID: <200510251826.57944.robdockins@fastmail.fm> Fellow Haskellers, I have hacked up Happy (http://www.haskell.org/happy/) to support attribute grammars. Attribute grammars are a way of annotating context-free grammars to support syntax directed translation and the checking of context-sensitive properties. What we have: * Support for attribute grammars using a slight modification to the Happy grammar syntax * Haskell 98! No language extensions required. * Support for all well-defined attribute grammars (conjecture, but I'm pretty sure) What we don't have: * Support for GLR parsing (mostly because I don't completely understand it) * Checks for proper attribute usage There is a darcs repo at based on the Happy 1.15 source distribution at: http://www.eecs.tufts.edu/~rdocki01/happy-ag/ And documentation for the extension can be found at: http://www.eecs.tufts.edu/~rdocki01/happy-ag-docs/sec-AttributeGrammar.html If there is sufficient interest I can clean up the code and write test cases and submit an official patch to Happy. Let me know what you think. Comments and suggestions are welcome. Thanks, Robert Dockins P.S. Discussion should probably move to haskell-cafe. From michael at schmong.org Tue Oct 25 20:36:10 2005 From: michael at schmong.org (michael@schmong.org) Date: Tue Oct 25 20:16:13 2005 Subject: [Haskell] logic problem Message-ID: <20051026003610.GA17438@schmong.org> Hi, My name is Michael. I'm new to Haskell. I'm working through The Craft of Functional Programming by Simon Thompson. I'm having problems with a few exercises from chapter 4. I will present one per post. This one is from 4.9 Given a function f of type Int -> Int give a recursive definition of a function of type Int -> Int which on input n returns the maximum values f 0, f 1, ... , f n I defined f as follows f 0 = 0 f 1 = 44 f 2 = 5 f 9 = 8 this works except when f n > n. In that case I get an "illegal instruction" error and hugs exits. I'm pretty sure this is a logic problem. Could someone point me in the right direction so I can think about this problem correctly. Here is my code maxOverf :: Int -> Int maxOverf m | f m > m = (f m) | otherwise = (maxOverf m-1) Any hints/help/flames welcome. Thanks Michael Litchard From marcot at minaslivre.org Tue Oct 25 21:00:46 2005 From: marcot at minaslivre.org (Marco Tulio Gontijo e Silva) Date: Tue Oct 25 20:46:52 2005 Subject: [Haskell] logic problem In-Reply-To: <20051026003610.GA17438@schmong.org> References: <20051026003610.GA17438@schmong.org> Message-ID: <1130288446.5941.8.camel@tonhao.no-ip.org> Skipped content of type multipart/signed-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3785 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20051025/bb936edd/smime.bin From robdockins at fastmail.fm Tue Oct 25 23:08:02 2005 From: robdockins at fastmail.fm (Robert Dockins) Date: Tue Oct 25 22:48:03 2005 Subject: [Haskell] logic problem In-Reply-To: <20051026003610.GA17438@schmong.org> References: <20051026003610.GA17438@schmong.org> Message-ID: <200510252308.02677.robdockins@fastmail.fm> On Tuesday 25 October 2005 08:36 pm, michael@schmong.org wrote: > Hi, > My name is Michael. I'm new to Haskell. I'm working through > The Craft of Functional Programming by Simon Thompson. > I'm having problems with a few exercises from chapter 4. I will > present one per post. > > This one is from 4.9 > Given a function f of type Int -> Int give a recursive definition > of a function of type Int -> Int which on input n returns the maximum > values f 0, f 1, ... , f n > > I defined f as follows > f 0 = 0 > f 1 = 44 > f 2 = 5 > f 9 = 8 Most likely your problem is that f is only defined for input values 0, 1, 2 and 9. If you call f with any other value, you will end up with an error. > this works except when f n > n. In that case I get an "illegal > instruction" error and hugs exits. > I'm pretty sure this is a logic problem. Could someone point me > in the right direction so I can think about this problem correctly. > Here is my code > > maxOverf :: Int -> Int > maxOverf m > > | f m > m = (f m) > | otherwise = (maxOverf m-1) Here you are calling f with successively decreasing values; that will run into areas where f is undefined for any value of m other than 1 or 2. > Any hints/help/flames welcome. Thanks Try a total rather than a partial function for f. You can just add a default clause to the end, like f _ = 0 which will define f x to be 0 for all values of x except the ones already mentioned. From list at atmarama.org Wed Oct 26 02:24:41 2005 From: list at atmarama.org (Gour) Date: Wed Oct 26 02:04:55 2005 Subject: [Haskell] logic problem In-Reply-To: <200510252308.02677.robdockins@fastmail.fm> References: <20051026003610.GA17438@schmong.org> <200510252308.02677.robdockins@fastmail.fm> Message-ID: <20051026062441.GA20180@mail.inet.hr> Robert Dockins (robdockins@fastmail.fm) wrote: > Try a total rather than a partial function for f. You can just add a > default clause to the end, like > > f _ = 0 btw, the above definition is in the text of the 4.9 exercise ;) Sincerely, Gour -- Registered Linux User | #278493 GPG Public Key | 8C44EDCD From wolfgang at jeltsch.net Wed Oct 26 05:52:45 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Wed Oct 26 05:32:56 2005 Subject: [Haskell] logic problem In-Reply-To: <20051026003610.GA17438@schmong.org> References: <20051026003610.GA17438@schmong.org> Message-ID: <200510261152.45805.wolfgang@jeltsch.net> Am Mittwoch, 26. Oktober 2005 02:36 schrieb michael@schmong.org: > In that case I get an "illegal instruction" error and hugs exits. This is a bug in Hugs but your code is incorrect, too. You get into infinite recursion for some argument values and I suppose, Hugs doesn't handle infinite recursions well. At least, Hugs sometimes dies with a segementation fault on Linux when it actually should cancel the computation cleanly because of a stack/heap overflow caused by infinite recursion. > [...] Best wishes, Wolfgang From simonpj at microsoft.com Wed Oct 26 09:01:08 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Oct 26 08:41:08 2005 Subject: [Haskell] multiple occurence of the same type variable in instancehead Message-ID: <036EAC76E7F5EC4996A3B3C3657D411603841781@EUR-MSG-21.europe.corp.microsoft.com> Quite right. I've fixed the documentation (in CVS). Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Wolfgang | Jeltsch | Sent: 17 October 2005 14:04 | To: Haskell ML | Subject: [Haskell] multiple occurence of the same type variable in instancehead | | Hello, | | the following is not Haskell 98: | | class C a | | instance C (a,a) | | Well, GHC allows this with the -fglasgow-exts flag. Surprisingly, I cannot | find a section in the GHC User's Guide which states that -fglasgow-exts can | be used to allow this kind of instance declarations. Well, in the section on | undecidable instances (7.4.4.3), one can read: | | Note that instance heads may contain repeated type variables. For example, | this is OK: | | instance Stateful (ST s) (MutVar s) where ... | | But one has to note that in this expample, the different occurences of s | aren't in the same type. Furthermore, multiple occurences of the same type | variable cannot result in undecidability (as far as I understand). The | above-mentioned statement talks about the things that are allowed *without* | -fallow-undecidable-instances, and premises that multiple occurences of a | type variable are okay. | | So am I missing something? | | Best wishes, | Wolfgang | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From yminsky at janestcapital.com Wed Oct 26 18:18:26 2005 From: yminsky at janestcapital.com (Yaron Minsky) Date: Wed Oct 26 17:58:25 2005 Subject: [Haskell] OCaml-intensive summer internships at trading firm Message-ID: <1130365106.4080.12.camel@quant2.janestcapital.quant> Jane Street Capital (http://janestcapital.com) is a proprietary trading company located in Manhattan. We're looking for students interested in internships for the summer of 2006. Jane Street is an open and informal environment (you can wear shorts and a t-shirt to the office), and the work is technically challenging, including systems programming, machine learning, statistical analysis, parallel processing, and anything that crosses our path that looks useful. One unusual attraction of the job is that the large majority of our programming is done in OCaml. Here's what we're looking for from candidates: - A commitment to the practical. Both development and research are tightly integrated with our trading operation, and we work very hard to keep our work relevant. One of the big attractions of the job is the opportunity to apply serious ideas to real-world problems. - Great communication skills. We need people who can explain things clearly and cogently, who can read dense academic papers and write clear documentation. - Strong programming skills. Most of our programming is in OCaml, so being a solid Caml hacker is a big plus. Extra points for deep knowledge of OCaml internals and experience wrapping thorny libraries. But we're also interested in great programmers who we are convinced will be able to pick up OCaml quickly, so anyone with high-level of proficiency with functional languages would be a good match. - Top-notch mathematical and analytic skills. We want people who can solve difficult technical problems, and think clearly and mathematically about all sorts of problems. - Strong Unix/Linux skills --- We're looking for someone who knows their way around the standard Unix tools, can write makefiles, shell scripts, etc. We're also very interested in people with serious systems administration and architecture experience. Summer interns are paid quite well, and we can help out with housing costs if you don't live nearby. If you're interested, please send a cover-letter and resume to: yminsky@janestcapital.com -- Yaron Minsky From jawarren at gmail.com Wed Oct 26 22:00:38 2005 From: jawarren at gmail.com (Jared Warren) Date: Wed Oct 26 21:40:35 2005 Subject: [Haskell] Instances That Ignore Type Constraints? (HList-related) Message-ID: <63648e1b0510261900ncada45dnd17d0c753bda5da7@mail.gmail.com> I'm working with data structures that contain class methods from the HList library (classes with functional dependencies). What I want to be able to do is operate on high-level parts of the structure while ignoring the type constraints of the lower-level components. For example, say I have two data types and a class method: > data Box x = Box x > data Carton x = Carton x > class Func x y | x -> y where func :: x -> y I want to define a function 'isBoxed' that identifies whether a function is in a Box or in a Carton that I can use like `isBoxed (Carton func)`. Naively: > class IsBoxed f b | f -> b where isBoxed :: f -> b > instance IsBoxed (Box x) HTrue where isBoxed _ = hTrue > instance IsBoxed (Carton x) HFalse where isBoxed _ = hFalse (Where hTrue is a constructorish thing for the empty datatype HTrue.) But `isBoxed (Box func)` fails in GHC with "Ambiguous type variables `x', `y' in the constraint: `Func x y' arising from use of `func'...". I realise that it's solvable if I have a finite number of instances for Func, but what I actually want to box is functions with recursive constraints like HList's hLookupByLabel.* I tried to borrow some ideas (like TypeCast and empty data types) from the examples that come along with HList (like keyword-arguments.hs) to no avail. Can anybody give me a hand? Thanks, Jared Warren * I could satisfy the type constraints with the infinite HList Record: {Label hZero -> undefined, Label (hSucc hZero) -> undefined, ...} ...but that obviously runs into an infinite type. From ralfla at microsoft.com Thu Oct 27 00:41:47 2005 From: ralfla at microsoft.com (Ralf Lammel) Date: Thu Oct 27 00:21:51 2005 Subject: [Haskell] Instances That Ignore Type Constraints? (HList-related) Message-ID: <1152E22EE8996742A7E36BBBA7768FEE07828DDD@RED-MSG-50.redmond.corp.microsoft.com> Hi, 'isBoxed (Carton func)' fails because there is no way whatsoever that any expression context will disambiguate the x y type variables of func's type. That is, the type of `isBoxed (Box func)` does not expose x (and y -- the latter being irrelevant because of the fundep); so there is no way that the type system could ever figure out which x (and y) was meant; hence overloading will never ever get resolved (check out the hugs type error, which tells you exactly that). One could argue in favor of incoherent choice of instances. (I don't!) Say, if you had: {-# OPTIONS -fallow-undecidable-instances #-} {-# OPTIONS -fallow-incoherent-instances #-} instance Func x x -- or some other generic instance It will work fine: ghci> isBoxed (Carton func) HFalse However, why would you want to wrap such a function anyhow, if you are not going to use it? :-) Perhaps, this is a case of superficial, say unintended polymorphism. If you *really* wanted to box (or to carton) a polymorphic type-class bounded function, then you may need to do something like this: data WFunc = WFunc (forall x y. Func x y => (x -> y)) hugs-or-ghci> isBoxed (Carton (WFunc func)) HFalse This works fine ... but this is probably *not* what you wanted in the first place. Also, this technique is extremely limiting because now you would need to fabricate wrappers like WFunc for each new polymorphic expression (when the constraints or the type differ). I am keen to hear more about your problem, and to help accordingly. (Haskell-caf??) Regards, Ralf > -----Original Message----- > From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On > Behalf Of Jared Warren > Sent: Wednesday, October 26, 2005 7:01 PM > To: Haskell Mailing List > Subject: [Haskell] Instances That Ignore Type Constraints? (HList-related) > > > > data Box x = Box x > > data Carton x = Carton x > > class Func x y | x -> y where func :: x -> y > > > class IsBoxed f b | f -> b where isBoxed :: f -> b > > instance IsBoxed (Box x) HTrue where isBoxed _ = hTrue > > instance IsBoxed (Carton x) HFalse where isBoxed _ = hFalse > > `isBoxed (Box func)` fails in GHC with "Ambiguous type variables > `x', `y' in the constraint: `Func x y' arising from use of `func'...". From oleg at pobox.com Thu Oct 27 04:04:49 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Thu Oct 27 03:46:39 2005 Subject: [Haskell] Re: Instances That Ignore Type Constraints? (HList-related) Message-ID: <20051027080449.1CD65ACB2@Adric.metnet.navy.mil> Just to add one more example to Ralf's reply: We get exactly the same kind of problem if we try *Main> null [fromEnum] :1:6: Ambiguous type variable `a' in the constraint: `Enum a' arising from use of `fromEnum' at :1:6-13 Probable fix: add a type signature that fixes these type variable(s) Indeed, fromEnum is a polymorphic function |fromEnum :: (Enum a) => a -> Int| The expression [fromEnum] has the type |(Enum a) => [a -> Int]| that carries the constraint Enum a. That constraint has to be eventually resolved somehow. For a top-level expression (not a function), the constraint must be resolved. Granted, the function 'null' could care less what the list is made of, and whether all constraints are resolved. But Haskell does. One may say that instead of inferring the type [fromEnum] :: forall a. (Enum a) => [a -> Int] Haskell should have inferred [fromEnum] :: [forall a. (Enum a) => a -> Int] and the problem would have been solved. There is no longer an (outermost, top-level) constraint to resolve. When GHC does implement MLF and start explicitly supporting impredicative types, the problem would be fixed indeed... Currently, the only way to achieve the same effect is to do this manually: newtype W = W (forall a. (Enum a) => a -> Int) *Main> null [W fromEnum] False Perhaps indeed we should move to Cafe... From ross at soi.city.ac.uk Thu Oct 27 07:18:32 2005 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Oct 27 06:58:30 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051013125136.GO21098@momenergy.repetae.net> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> <20051013125136.GO21098@momenergy.repetae.net> Message-ID: <20051027111832.GA8294@soi.city.ac.uk> On Thu, Oct 13, 2005 at 05:51:36AM -0700, John Meacham wrote: > On Thu, Oct 13, 2005 at 12:21:41PM +0100, Simon Peyton-Jones wrote: > > Anyway, my main point is: would a smaller change not suffice? > > I do not think it suffices. > > We could extend the supertyping relationship some more to make it > suitable, but I think we will end up with the exact same proposal but > with different terminology :) For concreteness, here's a slight narrowing of Simon's version. Given your H98 classes class Additive a where (+) :: a -> a -> a zero :: a class Additive a => Negative where (-) :: a -> a -> a negate :: a -> a x - y = x + negate y negate x = zero - x class Multiplicative a where (*) :: a -> a -> a one :: a extend the class syntax with an annotation on the assumptions (! for now), to allow class (Show a, !Additive a, !Negative a, !Multiplicative a) => Num a where fromInteger :: Integer -> a one = fromInteger 1 zero = fromInteger 0 (This is for illustration -- I'm not claiming this is the ideal factoring of the Num class.) The ! annotations would be ignored during type inference. Their only meaning is (a) the class declaration for Num may include defaults for the methods of the !'d superclasses, (b) an instance declaration for Num also defines instances for the !'d superclasses, and thus may include definitions for the methods of Num and those superclasses. Any methods of these classes not defined in the instance are assigned default definitions, with defaults in the Num class overriding any in the superclasses. Thus if a Num instance is given, a Show instance must also be in scope (as now), but Additive, Negative and Multiplicative instances cannot be given, e.g.: instance Show Int65536 where showsPrec n = showsPrec n . toInteger instance Num Int65536 where (+) = primPlusInt65536 (-) = primMinusInt65536 (*) = primMultInt65536 fromInteger = primFromInteger65536 In comparision with the class alias proposal, this loses aliasing, but retains the ability to define defaults for superclasses, which is what I've been missing for ages. All these proposals need to address repeated inheritance, as in an example from Davis Menendez: class (!Functor m) => Monad m where { fmap = liftM; ... } class (!Functor d) => Comonad d where { fmap = liftD; ... } With the above rules, it would be illegal to define instances of both these classes for the same type, but one could define class (!Monad f, !Comonad f) => MonadComonad f where ... as long as either the class includes a default definition of fmap, or the instance includes a definition: instance MonadComonad Id where fmap f (Id x) = Id (f x) ... MPTCs raise extra issues, like class (!Functor f, !Functor g) => Something f g where fmap = ... Which Functor is being given a default fmap? I'd prefer to avoid this by requiring that the !'d assumptions have exactly the same arguments as the class being defined. From Ketil.Malde at bccs.uib.no Thu Oct 27 09:30:54 2005 From: Ketil.Malde at bccs.uib.no (Ketil Malde) Date: Fri Oct 28 03:35:46 2005 Subject: [Haskell] [Fwd: Bug in Data.IntSet?] Message-ID: <4360D68E.90308@ii.uib.no> Sigh. My system insists on rewriting outgoing mail headers, and ghc-users refuses non-subscribers to post there. I'm too tired to fight this at the moment, so I'll send it here in the hope that it will be picked up by the right adressee. -k -------- Original Message -------- Subject: Bug in Data.IntSet? Date: Thu, 27 Oct 2005 15:25:30 +0200 From: Ketil Malde To: glasgow-haskell-users AFAICT, there is a bug in Data.IntSet.split Here's an excerpt from GHCi: *Main> let m=482 in Data.IntSet.split (16*m) $ Data.IntSet.fromList (List.map (m*) [17,18,19,30,40]) ({8194,8676,9158},{14460,19280}) *Main> let m=481 in Data.IntSet.split (16*m) $ Data.IntSet.fromList (List.map (m*) [17,18,19,30,40]) ({},{8177,8658,9139,14430,19240}) *Main> let m=481 in Data.Set.split (16*m) $ Data.Set.fromList (List.map (m*) [17,18,19,30,40]) ({},{8177,8658,9139,14430,19240}) *Main> let m=482 in Data.Set.split (16*m) $ Data.Set.fromList (List.map (m*) [17,18,19,30,40]) ({},{8194,8676,9158,14460,19280}) *Main> let m=482 in Data.Set.split (16*m) $ Data.Set.fromList (List.map (m*) [17,18,19,30,40]::[Int]) ({},{8194,8676,9158,14460,19280}) % ghci --version The Glorious Glasgow Haskell Compilation System, version 6.4.1 -k From thiagu at comp.nus.edu.sg Fri Oct 28 02:12:25 2005 From: thiagu at comp.nus.edu.sg (P S Thiagarajan) Date: Fri Oct 28 03:35:48 2005 Subject: [Haskell] Petri Nets 2006 CFP Message-ID: <20051028061225.GA27369@comp.nus.edu.sg> Apologies if you receive multiple copies. ------------------------------------------------------------------------ Call for Papers and Announcement Petri Nets 2006 27th INTERNATIONAL CONFERENCE ON APPLICATION AND THEORY OF PETRI NETS AND OTHER MODELS OF CONCURRENCY Turku, Finland, June 26-30, 2006 Additional information about the conference will be published via http://www.cs.abo.fi/atpn2006/ Contact e-mail: atpn2006@abo.fi In 2006 the Petri Nets conference is co-located with the ACSD'06. Important Dates: Submission of Papers & Tool Presentations: November 15, 2005 Notification: March 1, 2006 Final Version Due: April 1, 2006 Tutorials & Workshops: June 26-27, 2006 Conference: June 28-30, 2006 The deadline for submission of papers and tool presentations is STRICT. However, if you submit the title page before Nov. 15 it is sufficient to submit the full paper/tool presentation before Nov. 22. The title page must contain a short abstract, classification of the paper, and tell whether it is a theory paper, application paper, or tool presentation. The 27th annual international Petri Net conference and tutorials will be organised by ????o Akademi University, Department of Computer Science. Papers presenting original contributions in any area of application and theory of Petri nets are sought. The language of the conference is English. Topics System design and verification using nets, Analysis and synthesis, structure and behaviour of nets, Relationships between net theory and other approaches, Causality/partial order theory of concurrency, Net-based semantical, logical and algebraic calculi, Symbolic net representation (graphical or textual), Computer tools for nets, Experience with using nets, case studies, Educational issues related to nets, Higher-level net models, Timed and stochastic nets, Standardisation of nets, Applications of nets to different kinds of systems and application fields, e.g.: flexible manufacturing systems, real-time systems, embedded systems, defence systems, biological systems, health and medical systems, environmental systems, hardware structures, telecommunications, railway networks, office automation, workflows, supervisory control, protocols and networks, Internet, e-commerce and trading, programming languages, performance evaluation, operations research. The conference takes place under the auspices of EATCS and GI SIG "Petri Nets and Related System Models". Paper Submissions Submissions for papers must: * Contain original contributions that have not been published or submitted to other conferences/journals in parallel with this conference. * Clearly state the problem being addressed, the goal of the work, the results achieved, and the relation to other work. * Be in the Springer LNCS-format: http://www.springer.de/comp/lncs/authors.html. * Have a length that does not exceed 20 pages. * Be in English and in a form that can be immediately included in the proceedings without major revision. * Be sent electronically (as a PostScript or PDF file) using the website http://sttt.cs.uni-dortmund.de/atpn06/servlet/Conference no later than November 15, 2005. The title page must: * Contain a short abstract and a classification of the topics covered, preferably using the list of topics above. * Clearly indicate whether the paper is submitted as a theory paper, an application paper, or both. A typical application paper is a paper that describes one or more projects in which Petri net models and tools have been used in practice. An application paper may also describe a tool, a methodology, or other developments that demonstrate the applicability of Petri nets to industrial systems. Submissions received too late and submissions sent by fax will be immediately rejected. The same will happen with papers which are not in English or exceed the page limit. Authors will be notified of acceptance/rejection by March 1, 2006. The proceedings will be published by Springer-Verlag in Lecture Notes in Computer Science. The final camera-ready version of accepted papers must be received by Susanna Donatelli no later than April 1, 2006. The page limit is 20 pages. Program Committee Co-Chair (Theory Papers) P. S. Thiagarajan School of computing, NUS 3 Science Drive 2 Singapore 117543 Phone: +65-6874 7998 Fax: +65-6779 4580 Program Committee Co-Chair (Application Papers) Susanna Donatelli Universit? degli Studi di Torino Dipartimento di Informatica Corso Svizzera 185 I-10149 Torino Italy Phone: +39 011 6706746 Fax: +39 011 751603 Organising Committee Chair Johan Lilius ????o Akademi University Department of Computer Science Lemmink????nengatan 14 A FIN-20540 Turku FINLAND Phone: +358 40 5440741 Fax: +358 2 215 4732 Tools Demonstration Chair Jerker Bj????kqvist ????o Akademi University Department of Computer Science Lemmink????nengatan 14 A FIN-20540 Turku FINLAND Phone: +358 2 215 3348 Fax: +358 2 215 4732 Tutorials and Workshops The conference takes place Wednesday to Friday. However, the surrounding days also offer a large variety of Petri net activities. The Introductory Tutorial is offered to participants who have little or no prior experience with Petri nets. The talks give an overview of the area, and they will help new-comers to understand the basic ideas in many of the conference contributions. The Advanced Tutorials and Workshops are offered to those who already have some knowledge of Petri nets. They are divided into several strands covering different subjects. A detailed description of the tutorials and workshops will be available via the conference Web pages. Finally, it will be possible to arrange meetings for different groups, e.g., participants in international Petri net projects. It will also be possible to arrange small educational courses, e.g., with respect to some of the Petri net tools. Submissions for such activities must contain a 2-5 page description. They must be received by one of the PC-chairs no later than January 15, 2006. Tools for Petri Nets As part of the conference, there will be an exhibition of computer tools for Petri nets together with a limited number of tool presentations, i.e., talks about tools. For tool presentations a rotation principle will be enforced. This means that the same tool cannot be presented year after year -- unless it has been significantly enhanced. Submissions for tool presentations must: * Focus on the description of a computer tool for Petri Nets (not an application of the tool or the theory behind the tool). * Be in the Springer LNCS-format: http://www.springer.de/comp/lncs/authors.html. * Have a length that does not exceed 10 pages. * Be in English and in a form that can be immediately included in the proceedings without major revision. * Be sent electronically (as a PostScript or PDF file) using the website http://sttt.cs.uni-dortmund.de/atpn06/servlet/Conference no later than November 15, 2005. Submissions for tool demonstrations must: * Be in English and contain a 3-10 pages description of the tool. * Be received by the tool demonstration chair Jerker Bj????kqvist no later than April 1, 2006. Participants wishing to demonstrate tools are encouraged to bring their own machines, as only a limited number of local machines will be available for this purpose, with limited support for installation. Program Committee J. Billington, Australia D. Buchs, Switzerland N. Busi, Italy G. Ciardo, USA J.M. Colom, Spain P. Darondeau, France S. Donatelli, Italy (co-chair, applications) G. Franceschinis, Italy B. Haverkort, The Netherlands X. He, USA K. van Hee, The Netherlands M. Heiner, Germany J. Hillston, UK K. Hiraishi, Japan P. Jancar, Czech Republic G. Juhas, Germany M. Koutny, UK L.M. Kristensen, Denmark J. Lilius, Finland M. Mukund, India W. Penczek, Poland L. Petrucci, France L. Pomello, Italy L. Recalde, Spain K. Schmidt, Germany P.S. Thiagarajan, Singapore (co-chair, theory) T. Ushio, Japan R. Valk, Germany F. Vernadat, France Steering Committee W. van der Aalst, The Netherlands J. Billington, Australia J. Desel, Germany S. Donatelli, Italy S. Haddad, France K. Jensen, Denmark (chair) H.C.M. Kleijn, The Netherlands M. Koutny, UK S. Kumagai, Japan T. Murata, USA C.A. Petri, Germany (honorary member) L. Pomello, Italy W. Reisig, Germany G. Rozenberg, The Netherlands M. Silva, Spain From arthurvl at cs.uu.nl Fri Oct 28 04:15:58 2005 From: arthurvl at cs.uu.nl (Arthur van Leeuwen) Date: Fri Oct 28 03:55:46 2005 Subject: [Haskell] [Fwd: Bug in Data.IntSet?] In-Reply-To: <4360D68E.90308@ii.uib.no> References: <4360D68E.90308@ii.uib.no> Message-ID: On 27-okt-2005, at 15:30, Ketil Malde wrote: > > Sigh. My system insists on rewriting outgoing mail headers, and > ghc-users refuses non-subscribers to post there. I'm too tired to > fight this at the moment, so I'll send it here in the hope that it > will be picked up by the right adressee. > > BTW: I sent a mail to libraries with the attached patch that fixes this behaviour. Note that the problem lies in split not checking to see if the prefix of the number being split on is present in the tree. The patch also fixes the behaviour on negative numbers, by the way. Oh, and smaller testcases: > Data.IntSet.split 2 $ Data.IntSet.fromList [0,1] > Data.IntSet.split 2 $ Data.IntSet.fromList [4,6,8] > Data.IntSet.split 1 $ Data.IntSet.fromList [0,-1] -------------- next part -------------- A non-text attachment was scrubbed... Name: IntSetFix.patch Type: application/octet-stream Size: 2528 bytes Desc: not available Url : http://www.haskell.org//pipermail/haskell/attachments/20051028/b8997e29/IntSetFix.obj -------------- next part -------------- Doei, Arthur. (Who figured this out together with Bertram Felgenhauer) -- /\ / | arthurvl@cs.uu.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching From jeanphilippe.bernardy at gmail.com Fri Oct 28 04:19:10 2005 From: jeanphilippe.bernardy at gmail.com (Jean-Philippe Bernardy) Date: Fri Oct 28 03:59:03 2005 Subject: [Haskell] [Fwd: Bug in Data.IntSet?] In-Reply-To: References: <4360D68E.90308@ii.uib.no> Message-ID: <953e0d250510280119w436ff0e4g5c54d3f7cde67da2@mail.gmail.com> Thanks, I'll apply ASAP. Cheers, JP. On 10/28/05, Arthur van Leeuwen wrote: > > On 27-okt-2005, at 15:30, Ketil Malde wrote: > > > > > > Sigh. My system insists on rewriting outgoing mail headers, and > > ghc-users refuses non-subscribers to post there. I'm too tired to > > fight this at the moment, so I'll send it here in the hope that it > > will be picked up by the right adressee. > > > > > > BTW: I sent a mail to libraries with the attached patch that fixes > this behaviour. > Note that the problem lies in split not checking to see if the prefix > of the number > being split on is present in the tree. The patch also fixes the > behaviour > on negative numbers, by the way. > > Oh, and smaller testcases: > > > Data.IntSet.split 2 $ Data.IntSet.fromList [0,1] > > Data.IntSet.split 2 $ Data.IntSet.fromList [4,6,8] > > Data.IntSet.split 1 $ Data.IntSet.fromList [0,-1] > > > > > > Doei, Arthur. (Who figured this out together with Bertram Felgenhauer) > > -- /\ / | arthurvl@cs.uu.nl | Work like you don't > need the money > /__\ / | A friend is someone with whom | Love like you have never > been hurt > / \/__ | you can dare to be yourself | Dance like there's nobody > watching > > > > > > > _______________________________________________ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > > > > From simonpj at microsoft.com Fri Oct 28 06:40:29 2005 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Oct 28 06:20:23 2005 Subject: [Haskell] How to zip folds: A library of fold transformers Message-ID: <036EAC76E7F5EC4996A3B3C3657D4116038D0FD0@EUR-MSG-21.europe.corp.microsoft.com> Oleg: I'm sure you're aware of the close connection between your FR stuff (nice) and the foldr/build list-fusion work? (So-called "short-cut deforestation".) To make short-cut deforestation work, one has to write map, filter etc in precisely the style you give. I have not grokked your zip idea, though it looks cunning. I wonder if it could be formulated in such a way that we could do foldr/build fusion down both branches of a zip? John Launchbury et al had a paper about hyper-functions which tackled the zip problem too. http://citeseer.ist.psu.edu/krstic01hyperfunctions.html. Also Josef Svengingsson (ICFP'02). I don't know how these relate to your solution. Simon | -----Original Message----- | From: haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of | oleg@pobox.com | Sent: 12 October 2005 01:25 | To: haskell@haskell.org | Subject: [Haskell] How to zip folds: A library of fold transformers | | | 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)] | | _______________________________________________ | Haskell mailing list | Haskell@haskell.org | http://www.haskell.org/mailman/listinfo/haskell From wolfgang at jeltsch.net Fri Oct 28 07:25:26 2005 From: wolfgang at jeltsch.net (Wolfgang Jeltsch) Date: Fri Oct 28 07:05:22 2005 Subject: [Haskell] PROPOSAL: class aliases In-Reply-To: <20051027111832.GA8294@soi.city.ac.uk> References: <036EAC76E7F5EC4996A3B3C3657D411603671FED@EUR-MSG-21.europe.corp.microsoft.com> <20051013125136.GO21098@momenergy.repetae.net> <20051027111832.GA8294@soi.city.ac.uk> Message-ID: <200510281325.27014.wolfgang@jeltsch.net> Am Donnerstag, 27. Oktober 2005 13:18 schrieb Ross Paterson: > [...] > extend the class syntax with an annotation on the assumptions (! for now), > to allow > > class (Show a, !Additive a, !Negative a, !Multiplicative a) => > Num a where > fromInteger :: Integer -> a > > one = fromInteger 1 > zero = fromInteger 0 I don't think that such a syntax is a good idea, since class contexts are used elsewhere where such a syntax doesn't make sense. > [...] Best wishes, Wolfgang From mail at stefanwehr.de Fri Oct 28 21:49:16 2005 From: mail at stefanwehr.de (Stefan Wehr) Date: Fri Oct 28 21:31:33 2005 Subject: [Haskell] Problem with superclass entailment in "A Static Semantics for Haskell" Message-ID: <20051029014916.GC26363@shodan.cse.unsw.edu.au> Hi all, I believe there is a problem in the rule for instance declarations in "A Static Semantics For Haskell" [1] because the premise which ensures that instances for all superclasses are defined seems to hold trivially. [2] seems to have the same problem. I now describe the problem by showing how an incorrect program is accepted by the rules given in [1]. I omit many, many details that are irrelevant to this problem. Consider the following program: class C a class C a => D a instance D Int The instance environment IE for this program is built recursively by the rule for modules bodies (Fig. 15) and looks like this: IE = {forall a. D a => C a, D Int} We would expect that the rule for instance declarations (Fig. 26) rejects the program because there is no instance declaration for C Int. However, the rule uses the *whole* instance environment IE to check whether there is an instance declaration for C Int. But this holds trivially, because we have D Int in IE and the implication (forall a. D a => C a) lets us the conclude that C Int holds!! In other words: The rule uses the implication (forall a. D a => C a) to make sure that the very same implication is valid for a = Int. A possible solution might be to remove the constraint D Int before checking whether C Int holds. However, I am not sure whether the resulting rule is complete. An alternative solution would be to use a weaker entailment judgment. Any thoughts? Am I just missing some implicit condition on the instance environment? References: [1] @Article{Faxen02, title = "A static semantics for {Haskell}", author = "Karl-Filip Fax{\'e}n", journal = "Journal of Functional Programming", year = "2002", number = "4\&5", volume = "12", pages = "295--357", } [2] @Article{Hall1996, author = "Cordelia V. Hall and Kevin Hammond and Simon L. {Peyton Jones} and Philip L. Wadler", title = "Type classes in {Haskell}", journal = "ACM Transactions on Programming Languages and Systems", volume = "18", number = "2", pages = "109--138", year = "1996", } Cheers, Stefan Wehr -- Stefan Wehr Web: http://www.stefanwehr.de PGP: Key is available from pgp.mit.edu, ID 0B9F5CE4 From oleg at pobox.com Sat Oct 29 04:51:56 2005 From: oleg at pobox.com (oleg@pobox.com) Date: Sat Oct 29 04:33:49 2005 Subject: [Haskell] How to zip folds: A library of fold transformers In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D4116038D0FD0@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <20051029085156.C2083ACB2@Adric.metnet.navy.mil> Hello! > I'm sure you're aware of the close connection between your FR > stuff (nice) and the foldr/build list-fusion work? I am now. Indeed, the 'FR' representation of lists is what one passes to 'build'. Incidentally, the higher-rank type of FR is a _requirement_ (otherwise, things won't type) rather than just a precaution to prevent 'build' from using list constructors [] and (:) internally. > Also Josef Svengingsson (ICFP'02). I don't know how these relate to your > solution. His paper is actually quite related to our ICFP'05 paper: the function `destroy' (which he re-discovered after Gill) is somewhat related to `msplit' in the LogicT paper, and the function `reflect' of LogicT paper is related to unfoldr. There are many differences however. The function `msplit' has nothing to do with Haskell lists and never uses any lists constructors, even internally. The functions msplit and reflect operate over any backtracking computation over any base monad (which may be strict, btw). The presence of the base monad makes things trickier as we now must assure that we do not repeat effects. Therefore, the equivalent of the destroy/infoldr rule of Josef Svengingsson destroy . unfoldr === id is (in ``small-step semantics'') rr (lift m >> mzero) === lift m >> mzero rr (lift m `mplus` tma) === lift m `mplus` (rr tma) where rr tm = msplit tm >>= reflect One can read 'mzero' and 'mplus' as generalized list constructors [] and (:), and read (>>=) as a flipped application. The more complex laws assure that effects are not duplicated. It is fair to say that whereas foldr/build and destroy/infoldr fusion techniques work for Haskell lists, msplit/reflect in the LogicT paper is a fusion law for a general backtracking computation over arbitrary, perhaps even strict, base monad. That computation may look nothing like list (and in fact, the LogicT paper gives an example with delimited continuations, with `abort' playing the role of nil and `shift' the role of cons). Since the previous message on the Haskell list, a better implementation of szipWith has emerged -- in the process of answering a good question posed by Chung-chieh Shan. The new solution is actually quite simple and does not use msplit/destroy at all. If we recall that we already have stake and sdrop (so that we can `split' an FR stream into the head element (stake 1) and the rest (sdrop 1)), the code for szipWith becomes trivial. One may wonder why hadn't that occurred earlier. > szipWith :: (a->b->c) -> FR a -> FR b -> FR c > szipWith t l1 l2 = > FR(\f z -> > unFR l1 (\e1 r r2 -> > unFR r2 (\e2 _ -> f (t e1 e2) (r (sdrop 1 r2))) z) (const z) l2) > szip :: FR a -> FR b -> FR (a,b) > szip = szipWith (,) Indeed, the function sdrop already did the trick of splitting the stream. And the function sdrop is quite trivial: > 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) It means that the other, more complex expressions for szipWith, some of which include `msplit'-alike in disguise, can be mechanically derived from the above via the sequence of beta-reductions. The code for szipWith is not recursive and needs no recursive types. Let us look at szipWith closer: at first blush it looks like a nested fold (``nested loop''). But then we see that the nested expression operates on the progressively shorter list l2. That is, the 'tail' of l2 becomes the 'seed' of the outer fold represented by l1. The stream FR has the type > newtype FR a = FR (forall ans. (a -> ans -> ans) -> ans -> ans) The szipWith code demonstrates that `unFR l1' instantiates 'ans' to the type of 'l2' -- that is, to the type FR itself. We definitely have impredicativity -- the quantified type variable in FR may be instantiated to the type that is being defined by FR. Thus the higher-rank type of FR is not a nicety and is not merely a safety property -- it is a necessity. I'm afraid constructivists would be unhappy... > John Launchbury et al had a paper about hyper-functions which tackled > the zip problem too. > http://citeseer.ist.psu.edu/krstic01hyperfunctions.html. But existence of hyper-functions implies the existence of the fix-point operator. I specifically wanted to avoid Y in any guise! There are several reasons: - In the pure case, there will be nothing to prove. We can always convert an FR-list to an ordinary Haskell (i.e., co-inductive) list, and back. This is an iso-morphism, so the library of FR lists is a trivial consequence of the Haskell list library. If we banish Y however, we can no longer convert Haskell lists to FR lists, and so iso-morphism is broken. BTW, the iso-morphism between FR lists and Haskell lists no longer holds if we do all operations in some monad 'm' and that monad is strict. - It would be interesting to see, constructively, how to build the full-fledged (FR)-list library and avoid general recursion. Let the FR-list be the only driver of iterations. - Related to the above: how to build a list library without Y, without recursive types. We need only higher-ranked types. The zip function is particularly interesting because it relates to 'parallel loops'. It becomes especially interesting in the case of general backtracking computations, or backtracking computations in direct style, with delimited continuations modeling `lists'. From benjamin.franksen at bessy.de Sun Oct 30 16:14:10 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Sun Oct 30 14:54:37 2005 Subject: [Haskell] really undecidable instances? In-Reply-To: <036EAC76E7F5EC4996A3B3C3657D41160370EB4F@EUR-MSG-21.europe.corp.microsoft.com> References: <036EAC76E7F5EC4996A3B3C3657D41160370EB4F@EUR-MSG-21.europe.corp.microsoft.com> Message-ID: <200510302214.10665.benjamin.franksen@bessy.de> On Monday 17 October 2005 15:57, Simon Peyton-Jones wrote: > | Wolfgang Jeltsch: > | what ist the problem with instance declarations like the following: > | > | instance C Int a => D Char [a] > | > | Why are such declarations only allowed with > | -fallow-undecidable-instances in > | GHC? How can they result in undecidability? > > This one can't. But it's hard to formulate a general rule. > -fallow-undecidable-instances simply says that you, the programmer, > take responsibility for termination. Without the flag, GHC uses a > simple but sometimes over-conservative rule Hi, I've now been bitten by the same 'over-conservatism' of H98. In my case it's Non-type variables in constraint: Pretty (tree a) (Use -fallow-undecidable-instances to permit this) In the context: (Pretty a, Pretty (tree a)) This is the data type declaration: > data Node23 tree a > = N2 (tree a) a (tree a) > | N3 (tree a) a (tree a) a (tree a) and this is the instance, where the error is reported: > instance (Pretty a, Pretty (tree a)) => Pretty (Node23 tree a) where > ... The class Pretty is from Daan Leijen's pprint library. I think that the 'non-type variable' refered to above is the application (tree a) in the constraint (Pretty (tree a)), which is arguably "almost" a type variable. In this case I think it is even more obvious that it can't cause a loop, since the LHS clearly has a type constructor removed, right? I mention this mainly because my module is otherwise completely H98 and I thought it would be nice to keep it that way. I need the Pretty instance for debugging only, so it's not really a show-stopper. Still I wonder if somebody knows a work-around that doesn't need a language extension (some newtype trick, maybe?). Ben From zednenem at psualum.com Sun Oct 30 15:59:48 2005 From: zednenem at psualum.com (David Menendez) Date: Sun Oct 30 15:39:52 2005 Subject: [Haskell] really undecidable instances? In-Reply-To: <200510302214.10665.benjamin.franksen@bessy.de> Message-ID: Benjamin Franksen writes: > This is the data type declaration: > > > data Node23 tree a > > = N2 (tree a) a (tree a) > > | N3 (tree a) a (tree a) a (tree a) > > and this is the instance, where the error is reported: > > > instance (Pretty a, Pretty (tree a)) => Pretty (Node23 tree a) where > > ... > > The class Pretty is from Daan Leijen's pprint library. > > I think that the 'non-type variable' refered to above is the > application (tree a) in the constraint (Pretty (tree a)), which is > arguably "almost" a type variable. In this case I think it is even > more obvious that it can't cause a loop, since the LHS clearly has a > type constructor removed, right? > > I mention this mainly because my module is otherwise completely H98 > and I thought it would be nice to keep it that way. I need the Pretty > instance for debugging only, so it's not really a show-stopper. Still > I wonder if somebody knows a work-around that doesn't need a language > extension (some newtype trick, maybe?). I believe the "correct" way to do this is with a Pretty-promoting constructor class. class Pretty'1 f where pretty'1 :: Pretty a => f a -> Doc prettyList'1 :: Pretty a => [f a] -> Doc instance (Pretty a, Pretty'1 tree) => Pretty (Node23 tree a) where ... Your typical Pretty'1 instance will look like this: instance Pretty'1 T where pretty'1 = pretty prettyList'1 = prettyList -- David Menendez | "In this house, we obey the laws | of thermodynamics!" From benjamin.franksen at bessy.de Sun Oct 30 17:23:56 2005 From: benjamin.franksen at bessy.de (Benjamin Franksen) Date: Sun Oct 30 16:04:12 2005 Subject: [Haskell] really undecidable instances? In-Reply-To: References: Message-ID: <200510302323.56373.benjamin.franksen@bessy.de> On Sunday 30 October 2005 21:59, David Menendez wrote: > Benjamin Franksen writes: > > This is the data type declaration: > > > data Node23 tree a > > > = N2 (tree a) a (tree a) > > > > > > | N3 (tree a) a (tree a) a (tree a) > > > > and this is the instance, where the error is reported: > > > instance (Pretty a, Pretty (tree a)) => Pretty (Node23 tree a) > > > where ... > > > > The class Pretty is from Daan Leijen's pprint library. > > > > I think that the 'non-type variable' refered to above is the > > application (tree a) in the constraint (Pretty (tree a)), which is > > arguably "almost" a type variable. In this case I think it is even > > more obvious that it can't cause a loop, since the LHS clearly has > > a type constructor removed, right? > > > > I mention this mainly because my module is otherwise completely H98 > > and I thought it would be nice to keep it that way. I need the > > Pretty instance for debugging only, so it's not really a > > show-stopper. Still I wonder if somebody knows a work-around that > > doesn't need a language extension (some newtype trick, maybe?). > > I believe the "correct" way to do this is with a Pretty-promoting > constructor class. > > > class Pretty'1 f where > pretty'1 :: Pretty a => f a -> Doc > prettyList'1 :: Pretty a => [f a] -> Doc > > instance (Pretty a, Pretty'1 tree) => Pretty (Node23 tree a) > where ... > > Your typical Pretty'1 instance will look like this: > > instance Pretty'1 T where > pretty'1 = pretty > prettyList'1 = prettyList Works like a charm. Thanks a lot! Ben From gregory.woodhouse at sbcglobal.net Mon Oct 31 01:14:29 2005 From: gregory.woodhouse at sbcglobal.net (Gregory Woodhouse) Date: Mon Oct 31 00:54:12 2005 Subject: [Haskell] Monads vs. continuations Message-ID: Newbie alert: I have some superficial familiarity with continuations as they occur in traditional denotational semantics, but certainly not a deep understanding. I also have a special interest in distributed and/or concurrent processing, so it only seemed natural to me that the monad concept was one I'd want to confront head on. Now, I warn you: I am quite new to Haskell (though I have some prior exposure to Scheme and a background in mathematics). Now, I've just started reading through Thompson's text and came across this example: goUntilEmpty :: IO () goUntilEmpty = do line <- getLine if (line == []) then return () else (do putStrLn line goUntilEmpty) Okay, this seems sensible enough. Loosely speaking, I see this code as getting a line, checking to see if it's empty. If it is, it just quits (returning the "empty" value). Otherwise, it prints line, and invokes itself through a *new* do statement. That seems awfully like using a continuation to track the input stream as part of the environment. But it seems obvious to me that here is something I'm not understanding here. I think of the do as providing an appropriate continuation (one in which the line just read is gone) to pass to the next call. Okay, maybe I'm taking things a bit too literally here, but I seem to recall that a monad is an algebraic object with right and left identity and an associative composition. I understand the monad here takes a value (()) and returns an object IO (), and do becomes a functor of sorts, taking ordinary functions and mapping them to new functions having their codomain in a new category (an instance of a monad?) This is where it seems to me that I must be getting the terminology wrong. Can someone help me out here? === Gregory Woodhouse gregory.woodhouse@sbcglobal.net "The most incomprehensible thing about the world is that it is at all comprehensible." --Albert Einstein (1879-1955) From rene_de_visser at hotmail.com Mon Oct 31 03:13:30 2005 From: rene_de_visser at hotmail.com (Rene de Visser) Date: Mon Oct 31 02:53:15 2005 Subject: [Haskell] Writing large n-dim un-boxed array of Int32 quickly? Message-ID: Hello, I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And also read it back later). What I tried so far is import NewBinary.Binary ... mapM_ (put bin) $ elems array ... but this was exceedlying slow. The array contains about 10 000 000 entries. Any suggestions? Rene. From ketil at ii.uib.no Mon Oct 31 04:06:51 2005 From: ketil at ii.uib.no (Ketil Malde) Date: Mon Oct 31 03:46:35 2005 Subject: [Haskell] Writing large n-dim un-boxed array of Int32 quickly? In-Reply-To: References: Message-ID: <4365DEAB.1070205@ii.uib.no> Rene de Visser wrote: > I want to write a multi-dimensional unboxed arrary of Int32 to a file. > (And also read it back later). hGetArray/hPutArray? -k From events-admin at fmeurope.org Fri Oct 28 12:00:57 2005 From: events-admin at fmeurope.org (events-admin@fmeurope.org) Date: Mon Oct 31 03:48:25 2005 Subject: [Haskell] FM'06 Announcement and Call for Submissions Message-ID: <33740.213.84.47.100.1130515257.squirrel@www.west.nl> FM'06: 14TH INTERNATIONAL SYMPOSIUM ON FORMAL METHODS 21 - 27 August 2006 McMaster University, Hamilton, Ontario, Canada http://fm06.mcmaster.ca/ ANNOUNCEMENT AND CALL FOR SUBMISSIONS FM'06 is the fourteenth in a series of symposia organized by Formal Methods Europe, http://www.fmeurope.org, an independent association whose aim is to stimulate the use of, and research on, formal methods for software development. The symposia have been notably successful in bringing together innovators and practitioners in precise mathematical methods for software development, industrial users as well as researchers. Submissions are welcomed in the form of original papers on research and industrial experience, proposals for workshops and tutorials, entries for the exhibition of software tools and projects, and reports on ongoing doctoral work. FM'06 welcomes all aspects of formal methods research, both theoretical and practical. We are particularly interested in the experience of applying formal methods in practice. The broad topics of interest of this conference are: * Tools for formal methods: tool support and software engineering, environments for formal methods. * Theoretical foundations: specification and modelling, refining, static analysis, model-checking, verification, calculation, reusable domain theories. * Formal methods in practice: experience with introducing formal methods in industry, case studies. * Role of formal methods: formal methods in hardware and system design, method integration, development process. TECHNICAL PAPERS Full papers should be submitted via the web site. Papers will be evaluated by the Program Committee according to their originality, significance, soundness, quality of presentation and relevance with respect to the main issues of the symposium. Accepted papers will be published in the Symposium Proceedings, to appear in Springer's Lecture Notes in Computer Science series, http://www.springeronline.com/lncs . Submitted papers should have not been submitted elsewhere for publication, should be in Springer's format, (see Springer's web site), and should not exceed 16 pages including appendices. A prize for the best technical paper will be awarded at the symposium. INDUSTRIAL USAGE REPORTS One day will be dedicated to sharing the experience -- both positive and negative -- with using formal methods in industrial environments. The Industry Day is organized by ForTIA, the Formal Techniques Industry Association, http://www.fortia.org . This year's Industry Day investigates the use of formal methods in security and trust. Invited papers on organizational and technical issues will be presented. Inquiries should be directed to the Industry Day Chairs; see the web site for details. WORKSHOPS We welcome proposals for one-day or one-and-a-half-day workshops related to FM'06. In particular, but not exclusively, we encourage proposals for workshops on various application domains. Proposals should be directed to the Workshop Chair. TUTORIALS We are soliciting proposals for full-day or half-day tutorials. The tutorial contents can be selected from a wide range of topics that reflect the conference themes and provide clear utility to practitioners. Each proposal will be evaluated on importance, relevance, timeliness, audience appeal and past experience and qualification of the instructors. Proposals should be directed to the Tutorial Chair. POSTER AND TOOL EXHIBITION An exhibition of both research projects and commercial tools will accompany the technical symposium, with the opportunity of holding scheduled presentations of commercial tools. Proposals should be directed to the Poster and Tools Exhibition Chair. DOCTORAL SYMPOSIUM For the first time, FM'06 will feature a doctoral symposium. Students are invited to submit work in progress and to defend it in front of "friendly examiners". Participation for students who are accepted will be subsidized. Submissions should be directed to the Doctoral Symposium Chair. SUBMISSION DATES Technical Papers, Workshops, Tutorials: Friday, February 24, 2006 Posters and Tools, Doctoral Symposium: Friday, May 26, 2006 NOTIFICATION DATES Technical Papers: Friday, April 28, 2006 Workshops, Tutorials: Friday, March 10, 2006 Posters and Tools, Doctoral Symposium: Friday, June 9, 2006 ORGANIZATION General Chair: Emil Sekerinski (McMaster) Program Chairs: Jayadev Misra (U. Texas, Austin), Tobias Nipkow (TU Munich) Workshop Chair: Tom Maibaum (McMaster) Tutorial Chair: Jin Song Dong (NUS) Tools and Poster Exhibition Chair: Marsha Chechik (U. Toronto) Industry Day Chairs: Volkmar Lotz (SAP France), Asuman Suenbuel (SAP US) Doctoral Symposium Chair: Augusto Sampaio (U. Pernambuco) Sponsorship Chair: Juergen Dingel (Queens U.) PROGRAM COMMITTEE Jean-Raymond Abrial (ETH Zurich) Alex Aiken (Stanford U.) Keijiro Araki (Kyushu U.) Ralph Back (Abo Akademi) Gilles Barthe (INRIA) David Basin (ETH Zurich) Ed Brinksma (U. Twente) Michael Butler (U. Southampton) Rance Cleaveland (U. Stony Brook) Jorge Cuellar (Siemens) Werner Damm (U. Oldenburg) Frank de Boer (U. Utrecht) Javier Esparza (U. Stuttgart) Jose Fiadeiro (U. Leicester) Susanne Graf (VERIMAG) Ian Hayes (U. Queensland) Gerard Holzmann (JPL) Cliff Jones (U. Newcastle) Gary T. Leavens (Iowa State U.) Rustan Leino (Microsoft) Xavier Leroy (INRIA) Dominique Mery (LORIA) Carroll Morgan (UNSW) David Naumann (Stevens) E.-R. Olderog (U. Oldenburg) Paritosh Pandya (TIFR) Sriram Rajamani (Microsoft) John Rushby (SRI) Steve Schneider (U. Surrey) Vitaly Shmatikov (U. Texas, Austin) Bernhard Steffen (U. Dortmund) P.S. Thiagarajan (NUS) Axel van Lamsweerde (U. Louvain) Martin Wirsing (LMU Munich) Pierre Wolper (U. Liege) LOCAL ORGANIZATION Publicity: Wolfram Kahl, Alan Wassyng, Jeff Zucker Tools, Posters, Book Exhibition: Spencer Smith Social Events: Ridha Khedri Local Arrangements:: William Farmer, Mark Lawford Events Co-ordinator: Ryszard Janicki _______________________________________________ events mailing list events@fmeurope.org http://www.fmeurope.org/mailman/listinfo/events From bulatz at HotPOP.com Mon Oct 31 04:10:19 2005 From: bulatz at HotPOP.com (Bulat Ziganshin) Date: Mon Oct 31 03:50:44 2005 Subject: [Haskell] Writing large n-dim un-boxed array of Int32 quickly? In-Reply-To: References: Message-ID: <185654547189.20051031121019@HotPOP.com> Hello Rene, Monday, October 31, 2005, 11:13:30 AM, you wrote: RdV> Hello, RdV> I want to write a multi-dimensional unboxed arrary of Int32 to a file. (And RdV> also read it back later). how about fileWriteBuf/fileReadBuf? -- Best regards, Bulat mailto:bulatz@HotPOP.com From rene_de_visser at hotmail.com Mon Oct 31 04:21:01 2005 From: rene_de_visser at hotmail.com (Rene de Visser) Date: Mon Oct 31 04:00:46 2005 Subject: [Haskell] Writing large n-dim un-boxed array of Int32 quickly? In-Reply-To: <4365DEAB.1070205@ii.uib.no> Message-ID: >From: Ketil Malde >Rene de Visser wrote: > >>I want to write a multi-dimensional unboxed arrary of Int32 to a file. >>(And also read it back later). > >hGetArray/hPutArray? > To do this I need to cast my 5 dimensional array to a 1 dimensional array? Does this work? i.e. how do I know that GHC uses a flat array representation for multidemsional arrays (rather than a nested model using pointers). Rene. From rene_de_visser at hotmail.com Mon Oct 31 04:24:10 2005 From: rene_de_visser at hotmail.com (Rene de Visser) Date: Mon Oct 31 04:03:57 2005 Subject: [Haskell] Writing large n-dim un-boxed array of Int32 quickly? In-Reply-To: <185654547189.20051031121019@HotPOP.com> Message-ID: >From: Bulat Ziganshin >Hello Rene, > >Monday, October 31, 2005, 11:13:30 AM, you wrote: > >RdV> I want to write a multi-dimensional unboxed arrary of Int32 to a file. >(And >RdV> also read it back later). > >how about fileWriteBuf/fileReadBuf? Hello Bulat, How does this work? (is this from NewBinary, I don't have the sources with me). How do I convert my array to a buffer? Rene. From cgibbard at gmail.com Mon Oct 31 06:02:37 2005 From: cgibbard at gmail.com (Cale Gibbard) Date: Mon Oct 31 05:42:20 2005 Subject: [Haskell] Monads vs. continuations In-Reply-To: References: Message-ID: <89ca3d1f0510310302q22b9fa4fp@mail.gmail.com> On 31/10/05, Gregory Woodhouse wrote: > Newbie alert: > > I have some superficial familiarity with continuations as they occur > in traditional denotational semantics, but certainly not a deep > understanding. I also have a special interest in distributed and/or > concurrent processing, so it only seemed natural to me that the monad > concept was one I'd want to confront head on. Now, I warn you: I am > quite new to Haskell (though I have some prior exposure to Scheme and > a background in mathematics). Now, I've just started reading through > Thompson's text and came across this example: > > goUntilEmpty :: IO () > goUntilEmpty > = do line <- getLine > if (line == []) > then return () > else (do putStrLn line > goUntilEmpty) > > Okay, this seems sensible enough. Loosely speaking, I see this code > as getting a line, checking to see if it's empty. If it is, it just > quits (returning the "empty" value). Otherwise, it prints line, and > invokes itself through a *new* do statement. That seems awfully like > using a continuation to track the input stream as part of the > environment. But it seems obvious to me that here is something I'm > not understanding here. I think of the do as providing an appropriate > continuation (one in which the line just read is gone) to pass to the > next call. > > Okay, maybe I'm taking things a bit too literally here, but I seem to > recall that a monad is an algebraic object with right and left > identity and an associative composition. I understand the monad here > takes a value (()) and returns an object IO (), and do becomes a > functor of sorts, taking ordinary functions and mapping them to new > functions having their codomain in a new category (an instance of a > monad?) This is where it seems to me that I must be getting the > terminology wrong. Can someone help me out here? Perhaps you're referring to a monoid. Since you seem to have some familiarity with category theory, check out http://en.wikipedia.org/wiki/Monad_%28category_theory%29 for a formal definition of monads and some background. Translating between notation, ? = join and ? = return in Haskell. The application of the functor T to functions is called fmap, or liftM, which should always be equivalent. The functor behind a monad is always an endofunctor, that is, from the category to itself. In this case, you'll be interested in the category of Haskell types and Haskell-definable functions between them. For a much gentler description and one way in which monads relate to programming, check out http://www.haskell.org/hawiki/MonadsAsContainers which is an article that I wrote. For a different perspective on the programming aspects than presented by my article (both are important in practice) check out http://www.nomaware.com/monads/html/ Do notation is a shorthand for a bunch of algebraic operations which make the code look like imperative code. Desugaring goUntilEmpty results in something along the lines of: goUntilEmpty :: IO () goUntilEmpty = getLine >>= \line -> if line == [] -- better written as "null line" then return () else putStrLn line >>= \x -> goUntilEmpty where x >>= f = join (fmap f x), to write it in terms of the operations defined on wikipedia. Hope these links are useful to you :) - Cale From Benjamin.Rudiak-Gould at cl.cam.ac.uk Mon Oct 31 12:37:26 2005 From: Benjamin.Rudiak-Gould at cl.cam.ac.uk (Ben Rudiak-Gould) Date: Mon Oct 31 12:17:12 2005 Subject: [Haskell] Monads vs. continuations In-Reply-To: References: Message-ID: <43665656.90007@cl.cam.ac.uk> I don't know if this helps, but there's a straightforward way to understand the IO monad in terms of continuation passing. You can think of a value of type IO a as being a CPS expression with a hole in it; the hole is to be filled with a continuation which expects a value of type a. The only way to fill the hole is by using >>=, whose second argument is a continuation with another (nested) hole in it. So effectively with >>= you build a CPS expression from the outside in. The final continuation, which takes () and aborts the program, is ultimately filled in by the runtime system. This viewpoint doesn't work for other monads, since they always provide some sort of destructuring operations on monadic values, e.g. runState or the standard list deconstructors. But it works fine for IO provided you ignore the existence of unsafePerformIO and friends. -- Ben From gregory.woodhouse at sbcglobal.net Mon Oct 31 14:05:26 2005 From: gregory.woodhouse at sbcglobal.net (Gregory Woodhouse) Date: Mon Oct 31 13:45:10 2005 Subject: [Haskell] Monads vs. continuations In-Reply-To: <89ca3d1f0510310302q22b9fa4fp@mail.gmail.com> References: <89ca3d1f0510310302q22b9fa4fp@mail.gmail.com> Message-ID: <4870D849-E4E5-42ED-9CF9-E0B479213A05@sbcglobal.net> On Oct 31, 2005, at 3:02 AM, Cale Gibbard wrote: > Perhaps you're referring to a monoid. Since you seem to have some > familiarity with category theory, check out > http://en.wikipedia.org/wiki/Monad_%28category_theory%29 for a formal > definition of monads and some background. Translating between > notation, ? = join and ? = return in Haskell. The application of the > functor T to functions is called fmap, or liftM, which should always > be equivalent. > > The functor behind a monad is always an endofunctor, that is, from the > category to itself. In this case, you'll be interested in the category > of Haskell types and Haskell-definable functions between them. This was actually quite helpful. If someone had told me that a monad was a functor in the first place, this would all have been much less mysterious. (BTW, I have indeed encountered adjoint functors, Hom and Tensor, in the context of algebraic topology, so the article did leave me with a bit more of a sense of having my feet on the ground.) > > For a much gentler description and one way in which monads relate to > programming, check out > http://www.haskell.org/hawiki/MonadsAsContainers which is an article > that I wrote. > This is an excellent article! I found it extremely useful and lucid. To be sure, it's going to take a bit more time to let all these ideas sink in, but I liked the approach of focusing on fmap and join (>>= always seemed mysterious). Believe it or not, though I've read that lists are monads, this is perhaps the first time I've seen it spelled out just how. === Gregory Woodhouse gregory.woodhouse@sbcglobal.net "It is foolish to answer a question that you do not understand." --G. Polya ("How to Solve It") From gregory.woodhouse at sbcglobal.net Mon Oct 31 14:10:03 2005 From: gregory.woodhouse at sbcglobal.net (Gregory Woodhouse) Date: Mon Oct 31 13:49:46 2005 Subject: [Haskell] Monads vs. continuations In-Reply-To: <43665656.90007@cl.cam.ac.uk> References: <43665656.90007@cl.cam.ac.uk> Message-ID: On Oct 31, 2005, at 9:37 AM, Ben Rudiak-Gould wrote: > I don't know if this helps, but there's a straightforward way to > understand the IO monad in terms of continuation passing. > > You can think of a value of type IO a as being a CPS expression > with a hole in it; the hole is to be filled with a continuation > which expects a value of type a. The only way to fill the hole is > by using >>=, whose second argument is a continuation with another > (nested) hole in it. So effectively with >>= you build a CPS > expression from the outside in. The final continuation, which takes > () and aborts the program, is ultimately filled in by the runtime > system. > > This viewpoint doesn't work for other monads, since they always > provide some sort of destructuring operations on monadic values, > e.g. runState or the standard list deconstructors. But it works > fine for IO provided you ignore the existence of unsafePerformIO > and friends. > > -- Ben > No, that's definitely helpful. The analogy in the case of IO was obvious, but I had a sense that it was getting in the way of understanding what a monad is (i.e., by leading me to focus on the wrong issues). === Gregory Woodhouse gregory.woodhouse@sbcglobal.net "One must act on what has not yet happened." --Lao Tzu From ccshan at post.harvard.edu Mon Oct 31 13:30:14 2005 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Tue Nov 1 10:06:47 2005 Subject: [Haskell] Re: Writing large n-dim un-boxed array of Int32 quickly? References: <4365DEAB.1070205@ii.uib.no> Message-ID: Rene de Visser wrote in article in gmane.comp.lang.haskell.general: > To do this I need to cast my 5 dimensional array to a 1 dimensional > array? Does this work? i.e. how do I know that GHC uses a flat array > representation for multidemsional arrays (rather than a nested model > using pointers). You know that the array type you are using uses a flat representation because -it- doesn't know what index type you are using. IOUArray must be polymorphic over the index type (the first argument to the type constructor IOUArray), so it can't do anything with the indices that the Ix type class doesn't tell it how to do. The Ix type class doesn't tell IOUArray how many dimensions you have. But you may also want to look into StorableArray. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2005-11-06 Against Exploiting the Environment in War http://tinyurl.com/adhg9 2005-11-20 Universal Children's Day http://www.un.org/depts/dhl/children_day/ 2005-11-25 Elimination of Violence Against Women http://tinyurl.com/drd57 2005-11-25 Buy Nothing Day http://www.buynothingday.co.uk/ From ccshan at post.harvard.edu Mon Oct 31 13:23:42 2005 From: ccshan at post.harvard.edu (Chung-chieh Shan) Date: Tue Nov 1 10:12:22 2005 Subject: [Haskell] Re: Monads vs. continuations References: Message-ID: Gregory Woodhouse wrote in article in gmane.comp.lang.haskell.general: > Okay, this seems sensible enough. Loosely speaking, I see this code > as getting a line, checking to see if it's empty. If it is, it just > quits (returning the "empty" value). Otherwise, it prints line, and > invokes itself through a *new* do statement. That seems awfully like > using a continuation to track the input stream as part of the > environment. But it seems obvious to me that here is something I'm > not understanding here. I think of the do as providing an appropriate > continuation (one in which the line just read is gone) to pass to the > next call. Given your understanding of continuations, it may be more appropriate for you to think in terms of not "do" but the underlying combinations of "return" and ">>=" that "do" is syntactic sugar for. It may also help to consider monads other than IO, for example the input and output monads described in Section 7.3 of Philip Wadler's article "Comprehending Monads". I suspect that your understanding described in the paragraph above is essentially correct. You can also find more information on the relation between continuations and monads in: - Section 7.4 of "Combinations Monads", - Andrzej Filinski's articles "Representing Monads" and "Representing Layered Monads", and his dissertation "Controlling Effects", - Philip Wadler's article "Monads and Composable Continuations", - Section 3.2 of Philip Wadler's article "How to Declare an Imperative". -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig 2005-11-06 Against Exploiting the Environment in War http://tinyurl.com/adhg9 2005-11-20 Universal Children's Day http://www.un.org/depts/dhl/children_day/ 2005-11-25 Elimination of Violence Against Women http://tinyurl.com/drd57 2005-11-25 Buy Nothing Day http://www.buynothingday.co.uk/