halp

[mcgrant@rascals.stanford.edu (Michael C. Grant)]

Well, I received the manual, I joined the mailing list, I READ
the manual, I downloaded Thomas-1.1,...

...but for the life of me I can't seem to put together a complete class,
because 1) the book does not provide enough examples/explanation, and does
not answer all of my questions; and 2) despite my searching there's not
much example code out there...

So, considering that this is the only place to turn for questions/
comments and such, I shall ask a few:

1) Is there ANY significant example code out there I can look
   at? I don't learn any better than from example...
2) Can the types of variables supplied in #key arguments be
   specialized? If so, what's the syntax? I'd also like to
   see an example with specialization AND a default value.
3) I don't fully understand the communicaton between make and
   initialize... given the class <numeric-vector>, I'd like to
   be able to define a <polynomial> class which accepts the
   following make combinations:

   make <polynomail> var: nvar
   make <polynomial> gain: ngain var: nvar
   make <polynomial> roots: nroots gain: ngain var: nvar
   make <polynomial> coeffs: ncoeffs var: nvar

   where nroots, ncoeffs are of type <numeric-vector>, ngain
   is of type <number>, and var is of type <string> and is always
   optional... and, I'd like to reject all other 
   combinations as errors . What combination of initialize and
   make definitions must I have? Obviously some of these could
   be init-keywords in the class (especially var), and several
   of these different syntaxes could be combined with defaults,
   but again I just need to see something legal.
4) Has anyone addressed the issue of interfacing to other languages?
   I was specifically wondering if I was ever going to be able
   to define some sealed, optimized numeric classes for interfacing
   with LAPACK. This is indeed a BIG issue since I would actually
   depend on some sealed subclass of <vector>, say 
   <homogeneous-c-style-data-vector>, which supported only certain
   data types (like the various <numeric> types), etc.

More on #4: I realize just how tall an order #4 is. I also don't
expect any solutions in the near future. But from what I can tell
Dylan is as close to an ideal object-oriented numerics prototyping
(if not programming) language as anyone could get, ASSUMING

1) This interface to standard C/FORTRAN numerical code exists, and
2) Compilation efficiency can be assured, with compile-time
method resolution and inlining, for example.

and, would be absolutely AMAZING if

3) A C/Algol-like syntax were defined,
4) The C/FORTRAN interface could be preserved in a run-time,
   interpreted environment as well as the compiled environment.

I'm really impressed with how 'complete' Dylan feels from where I 
stand. Of course, without a standalone implementation, none of
us can be sure how successful it can be.

I think it's unnecessary to say that I like Dylan from head to toe,
although perhaps as I continue writing code I'll find things I wish
were different. I'd appreciate any answers to my Four Questions so
that I CAN continue to explore the language.

Thanks a lot,
Michael C. Grant
mcgrant@isl.stanford.edu