[boost] Re: compile time member detection

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-14 15:38:15

Brian McNamara <lorgon_at_[hidden]> writes:

> I am not sure what you are saying or asking here.  (Haskell can deal with
> the "associated types" using multi-parameter type classes--an extension
> which isn't in the Haskell 98 standard, but which is supported by all the
> Haskell compilers.)
>
> Since I am guessing it may help, here is how you would encode C++
> iterators in Haskell:
>
>    -- (Note that Haskell cannot easily express "implicitly convertible",
>    -- "assignment", or "const", so I am choosing not trying to deal with 
>    -- those issues here.)
>    
>    -- TrivialIterator
>    class (EqualityComparable iter,         -- anything inside (...)=>
>           DefaultConstructible iter)=>     -- is a "prior constraint"
>          TrivialIterator iter value_type where
>       deref :: iter -> value_type     -- "deref i" means "*i"
>    
>    -- InputIterator
>    class (TrivialIterator iter value_type,
>           SignedIntegralType distance_type)=>
>          InputIterator iter value_type distance_type where
>       preinc  :: iter -> iter         -- "preinc i" means "++i"
>       postinc :: iter -> iter         -- "postinc i" means "i++"
>       
>    -- 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.

>    -- etc.
>
>    -- Note that the iterator concepts "carry along with them" their 
>    -- "intrinsically associated types".  "Extrinsically associated
>    -- types" (like "reference type" and "pointer type", if I correctly 
>    -- understand C++ iterator concepts) can be declared using separate
>    -- type classes and "functional dependencies" (another Haskell
>    -- extension that the compilers now support).

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 am pretty confident that Haskell can adequately express everything
> that we could express in C++, and it can do so "roughly as
> succinctly" as we can in C++.

Check out http://tinyurl.com/v1k6 and get back to me ;^) You might
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.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com