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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On Behalf Of Dave
> Thomas
> Sent: Sunday, January 21, 2001 06:53 PM
> To: ruby-talk ML
> Subject: [ruby-talk:9695] Re: 101 Misconceptions About Dynamic Languages
>
>
> "Christoph Rippel" <[e-mail]> writes:
>
> > try to express this in Ruby - it is going to be a nightmare.
>
> Perhaps you could help me understand the problem. The Ruby solution
> would seem to my naive eyes about half the size an considerably
> clearer. Without the need to jump through template hoops for type
> safety, most of the issues of genericity seem to go away.
>
> What am I missing?
>
> Dave
I think what ruby is missing is syntactic sugar for writing class generating
functions - the ``polynomial.rb'' is an example where lack of this facility resulted
in an improvable design (sorry if I offend anyone).


I guess one would start writing this package with a (Class) generating like

class Ring
def   Ring.mod_ZZ (n) # you could write this class function
end
end

so that one could write

A  = Ring.mod_ZZ 13
B  = Ring.mod_ZZ 23
C = Ring.mod_ZZ 13


and A,B work exactly like (for B replace 13 => 23)


class A
  N = 13  # this is the crucial part
  def initialize n
      @rep = n % N
  end
  def + (r)
       (@rep + rep.r) % N
  end
  attr_reader :rep
...
end


The import thing is that the type information is attached to the object ...

a1 =  A.new 11
a2 =  B.new 11
b1 =  C.new 10  # definitely want A.id == C.id
b2 =  B.new 11  # is nor hard but is not natively supported

than the internal representation of

a1 + b1 and a2 + b2

won't be equal.


Once you are finished with this you want write a polynomial ring Class generating
function

def  Ring.poly myRing , *vars # array of strings
end

so that you can call

PolyRing =  Ring.poly  (A, [ 'x', 'y' ] )



The point is that A can be anything supporting your basic arithmetic operations like
Float, Bignum ... or one of the Rings above etc. and ``PolyRing''  would be your
standard polynomial ring supporting a couple of extra algorithms depending on the
type of myRing (example field, Euclidian ring, Float  ... ).  Again the main point
is that you have class constants

class PolyRing
Coefftype = A
Dim = var.length
...
end

This is the natural way of writing this package since this is the way how the math
works and in C++ you can easily do this. It would be equally okay to add a couple of
extra Class generating functions like
def Ring.poly_coeff_field  myField, *vars
..
end
but this is not the real issue.

What is striking that the ruby fluent writer of the ``polynomial.rb'' did not write
this like this and had to suffer the consequence of his un-mathematical design -
i.e. implement the same algorithms a couple of times instead of implementing a
generic algorithm once. I would be forced to rewrite everything if I wanted to add
another base ring (field).

My point is that this is an example where the syntactic inconvenience (or
limitations?) of the programming language resulted in an unnatural design - if ruby
would sport build in support for generics he surely would have used them. I believe
you can write something like this but I had trouble with #module_eval and the class
constant N and gave up on it.  Delicators are a absolute non-non because performance
issues. I hope I was not too incoherent.


Christoph