March 2002 - Haskell - Haskell.org

Lambda over types.
by anatoli 22 Mar '02

22 Mar '02

I apologise in case this doesn't make any sense. ghc -fglasgow-exts -fallow-undecidable-instances allows constructs which amount to lambda abstraction over types. I've written a small untyped lambda calculus interpreter in the Haskell class/instance sublanguage, just to prove this point. (The terms are Haskell *types*.) Using this interpreter as a basis, and adapting it as necessary, I can now write arbitrary "functions" [1] that take types to types. But of course it's a pain to write them like that. Maybe, after all, it does make sense to have a dedicated lambda-over-types Haskell extension which is convenient to use? [1] - I cannot produce an equivalent of > type Foo a b c = <some-function-over-types> a b c but I can do an equivalent of this: > fun :: T1 -> T2 -> T3 -> <some-function-over-types> T1 T2 T3 -- anatoli __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

2 1

Bug in IO libraries when sending data through a pipe?
by Volker Wysk 22 Mar '02

22 Mar '02

Hello There seems to be a bug in the IO libraries. I'm using the following procedure to call an external program and send it data through a pipe. pipeto :: String -> String -> [String] -> IO () pipeto txt prog par = do catch (do -- create pipe (zu, von) <- createPipe vonh <- fdToHandle von hSetBuffering vonh NoBuffering mpid <- forkProcess case mpid of Nothing -> do -- child -- connect pipe's read end to stdin -- and close its write end dupTo zu (intToFd 0) fdClose zu hClose vonh executeFile prog True par Nothing ... -- (print error message) Just pid -> do -- parent fdClose zu -- close pipe's read end -- ** here ** hPutStr vonh txt -- write text to forked process hClose vonh -- close pipe's write end -- wait for child process to finish (Just ps) <- getProcessStatus True True pid if ps == Exited ExitSuccess then return () else ...) -- (error message) (\err -> ...) -- print error message The problem is that the child process doesn't receive all the data which the parent sends. It's as if "hPutStr vonh txt" sends the data lazily somehow, and "hClose vonh" closes the pipe prematurely. It varies from run to run exactly which data gets through. If I cause the child process to read all its input immediately, the problem doesn't seem to occur. Normally, it does so gradually, which takes a few seconds. I'm using GHC 5.02.2 Volker

3 6

stripcomments 1.0
by Thomas Hallgren 22 Mar '02

22 Mar '02

Hi, There now is a program that strips comments and blank lines properly. You can get the Haskell source code from: http://www.cse.ogi.edu/~hallgren/stripcomments/ How hard it is to do a real job of course depends on what you start from. I happened to have a lexer for Haskell, that was really easy to reuse for this purpose! Regards, Thomas Hallgren Nicholas Nethercote wrote: >On Mon, 18 Mar 2002, Kevin Glynn wrote: > >> > Are there any programs to strip comments and blank lines from a Haskell >> > source file, that work on normal and literate programs? >> >>Doing a real job is 'hard' >> >I'm surprised there aren't programs out there that do this properly. >

1 0

re: Haskell slicing tool?
by Colin Runciman 22 Mar '02

22 Mar '02

> Are there any tools to perform program slicing on Haskell? > I often find myself wanting to find all "fromJusts" invoked > from the current function, or all functions that use a > particular member of my monad's ADT. Assuming that what you want to see are the applications of these functions that occur at run-time, and the evaluation contexts in which they arise, you could try the Hat tracing tools (http://www.cs.york.ac.uk/fp/hat/) Colin R

4 3

catch (fail "...")
by Brian Huffman 22 Mar '02

22 Mar '02

