Re: [Bug-apl] jot dot jot dot?

[Jay Foad]

The APL2 manual (p35) says "The right operand of a dyadic operator is the
function or array to its immediate right." This is their way of saying that
operator expressions are left-associative. For example, in ∘.∘.+ the right
operand of the leftmost dot is ∘ (not ∘.+); so ∘.∘.+ is parsed as (∘.∘).+

The fact that operator-operand expressions are left-associative while
function-array expressions are right-associative is one of the beautiful
symmetries of APL!

Some more examples demonstrating the left-associativity of operator
expressions:

  ≡⊂⍣4⍣6⊢'hello'
25
  ≡(⊂⍣4)⍣6⊢'hello'
25
  ≡⊂⍣(4⍣6)⊢'hello'
DOMAIN ERROR

  ⎕FX'R←(F L G)Y' 'R←F Y'
L
  ⎕FX'R←(F R G)Y' 'R←G Y'
R
  + L × R - 33
¯33
  (+ L ×) R - 33
¯33
  + L (× R -) 33
33

Jay.

On 27 June 2016 at 12:37, Juergen Sauermann 
wrote:

> Hi,
>
> not sure. First of all, both IBM APL2 and GNU APL return the same result
> in Alex's  example:
>
> *  5 ∘.∘.+ 9*
> *14*
> *  5 (∘.∘).+ 9*
> *14*
> *  5 ∘.(∘.+) 9*
> *14*
>
> Then the IBM language reference says this (p. 35):
>
> *"For example, the function expression +.×/ is a reduction by a **+.×**
> inner product*
> *because the **×** binds as right operand to the array product operator
> (. ), and not as*
> *left operand to the slash operator (/). The + binds as left operand to
> the dot; then*
> *the resulting product binds to the slash as its left operand.*
>
> *+.×/  ←→ (+.× )/ not + .(**×** /)*
>
>
> *" *However, the binding strength resolves the ambiguity in the IBM
> example only
> because / is not a dyadic operator. In Alex's example the operator is
> dyadic, and one
> could either bind the middle ∘ to the left ∘ or the + to the middle ∘
> without violating
> the binding strengths. In this case I would argue that the "basic APL2
> evaluation rule"
> should be applied because ∘.+ can be evaluated (yielding a derived
> function) because all arguments
> of . are available before the . and ∘ on the left show up.
>
> What is missing in both the ISO standard and in the APL2 language
> reference is a
> statement about left-to-right or right-to-left associativity of APL
> operators. I personally
> would find it counter-intuitive if functions are evaluated left-to-right
> while operators are
> evaluated right-to-left.
>
> /// Jürgen
>
>
> On 06/27/2016 11:48 AM, Jay Foad wrote:
>
> So it looks like GNU APL parses ∘.∘.+ as ∘.(∘.+).
>
> IBM APL2 and Dyalog appear to parse it as (∘.∘).+.
>
> Jay.
>
> On 15 June 2016 at 04:05, Xiao-Yong Jin  wrote:
>
>> Hi Alex,
>>
>> It is correct.  You need nested vectors to see the effect.
>>
>> Try the following.
>>
>>   (⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2 3⍴⍳6)
>>
>> Best,
>> Xiao-Yong
>>
>> > On Jun 14, 2016, at 6:39 PM, Alex Weiner 
>> wrote:
>> >
>> > Hi Bug-APL,
>> >
>> > Surely this is not correct:
>> >
>> >  5∘.∘.+9
>> > 14
>> >
>> >
>> > I would expect a syntax error.
>> > If this is valid, then I stand corrected
>> >
>> > -Alex
>> >
>>
>>
>>
>
>

Re: [Bug-apl] Not a bug, need help coding search&replace on a vector

[Jay Foad]

On 23 June 2016 at 15:28, Xiao-Yong Jin  wrote:

>
> > On Jun 23, 2016, at 7:07 AM, Louis Chretien  wrote:
> >
> > R←{X} (A ⎕R B) Y
>
> The line on the title?  It’s not really the language syntax.  It’s their
> way to tell you that ⎕R is an operator that receives required left and
> right operands A and B, and creates a ambivalent function that applies on
> right argument Y, with optional left argument X.
>

Right, though you can use this exact syntax on line 0 of a defined
operator, e.g.

∇ R←{X} (A MyDefinedOperator B) Y
  R←A B Y
