"Josh Stern" <jstern / foshay.citilink.com> wrote in message
news:3a6f3d73$0$26803$65a95bcd / news.citilink.com...
[..]
>
> Reimer, you misunderstood the pragmatics of my post.

Talking about misunderstanding. I  am the person who initiated
the sup-thread about generic programming never indicated that
there are issues about type safety or overloading with respect to
the IMO problematic support for generic programming.

> 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 automatic instantiation
 > of overloaded functions for the generic parameters.  There had

My beef with ruby that there doesn't exist a good infrastructure
to facilitate  automatic  instantiation of generic parameters
and I still hold this opinion.

However the mixin mechanism and the C++-template are conceptually
fairly close, see for example my incoherent  ramblings  [ruby-talk:8174]
on the  subject, but the current mixin mechanism does not come with built
in support of instantiation of Module constants  at ``include time''
(i.e. instantiation of generic parameters)   to be able mine this analogy.
(My generic prototype provides a quick  and incomplete fix )

> 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.
Agreed!

> 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.
Me neither.
> 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.

Belatedly responding to your explanation of  ``Koeniging'' - it seems to
me that a Ruby implementation of overloading wouldn't need to rely on such
facility since it is mainly used to resolve naming ambiguities resulting
from
of compile time versus runtime issues - which for obvious reason would not
exist in Ruby  but I might be a bit blue-eyed about this.

> Regards,
>
> -= Josh

Christoph