freepascal is as modern a language as it gets my friend - why you have a problem with it is beyond me - but to be honest not very professional of you now, is it, considering i run into more anti-apl then anti-freepascal programmers and i just wallop them all senseless
anyway - i have been running apl as a script in freepascal for years and it is the greatest combination of coding there is - no real need to use libapl.so/libapl.h anyway - right now it would be run as c code anyway as a cdecl extern. (but if you do have any c code that runs libapl.so/libapl.h with unquote or inner product or outer product - i would love it - can't find any on the internet - or any real usefull code to be honest) with the unquote function and ease of inner and outer product etc matrix functions - coupled with fpc being compiled and having complete control over processes https://www.freepascal.org/docs-html/current/fcl/process/tprocess.htm and threading and [trtl]tcriticalseciton and fpflock mutexes (there are a number of ways to perform parallal and threading programming and mutex on files and code sections) https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial https://www.freepascal.org/docs-html/rtl/system/trtlcriticalsection.html https://www.freepascal.org/docs-html/current/fcl/syncobjs/tcriticalsection.html and libcurl units, openssl units - and hundreds if not thousands more (okay maybe not thousands) ,,,,,, sorry - i gotta take a rest now ... can't get to excited ,,, doctors orders ,,, On Wed, 17 Jul 2019 12:30:05 +0200 Dr. Jürgen Sauermann <m...@xn--jrgen-sauermann-zvb.de> wrote: > 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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 <m...@xn--jrgen-sauermann-zvb.de> 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, enz...@gmx.com 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. > > > > > > > > >
