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
