Hi,
just for the sake of completeness regarding GNU APL and _javascript_
(which I suppose was meant as a joke in
the first place): we have that already in GNU APL 1.8.
If you look below directory websock resp. websock/server
then you will find wsocxk.js
which is an interface from _javascript_ into GNU APL (based on node.js).
Not as elegant as
the interfaces fort other languages, but good enough to run the try-GNU-APL
web page:
http://juergen-sauermann.de/try-GNU-APL
Best Regards,
Jürgen
On 6/27/19 9:29 PM, Rowan Cannaday
wrote:
Almost forgot, there is also this, but some of the design
decisions lead me to believe it aims to solve some of the
perceived shortcomings of APL (IO set to 0 for example),
than maybe a faithful implementation, but still an
interesting project worth taking a look at.
https://gitlab.com/n9n/apl
(also a shout out to the creator if theyre on here)
I think I also saw a wasm target for gnu-apl somewhere (I
believe from Dr. Sauermann), but my brain is starting to shut
off for the day...
On Thu, Jun 27, 2019 at 3:25
PM Rowan Cannaday < address@hidden> wrote:
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
|