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

[Peter Ross]

On Thu, Sep 28, 2000 at 02:09:36PM +1100, Tyson Dowd wrote:
> 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.
> 
This is exactly the point I have been trying to make, thanks Tys.

> 
> 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.
> 
As pointed out in an email, I am not sure that using a di/uo pair
actually makes that much difference (apart from more typing for me) so I
am not sure if it is worth the effort.  

> 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.
> 
I don't like the names I have chosen, perhaps highlevel should become
stream and lowlevel impure_c_stream

Pete
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------