[m-dev.] Stream2000

[Peter Ross]

On Thu, Nov 02, 2000 at 08:45:47PM +1100, Fergus Henderson wrote:
> On 01-Nov-2000, Peter Ross <peter.ross at miscrit.be> wrote:
> > On Wed, Nov 01, 2000 at 08:20:15AM +1100, Fergus Henderson wrote:
> > > On 31-Oct-2000, Peter Ross <peter.ross at miscrit.be> wrote:
> > > > The only issue I have with this version is that it makes heavy use of
> > > > existential types.  It seems once you start using them you just have to
> > > > keep using them.
> > > 
> > > Why not use abstract types rather than existential types?
> >
> > Abstract types are problematic when the stream has more then one extra
> > property.
> 
> Hmm, I don't see why...
> 
> > For example putback and linenumbers would be encoded as the type
> > putback(linenumber(S)) or linenumber(putback(S)) both of which are
> > equally valid.
> 
> Ok, fine so far.
> 
> > Now you have a pred which requires putback stream
> > 
> > :- pred p(putback(S), io__state, io__state) <= stream__input(S).
> 
> Declaring `p' like that is not a good idea.  I meant "use abstract
> types _and_ type classes rather than existential types and type
> classes", not "use abstract types (alone) rather than existential
> types and type classes".
> 
> So `p' should have type
> 
> 	:- pred p(S, io__state, io__state) <= stream__putback(S).
> 
> > So I don't think that you can get away from using existential types.
> 
> Your example only shows that we can't get away from using type classes.
> 
Ahh yes, I see.  Thanks.  The next question is which is better?  It
shouldn't really matter which method we use, except that one case may
have better error messages then the other.

The nice thing about existential types is that they simplify the
interface, as all the instance declarations are local to the module.

The nice thing about the abstract types approach is that I feel that
programmers may find it more comfortable (I now it took me a while to
get my head around existential types).

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