really since apl is older then pascal (excluding algol( i think you got it backwards with number of deceased
nicklaus wirth is still around what about iverson? lol On Thu, 27 Jun 2019 18:37:41 +0200 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > 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. > >> > >> > >> > >> > > >
