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

Hi, if I look at C++ then the standard is equally restrictive when it comes to the source code: "The basic source character set consists of 96 characters: the space character, the control characters repre- senting horizontal tab, vertical tab, form feed, a

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

Hi Elias: If we consider other programming languages and the size of their vocabularies vs the number of apl symbols, 256 seem to be enough for now. (and if we add in the plethora of system functions, variables and commands which have been added on willy nilly … well ….) We tend not to think in

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

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

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

Hi Elias, this is quite feasible technically. What I don't like, though is the incompatibility that it creates for the source code. Suppose I write a function Z←AؠB. Who else except myself can decipher what it is supposed to mean? I strongly believe that restriction names to almost only ASCII

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

Hi Elias, ... On 03/17/2016 05:13 PM, Elias Mårtenson wrote: On 17 March 2016 at 23:58, Juergen Sauermann wrote: if I look at C++

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

On Thu, Mar 17, 2016 at 10:51:11AM +0800, Elias Mårtenson wrote: >On 17 March 2016 at 00:41, David B. Lamkins <[1]da...@lamkins.net> >wrote: > > I'm not sure what you mean by this. Were we to follow the model of > Lisp's macroexpansion, the expander would simply be an APL program

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

On Wed, Mar 16, 2016 at 01:17:36PM +0800, Elias Mårtenson wrote: >On 16 March 2016 at 09:23, David B. Lamkins <[1]da...@lamkins.net> >wrote: > > On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote: > > > The lexical rewriter could be a plugin, but it could also be a

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

Hi, I believe a *⎕FX* wrapper would be a much simpler solution. Say a function *Z←∆FX**B* which reads your function text *B* (containing non-standard APL syntax) and converts it to some reasonable *B1 *which contains the standard syntax. Finally: *Z←⎕FX B1*. /// Jürgen On 03/17/2016 04:43

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

On 17 March 2016 at 22:16, Juergen Sauermann wrote: > 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. > What are yo

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

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 con

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

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

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

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 na

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

On 17 March 2016 at 00:41, David B. Lamkins wrote: I'm not sure what you mean by this. Were we to follow the model of Lisp's > macroexpansion, the expander would simply be an APL program that reads some > program text -- possibly but not necessarily containing local syntax > extensions -- and rew

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

On 18 March 2016 at 22:07, Juergen Sauermann wrote: 1. every user can define them differently, > 2. we cannot use them for system purposes because we don't know if they > conflict with some user's choice, and > 3 chaos will ensue > I guess we'll have to agree to disagree on this one. These are c

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

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 su

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

On 17 March 2016 at 23:58, Juergen Sauermann wrote: if I look at C++ then the standard is equally restrictive when it comes to > the source code: > True, but most modern (and some old ones) languages do support it. Including Java, Javascript, Lisp, C#, Go, Haskell and R, for example. > I canno

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

P.S. Just as a point of interest the I-beam is documented as an apl symbol in the APL2 Language Reference Page 473 but without a definition or page reference. P.P.S. Dyalog also has it as part of the apl character set and it is defined in their implementation. P.P.P.S. I could not find anything i

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

On 17 March 2016 at 22:46, Juergen Sauermann wrote: > Hi Elias, > > this is quite feasible technically. What I don't like, though is the > incompatibility > that it creates for the source code. > > Suppose I write a function Z←AؠB. Who else except myself can decipher > what it is supposed to mean

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

On 16 March 2016 at 09:23, David B. Lamkins wrote: > On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote: > > The lexical rewriter could be a plugin, but it could also be an APL > function. Imagine being able to assign an APL function to > quad-SOMETHINGOROTHER to define your own l

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

Maybe David is thinking along similar lines to my proposal in this thread? What would be wrong with implementing in quadAV a single overstrike (e.g. i-beam <=> overstrike of encode decode) which when used in an apl expression takes you off to your implementation of e.g. a faster inner or outer

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

On Tue, Mar 15, 2016 at 11:35:59AM +0800, Elias Mårtenson wrote: >I was thinking of something similar, but the problem is that creating a >plugin API that lets you implement trains is incredibly difficult, >since you need to hook deep into the parser. > >As for more simple extensio

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

Hi Peter, I would say that we have such a mechanism already in GNU APL, namely native functions. With the current SVN you can even override built-in functions and maybe (never tried, though) introduce new APL characters/symbols. One can i

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

Hi Elias, not quite. Both APL2 and GNU APL can bind an operator to its left argument with (). Neither APL2 nor GNU APL can bind a function to its left argument with (). The difference comes because APL2 binds operator / to its left

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

