Re: [Bug-apl] fpc/freepascal interface

[Alexey Veretennikov]

Need JavaScript/Node.js bindigs then :)

Dr. Jürgen Sauermann <address@hidden> writes:

> 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.
>>>
>>>
>>>
>>>
>>
>
>

-- 
Br,
/Alexey