Monadic scheme of I/O 
Author Message
 Monadic scheme of I/O

Quote:

>Haskell shows best and brightest the glamor of monads in performing
>i/o, calling C functions and doing other _interactions_. Other
>languages however are not barred from partaking in these riches. With
>an appropriate _style_, one can closely emulate monadic i/o, as this
>article tries to show on an example of Scheme.

Yes, you can emulate monadic i/o in Scheme, but the trouble with Scheme
or even ML is that the type system won't help you to distinguish between
procedures with side effects and those without.

--
Fergus Henderson              | Designing grand concepts is fun;

http://www.*-*-*.com/ ~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F



Fri, 15 Sep 2000 03:00:00 GMT  
 Monadic scheme of I/O

Quote:

> Yes, you can emulate monadic i/o in Scheme, but the trouble with Scheme
> or even ML is that the type system won't help you to distinguish between
> procedures with side effects and those without.

So in Haskell can I write a splay-tree library that uses a single imperative
update for performance reasons, but semantically behaves completely
functionally? Can I do this without cluttering my abstract functional
interface with an implementation detail?

Being able to distinguish between side-effecting and pure functions has it
advantages, but I think it also has the potential to force you to leak
implementation detail in your interface.



Fri, 15 Sep 2000 03:00:00 GMT  
 Monadic scheme of I/O

Quote:


>> Yes, you can emulate monadic i/o in Scheme, but the trouble with Scheme
>> or even ML is that the type system won't help you to distinguish between
>> procedures with side effects and those without.

>So in Haskell can I write a splay-tree library that uses a single imperative
>update for performance reasons, but semantically behaves completely
>functionally? Can I do this without cluttering my abstract functional
>interface with an implementation detail?

Yes, you can.  You just need to use `unsafePerformIO'
(and `MutVar' or something like that for the actual destructive update).

Of course, if you use `unsafePerformIO' willy-nilly, then Haskell's
type system won't help you either -- hence the name "unsafe".
But a disciplined use of `unsafePerformIO' in those relatively rare
situations such as the one described above will give you the best of
both worlds.

Haskell is not quite ideal in this area, IMHO; I think the approach
we've taken in the latest version of Mercury, where the language has
explicit support for `impure' procedures, is a little bit nicer.

Mercury is a pure language, like Haskell; the vast majority of Mercury
procedures are pure, and only a tiny minority are impure.
Since impure procedures make it much harder to reason about programs,
then if they do occur, we want this to be very clear.  Thus
Mercury's impurity system requires that every impure procedure
must be declared with the `impure' keyword, and every call to an
impure procedure must be preceded with the `impure' keyword.
Furthermore, for any procedure that calls an impure procedure,
either the caller must also be impure, or there must be a
`pragma promise_pure' declaration for the caller.

In Mercury, `unsafe_perform_io' is impure, and thus any procedure
which calls it must be declared impure or must have a `pragma promise_pure'
declaration.  I think this is slightly nicer than the Haskell approach,
because in order to abuse unsafe_perform_io you not only have to call
it, you also have to explicitly lie to the compiler (with an untruthful
`pragma promise_pure' declaration).

(However, in Haskell simply using `unsafePerformIO' may be good enough
that the [small] increase in complexity of Mercury's impurity system is
no warranted.)

--
Fergus Henderson              | Designing grand concepts is fun;

http://www.cs.mu.oz.au/~fjh   | -- Brooks, in "The Mythical Man-Month".
PGP key fingerprint: 00 D7 A2 27 65 09 B6 AC  8B 3E 0F 01 E7 5D C4 3F



Sat, 16 Sep 2000 03:00:00 GMT  
 Monadic scheme of I/O

Quote:


> > Yes, you can emulate monadic i/o in Scheme, but the trouble with Scheme
> > or even ML is that the type system won't help you to distinguish between
> > procedures with side effects and those without.

> So in Haskell can I write a splay-tree library that uses a single imperative
> update for performance reasons, but semantically behaves completely
> functionally? Can I do this without cluttering my abstract functional
> interface with an implementation detail?

As far as I understand, the splay-tree would have to be
single-threaded BUT the type system would enforce single-threadedness
at compile-time. The programs where the imperative splay-tree isn't
ST won't type check. (Well, that's my understanding, at least.)

                        Thomas
--
Thomas Lindgren, Uppsala University            

http://www.csd.uu.se/~thomasl/                      



Sat, 16 Sep 2000 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Monadic scheme of I/O

2. Monadic programming in Scheme: an example

3. Monadic scheme of I/O

4. PC-Scheme like Scheme for OS/2

5. Better Scheme in OS/2 than X-Scheme?

6. How does one mix monadic screen IO and monadic disk IO?

7. Monadic Roll and generating normal distributions in APL

8. monadic verb with Dot (J)

9. Dyadic or monadic?

10. higher-level monadic programming

11. monadic io

12. Parser generator vs. Monadic parsing

 

 
Powered by phpBB® Forum Software