From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-11-14 12:39:40
--On Friday, November 14, 2003 11:54 AM -0500 Brian McNamara
> On Fri, Nov 14, 2003 at 08:15:03AM -0800, Mat Marcus wrote:
>> Named conformance worries me, though I haven't programmed much in
>> Haskell yet. One question I have is: who writes the type classes (or
>> whatever you want to call these things)? I can't imagine it is the
>> library author since the generic (meta-)algorithms are meant to be
>> used with an unbounded set of types(, metafunctions, etc.). But a
> The library author writes them. Current library authors already
> "define the concepts"; the only difference now is that they would
> also reify them into "type classes" (or whatever we'd call them).
Oops, I mistated my question. I understand that the type classes
correspond to the concepts, and it is clear that some library author
must them. Please replace the question in the paragraph above with:
whose job is it to manually declare conformance to a give concept? I
see that you have addressed this below somewhat so I will move on.
>> library's usability would seem to suffer if the user has to manually
>> assert conformance to various concepts before calling generic
>> algorithms. A hybrid approach where the library author provides the
>> named conformance for "common types" doesn't seem to help. I want
>> the generic algorithm to be written in such a way that the compiler
>> can check conformance for me. Are you really worried about
>> accidental structural conformance? How do things work in practice
>> in Haskell?
> To answer the last two questions:
> (1) Somewhat. Accidental conformance is more of a problem "in
> theory" than "in practice", I think. However it's analogous
> to the argument for static typing (dynamic-typers will tell
> you that type errors are more of a problem "in theory" than "in
> practice"). See below.
Hmmm. Interesting. I need to digest this.
> (2) All conformance must be declared. Everything, even stuff like
> "int" is a "EqualityComparable" and a "LessThanComparable".
> It is not as bad at it sounds.
Not sure about that. A user can call the plain old function foo(int)
without making any additional declarations. But with named conformance
it would seem that the user of a generic foo(T) may incur an
additional responsibility to manually assert that int conforms to
whatever concept T myust model. In practice this would seem to lead to
users avoiding generic functions, just as the need to write helper
functions to use STL today is one barrier to acceptance (which is why
we like lambda).
> I suppose one of the main motivations for using any conformance-
> detecting approach is to get better compiler error messages. We all
> know how bad compiler error messages can be when you instantiate a
> template with a type which doesn't match the right concept. Using a
> conformance-detecting approach, this error can be automatically
> detected "at the entrance" to the library (rather than deep within
> its implementation) and the framework can help dispatch a "custom
> error message" if this is desired (or else just use SFINAE to make
> the library function "invisible" to non-conforming types).
I should have given a little more background. We spent a some time in
Kona going over early drafts of papers proposing the addition of
concepts to C++. These papers should appear as part of the post-Kona
mailing any day now at the bottom of
<http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/>. Of course
one of the key goals is to achieve the "better and earlier" error
detection benefit. One stumbling block is the difficulty of detecting
structural non-conformance at compile time without generating compiler
errors. The compiler vendors indicated that this was tantamount to
providing a will_this_compile metafunction and is too difficult.
Dietmar proposed a workaround requiring manual declarations of
conformance which IMO bears strong resemblance to Haskell's type class
mechanism. So I am considering all of this in an effort to try to
decide my position on how concepts should work in C++.
> The advantage to named conformance over structural conformance with
> respect to detection is that detecting named conformance is easy.
> OTOH, detecting structural conformance was largely impossible prior
> to the discovery of SFINAE, and I believe it is still quite
> difficult to do well (see, e.g., Brock's recent comments, or much of
> the discussion in "Static Interfaces in C++", esp. stuff like
Yes. See my last paragraph.
> The pre-existence of structural conformance as the C++ norm for
> concept checking creates a psychological barrier to the acceptance
> of named conformance. I do believe that, on the whole, the "named"
> approach is the best way to go. It's actually totally analogous to
> "static typing" versus "dynamic typing".
Not sure how will the analogy holds since concepts are multi-sorted
notions and I've always preferred Goguen/Burstall's "loose semantics"
over "initial semantics/ADT" based approaches. But I need to think
about this some more.
Somewhat facetiously: maybe what we need is the ability to write
generic algorithms that work when types conform structurally to the
requirements together with a mechanism for overriding this structural
detection (e.g. manual declaration of non-conformance).
[snip further development of the analogy]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk