Re: [Bug-apl] fpc/freepascal interface

[enztec]

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