Re: [Bug-apl] fpc/freepascal interface

[Rowan Cannaday]

@Alexey

I actually floated this idea to the creator of "April" (an APL subset that compiles to common lisp). I'll link the ticket below, but his response was as follows:

"JS is not a very good language for implementing APL because it has no true multidimensional arrays; only nested vectors. There's also no support for array displacement, no native complex numbers and some other mathematical deficiencies. You could use special classes to fill some of the gaps, write something that behaves like a multidimensional array, etc., but performance will suffer."

He might even be on this mailing list, if so shout out to another interesting prj.

https://github.com/phantomics/april/issues/4

On Thu, Jun 27, 2019 at 3:13 PM Alexey Veretennikov <address@hidden> wrote:

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