∇

Jay.

Re: [Bug-apl] Tab completion doesn't track )ERASE

[Juergen Sauermann]

  
  
Hi David,
  
  I have added a filter for unused and not localized names in the tab
  expansion, SVN 759.
  
  I am afraid there is no portable (in the sense that the ISO
  standard defines it) way to
  )ERASE a name from the symbol table.
  
  /// Jürgen
  
  

On 06/28/2016 08:37 AM, David B.
  Lamkins wrote:


  I see. I had assumed (incorrectly) that )ERASE and ⎕EX have the same effect.

IIUC, the names interned by any definition are available to tab completion until they are )ERASEd, even if they are no longer associated with an APL object in the workspace. I noticed that tab completion sees even names that have only ever been available as localized names in a function.

Is there a portable way to unintern a name from the symbol table? The ISO standard doesn't seem to specify whether 

  ⍎')system_command ...'

should be supported.



On Mon, Jun 27, 2016 at 01:58:07PM +0200, Juergen Sauermann wrote:

  
Hi David,

⎕EX only deletes the current-referent of a name (= the name at the
top of the )SI stack) but not its global-referent.

If you use )ERASE instead of ⎕EX then tab-completion will recognize this.

/// Jürgen


On 06/27/2016 07:05 AM, David B. Lamkins wrote:

Tab completion doesn't know that a symbol has been removed.

In the following,  is the tab character.

  ⎕fx 'foo'
foo
  f
  ⎕ex 'foo'
1
  ⎕nc 'foo'
0
  f
VALUE ERROR
  foo
  ^





  
  



  

Re: [Bug-apl] jot dot jot dot?

[Louis de Forcrand]

Operators are evaluated from left to right in Dyalog, NARS2000, and J at least. 
This seems logical:
+/{each} should parse as (+/){each}, not +(/{each}), and +/{rank}1 as 
(+/){rank}1, as "tacit" operators aren't supported in GNU APL or the standard 
(/{each} and /{rank}1 have no meaning).
The problem is that jot dot is not a usual operator since it is written to the 
left of its argument. I believe this is because it was originally perceived as 
similar to an inner product, but with no reduction, and jot was the "null 
function" (this comes from the original APL book). Inner products were written 
with the first function on top of the second, but to adapt this to terminals, a 
dot was instead placed between the two functions.
Thus °| became º.|
I would imagine jot dot should parse just like and inner product, except when 
the jot is read, an outer product is executed. So, as I see it (with * as 
times), °.°.* should parse as (°.°).*, just as +.*.* should parse as (+.*).* .
However, I don't see what (°.°) corresponds to.

It seems to me that APL2 parses it as 
°.(°.*) , in which case APL2 has some operators with a long left scope and 
others with a long right scope. Then you encounter problems such as °.*/; is 
that °.(*/) or (°.*)/ ?

My point is that I am almost sure that functions have a long right scope, and 
operators a long left scope; the exception here is jot dot, and I don't know 
what it has. To illustrate what Iverson thought, in J x (jot dot fun) y is 
written as x (fun/) y .

Louis

Sorry for the poor formatting!

