- Haskell - Haskell.org

Re: "interact" behaves oddly if used interactively
by S.J.Thompson 02 Oct '03

02 Oct '03

Bruce, All this discussion of 'interact' makes me feel quite nostalgic. In the late 80s(!) I did some work on this, since Miranda's only IO was in the form of interact. Understanding the interleaving behaviour is problematic, and hand-coded solutions proved to be difficult. I came up with a way of analysing these programs, and proved some elementary properties. The paper also contains a set of combinators for writing interactive programs, which prefigure the monadic interaction combinators. The paper is at: http://www.cs.kent.ac.uk/~sjt/Pubs/yoptrace.ps Best regards, Simon Thompson

1 0

Re: "interact" behaves oddly if used interactively
by b.i.mills＠massey.ac.nz 01 Oct '03

01 Oct '03

On the pedagogic part of this issue, I personally feel that using interact causes concentration on the temporal logic aspects of the code. That is, on understanding the interaction between the computer and the user as a whole. Although the monad approach has this in it, I feel it to be more hidden, and I like my students to have some experience with interact before going any significant distance into monadic IO. Similarly, I like them to look at other monads before IO monads, and IO monads before trying the do constructs. I've found that without the background of monads, the students get into tangles with the seemingly strange logic of the construct, and the error messages don't help them at all. However, on the down side of interact, I do have a grumble. I like to use the exercise of writing a generic command line processor, with line editing capacity as the basic task. The answer I'm looking for is just something like ... parse = lines execute s = if s==endCode then "" else "{" ++ s ++ "}" endCode = "stop" fini a = (take (length endCode) a) == endCode del ('\27':'\91':'\51':'\126':t) = True del _ = False edit s = aux 0 s [] where aux n [] b = '\n' : (blat (reverse b)) aux 0 b c | del b = aux 0 (drop 4 b) c aux n b (x:c) | del b = '\b' : ' ' : '\b' : (aux (n-1) (drop 4 b) c) aux n (a:b) c = a : (aux (n+1) b (a : c)) join (a:b) = a ++ "\n" ++ (if (fini a) then [] else "cmd: " ++ (join b)) blat s = execute (head (parse s)) myCmd = interact (\s -> "cmd: " ++ (join (map edit (lines s)))) In this code ... look at join, we could write this more along the lines of ... join ("stop\n":b) = "stop\n" join (a:b) = a ++ "\ncmd: " ++ (join b) But this basic approach has the problem (at least under Hugs) that when we enter the word "stop" at the command prompt, the word will not be echoed until we have got past the p in stop. But, it does not matter which line code we take, the initial characters of the string are the same. Although it is a tall order to work this out in general, it does seem to be fairly obvious in this case. That is, if I feed in something of the form ('s':b), then I can see that under each clause I must irrevocably get something of the form ('s':t) back, and further more if the first clause does not in the end match, then the second one will anyway (since we already know we have a list of at least one character). So, it is apparent at this stage that the output will not be an error (the only way that join has started processing this is that it was successfully returned by edit as a complete string), and will start with an 's'. Would such a characteristic make it easier or harder to work with interact? Just a thought, Bruce, Institute for Information and Mathematical Sciences Massey University at Albany, New Zealand.

1 0

exitImmediately's signature
by Dean Herington 01 Oct '03

01 Oct '03

Is there a good reason why `exitImmediately` (in System.Posix.Process as well as other places) shouldn't return `IO a` instead of `IO ()`?

1 0

Call for Contribution 18th World Computer Congress, Toulouse, France
by Karama Kanoun 01 Oct '03

01 Oct '03

