Re: [Bug-apl] fpc/freepascal interface

[Dr . Jürgen Sauermann]

Most of us are reaching the ends of our life cycles, so we should not lol too loudly. Iverson was born 9 years before Wirth, so he has all rights to leave first. By the same token, at the time when Pascal was invented, Iverson had 9 years more working experience. If I remember correctly (Pascal was a hot topic at that time) then Wirth never meant Pascal to be a programming language but rather a somewhat simplified syntax to teach compiler construction. I was only later when some people misunderstood it as a being programming language. Given the languages affordable at that time (BASIC and machine code without an assembler), the mistake is excusable, but we should learn from our mistakes and not perpetuate them. BR, Jürgen On 7/15/19 8:07 PM, enz...@gmx.com wrote: 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.