Re: [Bug-apl] fpc/freepascal interface

[Dr . Jürgen Sauermann]

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.