Hi Jürgen: Thanks for your patient reply. I fully understand what your explanation and consequently the functionality provided.
Thank you so much for having made GNU APL… a major contribution to the APL community IMHO. respect…. Peter > On Mar 17, 2016, at 10:16 AM, Juergen Sauermann > <[email protected]> wrote: > > Hi Peter, > > almost. Except that you should not (and cannot, and need not) use the name ⌶ > but instead a normal, user-defined > APL name. > > The old ⌶ (and also ⎕-names) were old "hacks" to achieve a particular > purpose. But they have considerable downsides: > localization, parser impacts, and source code portability. > > If we instead use normal user-defined names for introducing new > functionalities then we have no parser impacts > and another platform can emulate that functionality via a normal user-defined > APL function (that may then call > specific functions in the other platform if available). > > In practice this makes life rather simple: > > 1. You write a shared library, say my_lib.so. > 2. contains the implementations those function header combinations that you > want to provide. > For example 'Z←A f B', 'Z←f B' and 'Z←f[X] B' > 3. You bind the my_lib.so to an user defined APL name, for example > 'my_lib.so' ⎕FX 'NEW_FUN' > > Step 3 has then created a new APL function NEW_FUN that, when called, > executes the code in mylib.so. > More precisely, when you call A NEW_FUN B in APL then the first implemented > header will be executed, > when you call NEW_FUN B then the second implemented header will be executed, > and with NEW_FUN[X] B > the third implemented header will be executed. > > All this still follows APL syntax and therefore the parser is not involved > (the magic happens below the parser level). > > Your shared library has full access to the APL Interpreter at two points in > time: when it is ⎕FX'ed and when the > ⎕FX'ed functionis called. That means it can (as a side effect) create, > modify, or delete APL variables, and you > can even overload or extend the implementation of every build-in APL function > (primitive functions, operators, > and ⎕-functions). > > I believe all this gives us a lot of freedom to extend GNU APL within the > boundaries of the APL syntax so that I > can't see why we would need to change that syntax of APL if all we want to do > is extend its functionality. > > /// Jürgen > > > On 03/16/2016 10:46 PM, Peter Teeson wrote: >> Hi Jürgen: >> Thanks for your patience… I am probably still somewhat stuck in my >> time-sharing mainframe days. >> >> If I understand you correctly you are saying that I can make a shared >> library let’s say with a name ⌶? >> I haven’t tried making such a named library/plugin - Is it going to be >> possible to name it using the ⌶ symbol? >> >> e.g. On my keyboard using MacAplAlt as a keyboard source it’s >> option+shift+1 i.e. Unicode U+2336 ( which is the APL functional symbol >> I-Beam). >> >> Presently GNU APL gives me "No token" when I enter it. >> >> Then ⎕FX it and have an apl expression X⌶Y and another apl expression Xº∘Y? >> >> Where the 2nd expression uses the GNU APL outer product implementation and >> the first uses my implementation? >> ( ⌶ could be an implementation of train, or fork, or whatever a programmer >> would like to try as a language extension >> or operator speedup or more advanced algorithm, or non homogenous arrays >> because nested is not elegant, etc). >> >> Suppose it is — will the GNU APL interpreter then recognize it as a token >> and >> "call into my library" passing me the environment? >> >> Which is what I would like it to do. This is the key question and idea that >> I am proposing ….. >> >> Which is why the ⌶ symbol gets parsed in the interpreter as though it were >> an apl symbol. >> In ⌶ will I have access to the stack, heap, and so on? >> >> Of course that’s dangerous and one must be well behaved but that’s true now >> isn’t it? >> >> On the mainframe you had to be at physically at one of the 3 or 4 operator >> consoles plus also be privileged. >> IOW like root on Unix systems - sudo s. Of course on single user systems >> being root is not really necessary. >> >> If so maybe your suggestion works for me because the expression X⌶Y looks >> aplish. >> >> Anyway that’s what I have been thinking / imagining….. >> respect… >> >> Peter >>> On Mar 16, 2016, at 1:36 PM, Juergen Sauermann >>> <[email protected] <mailto:[email protected]>> >>> wrote: >>> >>> Hi Peter, >>> >>> I am not quite getting why you would need the I-beam thing in the first >>> place (or why you would need to involve the parser). >>> >>> If all you want is to write something in assembler (and then call it from >>> APL), then >>> >>> - Pick a suitable user-defined name for it, >>> - Put the assembler (or C or FORTRAN or whatever) into a shared library, >>> - ⎕FX the shared library under the chosen name >>> >>> From then on a call to the name will call the assembler code, passing the >>> arguments >>> given to the assembler code and it will return the result produced by the >>> assembler code. >>> >>> No need for new ⎕AV symbols or ⎕-names or I-beams or such. >>> >>> That IS a plugin in the form of a shared libraries. Many plugins are build >>> like this these days. >>> >>> And it works already! >>> >>> /// Jürgen >> >
