[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: halp
- From: firstname.lastname@example.org (Michael C. Grant)
- Date: Mon, 16 Nov 92 02:20:52 -0800
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