Experiment: Implementing Multiple Dispatch in D (misc comments)
Bruno Medeiros
brunodomedeirosATgmail at SPAM.com
Wed Aug 2 14:40:42 PDT 2006
Bruno Medeiros wrote:
> I watched some time ago a Google TechTalk about Common Lisp (
> http://video.google.com/videoplay?docid=448441135356213813&q=peter+seibel
> ) where, as expected from a Lispanatic, LISP is idolized and Java is
> whined about.
>
> The second part of the talk, talks about the CLOS (Common Lisp Object
> System) multiple dispatch system (called multimethods on Lisp lingo),
> and how it can be useful, etc.., and how in Java it all had to be
> implemented manually and non-generically (i.e., for each particular usage).
>
> I wondered, how would D fare? I started to think if and how that feature
> could be implemented in D, as an experimental, proof-of-concept, and
> template learning exercise. The first thing needed, I noticed, was a
> compile time reflection mechanism, for functions at least (to find it's
> parameter types). With some IFTI incantations this is actually already
> possible, but with the number of the funtion's parameters limited to
> some point(this is what TomS's funcmeta does).
>
Here are some miscellaneous comments I gathered from the MDF experiment:
* One can't just instantiate a template.
Sometimes one just wants to instantiate a template, but that is not
allowed, a declaration of some entity must be made, example:
alias tpl!(foo) _DUMMY;
* is-expression is tricky:
Using the is expression for type comparison is error-prone. Because it
also fails if the expression is not semantically correct, then
is-expressions like these:
is(typeof(foo) == typeof(bar))
may evaluate to false when you make a typo, instead of generating a
compile-time error. :(
* Template forwarding referencing problems are annoying
Template forwarding referencing problems are annoying. Ye pretty much.
But easy to work around I guess.
* IFTI doesn't work for member functions. (members of aggregate types)
Oskar had already pointed this out recently. It happens like this:
struct st {
void iftifunc(T) (T a) { }
}
void test() {
st s;
s.iftifunc(1);
}
main.d(2): template main.st.iftifunc(T) templates don't have properties
main.d(7): no property 'opCall' for type 'st'
main.d(7): function expected before (), not 1 of type int
* Templates are not allowed in functions
This restriction makes sense for some templates, but not for all. These
templates could be allowed, but with restrictions to the kind of member
entities they can have (similarly to struct and class inner templates).
Specifically, a template with only function members or with compile-time
members, could be allowed. I ran into three situations where I wanted
such templates inside a function, in MDF.
* Static arrays ... :(
Static arrays are a stain in the language. They're the black sheep of
the D types, as, most inconsistently, they are the only type which
cannot be assigned (with various ramifications as, cannot be inout
parameters, cannot be the key of AAs, etc.).
Again this is nothing new, both I and Oskar have mentioned this before,
but this is the first time I've been actually stinged by it.
We should seriously consider how and if it would be feasible to change
arrays so that they work as proper value types.
--
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
More information about the Digitalmars-d
mailing list