From: sam@csi.jpl.nasa.gov (Sam Sirlin)
Subject: Re: SIGNUM of teaching numerical methods
Originator: sam@kalessin
Organization: Jet Propulsion Laboratory, Pasadena, CA
Date: Thu, 30 Jul 1992 18:56:28 GMT


In article <1992Jul30.050314.19813@yrloc.ipsa.reuter.COM>, rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
(commenting on previous articles)

|> >And can I call in and out of other compiled languages promiscuously, without
|> >fear of copying data?
|> 
|> Of course not. 
|> \begin{serious}
|> a. Calling other languages is a pig, because they don't believe in
|>    arrays. Once they believe in arrays, then we'll see progress,
|>    because they'll slow down to the speed of APL.

I don't think lots of people with scientific uses for code will
tolerate this. If C++ is slow they'll just use f77. 

|> b. Calling other languages is a pig, because they don't believe in 
|>    arrays. They believe in pointers to a hunk of undifferentiated
|>    mainstore, which you Promise To Treat Gently. In particular,
|>    there are Other Variables, which may (or may not) tell you
|>    things such as: Rank, Shape, Element Count, etc. 
|> 
|>    Of course, data type is Fixed At Compile Time.

And rank and shape as well. But this seems reasonable if it gives a
real speedup. Tim Budd's APLc allows this (fixed type) as well. 

|>    So, even if you can embed calls to other languages into your APL
|>    code, as we could trivially do in ACORN by merely not compiling
|>    any function with the name of the foreign language routine,
|>    you still need to write a specific "impedance matcher" for 
|>    each of them, which specifies all the above junk, because
|>    each Foreign Routine is different. 

This of course seems an insurmountable problem to get to run fast in
all possible cases, but is this really a requirement? It seems to me
the interface should be flexible enough that the programmer can make
it work. For example if you want to pass an array to a fortran
routine, the programmer must be aware that fortran wants column
orientation whereas the apl internal storage is probably row oriented.
But if she adds suitable transposes, possible flattening, and then can
just hand the fortran routine a pointer to the start of the data
(after the header) shouldn't this work?

Of course the easiest way to do the interface is to ignore it
completely, but translate the APL into compileable code (fortran or
c), and then the programmer can add whatever he likes at whatever cost
he wants.

|> c. Calling other languages is a pig, because they like to tinker
|>    global variables. If you cannot determine this property, then you
|>    MUST COPY any array argument which has a reference count greater
|>    than one (Eg, anything other than a temp!). You also have
|>    the problem of multiple results from functions, I mean subroutines,
|>    which return their results via side effects, rather than functional
|>    approaches.

It seems to me that nested arrays are the solution to this. I've often
wanted this capability in APL, as many routines really do return more
than one "value" (maybe a set of arrays) and gluing things togther is
a kludge. Now that we all have one universal standard for nested
arrays this problem is no more (;-). It's a late problem. 

|> d. All the above create problems which can be dealt with one at a time,
|>    but not in a systematic manner. These are hell for compilers,
|>    compiler writers, and those who would use parallel systems.

If you allow interfacing with completely unknown and unspecified other
languages this will never go away. I think this (togther with
portability) makes an irrefutable argument for a translator rather
than a direct compiler. If someone really wants to take the trouble to
make things fast, it might take some effort, and the APL compiler
can't be expected to do the whole job!

|> >Have things changed since 1990?
|> 
|> Of course they have. But (   8^}   ) the compilers are STILL not good
|> enough.
|> If you talk with John Feo (Sisal), you may find that his opinion is that
|> even if compilers ARE good enough (SISAL beats Fortran on many
|> problems), that the world still does not beat a path to your door.

Well APL compilers aren't exactly easily available (except for the
free ones which are still buggy/primitive - sigh... though getting
better). While some comercial ones exist they are totally unmarketed
as far as I can see.  Has anyone ever seen an add for one in Byte for
example? Since they're not easily available, the problem isn't solved
yet. 

|> We hope that APL will escape this fate.

What fate? The world beating a path to our door? We don't really seem
to have to worry about that now...

Actually I had an idea for something that might catch on. Matlab is
very popular here, but suffers from many of the same problems as APL.
Specifically it's an interpreter, and many people just use simple
array operations to write code fast, but then the code ends up running
slow. I think I'll try writing a translator from (simple) Matlab to
APL (in APL), then voila, using APLc I get a Matlab compiler. Pretty
twisted huh? Well I could always write the translator in J... Anyway
I'll have to see about speed tests...

-- 
Sam Sirlin
Jet Propulsion Laboratory         sam@kalessin.jpl.nasa.gov

Newsgroups: comp.lang.apl