> On 27 Jun 2016, at 13:37, Juergen Sauermann  
> wrote:
> 
> Hi,
> 
> not sure. First of all, both IBM APL2 and GNU APL return the same result in 
> Alex's  example:
> 
>   5 ∘.∘.+ 9
> 14
>   5 (∘.∘).+ 9
> 14
>   5 ∘.(∘.+) 9
> 14
> 
> Then the IBM language reference says this (p. 35):
> 
> "For example, the function expression +.×/ is a reduction by a +.×  inner 
> product
> because the × binds as right operand to the array product operator (.), and 
> not as
> left operand to the slash operator (/). The + binds as left operand to the 
> dot; then
> the resulting product binds to the slash as its left operand.
> 
> +.×/  ←→ (+.× )/ not +.(× /)
> "
> 
> However, the binding strength resolves the ambiguity in the IBM example only
> because / is not a dyadic operator. In Alex's example the operator is dyadic, 
> and one
> could either bind the middle ∘ to the left ∘ or the + to the middle ∘ without 
> violating
> the binding strengths. In this case I would argue that the "basic APL2 
> evaluation rule"
> should be applied because ∘.+ can be evaluated (yielding a derived function) 
> because all arguments
> of . are available before the . and ∘ on the left show up.
>  
> What is missing in both the ISO standard and in the APL2 language reference 
> is a
> statement about left-to-right or right-to-left associativity of APL 
> operators. I personally
> would find it counter-intuitive if functions are evaluated left-to-right 
> while operators are
> evaluated right-to-left.
> 
> /// Jürgen
> 
> 
>> On 06/27/2016 11:48 AM, Jay Foad wrote:
>> So it looks like GNU APL parses ∘.∘.+ as ∘.(∘.+).
>> 
>> IBM APL2 and Dyalog appear to parse it as (∘.∘).+.
>> 
>> Jay.
>> 
>> On 15 June 2016 at 04:05, Xiao-Yong Jin  wrote:
>>> Hi Alex,
>>> 
>>> It is correct.  You need nested vectors to see the effect.
>>> 
>>> Try the following.
>>> 
>>>   (⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2 3⍴⍳6)
>>> 
>>> Best,
>>> Xiao-Yong
>>> 
>>> > On Jun 14, 2016, at 6:39 PM, Alex Weiner  
>>> > wrote:
>>> >
>>> > Hi Bug-APL,
>>> >
>>> > Surely this is not correct:
>>> >
>>> >  5∘.∘.+9
>>> > 14
>>> >
>>> >
>>> > I would expect a syntax error.
>>> > If this is valid, then I stand corrected
>>> >
>>> > -Alex
>>> >
> 

Re: [Bug-apl] jot dot jot dot?

[Jay Foad]

I don't think that's true. Here's an example from IBM APL2 Workstation:

  (1 2)(3 4)∘.∘.*(5 6)(7 8)
SYNTAX ERROR
  (1 2)(3 4)∘.∘.*(5 6)(7 8)
  ^

  (1 2)(3 4)(∘.∘).*(5 6)(7 8)
SYNTAX ERROR
  (1 2)(3 4)(∘.∘).*(5 6)(7 8)
  ^

  (1 2)(3 4)∘.(∘.*)(5 6)(7 8)
  1  1 1   1
 32 64   128 256

  243  7292187  6561
 1024 4096   16384 65536

Jay.

On 28 June 2016 at 16:26, Louis de Forcrand  wrote:

> It seems to me that APL2 parses it as
> °.(°.*) , in which case APL2 has some operators with a long left scope and
> others with a long right scope.
>

Re: [Bug-apl] Tab completion doesn't track )ERASE

[David Lamkins]

Thank you.
On Jun 28, 2016 8:09 AM, "Juergen Sauermann" 
wrote:

> Hi David,
>
> I have added a filter for unused and not localized names in the tab
> expansion, *SVN 759*.
>
> I am afraid there is no portable (in the sense that the ISO standard
> defines it) way to
> )ERASE a name from the symbol table.
>
> /// Jürgen
>
>
> On 06/28/2016 08:37 AM, David B. Lamkins wrote:
>
> I see. I had assumed (incorrectly) that )ERASE and ⎕EX have the same effect.
>
> IIUC, the names interned by any definition are available to tab completion 
> until they are )ERASEd, even if they are no longer associated with an APL 
> object in the workspace. I noticed that tab completion sees even names that 
> have only ever been available as localized names in a function.
>
> Is there a portable way to unintern a name from the symbol table? The ISO 
> standard doesn't seem to specify whether
>
>   ⍎')system_command ...'
>
> should be supported.
>
>
>
> On Mon, Jun 27, 2016 at 01:58:07PM +0200, Juergen Sauermann wrote:
>
> Hi David,
>
> ⎕EX only deletes the current-referent of a name (= the name at the
> top of the )SI stack) but not its global-referent.
>
> If you use )ERASE instead of ⎕EX then tab-completion will recognize this.
>
> /// Jürgen
>
>
> On 06/27/2016 07:05 AM, David B. Lamkins wrote:
>
> Tab completion doesn't know that a symbol has been removed.
>
> In the following,  is the tab character.
>
>   ⎕fx 'foo'
> foo
>   f
>   ⎕ex 'foo'
> 1
>   ⎕nc 'foo'
> 0
>   f
> VALUE ERROR
>   foo
>   ^
>
>
>
>
>
>
>

Re: [Bug-apl] jot dot jot dot?

[Xiao-Yong Jin]

