Experiment: Implementing Multiple Dispatch in D (misc comments)

[Bruno Medeiros]

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