============== ** SINCERE APOLOGIES IF YOU RECEIVE MULTIPLE COPIES OF THIS CfC ** ******************************************************************* Call for contributions 18th IFIP World Computer Congress The premier international forum on Sciences and Technologies of Information and Communication 22-27 August 2004 Toulouse, France http://www.wcc2004.org ******************************************************************* The technological evolution of the sciences and technologies of information and communication (STIC) during the last decades is far from reaching completion. The challenges posed to the STIC community for pursuing the evolution share a dramatic jump in complexity, be it for the fall of elementary hardware dimensions towards nanometric scales, for producing software of warranted quality, or for providing the informational infrastructure with protections and with human-machine interaction modes that enable the emerging paradigm of Ambient Intelligence to support the Knowledge Society. The 18th IFIP World Computer Congress will cover the above-mentioned challenges via a rich program featuring nine co-located established conferences, topical days or sessions, workshops, tutorials, a student forum, an exhibition. The topics of the co-located conferences range from theoretical informatics to the relationship between informatics and society, through hardware and software technologies and non-functional aspects relating to our dependency on networked information systems: - Theoretical Computer Science - TCS - Information Security - SEC - Smartcard Research and Advanced Applications - CARDIS - Distributed and Parallel Embedded Systems - DIPES - Artificial Intelligence Applications and Innovations - AIAI - Human Error, Safety and System Development - HESSD - Virtual Enterprises - PRO-VE - e-Commerce, e-Business and e-Government - I3E - History of Computing in Education - HCE The topical days or sessions will offer synthetic and prospective views on topics of dramatic interest for the emergence of the Knowledge Society. Deadlines for submission: - Topical sessions/days, Workshops: end October 2003 - Conference papers (see the website for the various conferences), Tutorials: January 2004 Please visit the conference web site for detailed submission instructions and updated information on the Congress (http://www.wcc2004.org) Congress Chair: Jean-Claude Laprie, LAAS-CNRS, France <laprie(a)wcc2004.org> Programme Chair: Reino Kurki-Suonio, Tampere University of Technology, Finland <rks(a)cs.tut.fi> Programme Vice-Chair: Michel Diaz, LAAS-CNRS, France <diaz(a)wcc2004.org> Support Committee Chair: Alain Costes, LAAS-CNRS, France <costes @wcc2004.org> Local Organization Chair: Marie Dervillers, LAAS-CNRS <dervillers @wcc2004.org> Publication Chair: Leon Strous, De Nederlandsche Bank, Netherlands <strous(a)iaehv.nl> Publicity Chair: Karama Kanoun, LAAS-CNRS, France <kanoun(a)wcc2004.org> Topical Session/Day Chair: Rene Jacquart, ONERA Toulouse, France <Rene.Jacquart(a)cert.fr> Workshop Chair: Michel Diaz, LAAS-CNRS, France <diaz(a)wcc2004.org> Tutorial Chair: Ricardo Reis, Federal University of Rio Grande do Sul, Brazil <reis(a)inf.ufrgs.br> Student Forum Chair: Mohamed Kaâniche, LAAS-CNRS, France <kaaniche(a)wcc2004.org> Submission Handling Chair: Jean-Charles Fabre, LAAS-CNRS, France <fabre(a)wcc2004.org>

1 0

RE: "interact" behaves oddly if used interactively
by Simon Marlow 01 Oct '03

01 Oct '03

> For GHC (6.0.1) > > "main=interact id" basically echoes every line of my input, whereas > "main=interact show" correctly waits for EOF before > outputting something. Which of these are you claiming is wrong? This is the behaviour I'd expect in both cases (although I'd have to go and carefully review the code for 'show :: String -> String' in the report to be able to tell whether it was supposed to be that strict or not). > Furthermore the buffering mode must be "LineBuffering". The buffering mode of a Handle attached to a terminal is LineBuffering by default. > If I explicitely set the buffering to "NoBuffering" I'm not able to > enter EOF by typing "ctrl-d". This is a consequence of Unixy terminal semantics. Unix does line buffering on terminals in the kernel as part of the terminal processing, unless you turn it off. However, the Ctrl-D processing is also part of the terminal processing which gets turned off when the kernel line buffering is disabled. So GHC tries its best to get NoBuffering semantics by turning off the kernel line buffering, but as a result you lose Ctrl-D. C'est la vie. I've added this to the FAQ. > Furthermore my terminal seems > to remain in > the buffering mode set by the previously called ghc-haskell program > (because it effects programs that do not "hSetBuffering".) This is a bug, recently fixed. > What should a student think about "interact" in the Prelude? (It's ok > for pipes only, I guess.) Well, combining laziness with I/O is always going to be problematic. I'd say steer clear of introducing students to interact. Cheers, Simon

9 15

RE: "interact" behaves oddly if used interactively
by Simon Marlow 01 Oct '03

01 Oct '03