I agree that in terms of the . operator, f.g.h should parse as (f.g).h.  It 
seems more logical to treat ∘ as a function so ∘.∘.f parse as (∘.∘).f too, but 
perhaps APL2 is doing something special with ∘. as one operator?

Here is a session with Dyalog,
  ⎕ML←2
  ⍝ Some high dimensional mind twist
  (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
  3.00060006J30.0060006 2.00080012J20.0080012
  (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
  3.00060006J30.0060006 2.00080012J20.0080012
  (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
  3.0006J30.006 6.0006J60.006
  ⍝ ∘.∘ completely baffled me
  1∘.∘.+2
3
  1∘.∘.+2 3
SYNTAX ERROR: The function does not take a left argument
  1∘.∘.+2 3
 ∧
  ∘.∘.+2 3
SYNTAX ERROR: The function requires a left argument
  ∘.∘.+2 3
 ∧

Unfortunately, gnu apl fails at this f.g.h fun
  (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
   ^ ^
  )reset
  (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
   ^ ^
  )reset
  (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
LENGTH ERROR
μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
   ^ ^

Best,
Xiao-Yong

> On Jun 28, 2016, at 10:26 AM, Louis de Forcrand  wrote:
> 
> Operators are evaluated from left to right in Dyalog, NARS2000, and J at 
> least. This seems logical:
> +/{each} should parse as (+/){each}, not +(/{each}), and +/{rank}1 as 
> (+/){rank}1, as "tacit" operators aren't supported in GNU APL or the standard 
> (/{each} and /{rank}1 have no meaning).
> The problem is that jot dot is not a usual operator since it is written to 
> the left of its argument. I believe this is because it was originally 
> perceived as similar to an inner product, but with no reduction, and jot was 
> the "null function" (this comes from the original APL book). Inner products 
> were written with the first function on top of the second, but to adapt this 
> to terminals, a dot was instead placed between the two functions.
> Thus °| became º.|
> I would imagine jot dot should parse just like and inner product, except when 
> the jot is read, an outer product is executed. So, as I see it (with * as 
> times), °.°.* should parse as (°.°).*, just as +.*.* should parse as (+.*).* .
> However, I don't see what (°.°) corresponds to.
> 
> It seems to me that APL2 parses it as 
> °.(°.*) , in which case APL2 has some operators with a long left scope and 
> others with a long right scope. Then you encounter problems such as °.*/; is 
> that °.(*/) or (°.*)/ ?
> 
> My point is that I am almost sure that functions have a long right scope, and 
> operators a long left scope; the exception here is jot dot, and I don't know 
> what it has. To illustrate what Iverson thought, in J x (jot dot fun) y is 
> written as x (fun/) y .
> 
> Louis
> 
> Sorry for the poor formatting!
> 
> On 27 Jun 2016, at 13:37, Juergen Sauermann  
> wrote:
> 
>> Hi,
>> 
>> not sure. First of all, both IBM APL2 and GNU APL return the same result in 
>> Alex's  example:
>> 
>>   5 ∘.∘.+ 9
>> 14
>>   5 (∘.∘).+ 9
>> 14
>>   5 ∘.(∘.+) 9
>> 14
>> 
>> Then the IBM language reference says this (p. 35):
>> 
>> "For example, the function expression +.×/ is a reduction by a +.×  inner 
>> product
>> because the × binds as right operand to the array product operator (.), and 
>> not as
>> left operand to the slash operator (/). The + binds as left operand to the 
>> dot; then
>> the resulting product binds to the slash as its left operand.
>> 
>> +.×/  ←→ (+.× )/ not +.(× /)
>> "
>> 
>> However, the binding strength resolves the ambiguity in the IBM example only
>> because / is not a dyadic operator. In Alex's example the operator is 
>> dyadic, and one
>> could either bind the middle ∘ to the left ∘ or the + to the middle ∘ 
>> without violating
>> the binding strengths. In this case I would argue that the "basic APL2 
>> evaluation rule"
>> should be applied because ∘.+ can be evaluated (yielding a derived function) 
>> because all arguments
>> of . are available before the . and ∘ on the left show up.
>>  
>> What is missing in both the ISO standard and in the APL2 language reference 
>> is a
>> statement about left-to-right or right-to-left associativity of APL 
>> operators. I personally
>> would find it counter-intuitive if functions are evaluated left-to-right 
>> while operators are
>> evaluated right-to-left.
>> 
>> /// Jürgen
>> 
>> 
>> On 06/27/2016 11:48 AM, Jay Foad wrote:
>>> So it looks like GNU APL parses ∘.∘.+ as ∘.(∘.+).
>>> 
>>> IBM APL2 and Dyalog appear to parse it as (∘.∘).+.
>>> 
>>> Jay.
>>> 
>>> On 15 June 2016 at 04:05, Xiao-Yong Jin  wrote:
>>> Hi Alex,
>>> 
>>> It is correct.  You need nested vectors to see the effect.
>>> 
>>> Try the following.
>>> 
>>>   (⊂[2]2 3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺

Re: [Bug-apl] jot dot jot dot?

[Juergen Sauermann]

  
  
Hi,
  
  thanks, fixed in SVN 620.
  
  /// Jürgen
  
  

On 06/28/2016 01:23 PM, Jay Foad wrote:


  The APL2 manual (p35) says "The right operand of a
dyadic operator is the function or array to its immediate
right." This is their way of saying that operator expressions
are left-associative. For example, in ∘.∘.+ the right operand of
the leftmost dot is ∘ (not ∘.+); so ∘.∘.+ is parsed as (∘.∘).+


The fact that operator-operand expressions are
  left-associative while function-array expressions are
  right-associative is one of the beautiful symmetries of APL!


Some more examples demonstrating the left-associativity of
  operator expressions:



        ≡⊂⍣4⍣6⊢'hello'
  25
        ≡(⊂⍣4)⍣6⊢'hello'
  25
        ≡⊂⍣(4⍣6)⊢'hello'
  DOMAIN ERROR




        ⎕FX'R←(F L G)Y' 'R←F Y'
  L
        ⎕FX'R←(F R G)Y' 'R←G Y'
  R
        + L × R - 33
  ¯33
        (+ L ×) R - 33
  ¯33
        + L (× R -) 33
  33



Jay.
  
  
On 27 June 2016 at 12:37, Juergen
  Sauermann 
  wrote:
  
 Hi,

not sure. First of all, both IBM APL2 and GNU APL return
the same result in Alex's  example:

  5
∘.∘.+ 9
  14
    5 (∘.∘).+ 9
  14
    5 ∘.(∘.+) 9
  14
  
Then the IBM language reference says this (p. 35):

"For example, the function _expression_ +.×/ is
  a reduction by a +.×  
  inner product
because the × binds as right
  operand to the array product operator (. ),
  and not as
left operand to the slash operator (/).
  The +
  binds as left operand to the dot; then
the resulting product binds to the slash as its
  left operand.

+.×/ 
  ←→ (+.×
)/ not + .(×
/)
"
  
However, the binding strength resolves the ambiguity
in the IBM example only
because /
is not a dyadic operator. In Alex's example the operator
is dyadic, and one
could either bind the middle ∘ to the left ∘ or the + to
the middle ∘ without violating
the binding strengths. In this case I would argue that
the "basic APL2 evaluation rule"
should be applied because ∘.+ can be evaluated
(yielding a derived function) because all arguments
of . are available before the . and ∘ on the left show
up.
 
What is missing in both the ISO standard and in the APL2
language reference is a
statement about left-to-right or right-to-left
associativity of APL operators. I personally
would find it counter-intuitive if functions are
evaluated left-to-right while operators are
evaluated right-to-left.

/// Jürgen


  
  

  On 06/27/2016 11:48 AM, Jay Foad wrote:
  
  
So it looks like GNU APL parses ∘.∘.+
  as ∘.(∘.+).
  
  
  IBM APL2 and Dyalog appear to parse it as
(∘.∘).+.
  
  
  Jay.


  On 15 June 2016 at 04:05,
Xiao-Yong Jin 
wrote:
Hi Alex,
  
  It is correct.  You need nested vectors to see
  the effect.
  
  Try the following.
  
        (⊂[2]2
  3⍴⍳6)∘.{⍺∘.{⍺+⍵⊣⎕←⍺,'I',⍵}⍵⊣⎕←⍺,'O',⍵}(⊂[2]10×2
  3⍴⍳6)
  
  Best,
  Xiao-Yong
  

  >

[Bug-apl] APL Package Manager

[David B. Lamkins]

https://github.com/TieDyedDevil/apl-pkg

Here's news for those of you interested in the APL Package Manager:

Changes introduced by GNU APL svn r740+ broke the package manager due to my 
inadvertent use of some code that was not standard-compliant but still valid in 
GNU APL up through svn r739.

I've backported fixes from my development branch into the master branch and 
have also published a 0.3.1 release with the ammended code.

Now the master branch, the percy branch and the 0.3.1 release all work as 
designed with the current GNU APL svn version.

I do *not* provide support for the packaged GNU APL 1.5 release. Note that 
Jüergen recommends building GNU APL from the head of the svn tree; the packaged 
release is mainly for trial purposes.

If you're interested in tracking the current development version of the package 
manager, please run the percy branch from the git repo. The percy branch has a 
number of new features, but the main feature -- versioned dependencies -- is 
not yet available for use. See doc/CHANGES.md for additional details.

Re: [Bug-apl] jot dot jot dot?

[Louis de Forcrand]

The reason Dyalog is doing weird stuff with the jot is that it uses jot to bind 
left or right arguments (1 jot + = increment) AND for composition in its tacit 
style. It must have very complicated parsing rules.

What I would suggest is:
All operators have a long left scope, except jot dot, which takes as its right 
(and only) argument the whole chain of jots and dots to its right up to and 
including the first function:

jot dot jot dot jot dot + / each
would parse as
((jot dot (jot dot ( jot dot +))) /) each

This would produce maximum compatibility, since (jot dot jot) doesn't mean 
anything according to the standard anyway, and APL2 clearly states that
jot dot + / 
is
(jot dot +)/
not
jot dot (+/) .

Louis

> On 28 Jun 2016, at 18:20, Xiao-Yong Jin  wrote:
> 
> I agree that in terms of the . operator, f.g.h should parse as (f.g).h.  It 
> seems more logical to treat ∘ as a function so ∘.∘.f parse as (∘.∘).f too, 
> but perhaps APL2 is doing something special with ∘. as one operator?
> 
> Here is a session with Dyalog,
>  ⎕ML←2
>  ⍝ Some high dimensional mind twist
>  (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
>  3.00060006J30.0060006 2.00080012J20.0080012
>  (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
>  3.00060006J30.0060006 2.00080012J20.0080012
>  (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
>  3.0006J30.006 6.0006J60.006
>  ⍝ ∘.∘ completely baffled me
>  1∘.∘.+2
> 3
>  1∘.∘.+2 3
> SYNTAX ERROR: The function does not take a left argument
>  1∘.∘.+2 3
> ∧
>  ∘.∘.+2 3
> SYNTAX ERROR: The function requires a left argument
>  ∘.∘.+2 3
> ∧
> 
> Unfortunately, gnu apl fails at this f.g.h fun
>  (⊂[1]⍳2 3)+.{⍺+⍵×.0001}.{⍺+⍵×0J1}⊂[1]10×⍳2 3
> LENGTH ERROR
> μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
>   ^ ^
>  )reset
>  (⊂[1]⍳2 3)(+.{⍺+⍵×.0001}).{⍺+⍵×0J1}⊂[1]10×⍳2 3
> LENGTH ERROR
> μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
>   ^ ^
>  )reset
>  (⊂[1]⍳2 3)+.({⍺+⍵×.0001}.{⍺+⍵×0J1})⊂[1]10×⍳2 3
> LENGTH ERROR
> μ-Z__A_LO_INNER_RO_B[5]  (μ-IA μ-IB)←⊃μ-I[μ-N]
>   ^ ^
> 
> Best,
> Xiao-Yong
> 
>> On Jun 28, 2016, at 10:26 AM, Louis de Forcrand  wrote:
>> 
>> Operators are evaluated from left to right in Dyalog, NARS2000, and J at 
>> least. This seems logical:
>> +/{each} should parse as (+/){each}, not +(/{each}), and +/{rank}1 as 
>> (+/){rank}1, as "tacit" operators aren't supported in GNU APL or the 
>> standard (/{each} and /{rank}1 have no meaning).
>> The problem is that jot dot is not a usual operator since it is written to 
>> the left of its argument. I believe this is because it was originally 
>> perceived as similar to an inner product, but with no reduction, and jot was 
>> the "null function" (this comes from the original APL book). Inner products 
>> were written with the first function on top of the second, but to adapt this 
>> to terminals, a dot was instead placed between the two functions.
>> Thus °| became º.|
>> I would imagine jot dot should parse just like and inner product, except 
>> when the jot is read, an outer product is executed. So, as I see it (with * 
>> as times), °.°.* should parse as (°.°).*, just as +.*.* should parse as 
>> (+.*).* .
>> However, I don't see what (°.°) corresponds to.
>> 
>> It seems to me that APL2 parses it as 
>> °.(°.*) , in which case APL2 has some operators with a long left scope and 
>> others with a long right scope. Then you encounter problems such as °.*/; is 
>> that °.(*/) or (°.*)/ ?
>> 
>> My point is that I am almost sure that functions have a long right scope, 
>> and operators a long left scope; the exception here is jot dot, and I don't 
>> know what it has. To illustrate what Iverson thought, in J x (jot dot fun) y 
>> is written as x (fun/) y .
>> 
>> Louis
>> 
>> Sorry for the poor formatting!
>> 
>>> On 27 Jun 2016, at 13:37, Juergen Sauermann  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> not sure. First of all, both IBM APL2 and GNU APL return the same result in 
>>> Alex's  example:
>>> 
>>>  5 ∘.∘.+ 9
>>> 14
>>>  5 (∘.∘).+ 9
>>> 14
>>>  5 ∘.(∘.+) 9
>>> 14
>>> 
>>> Then the IBM language reference says this (p. 35):
>>> 
>>> "For example, the function expression +.×/ is a reduction by a +.×  inner 
>>> product
>>> because the × binds as right operand to the array product operator (.), 
>>> and not as
>>> left operand to the slash operator (/). The + binds as left operand to the 
>>> dot; then
>>> the resulting product binds to the slash as its left operand.
>>> 
>>> +.×/  ←→ (+.× )/ not +.(× /)
>>> "
>>> 
>>> However, the binding strength resolves the ambiguity in the IBM example only
>>> because / is not a dyadic operator. In Alex's example the operator is 
>>> dyadic, and one
>>> could either bind the middle ∘ to the left ∘ or the + to the middle ∘ 
>>> without violating
>>> the binding strengths. In this case I would argue that the "basic APL2 
>>

[Bug-apl] Message has wrong SVN Version

[Blake McBride]

Why does it say "but is now being )LOADed with SVN version  755"?
Shouldn't it be 761?



  )load FormatFns
WARNING: this workspace was )SAVEd with SVN version  670
  but is now being )LOADed with SVN version  755
Expect problems, in particular when the )SI was not clear.
In case of problems, please try )COPY instead of )LOAD.
SAVED 2016-02-07 05:04:20 (GMT-6)


