- Haskell-Cafe - Haskell.org

RE: haskell httpd
by Simon Marlow 14 Nov '03

14 Nov '03

> <rant> > Frustrating. > > Its been 4 years since I seriously looked at > Haskell. I would have expected that over this > time, someone here would have consolidated it into > a language useful for real world applications. > > The Haskell in Practice page is shockingly short > and many of the examples are not actually Haskell > in practice. > > Does anyone here eat the Haskell dog food or is > this all just fooling around (basic reasearch)? > > Simon, why did you write the Haskell web server? 1. To show that it could be done 2. Because it was fun, and 3. So I could write a paper about it Note that this list does *not* include 4. So I could use it However, several people have found the web server useful and are using it, either as the basis of further research, or in some cases as the basis for a real production web server. It isn't a production web server, as you noticed, but it's a start. Cheers, Simon

2 1

Re: what's the deal with "user error" on fail?
by Jon Cast 14 Nov '03

14 Nov '03

David Roundy <droundy(a)abridgegame.org> 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

1 0

record matching syntax forensics
by John Meacham 14 Nov '03

14 Nov '03

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. - john(a)foo.net ---------------------------------------------------------------------------

2 1

Re: what's the deal with "user error" on fail?
by Jon Cast 14 Nov '03

14 Nov '03

David Roundy <droundy(a)abridgegame.org> 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

3 2

Re: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
by Graham Klyne 13 Nov '03

13 Nov '03

[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 > \__/ qrczak(a)knm.org.pl > ^^ http://qrnik.knm.org.pl/~qrczak/ > >_______________________________________________ >Haskell mailing list >Haskell(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

2 1

Graphical Programming Environments (was: ANNOUNCE: Release of Vit al, an interactive visual programming environment for Haskell)
by Markus.Schnell＠infineon.com 13 Nov '03

13 Nov '03

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

3 2

RE: ANNOUNCE: Release of Vital, an interactive visual programming environment for Haskell
by Tim Docker 13 Nov '03

13 Nov '03

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:GK@ninebynine.org] > Sent: Thursday, November 13, 2003 10:03 AM > To: Marcin 'Qrczak' Kowalczyk > Cc: haskell-cafe(a)haskell.org > 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 > > \__/ qrczak(a)knm.org.pl > > ^^ http://qrnik.knm.org.pl/~qrczak/ > > > >_______________________________________________ > >Haskell mailing list > >Haskell(a)haskell.org > >http://www.haskell.org/mailman/listinfo/haskell > > ------------ > Graham Klyne > For email: > http://www.ninebynine.org/#Contact > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

RE: Treating POSIX signals as exceptions?
by Simon Marlow 13 Nov '03

13 Nov '03

> 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

1 0

RE: Why doesn't GHC do the following optimisation?
by Simon Peyton-Jones 13 Nov '03

13 Nov '03

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: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | andrew cooke | Sent: 12 November 2003 17:40 | To: haskell-cafe(a)haskell.org | 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 | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Programming style (or: too clever by half?)
by Graham Klyne 13 Nov '03

13 Nov '03

I just spotted a possible idiom for something that seems to pop up from time to time: foldr const But I can't help feeling that this code is perversely obscure. Does it have any advantages over the more obvious form suggested below? [[ headOrSomething = foldr const headOrSomething1 _ (x:_) = x headOrSomething1 x [] = x h = headOrSomething -- h = headOrSomething1 test1 = h 0 [1,2,3] == 1 test2 = h 0 [] == 0 test3 = h 0 (repeat 42) == 42 ]] This suggests, e.g., an alternative coding of Maybe.listToMaybe: [[ altListToMaybe = foldr (const . Just) Nothing ]] Opinions? #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

3 2