Re: [boost] Re: compile time member detection

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 
<lorgon_at_[hidden]> wrote:

> 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
> "HeroicProxy").

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]

 - Mat