Almost forgot, there is also this, but some of the design decisions lead me to believe it aims to solve some of the perceived shortcomings of APL (IO set to 0 for example), than maybe a faithful implementation, but still an interesting project worth taking a look at.
https://gitlab.com/n9n/apl (also a shout out to the creator if theyre on here) I think I also saw a wasm target for gnu-apl somewhere (I believe from Dr. Sauermann), but my brain is starting to shut off for the day... On Thu, Jun 27, 2019 at 3:25 PM Rowan Cannaday <cannad...@gmail.com> wrote: > @Alexey > > I actually floated this idea to the creator of "April" (an APL subset that > compiles to common lisp). I'll link the ticket below, but his response was > as follows: > > "JS is not a very good language for implementing APL because it has no > true multidimensional arrays; only nested vectors. There's also no support > for array displacement, no native complex numbers and some other > mathematical deficiencies. You could use special classes to fill some of > the gaps, write something that behaves like a multidimensional array, etc., > but performance will suffer." > > He might even be on this mailing list, if so shout out to another > interesting prj. > > https://github.com/phantomics/april/issues/4 > > > > On Thu, Jun 27, 2019 at 3:13 PM Alexey Veretennikov <txm.four...@gmail.com> > wrote: > >> Need JavaScript/Node.js bindigs then :) >> >> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> writes: >> >> > sure. But I would bet that today the number of python users is at least >> > two magnitudes greater >> > than the number of Pascal users (not counting those who have ceased to >> > exist since Pascal >> > was invented). >> > >> > >> > On 6/27/19 5:37 PM, enz...@gmx.com wrote: >> >> a grand geocentric (aplcentric) point of view indeed - i'm pretty sure >> the >> >> number of pascal users is orders of magnitude greater then the number >> of apl >> >> programmers >> >> >> >> On Tue, 18 Jun 2019 22:10:20 +0200 >> >> Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: >> >> >> >>> Hi, >> >>> >> >>> I believe that extending some language X with an interface to APL >> makes only >> >>> sense if: >> >>> >> >>> 1. language X is popular or at least is gaining popularity, and >> >>> 2. (GNU-) APL can provide an advantage in an area where language X is >> weak. >> >>> >> >>> According to >> http://statisticstimes.com/tech/top-computer-languages.php >> >>> and others, C/C++ and python are the most frequently used languages >> >>> today, with Erlang and Pascal having a far lower popularity (although >> >>> probably increasing for Erlang but decreasing for Pascal). >> >>> >> >>> Erlang and Python are both weak for large vectors and even weaker for >> >>> arrays with higher ranks. Reason is the linked list structure that >> they use >> >>> for vectors. >> >>> >> >>> Now to Pascal: it is not popular and is not weak in a particular area >> (being >> >>> weak in total does not count here). A further difficulty is the need >> to >> >>> declare >> >>> the data types of variables beforehand, which does not fit well to the >> >>> dynamic >> >>> typing of APL. Python and Erlang are both dynamically type and >> therefore >> >>> this problem does not exist for them. >> >>> >> >>> For that reason you are on your own when it comes to extending Pascal >> with >> >>> GNU APL. I will be glad to help you with technical advice how to do >> that and >> >>> how GNU APL works internally, but I would prefer not be involved in >> building >> >>> such an interface. >> >>> >> >>> Best regards, >> >>> Jürgen >> >>> >> >>> >> >>> >> >>> On 6/17/19 5:05 PM, enz...@gmx.com wrote: >> >>> >> >>> Hi Jürgen, >> >>> >> >>> Regarding fpc it depends on how they have built their C/C++ interface >> (if >> >>> they did). >> >>> The last time I used Pascal was the time when the only other >> programming >> >>> language on my platform was BASIC. So I am not really up-to-date with >> Pascal. >> >>> If you want to try it, then I can help with technical information >> that you >> >>> may need. >> >>> >> >>> this is the fpc/c/c++ interface guide that i have used for accessing >> c libs >> >>> from fpc >> >>> using c++ in fpc is a lot more complicated - i have 'working >> examples' from >> >>> the following guide (hello++.pas) but that is it for c++. >> >>> ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf >> >>> >> >>> This is an example of the c interface (how i can use 'c/libc' from >> fpc) >> >>> >> >>> this can be your first fpc program!! >> >>> >> >>> // sysconf.pas >> >>> program sysconf; // see man 3 syscon >> >>> uses ctypes; >> >>> const _SC_NPROCESSORS_ONLN = 84; // _SC_NPROCESSORS_ONLN The number of >> >>> processors currently online (available). >> >>> function sysconf(i: cint): clong; cdecl; external 'c'; // libc >> unistd.h >> >>> begin >> >>> writeln(sysconf(_SC_NPROCESSORS_ONLN), ' cpus : >> _SC_NPROCESSORS_ONLN'); >> >>> writeln; >> >>> end. >> >>> >> >>> to compile >> >>> fpc -XX sysconf.pas # -XX use smart linking to get smallest >> executable use >> >>> -gl for generating debug info for gdb and use lineinfo unit >> >>> >> >>> --- >> >>> >> >>> The shell approach is fine as long as your programs process a small >> to medium >> >>> amount of data. When the volume of data becomes huge then you have a >> lot of >> >>> overhead (formatting on the shell side and tokenization and >> optimization on >> >>> the >> >>> APL side) which can only be avoided by calling directly into the APL >> >>> interpreter. >> >>> >> >>> so far i've had no problem using cli apl from fpc (there are actually >> 2 ways >> >>> depending on if i want to 'trap' and use any apl standard output >> >>> (aprocess.execute) or not (sysutils.executeprocess) >> >>> >> >>> program fpcapl; >> >>> uses sysutils; >> >>> var l : ansistring; >> >>> begin >> >>> l := '-c "/usr/local/bin/apl --cfg"'; >> >>> //l := '-c "/apl/workspaces/script.apl"'; // script.apl file has #! >> >>> /usr/local/bin/apl --script -- then apl code >> >>> sysutils.executeprocess('/bin/bash', l); // apl standard output just >> >>> displayed >> >>> end. >> >>> >> >>> >> >>> >> >>> >> >> >> > >> > >> >> -- >> Br, >> /Alexey >> >>