> Pardon? Haskell is a non-strict language. Using 'interact' is one of > numerous situations where one takes advantage of non-strict semantics. > (Keith just gave a different example.) > > Non-strict semantics does not prescribe the evaluation order, although > usually lazy evaluation is used. I suppose you are talking about > optimistic evaluation, which is a mixture of eager and lazy > evaluation. Yes sorry, I meant optimistic evaluation. > That is fine and should work well with 'interact', otherwise there is > something wrong with optimistic evaluation. No, optimistic evaluation does not work well with interact, because it causes the input stream to be evaluated (and therefore demanded) earlier than you would expect. This is the problem: interact exposes more than just non-strictness, it exposes laziness. In Robert Ennals' implementation of optimistic evaluation he has to fall back to lazy evaluation for lazy I/O, precisely because of this problem. Cheers, Simon

3 2

Imported instance declarations
by Frieder Kalisch 01 Oct '03

01 Oct '03

Hello, While trying to learn Hakell I came across a weird (to me) error message concerning imported instance declarations. This module module XXX() where import Control.Monad.Error() instance Functor ((->)i) where fmap = (.) gives this error message (compiling with ghc 5.0.4.2): Duplicate instance declarations: XXX.hs:5: Functor ((->) i) <No locn>: Functor ((->) r) For me this error message is somewhat puzzling: Where is the second instance declaration given? In this case it happens to be in Control.Monad.Reader, but how can I find out without looking for it in the CVS repository? The documentation for Control.Monad.Error does not mention the imported modules. I suppose, that the compiler knows in which module the instance declaration was given, because it needs to tell duplicate import paths from duplicate instance declarations. Why is it not given in this example? Greetings Frieder Kalisch -- Frieder Kalisch f.kalisch(a)tphys.uni-heidelberg.de +49-6221-549-432

1 0

RE: "interact" behaves oddly if used interactively
by Simon Marlow 01 Oct '03

01 Oct '03

Malcolm Wallace writes: > But the whole purpose of 'interact' is to use its argument as the > demanding function which drives lazy consumption of the input. It is > *designed* to reveal the evaluation behaviour, by hoisting it into > the I/O monad. This is why interact is bad, IMO: it forces you to think about the evaluation order. The evaluation order for Haskell is not part of the language definition - it is normally up to the implementation to pick a strategy. Except when you get to lazy I/O. The commonly accepted meaning for the lazy I/O operations forces the implementation to adopt a lazy evaluation strategy for values which require lazy I/O. For example, eager evaluation would be a completely valid implementation strategy for Haskell if it were not for lazy I/O. This has been swept under the carpet for far too long! Cheers, Simon

3 2

early registration until 15 October, Technology Enhanced Learning T.E.L.'03 Conference, Milano, 20-21 Nov '03
by Giorgio Valle 01 Oct '03

01 Oct '03

1 0

"interact" behaves oddly if used interactively
by Christian Maeder 01 Oct '03

01 Oct '03

Hi, For GHC (6.0.1) "main=interact id" basically echoes every line of my input, whereas "main=interact show" correctly waits for EOF before outputting something. Furthermore the buffering mode must be "LineBuffering". If I explicitely set the buffering to "NoBuffering" I'm not able to enter EOF by typing "ctrl-d". Furthermore my terminal seems to remain in the buffering mode set by the previously called ghc-haskell program (because it effects programs that do not "hSetBuffering".) With "runhugs" (Nov 2002) there is no premature output for "interact id", the buffering mode does not matter, but "ctrl-d" is not recognized as EOF. NHC98 does not even wait for a line break before outputting the result (and echoes "\EOT" for "ctrl-d"). What should a student think about "interact" in the Prelude? (It's ok for pipes only, I guess.) Christian module Main where import System.IO main = do hSetBuffering stdin NoBuffering interact id -- maeder@turing:~/haskell/examples> bash --version GNU bash, version 2.05b.0(1)-release (i586-suse-linux) Copyright (C) 2002 Free Software Foundation, Inc. maeder@turing:~/haskell/examples> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.0.1 maeder@turing:~/haskell/examples> ghc --make Interact.hs -o interact Chasing modules from: Interact.hs Compiling Main ( Interact.hs, ./Interact.o ) Linking ... maeder@turing:~/haskell/examples> ./interact 1 1 2 2 3 3 ^D^D^D ccc interact: interrupted

3 2