Home > Archive > APL > August 2004 > Precedence of basic language elements
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Precedence of basic language elements
|
|
| ernobe 2004-07-29, 3:55 pm |
|
I was reading thru the pdf manual for CAPLIB2 and have a question
regarding basic language elements and their binding strengths. These are
the basic language elements ( from page 8 ):
"Arrays are ordered rectangular collections of data items
Functions accept arrays as arguments, and produce new arrays as results.
Operators accept both arrays and functions, applying the functions in
special ways, also producing arrays as results."
What is a 'rectangular' collection of data items, and how could it have
been disordered to begin with? Then on page 10 there are the binding
strengths:
"Hierarchy of Binding Strengths
Binding Strength What is bound
Brackets Brackets to what is on their left
Specification left Left arrow to what is on its left
Right operand Dyadic operator to its right operand
Vector Array to an array
Left operand Function to its left argument
Left argument Function to its left argument
Right argument Function to its right argument
Specification right Left arrow to what is on its right.
Note 1: For binding, the branch right operator behaves as a monadic
function.
Note 2: Brackets and monadic operators have no binding strength on the
right.
Note 3: Parenthesis override the default binding."
Both the left operand and the left argument bind a function to
its left argument. Assuming that arguments are passed to functions while
operands are passed to operators, it appears that this is either a typing
error or the author purposely equates an 'operator' with a 'function'.
The binding strengths table appears to give precedence to operators over
functions, but if they are in a sense equivalent, how can the precedence
be established?
--
PS. I've checked this post for spelling errors.
Unchecked material can be found here:
http://www.costarricense.cr/pagina/ernobe
| |
| James J. Weinkam 2004-07-29, 8:55 pm |
| ernobe wrote:
>
> I was reading thru the pdf manual for CAPLIB2 and have a question
> regarding basic language elements and their binding strengths. These are
> the basic language elements ( from page 8 ):
>
>
> "Arrays are ordered rectangular collections of data items
>
> Functions accept arrays as arguments, and produce new arrays as results.
>
> Operators accept both arrays and functions, applying the functions in
> special ways, also producing arrays as results."
>
> What is a 'rectangular' collection of data items,
Just what it says. A collection of data items presented in a specific order
that is thought to be arranged into a rectangular pattern of columns, rows,
slices, blocks, etc whatever you want to call the higher dimensional gadgets.
and how could it have
> been disordered to begin with?
The expression ordered collection means that the order of presentation is
significant as opposed to an unordered collection in which only the number of
times, if any, that each distinct item appears is significant and not the order
in which they are mentioned.
Then on page 10 there are the binding
> strengths:
>
>
> "Hierarchy of Binding Strengths
>
> Binding Strength What is bound
>
> Brackets Brackets to what is on their left
> Specification left Left arrow to what is on its left
> Right operand Dyadic operator to its right operand
> Vector Array to an array
> Left operand Function to its left argument
> Left argument Function to its left argument
> Right argument Function to its right argument
> Specification right Left arrow to what is on its right.
>
> Note 1: For binding, the branch right operator behaves as a monadic
> function.
> Note 2: Brackets and monadic operators have no binding strength on the
> right.
> Note 3: Parenthesis override the default binding."
>
> Both the left operand and the left argument bind a function to
> its left argument. Assuming that arguments are passed to functions while
> operands are passed to operators, it appears that this is either a typing
You are right. Someone somewhere made a typing error. It should read Operator
to its left operand.
> error or the author purposely equates an 'operator' with a 'function'.
> The binding strengths table appears to give precedence to operators over
> functions, but if they are in a sense equivalent, how can the precedence
> be established?
>
>
| |
| ernobe 2004-07-30, 3:55 pm |
| On Thu, 29 Jul 2004 15:12:31 -0700, James J. Weinkam wrote:
> ernobe wrote:
>
> Just what it says.
If what he means is 'an operator is passed arrays as arguments, but can
also accept other operators', then why does he not just say so, and
perhaps offer an example, instead of making a broad language definition
that cannot be justified and only confuses what could be a general
understanding of the language? What does he mean?
--
PS. I've checked this post for spelling errors.
Unchecked material can be found here:
http://www.costarricense.cr/pagina/ernobe
| |
| James J. Weinkam 2004-07-30, 8:55 pm |
| ernobe wrote:
> On Thu, 29 Jul 2004 15:12:31 -0700, James J. Weinkam wrote:
>
>
Are you sure you quoted this correctly. That is certainly not the way operators
are defined in APL2.
[color=darkred]
>
>
> If what he means is 'an operator is passed arrays as arguments, but can
> also accept other operators', then why does he not just say so, and
> perhaps offer an example, instead of making a broad language definition
> that cannot be justified and only confuses what could be a general
> understanding of the language? What does he mean?
>
>
Functions and operators are fundamentally different. Primitive functions and
operators are built into the language. Defined functions and opertors are
defined by the programmer.
Primitive functions are either monadic or dyadic (in other words they can either
have one or two arguments, which are always arrays) and produce an array result.
Defined functions are either niladic, monadic, or dyadic (in ather words they
can have no, one, or two arguments, which are always arrays) and can either
produce an array result or not have an explicit result (generally, functions
without a result have side effects i.e., non explicit results).
Monadic functions take a right argument but no left argument.
Both defined and primitive operators may be either monadic or dyadic (in other
words they can have either one or two operands each of which may be either a
function of an array (no existing primitive operator takes an array right
operand at least in APL2) and produce a function, referred to as a derived
function, as a result. The derived function is always either monadic or dyadic
and always produces an explicit result.
Monadic operators take a left operand but no right operand.
For example, . is a dyadic operator, + and {times} are functions, and
+.{times} is a derived function, inner product. If x and y are suitable arrays,
the result of x+.{times}y is the inner product of x and y.
As another example, / is a monadic operator and +/ is the derived function plus
reduction or summation; although + is a dyadic function, the derived function +/
is monadic. (Actually, it would probably be more correct to say that the derived
function is ambivalent. If used monadically it is simple reduction; if used
dyadically with left argument n it is n-wise reduction. For instance, if x is a
vector and {rho}x>=5 then (5+/x){divide}5 is a vector of moving averages of x
with window 5. Suffice it to say the the left argument is used plays an
entirely different role than the right argument and is unrelated to the
argument(s) of the function whinh is the left operand.) On the other hand, if
the left operand is a vector of integers, the derived function is called
replication or in the special case of a Boolean vector, compression.
| |
| ernobe 2004-07-30, 8:55 pm |
| On Fri, 30 Jul 2004 13:09:28 -0700, James J. Weinkam wrote:
>
>
> Are you sure you quoted this correctly. That is certainly not the way operators
> are defined in APL2.
I obtained CAPLIB2 from the Waterloo site,
ftp://watserv1.uwaterloo.ca/languages/apl/CAP
>
> Monadic functions take a right argument but no left argument.
>
> Both defined and primitive operators may be either monadic or dyadic (in other
> words they can have either one or two operands each of which may be either a
> function of an array (no existing primitive operator takes an array right
> operand at least in APL2) and produce a function, referred to as a derived
> function, as a result. The derived function is always either monadic or dyadic
> and always produces an explicit result.
>
> Monadic operators take a left operand but no right operand.
So both operators and functions can be dyadic and return an array result?
Even so, the main difference appears to be that operators produce derived
functions, therefore one could perhaps use a function as an operator to
produce a derived function? I wonder what the original APL did, since
I've installed ( compiled ) APL/11, but have no documentation for it.
From what you've said it appears that in APL2 functions and operators are
interchangeable terms for dyadic operations, while the Dyalog
documentation makes them entirely different from the point of view of
scope. Can you think of any sorts of tests I can run on APL/11 to find
out what the situation is there? I'll look around and see if I can find
example code, but even if it does work, I couldn't understand what it is
doing unless it comes well documented. Thanks for the explanation.
--
PS. I've checked this post for spelling errors.
Unchecked material can be found here:
http://www.costarricense.cr/pagina/ernobe
| |
| TaliesinSoft 2004-07-30, 8:55 pm |
| On Fri, 30 Jul 2004 14:16:51 -0500, ernobe wrote
(in article <pan.2004.07.30.19.16.40.103989@yahoo.com> ):
[in the context of the difference between operators and functions in APL]
> I wonder what the original APL did,
When I first encountered APL in 1969 the notion of operators as such had yet
to be introduced into the language. Reduction, and inner and outer product
did exist, but they were referred to as "composite functions" and were
constrained to only involve the primitive scalar dyadic functions.
-- James L. Ryan -- TaliesinSoft
"My dog never came across a bush he didn't like!"
| |
| James J. Weinkam 2004-07-31, 3:55 pm |
| ernobe wrote:
>
> So both operators and functions can be dyadic and return an array result?
No. Functions return an array if they return anything. Operators always return
a derived function. When the derived function is applied to its argument(s) it
returns an array.
> Even so, the main difference appears to be that operators produce derived
> functions, therefore one could perhaps use a function as an operator to
> produce a derived function?
No.
I wonder what the original APL did,
The same, except that user defined operators were not available.
since
> I've installed ( compiled ) APL/11, but have no documentation for it.
> From what you've said it appears that in APL2 functions and operators are
> interchangeable terms for dyadic operations,
No. Functions and operators are fundamentally different, and both can be either
monadic or dyadic.
| |
| Ted Edwards 2004-08-05, 3:55 pm |
| TaliesinSoft wrote:
> When I first encountered APL in 1969 the notion of operators as such had yet
> to be introduced into the language. Reduction, and inner and outer product
> did exist, but they were referred to as "composite functions" and were
> constrained to only involve the primitive scalar dyadic functions.
I seem to recall discussing operators with Ken and Adin back in 1967.
Even then we considered the restriction to primitive scalar dyadic
functions an implementation restriction not a language restriction.
APL*STAR dropped the "primitive" from that.
Ted
| |
| TaliesinSoft 2004-08-05, 3:55 pm |
| On Thu, 5 Aug 2004 12:40:47 -0500, Ted Edwards wrote
(in article <41126618.A9A@telus.net> ):
> TaliesinSoft wrote:
>
>
> I seem to recall discussing operators with Ken and Adin back in 1967.
> Even then we considered the restriction to primitive scalar dyadic
> functions an implementation restriction not a language restriction.
> APL*STAR dropped the "primitive" from that.
>
> Ted
Do you recall when the term "operator" replaced "composite function"?
-- James L. Ryan -- TaliesinSoft
"My dog never came across a bush he didn't like!"
| |
| Gilbert Giappési 2004-08-06, 3:55 pm |
| Good morning to all,
as far as I can remember some 35-37 years ago, some "composite functions" existed until they
they were replace by ad hoc operators in a "next generation" interpreter soon thereafter !!
Am I really true ?
TaliesinSoft a écrit:
> On Thu, 5 Aug 2004 12:40:47 -0500, Ted Edwards wrote
> (in article <41126618.A9A@telus.net> ):
>
>
>
>
> Do you recall when the term "operator" replaced "composite function"?
>
>
>
>
> -- James L. Ryan -- TaliesinSoft
>
> "My dog never came across a bush he didn't like!"
>
| |
| Ted Edwards 2004-08-06, 8:55 pm |
| TaliesinSoft wrote:
> Do you recall when the term "operator" replaced "composite function"?
My involvement with APL started with APL\360 in 1967. My recolection is
that we have always called "/","{nul}." and "." operators and the
results of applying them (e.g. "+.{times}") composite functions.
Ted
| |
| Bob Cain 2004-08-07, 3:55 pm |
|
Ted Edwards wrote:
> TaliesinSoft wrote:
>
>
>
>
> My involvement with APL started with APL\360 in 1967. My recolection is
> that we have always called "/","{nul}." and "." operators and the
> results of applying them (e.g. "+.{times}") composite functions.
That's also my recolection from an involvement that began
about a year later.
Bob
--
"Things should be described as simply as possible, but no
simpler."
A. Einstein
|
|
|
|
|