[m-dev.] for discussion: stream library v2

[Tyson Dowd]

On 27-Sep-2000, Ralph Becket <rbeck at microsoft.com> wrote:
> >From Peter Ross on 27/09/2000 13:56:17
> > They are impure because they were designed to map gracefully onto the
> > foreign function interface.  If you so desire, you can implement you
> > stream interface at a higher level, hopefully getting the best of both
> > worlds.
> 
> That still doesn't explain why they *have* to be impure or
> even declared as such.  Can you give me an example where it's
> necessary to have impure low-level stream code that can't be 
> hidden behind a pure interface?

Hmm...  Perhaps Fergus is right in saying that it would be a good idea
to leave out the lowlevel interface for now...

highlevel.m provides a typeclass for people who want to write streams in
Mercury.  It's completely pure and you are encouraged to use it to write
streams in Mercury.  If you are not a library implementor you should
stop reading now.

END USER SECTION OF STREAMS INTERFACE.

Ah, so you're a library implementor.  You'll be aware that writing pure
interfaces to everything in C is sometimes a pain in the arse.

And you'll also know that if you use Mercury's impurity interface
(allowing you to at least use all the functionality of Mercury while
using impure code to make a pure interface), you end up using the same
old techniques over and over again every time you implement di/uo stream
pair interfaces.  That's because C uses almost the same stream interface
every single time, and we use the same stream interface every single
time.  Good computer scientists don't repeat the same thing over and
over again, they generalize it.

lowlevel.m provides a typeclass for people who want to map the streams
to a foreign language binding while doing the minimum of work.  In
particular you need to write much less foreign language code, since you
only need to implement a few impure predicates with a well defined
interface -- (well it's not *really* well defined yet but it will be).

Lowlevel provides throwing exceptions, grabbing error messages, results
packaged into ok/error/eof, and turning C style handle based IO into
Mercury di/uo.  That's all it does.  But it's something you'll have to
do and get right every time you implement a stream. 

There is absolutely *nothing less pure* about doing things this way. 
The C code is still underneath any interface you might write that
targets the highlevel typeclass.  But you have to write all the
scaffolding yourself.  The "new stream" stuff in the current IO library
does almost exactly this stuff but a lot more is in C!  

- There is a table of function pointers, which are called from pragma C
  code (typeclasses, anyone?).
- The pragma C code provides the di/uo moded stream (and so we have to
  implement half of the IO data structures in C -- e.g. line numbers and
  stream names).
- We grab system error messages using C and a di/uo pair.
- pure Mercury built on top of that C code provides ok/error/eof and
  exception throwing.


Fergus suggests that we could do the di/uo pairing in C, and lowlevel
could provide an interface that just does ok/error/eof and exception
throwing (e.g. much like what we have in the current IO library).

IMHO is a reasonable suggestion -- an interface at that level might be
useful too.  Given that we don't have `ui' mode support at the moment,
this might be the right thing to do for now.  I like the idea of using
typeclasses to automatically implement patterns for turning impure code
into pure code, but I think in this case the pattern is sufficiently
simple that it won't necessarily hurt us to do it by hand.
So how about if lowlevel is a pure interface that does everything
lowlevel currently does *except* it already expects di/uo stream pairs.

If we were to have a typeclass for turning impure C streams into Mercury
di/uo streams, it would be better to name it "impure_c_stream" or
something like that.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------