On 15 Mar 2016 23:56, "Juergen Sauermann" wrote: > > And the syntax error is a mere consequence of / being a function in the example (you > cannot bind a function to its left argument with (). I know GNU APL can't do that, but apparently APL2 can? Is that true? Regards, Elias

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

Hi, maybe, maybe not. it seems like in APL2, / and friends (⌿ \ and ⍀) are always operators. In GNU APL / and friends are operators if their left argument is a function, and functions if their left argument is a value.

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

On 15 March 2016 at 22:47, Jay Foad wrote: > On 15 March 2016 at 13:24, Elias Mårtenson wrote: > > On 15 March 2016 at 21:14, Jay Foad wrote: > >> > >> 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4 > >> 3 3 3 4 4 4 > > > > Are you saying that (1 2 /)¨ 3 4 is syntactically correct in

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

On 15 March 2016 at 13:24, Elias Mårtenson wrote: > On 15 March 2016 at 21:14, Jay Foad wrote: >> >> 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4 >> 3 3 3 4 4 4 > > Are you saying that (1 2 /)¨ 3 4 is syntactically correct in APL2? Yes. / is an operator, so 1 2/ is a derived function

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

On Mon, Mar 14, 2016 at 2:03 PM, Juergen Sauermann wrote: > Consider this: > > 1 (+//) 1 2 3 4 > 1 2 3 4 FWIW, Dyalog returns the same, but it certainly does something weird I don't understand here. It treats it as an operator even when it says it is a function: f←/ ⎕NC'f' 3

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

On 15 March 2016 at 21:14, Jay Foad wrote: > 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4 > 3 3 3 4 4 4 > Are you saying that (1 2 /)¨ 3 4 is syntactically correct in APL2? If so, there is an incompatibility here since GNU APL gives SYNTAX ERROR on that.

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

In APL2 this is not a problem, because / et al are always operators: 1 2 /¨ 3 4 ⍝ in APL2 this parses as (1 2 /)¨ 3 4 3 3 3 4 4 4 1 2 /¨ 3 4 ⍝ in GNU APL this parses as 1 2 (/¨) 3 4 3 4 4 Jay. On 14 March 2016 at 13:03, Juergen Sauermann wrote: > Hi Kacper, > > yes. The tricky

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

I was thinking of something similar, but the problem is that creating a plugin API that lets you implement trains is incredibly difficult, since you need to hook deep into the parser. As for more simple extensions, we already have almost all that is needed in the plugin API, with the exception of

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

Hi all: The gist of my suggestion is Why not have a Plugin API? Is there any interest is such an idea? I strongly support Juergen’s position that GNU APL remain an implementation of the ISO Standard. And that the IBM APL2 implementation is one that it makes sense to use as a comparison. This i

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

Although I personally like tacit style, I agree that they shouldn't make their way into the main branch. It could be interesting to see them added to a fork (heh) of GNU APL however. Alexey: As to the lack of APL symbols in J, I sometimes miss the nice symbols present in APL. J thus loses some "ha

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

Hi, Dyalog APL returned exactly this: 1 (+//) 1 2 3 4 1 2 3 4 Juergen Sauermann writes: > Hi Kacper, > > yes. The tricky case is when it cannot be decided if g is an operator or not. > > Consider this: > > 1 (+//) 1 2 3 4 > 1 2 3 4 > > We get the same result in GNU APL and IBM APL2. No

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

Hi Kacper, yes. The tricky case is when it cannot be decided if g is an operator or not. Consider this:   1 (+//) 1 2 3 4 1 2 3 4 We get the same result in GNU APL and IBM APL2. No idea what Dyalog

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

On Sun, Mar 13, 2016 at 6:20 PM, Juergen Sauermann wrote: > it actually does create conflicts. > > In IBM APL2 and in GNU APL, the expression > > ⍺ (f g h) ⍵ > > gives a 3 item vector with the items being ⍺, (f g h), and ⍵. > In Dyalog APL it gives (quote): > > (⍺ f ⍵) g (⍺ h ⍵) ⍝ dyadic (fgh) for

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

Hi, Ah I see if it conflicts when probably there is no way to introduce it. Thanks for digging into it! Juergen Sauermann writes: > Hi Alexey, > > it actually does create conflicts. > > In IBM APL2 and in GNU APL, the expression > > ⍺ (f g h) ⍵ > > gives a 3 item vector with the items being ⍺,

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

Hi Alexey, it actually does create conflicts. In IBM APL2 and in GNU APL, the _expression_ ⍺ (f g h) ⍵ gives a 3 item vector with the items being ⍺, (f g h), and ⍵. In Dyalog APL it gives (quote): (⍺ f ⍵) g (⍺

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

Hi, At first I also thought like this, but since it is already part of J language and Dyalog APL, and it is not something alien but rather invented by Ken Iverson himself, I believe it could be a part of language if it does not produce conflicts. >From what I understood the general idea is to ha

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

Hi, after looking at the examples in the Dyalog  APL Programmer's Guide, I don't think that forks and trains are something that should be added to GNU APL. In my opinion, one of the strengths of APL is its syntactic simplicity,

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

Thanks for the info! I've watched the Morten Kronberg's talk at Google(available on youtube) and he described how Ken Iverson got to the idea of forks. Only after this description of the roots of it I finally got the idea; I think it is great what forks ended up in the Dyalog APL since for me pers

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

FYI Dyalog version 14 has forks. You can try it at tryapl.org: http://tryapl.org/?a=%28+%u233F%F7%u2262%291%202%203%204&run Jay. On 5 March 2016 at 17:17, Louis de Forcrand wrote: > To add to the confusion, while > ( {+⌿ ÷ ≢} y) ≡ ( +⌿y) ÷ ≢y > (x {+⌿ ÷ ≢} y) ≡ (x+⌿y) ÷ x≢y > whatever that doe

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

To add to the confusion, while ( {+⌿ ÷ ≢} y) ≡ ( +⌿y) ÷ ≢y (x {+⌿ ÷ ≢} y) ≡ (x+⌿y) ÷ x≢y whatever that does. I completely agree, it’s quite obscure, especially if one is not accustomed to tacit definition. This by the way is a fork, and is basically a way to avoid parentheses. M

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

On 5 March 2016 at 23:28, Louis de Forcrand wrote: > That would be a great idea. However, it would indeed take not only quite a > bit of > time to set up, but would also need constant checking to make sure the > updates > in the main branch don’t conflict with additions. > While I just said that

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

That would be a great idea. However, it would indeed take not only quite a bit of time to set up, but would also need constant checking to make sure the updates in the main branch don’t conflict with additions. While I just said that I believe the main branch should probably concentrate on the sta

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

On 5 March 2016 at 23:09, Louis de Forcrand wrote: > While talking about features to add, instead of introducing a new function > header > style, IMHO a new local assignment function would be more useful. > For example, instead of typing > ∇Z←X F Y;A;B;C > to declare local variables, instead one

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

Then again, I feel the goal of GNU APL is really to implement a complete, sturdy, and (eventually) fast version of the standard. If some extensions are implemented, then why not implement all of them? If Jürgen prefers to polish off an exact copy of the standard before adding features, then let’

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

While talking about features to add, instead of introducing a new function header style, IMHO a new local assignment function would be more useful. For example, instead of typing ∇Z←X F Y;A;B;C to declare local variables, instead one would simply type ∇Z←X F Y and then assign varia

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

On 5 March 2016 at 19:29, Juergen Sauermann wrote: IMHO a language does not get any better if it provides > different syntactic constructs for (almost) the same thing. The complexity > of the > language is being increased without a noticeable benefit. I would also > claim > that the best language

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

Hi, I believe what in this particular case the syntaxic sugar makes sense since the original way of doing it (explicitely introducing local variables and using destructive bind) is a drawback rather than benefit, and looks like was blindly following the concept of having only 2 arguments of a func

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

Hi Alexey, as Christian has pointed out, the IBM APL2 equivalent of Dyalog's ∇multi(a1 a2 a3) is: ∇multi a (a1 a2 a3)←a IMHO a language does not get any better if it provides different syntactic constructs

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

You can also use something like this ∇multi a;a1;a2;a3 [1] (a1 a2 a3)←a [2] ⍕a1 [3] ⍕a2 [4] ⍕a3 [5] ∇ multi 3 5 7 3 5 7 I think that implementing this "a la Dyalog" way is possible but would not be trivial source changes. Xtian. On 2016-03-03 17:17, Alexey Veretennikov wrote: Hi,

[Bug-apl] Feature suggestion: multiple function arguments

Hi, In GNU APL in order to supply several (>2) arguments to the function I have to write something like this: ∇multi a;a1;a2;a3 a1←a[1] a2←a[2] a3←a[3] ⍕a1 ⍕a2 ⍕a3 In Dyalog APL I can just write ∇multi(a1 a2 a3) ⍕a1 ⍕a2 ⍕a3 The same syntax in GNU APL lead to an errer in function header. Can we