Re: [Bug-apl] Feature suggestion: multiple function arguments

[Juergen Sauermann]

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

On 03/16/2016 06:09 PM, Peter Teeson wrote:

Sorry but I have no knowledge of what you are referring to wrt the Lisp comments

Personally I think we have gone a bit overboard with the quad functions.
But be that as it may they are not really a part of the apl language per se are they?

What I am suggesting is a single apl symbol consuming 1 point in quad av.

That symbol could be used in any apl _expression_ because the parser would just
branch off to your implementation of whatever.

Not a library; not a framework; but a plugin that is aware of the interpreter environment
and is well behaved. 

As I recall we used to model language enhancements using apl itself.
But you don’t need a plugin for that.

Once we had it figured out we would implement it in assembly language.
And that was what we would have access to via the i-beam.

And for existing code (speeding up dot products which I worked on) we would test using
the i-beam feature as I recall.

Peter

On Mar 16, 2016, at 12:41 PM, David B. Lamkins <address@hidden> wrote:
On Wed, Mar 16, 2016 at 01:17:36PM +0800, Elias Mårtenson wrote:

  I'm not entirely sure why Quad-AV even needs to exist in a modern
  program? We should be able to use all of Unicode to name our functions.

Clearly quad-AV is necessary for compatibility with legacy APL code; as such, it'd be ill-advised to break that compatibility.

Of course