Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!cs.utexas.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!socrates!socrates!rockwell
From: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Subject: Re: Weaning  myself from Matlab: is APL a viable alternative for scientific programming and signal processing?
In-Reply-To: andrew@rentec.com's message of 29 Jan 93 22:35:14 GMT
Message-ID: <ROCKWELL.93Feb3020837@socrates.umd.edu>
Sender: rockwell@socrates.umd.edu (Raul Deluth Miller-Rockwell)
Organization: Traveller
References: <WEG.93Jan19140548@mace.cc.purdue.edu> <1502@kepler1.rentec.com>
	<WEG.93Jan26115205@mace.cc.purdue.edu> <1522@kepler1.rentec.com>
Date: Wed, 3 Feb 1993 07:08:37 GMT
Lines: 26

Andrew Mullhaupt:
   I do not normally ask about J, but in this case the question has a
   tremendously significant answer - so I'll ask. What is the
   mechanism by which foreign code is called from J? I don't mean how
   to write J to do this, but rather what technology does J use to
   actually invoke foreign code? There is a correct answer, and it is:

   Anything much less than dynamic loading is hopelessy down-rev,
   stupid, backward and uninformed. The technology is trivial in
   modern Unix, totally straightforward in Windows and OS/2. What's
   not to like? Just because we won't get a CP/M version is _no
   excuse_.

I'm not aware of any standard mechanism for dynamic loading under unix
(standard across various unix versions, not tied to the mechanisms of
a particular machine).  You're right in that it's trivial to
implement.  But is it trivial to implement portably?

Currently, J is implemented using C compiler technology.  This has
the obvious flaw of limiting J to the speed and portability of C and
its libraries.

Besides, if a specific implementation of J (say, J on the amiga)
implements dynamic loading, what good would that do you?

Raul
