From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: SIGNUM of teaching numerical methods
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 05:03:14 GMT

In article <1122@kepler1.rentec.com> andrew@rentec.com (Andrew Mullhaupt) writes:
>In article <ROCKWELL.92Jul26190755@socrates.umd.edu> rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell) writes:
>>Andrew Mullhaupt:
>>   Yes. And what I _really_ want to know is why is this not a problem
>>   which has been solved ten years ago?
>>
>>It was.  The compiler we use at work is about that old.
Us compiler writers are dumb. Stupid, really. 
>
>And does this compiler compile all of APL? Or if I execute some string which
>I build up will it be just a transparent shell for the interpreter...


See above. 

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

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.

   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. 

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.

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.

\end{serious}

>I think compiled APL should be one of the more useful things. However the APL
>gurus I used to know had a concensus view that they were'nt good enough yet.
>
>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.

We hope that APL will escape this fate.


Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada
Newsgroups: comp.lang.apl