Re: syntax suggestion for concepts
Douglas Gregor wrote:
On Mar 6, 11:09 pm, "W Karas" <wka...@yahoo.com> wrote:
Another way to address multiple dispatch in a way more similar to
C++ OO is to think of the function as a "member" of an implied
class that is the tuple of the types of the function parameters.
Yes. This is typically called "dictionary passing", and is the
implementation technique used by both Haskell and G.
In a sense, this is the same way that C++ concepts are implemented,
but the dictionary is passed at compile time, not run time.
Interestingly, would we call it "generic programming" or whatever, it
is still implemented with an OO programming, as OO is the most generic
programming style :)
Is ultimately the key difference between GP and OO the fact
that member functions are central to OO but not to GP? To
me, member functions seem more central to encapsulation than
polymorphism.
One of the typical Generic Programming complaints about OO is that it
ties together the questions of "What can this type do?" and "How is
this type implemented?" into the same language mechanism: inheritance.
Yes. And we have a notion of "interface" that doesn't deal with
implementation, and a "mixin class" that is implementation-only.
The first question is the more important question for someone writing
a polymorphic algorithm, because we don't care what the type is...
In OO programming, we also able to forget about the exact type, we can
just work with its "interface".
we
just want to be sure that it will work with our algorithm. So, GP only
concerns itself with this first question: A concept describes what a
certain type needs to be able to do to work inside a polymorphic
algorithm. A concept map tells *how* a particular type meets the
requirements of a concept, allowing us to smooth over syntactic
differences and tie together independely-developed pieces.
It seems easy to conceive of a programming
language with runtime polymorphism but no membership, where
vptrs are passed as hidden function paramaters rather than
being hidden object data members. With this approach,
multiple dispatch becomes easy -- there is a vptr hidden
parameter for each "polymorphic type tuple" rather than
just for each polymorphic type.
Exactly!
I would have to recall the same solution mentioned in D&E 13.8
(Stroustrup says the idea was suggested by Doug Lea in 1991):
bool intersect(virtual const Shape& , virtual const Shape& );
Was it the syntax for what you call a "parametric polymorphism"?
If yes, then I would say that multimethods problem are unrelated
to concepts proposal. Well, it might be convenient to introduce both
"concepts" and "parametric polymorphism" at once as a single unit,
but they are unrelated to each other and can be introduced separately.
In fact, if we would have the above syntax in 1991, we can now write:
class Shape {
public:
virtual bool isEqual(virtual const Shape& ) const = 0;
};
That could mean that "polymorphic tuple" passed as hidden parameter
or whatever: that was the problem that needs to be solved when we
discuss multimethods. That is a separate problem.
To this very time, there is no noticeable differences between the
OO interfaces and GP concepts, how you describe them.
--
Andrei Polushin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]