Re: Lazy streams and unsafeInterleaveIO

[Glynn Clements]

Jyrinx wrote:

 So is this lazy-stream-via-unsafeInterleaveIO not so nasty, then, so 
 long as a few precautions (not reading too far into the stream, 
 accounting for buffering, etc.) are taken? I like the idiom Hudak uses 
 (passing a stream of I/O results to the purely functional part of the 
 program), so if it's kosher enough I'd like to get hacking elsewhere ...

It depends upon the amount and the complexity of the program's I/O,
and the degree of control which you require. For a simple stream
filter (read stdin, write stdout), lazy I/O is fine; for a program
which has more complex I/O behaviour, lazy I/O may become a nuisance
as the program grows more complex or as you need finer control.

If you just wanted a getContents replacement with a prompt, the
obvious solution would be to use unsafeInterleaveIO just to implement
that specific function.

The main problems with lazy I/O are the lack of control over ordering
(e.g. you can't delete the file until a stream has been closed, but
you may not be able to control how long the stream remains open), and
the inability to handle exceptions (the actual exception won't occur
until after e.g. getContents has returned).

-- 
Glynn Clements [EMAIL PROTECTED]
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: Interpret haskell within haskell.

[oleg]

Lauri Alanko wrote on Dec 22:
 The magic is _here_:

 (begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment)) a)
 == 6

 Here (interaction-enviroment) is a run-time representation of the
 compile-time environment. It makes possible two-way interaction between the
 stages. Essentially, first-class environments are all the magic you need to
 implement eval.

I'm sorry to act as a Grinch, but there is no magic. First, according
to R5RS, (interaction-environment) is not a first-class environment.

R5RS says (Section 6.5):

 [[optional procedure]] (interaction-environment)

 This procedure returns a specifier for the environment that contains
 implementation-defined bindings, typically a superset of those listed
 in the report. The intent is that this procedure will return the
 environment in which the implementation would evaluate expressions
 dynamically typed by the user.

There is nothing there about interaction between phases. And in fact,
this interaction does not work. If you put the following code

(module aaa)
(begin (define a 5) (eval '(set! a (+ a 1)) (interaction-environment))
   (display a) (newline))

into a file, _compile_ that file using Bigloo, and run the resulting
a.out, you will see a message
*** ERROR:bigloo:eval:
Unbound variable -- a

Nowhere the Scheme report talks about first-class environments. Please
note that the result of (interaction-environment) is a _specifier_ for
an environment.

Some Scheme systems do provide first-class environments.  For example,
MIT Scheme has a form 'the-environment'. It comes at a price. In a
post Re: why isn't the environment explicit ? on comp.lang.scheme on
Mar 15, 2001, Joe Marshall wrote:

  Since you can (sort of) regard call/cc as making continuations
  explicit, why aren't environments explict ?

 In MIT Scheme, they are.  The special form (the-environment) returns
 the current environment as a first-class object.

 However.

 The difficulty with using such a form is that it destroys any
 possibility of compiler optimization.  If you compile code with a
 (the-environment) form in it (in MIT Scheme), the compiler essentially
 throws up its hands and inserts code to call the interpreter.

There is no Santa either.

___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe