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, address@hidden 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.