BUT


$ svn info
Path: .
Working Copy Root Path: /home/blake/Backup/gnu-apl.svn
URL: http://svn.savannah.gnu.org/svn/apl/trunk
Relative URL: ^/trunk
Repository Root: http://svn.savannah.gnu.org/svn/apl
Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
Revision: 761
Node Kind: directory
Schedule: normal
Last Changed Author: j_sauermann
Last Changed Rev: 761
Last Changed Date: 2016-06-28 13:20:42 -0500 (Tue, 28 Jun 2016)

[Bug-apl] No token

[Blake McBride]

  ∇
DEFN ERROR+
  ∇
  ^
  ⍫
No token

Re: [Bug-apl] Message has wrong SVN Version

[Blake McBride]

Presuming the 755 represents a hard-coded number that you set when the
loading is affected, perhaps the message can be changed to:

WARNING: this workspace was )SAVEd with SVN version  670
  but is now being )LOADed with SVN version greater than 755
...

This would avoid any confusion.

Thanks.

Blake

On Tue, Jun 28, 2016 at 9:40 PM, Blake McBride  wrote:

> Also:
>
> $ /usr/local/bin/apl --version
> BUILDTAG:
> -
> Project:GNU APL
> Version / SVN:  1.5 / 761
> Build Date: 2016-06-29 02:22:47 UTC
> Build OS:   Linux 3.13.0-37-generic x86_64
> config.status:  unknown configure options
>
>
>
> On Tue, Jun 28, 2016 at 9:34 PM, Blake McBride 
> wrote:
>
>> Why does it say "but is now being )LOADed with SVN version  755"?
>> Shouldn't it be 761?
>>
>>
>>
>>   )load FormatFns
>> WARNING: this workspace was )SAVEd with SVN version  670
>>   but is now being )LOADed with SVN version  755
>> Expect problems, in particular when the )SI was not clear.
>> In case of problems, please try )COPY instead of )LOAD.
>> SAVED 2016-02-07 05:04:20 (GMT-6)
>>
>>
>> BUT
>>
>>
>> $ svn info
>> Path: .
>> Working Copy Root Path: /home/blake/Backup/gnu-apl.svn
>> URL: http://svn.savannah.gnu.org/svn/apl/trunk
>> Relative URL: ^/trunk
>> Repository Root: http://svn.savannah.gnu.org/svn/apl
>> Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
>> Revision: 761
>> Node Kind: directory
>> Schedule: normal
>> Last Changed Author: j_sauermann
>> Last Changed Rev: 761
>> Last Changed Date: 2016-06-28 13:20:42 -0500 (Tue, 28 Jun 2016)
>>
>>
>

