Re: [boost] Re: compile time member detection

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
   http://www.sgi.com/tech/stl/istream_iterator.html
suggests otherwise; I was just copying that.

Regardless,

> 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
idea):

   instance InputIterator istream_iterator 
                          istream_iterator::value_type
                          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 http://tinyurl.com/v1k6 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])