Hello Jürgen,
Why does your justification for not reporting AXIS ERROR's
apply to monadic functions like sign(+), first (↑), factorial
(!),not(∼), etc, but not their dyadic partners, add, pick, binomial and
with-out? For example,
a ← 3 3 ⍴ ⍳ 9 b ← 2 + a +[1] a1 2 34 5 67 8 9 a
+[1] bAXIS ERROR a+[1]b ^ ^Not that I am suggesting you do
it, the axis specification could be just as easily ignored for the add
function as the sign function. To the contrary, I believe sign, first,
factorial, not, and other monadic functions that do not support axis
specifications should also report AXIS ERROR's. I'm confident doing so
would benefit anyone trying to learn APL and those of us who
occasionally get confused about what is and is not supported by the
language.
Per your comments in item 3) of your email, I was able make
monadic primitives that do not support axis specifications report
SYNTAX_ERROR's if an axis-specification is applied to them. The only
wrinkle was that I had to add methods eval_XB, eval_ALXb, eval_LRXB
and eval_ALRXB to eval_XXX group of methods modified. And for
consistency with how the dyadic function axis specification errors are
reported, AXIS_ERROR should be used rather than SYNTAX_ERROR.
Regards,
On Wed, 2017-07-05 at 00:01 +0200, Juergen Sauermann wrote:
> Hi Fred,
>
>
>
> this is actually a language extension which has a deeper
> background.
>
>
>
> I define a language extension to be a (different) behaviour of
> the
> interpreter when
>
> the standard or the IBM language reference return an error.
> Sometimes extensions
>
> are introduced or adopted from other interpreters (for example ⍳1
> 2
> 3 taken from
>
> Dyalog) or because the language becomes more general.
>
>
>
> So what you see is a language extension and the reason is this.
>
>
>
> 1. GNU APL supports axis arguments for defined functions. This is
> so
> that you can
>
> write proper wrapper functions around APL primitives. Since
> defined
> functions can
>
> not be overloaded you need a way to write a wrapper that can
> emulate
> the optional
>
> axis argument of the wrapped apl primitive. I was always annoyed
> by
> not being able
>
> to write such wrappers, in particular for benchmarking purposes.
>
>
>
> 2. Since the axis argument is optional in all apl primitives that
> can have one, the axis
>
> is also optional in GNU APL defined functions. You can check for
> its
> presence with
>
> ⎕NC just like for optional left arguments.
>
>
>
> 3. Another concept in GNU APL is that there shall be as few
> differences as possible
>
> between primitive functions (including ⎕-functions) and defined
> functions. A consequence
>
> of that (which simplifies the parser a lot) is that also all
> primitive function can have
>
> an axis argument. The default behaviour in both cases is to
> ignore
> the axis argument.
>
> That is what you see for ↑[] but also for all other primitives
> that
> have no axis variant.
>
> You can change that by changing e.g.
>
>
>
> virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)
>
> { return eval_AB(A, B); }
>
>
>
> to:
>
>
>
> virtual Token eval_AXB(Value_P A, Value_P X, Value_P B)
>
>
> { SYNTAX_ERROR; }
>
>
>
>
>
> in all eval_XXX() functions declared in Function.hh
> that have an X (for axis) in their name. Since all functions
> are derived from this class it will change all primitives, but
>
> also all defined functions and operators. I personally would not
> do
> it, though.
>
>
>
> This language extension has been in GNU APL since almost day one.
> Therefore I
>
> cannot predict how often it is used (you can also do some dirty
> tricks with it). For
>
> that reason I believe it is better not to change it.
>
>
>
> Best Regards,
>
> Jürgen Sauermann
>
>
>
>
>
>
>
> On 07/04/2017 07:42 PM, Frederick Pitts
> wrote:
>
>
>
> > Hello Jürgen,
> >
> > The IBM 'APL2 Programming: Language Reference' suggests that
> > axis specification is not allowed with the first function in that
> > 'Figure 7. Functions and Operators That Allow Axis Specification',
> > page
> > 45, does not list 'First' by the '↑' symbol, whereas ravel,
> > catenate
> > and laminate are listed by the ',' symbol. The text under Figure 7
> > says
> > an AXIS ERROR occurs if a function or operator is not in the list.
> >
> > ISO/IEC 13751:2000(E)' contains 'Table 4: The Form Table',
> > pages 71-74, which claims to list all syntactic-units for which
> > evaluation sequences exist. The first function with axis
> > specification
> > does not appear in that table.
> >
> > Yet Gnu-APL allows
> >
> > ↑[ 2 ] 3 3 3 ⍳ 27
> > 1
> >
> > which is the first scalar in the ravel of the argument and the axis
> > specification is being ignored.
> >
> > Neither IBM or ISO specifications say that the first function
> > with axis specification is part of the language. I respectfully
> > submit
> > that Gnu-APL should report an attempt to use first function with
> > axis
> > specification as a syntax error.
> >
> > Regards,
> >
> > Fred
> >
> >
> >
> >
>
>
>
>
>