Re: [Bug-apl] Cloning Optimization

[Blake McBride]

Very nice.  Thanks!  This has been on my mind.


On Mon, Jun 27, 2016 at 8:35 AM, Juergen Sauermann <
juergen.sauerm...@t-online.de> wrote:

> Hi,
>
> coming back to an earlier discussion, I have optimized the cloning of
> APL values a little. *SVN 757*.
>
> /// Jürgen
>
>

Re: [Bug-apl] Message has wrong SVN Version

[Blake McBride]

Also:

$ /usr/local/bin/apl --version
BUILDTAG:
-
Project:GNU APL
Version / SVN:  1.5 / 761
Build Date: 2016-06-29 02:22:47 UTC
Build OS:   Linux 3.13.0-37-generic x86_64
config.status:  unknown configure options



On Tue, Jun 28, 2016 at 9:34 PM, Blake McBride  wrote:

> Why does it say "but is now being )LOADed with SVN version  755"?
> Shouldn't it be 761?
>
>
>
>   )load FormatFns
> WARNING: this workspace was )SAVEd with SVN version  670
>   but is now being )LOADed with SVN version  755
> Expect problems, in particular when the )SI was not clear.
> In case of problems, please try )COPY instead of )LOAD.
> SAVED 2016-02-07 05:04:20 (GMT-6)
>
>
> BUT
>
>
> $ svn info
> Path: .
> Working Copy Root Path: /home/blake/Backup/gnu-apl.svn
> URL: http://svn.savannah.gnu.org/svn/apl/trunk
> Relative URL: ^/trunk
> Repository Root: http://svn.savannah.gnu.org/svn/apl
> Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
> Revision: 761
> Node Kind: directory
> Schedule: normal
> Last Changed Author: j_sauermann
> Last Changed Rev: 761
> Last Changed Date: 2016-06-28 13:20:42 -0500 (Tue, 28 Jun 2016)
>
>

