Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-11-14 17:00:54

On Fri, Nov 14, 2003 at 10:38:15AM -1000, David Abrahams wrote:
> Brian McNamara <lorgon_at_[hidden]> writes:
> > -- istream_iterator models InputIterator
> > instance InputIterator (istream_iterator t d) t d where
> > ...
> istream_iterator isn't parameterized on its distance_type, which I
> think is part of the point I am making.

The top of
suggests otherwise; I was just copying that.


> Sure. My point was that, IIUC, you can't declare the InputIterator
> type class in Haskell such that, in addition to being able to write:
> instance InputIterator (istream_iterator t d) t d where
> ...
> you can write something like:
> instance InputIterator (istream_iterator t) where
> ...
> and have the InputIterator look inside istream_iterator for its nested
> value_type and distance_type.

I think from the Haskell point-of-view, the first declaration does
exactly that. That is,

   instance InputIterator (istream_iterator t d) t d where

means the same as (inventing new syntax on-the-fly to communicate the

   instance InputIterator istream_iterator
                          istream_iterator::distance_type where

(The former just uses pattern matching to name the components, whereas
the latter uses a "nesting" syntax.)

In any case,

> Check out and get back to me ;^) You might

Thanks much for this reference! (I would have discovered it on my own
soon when I looked at my copy of the OOPSLA proceedings, but "now" is
better than "soon". :) ) Looks very cool.

> want to ask the authors what they mean what they say:
> With respect to generics, ML and Haskell provide an informative
> contrast to the object-oriented languages... The discussions of Java
> generics, Generic C#, and Eiffel suggest that Haskell and ML avoid
> some difficulties with implementing generic libraries that the
> object-oriented languages share... Both languages have
> disadvantages. ML lacks functions with constrained genericity aside
> from functions nested within functors. Haskell, though quite
> expressive, requires an awkward mechanism to express associated
> types.

I have only glanced at it so far to get a feel for their example. It
may well be that there I've missed which makes it harder/more-awkward/
less-scalable/something than I have thought. Or maybe it's just a case
of "feels awkward" being relative to the language background one is
coming from.

In any case, thanks again for this pointer; I am thrilled to see a paper
on this topic, especially when it's authored by "all the right people".

-Brian McNamara (lorgon_at_[hidden])

Boost list run by bdawes at, gregod at, cpdaniel at, john at