RE: Why doesn't GHC do the following optimisation?
It's a while since I paid serious attention to making sure that GHC's transformations are all working right. Things are usually more complicated than one might hope. In this case, * foldl is defined in the prelude using explicit recursion, as it happens * you've defined foldl' using foldr, and that has the potential to do list fusion with the [1..n] * but you've exported sum2, so the inlining doesn't happen. If you keep sum2 private module Main( main ) ... you'll see quite different code * there's an awkwardness with eta-expanding foldl, which I have never fully dealt with -- needs a kind of analysis. It's described in 3.2.3 of Gill's thesis (see also 4.4). http://www.cse.ogi.edu/~andy/ I wish it were all more predictable! Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of | andrew cooke | Sent: 12 November 2003 17:40 | To: [EMAIL PROTECTED] | Subject: Why doesn't GHC do the following optimisation? | | | Hi, | | This question is purely out of curiousity - I'm no expert on this. I | wrote the following code: | | sum1 :: [Int] - Int | sum1 = foldl (+) 0 | | foldl' :: (a - b - a) - a - [b] - a | foldl' f v l = foldr (\x - \fld - \v' - fld $ f v' x) id l v | | sum2 :: [Int] - Int | sum2 = foldl' (+) 0 | | main :: IO () | main = do n - readLn; | print $ sum1 [1..n]; | print $ sum2 [1..n] | | and ran it through ghc with: ghc Folds.hs -ddump-simpl -O | | I was expecting the two calls to be optimized to something equivalent, or | even for the result of a single calculation to be printed twice. However, | peering at the Core output, it seems that the two sum functions exist | separately and have different structure (sum1 appears to have a simple | recursive definition, while sum2 involves two lamba expressions). | | I did all this because I read a paper introducing folds that showed how | you can express foldl in terms of foldr and giving the derivation. | Unfortunately I don't have the paper/derivation, but I believe my foldl' | is correct (that may be the problem, of course - that sum1 and sum2 are | not equivalent either because of a coding error, or because of some | subtlety in the types, although I carefully gave them explicit types to | try and avoid that). | | The derivation wasn't that complicated (althugh I find it simpler to | simply write the fold down). If it's not an error on my part, why doesn't | ghc do the same kind of transformation itself? Or am mistaken in | thinking that if derivation is easy then the revrese transformation as an | optimisation should also be easy? | | Thanks, | Andrew | | -- | http://www.acooke.org/andrew | ___ | Haskell-Cafe mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Graphical Programming Environments (was: ANNOUNCE: Release of Vit al, an interactive visual programming environment for Haskell)
I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming; I don't understand why so many people talk about graphical programming, i.e. putting together functions, arguments, definitins etc. with the mouse instead of the keyboard, drawing arrows instead of naming etc. No wonder it didn't succeed. It would be much less convenient than typing text and less readable too. That's not necessarily correct. If 'graphical' isn't taken too literally, you can think of a dialog per function with the possibility to specify pre and post conditions, tests, comments, etc. Then it would be possible to view only things your are interested in: default code, exception handling, interfaces, ... without cluttering the screen with 'code of no interest'. I agree that putting together programs just by click and point would be tedious. But _viewing_ programs this way could be advantagous. What do you think? Best wishes, Markus ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Hypothetical reasoning in type classes
Hello, Has anyone thought about adding hereditary Harrop formulas, in other words hypothetical reasoning and universal quantification, to the instance contexts in the Hsakell type class system? Just today (and not only today) I wanted to write instance definitions like instance (forall a. C a = D a) = E [a] where ... This is analogous to wanting to write a rank-2 dictionary constructor (forall a. C a - D a) - E [a] at the term level, but with type classes, this dictionary constructor should be applied automatically, in a type-directed fashion, at compile time. The theory behind such instance contexts doesn't seem so intractable; indeed it looks decidable to my cursory examination. The opreational intuition is that we would like the type checker to generate an eigenvariable a and perform hypothetical reasoning. I would also like to quantify universally over type classes; in other words, if ? is the kind of a type class constraint (aka a dictionary type; perhaps o would be a better choice of notation), then I would like to define not just types of kind *-*-? (aka type classes) or kind (*-*)-? (aka constructor classes), but also types of kind (*-?)-(*-?). But that's for another day... Ken -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig Hi, my name is Kent, and I let people change my .sig on the internet. Hi, Ken! Put midgets back in midget porn! -- Not authorized by Ken Shan. Supported by the association of midget porn workers, Local 9823. signature.asc Description: Digital signature ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Treating POSIX signals as exceptions?
There is a strong difference between asynchronous signals (like SIGIO, SIGINT, etc..) and synchronous ones (SIGFPE, SIGSEG). I think only the second type should be treated as exceptions, since they are tied to a specific thread of execution. tying asynchronous signals to exceptions just because they are posted to the program in the same way seems wrong. Good point: the synchronous signals should be treated as synchronous exceptions. The question raised by the initial post was whether the asynchronous signals should be treated as asynchronous exceptions; indeed there are cases when this is useful: in GHC the SIGINT signal is converted into an asynchronous exception which terminates the compiler. It is necessary to use an exception so that the compiler can clean up before exiting. especially when we have concurrency. registering a callback, or even having a 'wait' like thing to blockingly wait for the next asynchronous signal would be ideal. We already have the callback model, and it turns out you can implement pretty much anything else you want on top of it. There's no reason to restrict ourselves to just one API for signals. we need some data type which contains the information in the 'siginfo_t' structure. then we can include this as a standard Exception type for use with synchronous signals. Yes, we should do this too. Cheers, Simon ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
[Switching to haskell-cafe] For serious programming, I entirely agree. But my view is that we are seeing some degree of programmability entering all sorts of everyday objects -- video recorders spring to mind as an early example -- and there's lots of work going on in the field of ubiquitous computing. Many of these pervasive devices may be fire-and-forget, but I suspect many will not be. Graphical displays may be more common than full keyboards. So how is the user to be presented with options to enter programming information? I don't have any final answers here, but I do have an intuition that for many users, where the programming requirement is a simple but flexible composition of existing functions, that a graphical, self-documenting interface may be an appropriate response to the video recorder programming hell syndrome. Some of my thoughts about this came from considering issues faced by a friend of mine who has recently wired his new home for total data (several kilometres of Cat5A cable in the loft!) -- it's all very well having all these intelligent devices around the home, but how to actually tell them what to do? Opening a door may signal that a light should turned on, or an alarm should be set off -- how to describe the distinction? (Assuming the owner is not an experienced programmer.) Finally, as evidence for this view of user interfaces, I note that for tasks like computer system administration, graphical interfaces have pretty much taken over from the old command-line-and-text-file approach. Even Linux systems have graphical front-ends for most of the common configuration, even though, for an experienced sysadmin, the text-based versions are generally quicker to set up and understand what's happenning. In short, it's the occasional user, not the full-time expert, who may be better served by a non-textual approach. #g -- At 23:56 12/11/03 +0100, Marcin 'Qrczak' Kowalczyk wrote: W li¶cie z ¶ro, 12-11-2003, godz. 11:06, Graham Klyne pisze: I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming; I don't understand why so many people talk about graphical programming, i.e. putting together functions, arguments, definitins etc. with the mouse instead of the keyboard, drawing arrows instead of naming etc. No wonder it didn't succeed. It would be much less convenient than typing text and less readable too. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
As a serious programmer, I'd be very happy to have a more graphical, more interactive programming experience as far as _output_ is concern. I'm happy to input textual expressions and definitions, but I'd like instant feedback and display of intermediate results as tables, graphs, trees, charts etc. Vital looks quite promising in the regard (though I've only browsed the website, and not used it). Spreadsheets are successful, I believe, because of the instant visual feedback they provide. An environment that worked in a similar way, but built upon a rigorous and high level language like haskell could well be a killer app. Tim -Original Message- From: Graham Klyne [mailto:[EMAIL PROTECTED] Sent: Thursday, November 13, 2003 10:03 AM To: Marcin 'Qrczak' Kowalczyk Cc: [EMAIL PROTECTED] Subject: Re: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell [Switching to haskell-cafe] For serious programming, I entirely agree. But my view is that we are seeing some degree of programmability entering all sorts of everyday objects -- video recorders spring to mind as an early example -- and there's lots of work going on in the field of ubiquitous computing. Many of these pervasive devices may be fire-and-forget, but I suspect many will not be. Graphical displays may be more common than full keyboards. So how is the user to be presented with options to enter programming information? I don't have any final answers here, but I do have an intuition that for many users, where the programming requirement is a simple but flexible composition of existing functions, that a graphical, self-documenting interface may be an appropriate response to the video recorder programming hell syndrome. Some of my thoughts about this came from considering issues faced by a friend of mine who has recently wired his new home for total data (several kilometres of Cat5A cable in the loft!) -- it's all very well having all these intelligent devices around the home, but how to actually tell them what to do? Opening a door may signal that a light should turned on, or an alarm should be set off -- how to describe the distinction? (Assuming the owner is not an experienced programmer.) Finally, as evidence for this view of user interfaces, I note that for tasks like computer system administration, graphical interfaces have pretty much taken over from the old command-line-and-text-file approach. Even Linux systems have graphical front-ends for most of the common configuration, even though, for an experienced sysadmin, the text-based versions are generally quicker to set up and understand what's happenning. In short, it's the occasional user, not the full-time expert, who may be better served by a non-textual approach. #g -- At 23:56 12/11/03 +0100, Marcin 'Qrczak' Kowalczyk wrote: W li¶cie z ¶ro, 12-11-2003, godz. 11:06, Graham Klyne pisze: I've sometimes thought that a functional language would be the ideal platform to usher in a purely graphical style of programming; I don't understand why so many people talk about graphical programming, i.e. putting together functions, arguments, definitins etc. with the mouse instead of the keyboard, drawing arrows instead of naming etc. No wonder it didn't succeed. It would be much less convenient than typing text and less readable too. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell Graham Klyne For email: http://www.ninebynine.org/#Contact ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
what's the deal with user error on fail?
When one triggers an exception with something like fail Error opening file The user gets a message like Fail: user error Reason: Error opening file which is confusing to the user, because it the user's fault. Is there some other way that it is recommended one fail? Or should I be catching userErrors at the top level and failing with my own error message? -- David Roundy http://www.abridgegame.org/darcs ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Graphical Programming Environments (was: ANNOUNCE: Release of Vit al, an interactive visual programming environment for Haskell)
W licie z czw, 13-11-2003, godz. 10:34, [EMAIL PROTECTED] pisze: If 'graphical' isn't taken too literally, you can think of a dialog per function with the possibility to specify pre and post conditions, tests, comments, etc. I still doubt it would be more convenient. Maybe it's just me, but I prefer to be able to scroll across many function bodies which are grouped and ordered manually, to using a Smalltalk browser where I must click to expand everything and the grouping is dictated by classes the functions operate on and by the environment. An additional overview browser showing just headers for quickly locating functions is fine, as long as it doesn't take away the ability to view all the information with minimal navigation (only scrolling) and the ability to use standard text tools on the source (e.g. grep, diff, perl). -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Graphical Programming Environments (was: ANNOUNCE: Release of Vit al, an interactive visual programming environment for Haskell)
I love religious wars. Having been around awhile, I make a prediction. This will thrash a while, those who like graphical environments will make their points, those who like textual environments will make their points, no one will convince anyone else, and eventually it will die down. In fact (in my opinion), people operate differently. Some operate better graphically, some operate better textually, and I'm glad both tools are available. Me, I'm a text person, but I know folks who think better in pictures, bless 'em. Let the games begin. Dave Barton EDAptive Computing ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: Hypothetical reasoning in type classes
Yes, absolutely. See http://research.microsoft.com/~simonpj/Papers/derive.htm Section 7, and Trifanov's paper at the Haskell Workshop 2003 Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ken | Shan | Sent: 13 November 2003 05:40 | To: [EMAIL PROTECTED] | Subject: Hypothetical reasoning in type classes | | Hello, | | Has anyone thought about adding hereditary Harrop formulas, in other | words hypothetical reasoning and universal quantification, to the | instance contexts in the Hsakell type class system? Just today (and not | only today) I wanted to write instance definitions like | | instance (forall a. C a = D a) = E [a] where ... | | This is analogous to wanting to write a rank-2 dictionary constructor | | (forall a. C a - D a) - E [a] | | at the term level, but with type classes, this dictionary constructor | should be applied automatically, in a type-directed fashion, at compile | time. The theory behind such instance contexts doesn't seem so | intractable; indeed it looks decidable to my cursory examination. The | opreational intuition is that we would like the type checker to generate | an eigenvariable a and perform hypothetical reasoning. | | I would also like to quantify universally over type classes; in other | words, if ? is the kind of a type class constraint (aka a dictionary | type; perhaps o would be a better choice of notation), then I would | like to define not just types of kind *-*-? (aka type classes) or | kind (*-*)-? (aka constructor classes), but also types of kind | (*-?)-(*-?). But that's for another day... | | Ken | | -- | Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig | Hi, my name is Kent, and I let people change my .sig on the internet. | Hi, Ken! | Put midgets back in midget porn! -- Not authorized by Ken Shan. Supported by | the association of midget porn workers, Local 9823. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
hello, i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors and this should not be the case. not to mention that often the error that needs to be reported is not a string. but to answer your question, i think the motivation behind user error, is that this is the user from the perspective of the compiler writer, i.e. the programmer. i think one should think of those errors as analogous to segmentation fault in C, or java's unhandled exceptions, i.e. in a well written program the user of the program should never see them, but they can be useful to the programmers while debugging their code. David Roundy wrote: When one triggers an exception with something like fail Error opening file The user gets a message like Fail: user error Reason: Error opening file which is confusing to the user, because it the user's fault. Is there some other way that it is recommended one fail? Or should I be catching userErrors at the top level and failing with my own error message? -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
Quoting Graham Klyne [EMAIL PROTECTED]: Finally, as evidence for this view of user interfaces, I note that for tasks like computer system administration, graphical interfaces have pretty much taken over from the old command-line-and-text-file approach. Even Linux systems have graphical front-ends for most of the common configuration, even though, for an experienced sysadmin, ... In short, it's the occasional user, not the full-time expert, who may be better served by a non-textual approach. I don't think the Linux developments are really evidence of anything other than a desire to have a more Windows-like interface, because that looks like it will make it easier for Linux to penetrate certain markets, or because that's what the people who develop these interfaces are used to. My own experience -- as an occasional user of Linux, but familiar with BSD and able to use Macs without much trouble and even to tolerate Windows for limited purposes -- was that the graphical Linux interfaces were virtually unusable. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
David Roundy [EMAIL PROTECTED] wrote: i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors ^^^ In Haskell, this is indeed the case---every monad is after all a monad transformer applied to Haskell's identity monad, which supports errors (hence the existence of Haskell's `error' function :). So even if a monad designer doesn't explicitly add error support, the monad still supports errors. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Sockets howto
Hello guys, any one aware of a Sockets howto for haskell ? Greets, Jad ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
hello, well that's because haskell is not as pure as it claims to be :-) if every monad supports errors depends on what you mean by supporting errors. i would argue that supporting errors and divergence is not the same thing. the difference is that one should be able to handle an error thrown by a computation, while clearly we cannot detect nonterminating computations. bye iavor Jon Cast wrote: David Roundy [EMAIL PROTECTED] wrote: i would say that if you are wanting to report errors to users, you should not use fail or error. you should instead explicitly report the error. when i program i typically use error in situations that i think are imposible, but if there is a bug one gets a better error messeage. i don't use fail (well except sometimes implicitly in list comprahensions). the reason i avoid fail is that it seems hackish to me -- it implies that every monad supports errors ^^^ In Haskell, this is indeed the case---every monad is after all a monad transformer applied to Haskell's identity monad, which supports errors (hence the existence of Haskell's `error' function :). So even if a monad designer doesn't explicitly add error support, the monad still supports errors. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe -- == | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | == ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
record matching syntax forensics
so I noticed DrIFT was generating code like
f Foo{bar} = ...
as seemingly a shorthand for
f Foo{bar = bar} = ...
which does not seem to work with current compilers. I fixed this in
2.0.2 but was curious why it was generating code like that in the first
place. it appears to be illegal looking at the haskell report and I was
uncertain who wrote the derive rules in the first place so thought I
would ask here.
John
--
---
John Meacham - California Institute of Technology, Alum. - [EMAIL PROTECTED]
---
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: record matching syntax forensics
Google for 'punning'. It was removed from Haskell (I don't know why --
look at the list archives). But that used to be legal.
On Thu, 13 Nov 2003, John Meacham wrote:
so I noticed DrIFT was generating code like
f Foo{bar} = ...
as seemingly a shorthand for
f Foo{bar = bar} = ...
which does not seem to work with current compilers. I fixed this in
2.0.2 but was curious why it was generating code like that in the first
place. it appears to be illegal looking at the haskell report and I was
uncertain who wrote the derive rules in the first place so thought I
would ask here.
John
--
Hal Daume III | [EMAIL PROTECTED]
Arrest this man, he talks in maths. | www.isi.edu/~hdaume
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: what's the deal with user error on fail?
David Roundy [EMAIL PROTECTED] wrote: hello, well that's because haskell is not as pure as it claims to be :-) Nonsense. Haskell is perfectly pure; the IO monad is just nondeterministic :) if every monad supports errors depends on what you mean by supporting errors. I mean `supporting errors' in the only possible sense that `supporting errors' can be implied by the existence of `fail': we have a throw function. i would argue that supporting errors and divergence is not the same thing. I never said it was. the difference is that one should be able to handle an error thrown by a computation, Although this doesn't imply the existence of a `catch' HOF; see the MonadPlus instance for Maybe. while clearly we cannot detect nonterminating computations. Of course. But we can detect exceptions thrown by `error'. Even though we can't distinguish them from non-termination /in pure Haskell/. We can of course distinguish them in the IO monad (which perhaps ought to be re-named the SinBin monad, to be more honest...). So we can detect erroneous computations in any monad. Jon Cast ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
