Precedence of basic language elements

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

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 o
f
times, if any, that each distinct item appears is significant and not the or
der
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 Opera
tor
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?
>
>

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

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 opera
tors
are defined in APL2.
 
>
>
> 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 an
d
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 ei
ther
have one or two arguments, which are always arrays) and produce an array res
ult.

Defined functions are either niladic, monadic, or dyadic (in ather words the
y
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 oth
er
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 dyad
ic
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 arr
ays,
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 p
lus
reduction or summation; although + is a dyadic function, the derived functio
n +/
is monadic. (Actually, it would probably be more correct to say that the der
ived
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.

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 ope
rators
> 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 o
ther
> 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 dy
adic
> 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

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!"

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 re
turn
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 ei
ther
monadic or dyadic.

TaliesinSoft wrote:

> When I first encountered APL in 1969 the notion of operators as such had y
et
> 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

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!"

Good morning to all,
as far as I can remember some 35-37 years ago, some "composite functions" ex
isted until they
they were replace by ad hoc operators in a "next generation" interpreter soo
n 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!"
>