Hi Fred,
my definiton of APL2 compliance is that a program that runs on
APL2 should ideally
run on GNU APL as well. But not the other way around.
I have added a chapter 3.14 to mention optional axis arguments for
APL
primitives. SVN 979.
Best Regards,
Jürgen
On 07/05/2017 02:42 AM, Frederick Pitts
wrote:
Jürgen,
Not to issue AXIS ERROR's on primitive functions where IBM
APL2 does seems to be a fairly large deviation from Gnu-APL's
claim to be IBM APL2 compliant. Yes, having the ability to use
axis specifications with defined functions is a desirable
extension to the language as long as the feature does not
interfere with the base language. Breaking syntax checking looks
like interference. With defined functions, the person using the
function is probably the person who wrote it, so he/she knows
the feature is there. With primitive functions the documentation
is sketchy and the user depends on the interpreter to point out
syntax errors. Trying to use a axis specification with a
primitive that does support it is a syntax error (at least, the
IBM APL2 documentation says it is).
Section 3.13 'Axis arguments in defined functions' of the
apl.html documentation does not give a hint of the non-existence
of syntax checking for primitive functions with respect to axis
specification support. Maybe a warning to that effect and a list
of Gnu-APL primitives supporting axis specifications can be
added to the section.
Regards,
Fred
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
|