Re: [Bug-apl] Message has wrong SVN Version

[Xiao-Yong Jin]

That’s the version of the Archive.cc.  See
$ sed -n '10,11p' src/buildtag
ARCHIVE_SVNINFO=`svn info Archive.cc | grep "Last Changed Rev" \
 | awk -F : '{print $2;}'`

> On Jun 28, 2016, at 9:34 PM, Blake McBride  wrote:
> 
> Why does it say "but is now being )LOADed with SVN version  755"?  Shouldn't 
> it be 761?
> 
> 
> 
>   )load FormatFns
> WARNING: this workspace was )SAVEd with SVN version  670
>   but is now being )LOADed with SVN version  755
> Expect problems, in particular when the )SI was not clear.
> In case of problems, please try )COPY instead of )LOAD.
> SAVED 2016-02-07 05:04:20 (GMT-6)
> 
> 
> BUT
> 
> 
> $ svn info
> Path: .
> Working Copy Root Path: /home/blake/Backup/gnu-apl.svn
> URL: http://svn.savannah.gnu.org/svn/apl/trunk
> Relative URL: ^/trunk
> Repository Root: http://svn.savannah.gnu.org/svn/apl
> Repository UUID: bd74f7bd-1a55-4bac-9fab-68015b139e80
> Revision: 761
> Node Kind: directory
> Schedule: normal
> Last Changed Author: j_sauermann
> Last Changed Rev: 761
> Last Changed Date: 2016-06-28 13:20:42 -0500 (Tue, 28 Jun 2016)
>