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