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
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk