[ruby-talk:9827] Re: 101 Misconceptions About Dynamic Languages

Reimer Behrends <[e-mail]> wrote:
>Josh Stern ([e-mail]) wrote:
>> There is a real, non-trivial, example of template
>> genericity being used to express mathematical ideas
>> in the CGAL library:
>> 
>> http://www.cgal.org/Manual/doc_html/frameset/fsKernel.html
>> http://www.cgal.org/Manual/doc_html/frameset/fsBasic.html
>> 
>> How to do such things in Ruby in full generality (efficiency
>> aside)?  

Reimer, you misunderstood the pragmatics of my post.
It had previously  been asserted in the discussion that
Ruby would have trouble with full blown generic programming
because of the lack of overloading and and automatic instantiation
of overloaded functions for the generic parameters.  There had
also been a request for a more fully explained example of
generic programming, especially in a mathematical project
where its use may allow the mathematician to think in the
'language of the problem' which can be a complex abstract
language for a mathematician.  So  I mention CGAL as
a good example of the latter.  I also mentioned that a
good way to do generic programming, in its full generality
in Ruby, would be to transpose the 'traits' technique
to one in which a proxy class directly implements
ruby functions that returns types as objects.  In your
discussion below, you seem to express a superficially
similar idea about how to do generic programming in
Ruby, though I confess that I don't understand all
of your post.

>To begin with, for the most basic use of generic types, no additional
>effort is necessary--Array and Hash are obvious examples. 

A main idea of the traits technique is that one may bundle
all of the generic inteface in a kind of proxy class.
I agree that for the simple collectin classes like hash,
the generic interface (involving hashing and comparison)
is simple enough (only two operations) that there is
no need to do this.  The traits technique pays dividends
when there interface has many more methods and there
are reusability relationships between the traits needs
of different classes.

>For more
>advanced schemes, it may be best to avoid the elaborate and
>unnecessarily complicated maze of C++ templates and return to simpler
>approaches. 

C++ templates aren't actually complicated, but anyway, that's
off the point anyway.

For instance, the instantion of a parametric type A[X] as
>A[T], where X is a formal parameter and T a concrete type, can be seen
>as specialization inheritance from A[X] with X = T. What we need for
>this to work is to be able to work with types as first class
>objects--something that C++ can't do, 

a) that's not necessary
b) the traits technique approximates the same thing anyway.

>but Ruby can. Instantiating formal
>parameters of generic types is basically constraining a family of
>objects along one more dimensions. While I believe that somebody
>mentioned earlier that genericity and inheritance are orthogonal
>concepts, the opposite is true: generics introduce a classical is-a
>relation, generally with full substitutivity (modulo the usual
>covariance issues).

I don't understand which is-a relationship you are talking about here.
Could you give an example?

>A straightforward implementation would pass types, and whatever other
>generic parameters you have, as arguments to 'new', to be stored in type
>variables. 

What happens in practice is that little details of implementation
can change the interface, since more types are required.
That is one reason why it works out well to bundle them
in a trait class.  But we agree on the idea of using
types as objects in Ruby.

>Instantiating the formal paramaters would then be the
>equivalent to performining currying on 'initialize'. 

Have to ask you again for an example.  I know currying
and initialize, but I'm not sure what your vision is
here.

>Variants would be
>having functions returning types, which can then be redefined, or
>aliasing type names to constants. (And of course, when I'm referring to
>types, just about any type of object can be substituted.)
>
>The implementation of Z_n, for instance, should be a straightforward
>exercise. The need of generics for a polynomial ring is not equally
>obvious; we only need a type parameter as a simple case of a factory
>pattern, and even this could be avoided if desired.

>A lot of the problems that you have in many statically typed languages
>just go away when you have types as first-class objects. 

Agreed!

It should also
>be noted that just because something is part of C++ it should not
>necessarily be added to another language; in fact, the converse is
>generally true.

I wasn't advocating that.  Though I have suggested in other posts
that overloading would be useful in Ruby, but for somewhat different
reasons.

Regards,

-= Josh