- Haskell-Cafe - Haskell.org

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 14 Nov '03

14 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

Why doesn't GHC do the following optimisation?
by andrew cooke 13 Nov '03

13 Nov '03

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

1 0

Why no findM ? simple Cat revisited
by Ahn Ki-yung 12 Nov '03

12 Nov '03

Simple Cat (revisitied) \begin{code} import IO findM f [] = return Nothing findM f (x:xs) = do { v <- x; if f v then return (Just v) else findM f xs } isLeft (Left _) = True isLeft _ = False main = findM (isLeft) (hCat stdin) where hCat h = try (hGetLine h) : hCat h \end{code} This is my answer for the question of my own, which is posted a couple There are mapM, filterM in the Haskell 98 Standard Library. But why no findM there ? As you can see from simple cat, it seems quite useful. I think fildM should be added to the module Monad. -- Ahn Ki-yung

5 8

Treating POSIX signals as exceptions?
by David Roundy 12 Nov '03

12 Nov '03

I was wondering why System.Posix.Signals is as it is, and whether it could be rewritten to use exceptions, which seems like the obvious way to handle signals. Of course, that requires asynchronous exceptions, but that doesn't seem like a severe problem. What I currently do is to use the following function withSig :: Signal -> IO a -> IO a -> IO a withSig s handler job = do id <- myThreadId installHandler s (Catch $ throwDynTo id s) Nothing job `catchDyn` catcher where catcher s' | s' == s = handler catcher s' = throwDyn s' which just catches a given signal and throws an exception, and then catches that exception with a given default handler. This has the nice effect that my 'job' can't be rudely interrupted by the user hitting ^C at just the wrong time (since I use this to catch sigINT). Thus, this makes bracket work in the presence of signals, allows me to use block to avoid being interrupted by a ^C when this could cause data corruption, etc. (Yes, I know that the above isn't very clean, since any other process that uses {catch,throw}Dyn on a CInt will mess things up, but creating a new Typeable instance seemed like too much trouble.) Is there any reason all of System.Posix.Signals couldn't be done in this manner? Have the RTS always add a handler for each signal, which just throws an exception. Off the top of my head, all we'd need is one function acceptSignals :: IO () -- tells RTS to send signal exceptions to this -- thread. We'd also need some sort of SignalException type (and of course, to define all the signals), and the rest would be done using the existing Control.Exception code. And, of course, default signal handlers would need to be converted to default exception handlers. Is there a problem with this idea? -- David Roundy http://www.abridgegame.org/darcs

3 3