Hi, Here is a problem I came across recently, revealing a difference between ghci and Hugs: hugs> catch (error "not ok") (\e -> putStrLn "ok") Program error: not ok ghci> catch (error "not ok") (\e -> putStrLn "ok") *** Exception: not ok hugs> catch (ioError (userError "not ok")) (\e -> putStrLn "ok") ok ghci> catch (ioError (userError "not ok")) (\e -> putStrLn "ok") ok hugs> catch (fail "not ok") (\e -> putStrLn "ok") Program error: not ok ghci> catch (fail "not ok") (\e -> putStrLn "ok") ok As I expected, neither of them can catch "error", and both of them can catch "ioError". But only ghci can catch the "fail". It seems to me that ghc has made a convenient choice here, because if I need to raise an IO exception, it is easier to type "fail s" than "ioError (userError s)". However, the online Haskell report says that for IO, fail s = error s, which is what Hugs does. (http://www.haskell.org/onlinereport/standard-prelude.html#$iMonad$$IO) Does anyone know the reasoning behind the design choice made in the report, or why the ghc implementation is different? I am mainly concerned about portability issues: particularly, is it a good idea to use fail for raising IO exceptions? Thanks - Brian Huffman

1 0

ICALP2002: accepted papers and preliminary program
by icalp2002＠informatica.uma.es 21 Mar '02

21 Mar '02

Dear Sir/Madam, I'm sending you the following information: -the list of accepted papers for ICALP'2002 (an HTML table with two columns; authors and title) -the preliminary program of ICALP'2002 is available on http://sirius.lcc.uma.es/ICALP2002/PreliminarySchedule.html (and on the "news" of ICALP2002 pages: http://www.lcc.uma.es/ICALP2002) -the preliminary program of the satellite event "Global Computing" (in the same link). I consider that this conference can be of your interest. The registration will be open in a few days. Best regards, Rafael Morales

1 0

Re: Lambda over types.
by anatoli 21 Mar '02

21 Mar '02

Hal Daume III <hdaume(a)ISI.EDU> wrote: > I'd be interested in seeing how you do this. I attempted such a thing a > while back but was unsuccessful. Attached are two interpreters: one for untyped lambda calculus, and one for an Unlambda-style language (combinators). Of course pure lambda terms are not very useful Haskell types. You may use your own types as primitive terms by defining instances of Subst and/or Eval of them. -- anatoli __________________________________________________ Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards� http://movies.yahoo.com/

1 0

Re: Haskell puzzles!
by Zdenek Dvorak 21 Mar '02

21 Mar '02

Hello. >- All the answers are at the end of this mail. > >----------------------------------------------------- >1) Are e1 and e2 equal? > > > f (x:xs) y = x > > g (x:xs) = \y -> x > > > > e1 = seq (f []) 1 > > e2 = seq (g []) 1 Should not these be f (x:xs) y = y g (x:xs) = \y -> y ? Otherwise, both e1 and e2 are obviously undefined. Zdenek Dvorak _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com

2 1

Re: using less stack
by Graham Hutton 21 Mar '02

21 Mar '02

> In the case of foldr the end of the list has to be > reached before anything can be evaluated. This is perhaps a good time to point out the common missconception that foldr can only be used to define functions that process the elements of lists in right-to-left order. For a discussion of this point, see section 5 of my JFP tutorial paper on foldr, which (amonst other things) shows how to sum a list of numbers in left-to-right order using foldr: http://www.cs.nott.ac.uk/~gmh/fold.pdf Graham +----------------------------------------------------------------------------+ | Dr Graham Hutton Email : gmh(a)cs.nott.ac.uk | | Foundations of Programming Group Web : http://www.cs.nott.ac.uk/~gmh | | School of Computer Science and IT | | University of Nottingham | | Jubilee Campus, Wollaton Road | | Nottingham NG8 1BB Phone : +44 (0)115 951 4220 | | United Kingdom Fax : +44 (0)115 951 4254 | +----------------------------------------------------------------------------+

1 0

question about concurrency implementation
by Dean Herington 21 Mar '02

21 Mar '02

I'm curious about the implementation of Concurrent Haskell in GHC and Hugs. Does access to values possibly shared among threads cost the same in Concurrent Haskell as in regular Haskell? I'm guessing the answer is "yes", because Concurrent Haskell is provided by default in GHC. If the costs are the same, does that rely on there being no true concurrency in the current implementations? How would the cost change if true concurrency were provided? Wouldn't thunk evaluation involve mutual exclusion? Dean Herington

4 4