C Builtin Functions
Frank Adams
>I can feel the flames ("More operators? It's getting as bad as APL!").
>
>Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
"More operators? It's getting as good as APL!" -- except that it still
falls way short in this respect. I'm serious; APL does *not* have too many
operators. It does have too little structure.
Frank Adams ihnp4!philabs!pwa-b!mmintl!franka
Multimate International 52 Oakland Ave North E. Hartford, CT 06108
KW Heuer
>In article <7...@bentley.UUCP> k...@bentley.UUCP writes:
>>I can feel the flames ("More operators? It's getting as bad as APL!").
>
>falls way short in this respect. I'm serious; APL does *not* have too many
>operators. It does have too little structure.
The primitive functions in APL correspond roughly to C operators *and* the
entire runtime library. I agree that APL does not have a problem there.
APL has its own character set; C is restricted to a subset of ASCII. The
size of the alphabet is not a serious problem since new operators in C may
be multi-character; however, this may make them less mnemonic. (Of course,
some of the APL characters are not all that mnemonic either: "x" for signum
is a good example.)
The reason APL can deal with having so many primitives is that they all have
the same precedence. Adding that many operators to C would be a disaster.
You say APL has "too little structure". If you mean things like "while" and
"if", I think they may be unwelcome. Put in a "while" loop, and people will
start using it to implement a matrix multiply. (For those who don't get it,
APL has a builtin matrix multiply, "+.x".) The language doesn't need much
program structure, because it has data structure in its place.
Now, I *would* like to see some improvement in the data structure. It's now
practically impossible to write a function which expects, say, three string
(character vector) arguments. I like the grounded tree model, myself, as a
fix for this. Also, APL is *severely* in need of *variable declarations*!
Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
*** Please restrict followups appropriately! {net.lang.c|net.lang.apl} ***
Frank Adams
In article <8...@bentley.UUCP> k...@bentley.UUCP writes:
>You say APL has "too little structure". If you mean things like "while" and
>"if", I think they may be unwelcome. Put in a "while" loop, and people will
>start using it to implement a matrix multiply. (For those who don't get it,
>APL has a builtin matrix multiply, "+.x".) The language doesn't need much
>program structure, because it has data structure in its place.
I disagree. "if/then/else" would be very useful in APL. You wind up
using go to (->) instead. This is bad for the same reason it is bad in
other languages. The data structuring somewhat reduces the need for such
things, but not all that much -- particularly for complex applications.
People can write a matrix multiply using go to right now. There is no cure
for idiocy, and only one for ignorance.
>Now, I *would* like to see some improvement in the data structure. It's now
>practically impossible to write a function which expects, say, three string
>(character vector) arguments. I like the grounded tree model, myself, as a
>fix for this. Also, APL is *severely* in need of *variable declarations*!
I had both program and data structure in mind when I made that statement.
One advantage of a proper implementation of variable declarations is that
one would be able to define a function as operating on, say, two scalar
arguments; if invoked with two arrays of the same dimensions, it would
automatically be called for each corresponding pair of scalars.
David Laur
Frank Adams remarked:
>
>One advantage of a proper implementation of variable declarations is that
>one would be able to define a function as operating on, say, two scalar
>arguments; if invoked with two arrays of the same dimensions, it would
>automatically be called for each corresponding pair of scalars.
>
IBM research on this one ... they've been using APL2 (in various guises)
for YEARS now! Our site, Princeton University, has had it online for
about 3 years and we have some people who use it heavily. We do not
have any I.P. Sharp systems, so I can't say much about their
enhancements; and I don't know very much about the STSC APL/UNX product
except that they seem to have decided to use IBM's APL2 as the model
for their general array extensions. I would like to set the record
straight on a few items which people seem to be confused about.
First of all, I don't know the religious vocabulary which should be
used when discussing variable declarations, but I will try to explain
the APL model from my point of view. I think that many people would
argue that one of the things that makes APL easy to use is that the
user does NOT have to worry about declaring variables! More importantly
though, the APL approach has been to allow 'any' kind of data in arrays
(variables) and then to allow the functions to decide (selectively) if
their arguments are from a useable domain or class of objects. Again,
in APL the important distinctions are between numeric and character
types, and distinguishing between the shapes and ranks of arrays.
My interpretation of the comment about APL needing variable declarations
was that there is a need to describe the structure of the array rather
than 'type' of the elements. The specific example application given
is a perfect introduction to the new powers of APL2. One of the most
important things to have come out of the development of APL2 is the
formalization of many 'loosely defined' APL concepts. Among them, the
concepts of 'a scalar' and of 'scalar functions'. For some primitive
functions in APL, the two arguments are somewhat independent of each
other; for example, the left argument to RESHAPE is a description of the
new shape for the array right argument, these two arguments are usually
very different in their shape and size. Other primitives, like PLUS,
require that their arguments be identical in rank and shape; they return
a result of the same size which is produced by operating on
corresponding elements in the arguments in a pairwise fashion.
Functions which work, pairwise, on the scalar elements of the argument
arrays are called 'scalar functions'. User defined functions in VS/APL
and APL2 can not be defined to be scalar functions, which would solve
the stated problem; however, in APL2 there is a new operator (recall the
distinction between functions and operators in APL) which will turn any
function into a scalar function. It is called EACH and it will work on
both primitive and user defined functions, for example:
this expression: 2 3 4 reshape each 10 20 30
produces: 10 10 20 20 20 30 30 30 30
(which is a 3 element, nested vector of vectors)
The symbol for EACH is the dieresis -- the shift-one character which
looks a little like a sideways colon. It can also be used with monadic
functions:
this expression: iota each 1 2 3
produces: 1 1 2 1 2 3
(which is also a 3 element, nested vector of vectors)
Since this operator can be used with user defined functions, it will
easily solve the problem posted previously without introducing
variable declarations or 'structure' definitions.
So, what else does APL2 have, (you ask, knees quivering) ...
_________________________________
A partial list of enhancements (over IBM VS/APL):
- General Arrays
. that is: arrays whose scalar elements are other arrays,
these arrays can have ANY shape, rank, and mixture of types
. primitive which makes arrays into scalars (Enclose)
. primitive which undoes Enclose (Disclose)
. primitive for determining depth of nesting (Depth)
. primitive for reaching any level of a nested array (Pick)
. primitive which does a 'super ravel' on nested arrays (Enlist)
. Strand Notation for explicitly typing nested arrays
note: this is a 'natural' extension of A <- 1 2 3
there isn't an explicit 'glue' function between the numbers.
- Complex Numbers (Yep)
. Can be used anywhere
. Primitives like '*' changed to produce complex results
. New circle functions
. Real and Imaginary format - 1.4J3
. Magnitude and Angle format
Degrees - 25.3D90
Radians - 25.3R1.5707
- The Each operator, as described above
- There are now user defined Operators as well as functions
- User defined functions and operators can be used anywhere that
primitive ones can, eg: jot.MYFCN or MYFCN/VECTOR
- Also operator expressions are allowed: +.*/Vector_of_Matrices
- Nested Assignment: (A B C) <- 1 2 3
this would assign 1 to A, 2 to B, and 3 to C
- Selective Specification, this is an extension of A[2;3] <- 17
the new feature allows any selection expression in assignment,
for example: ((VECTOR='x')/VECTOR) <- 'y'
- A primitive for finding occurrences of one string in another (Find)
- A primitive called 'without' for set-type operations: A without B
- You can use Xedit as the APL editor
- You can use lower case letters instead of underscored letters
- There is support for 2*31 characters
- There are supplied functions which call special assembler code for
. Finding the roots of polynomials (answers can be complex)
. Finding Eigenvectors and Eigenvalues
- You can enter commands and get error messages in any of
12 national languages.
- There is a )HOST command for talking to the underlying system
- There is a new aux processor for SQL/DS and DB2
- There is a new aux processor for ISPF
- APL2 users can share variables with each other
- There are many new tools for error trapping and analysis
- The symbol table grows and shrinks dynamically
- Character data is now in standard system format (ebcdic)
- There is a very clever new interface via a new system function
called quad-NA:
. It is essentially a way to call compiled programs from APL2
. There is custom tailored support for programs written in
FORTRAN
Assembly Language
Rexx (a very nice PL/1ish exec language under CMS)
. the interface will actually support anything which uses
the OS calling conventions, so many programs written in
C, COBOL, Pascal, etc can also be used.
. As a result there is now direct access to existing subroutine
libraries, such as IMSL.
. There are some 'example' tools supplied with the interface
which are very useful additions to APL:
Fast File i/o
Parsing functions, eg: strings -> vector of words
An interface to GDDM's subroutine library
- And many more ...
_________________________________
I'd be happy to be more specific if anyone is curious, and I would
certainly like to hear about the features/pitfalls of other enhanced
versions of APL. Perhaps this would be a good opportunity for me to
'fan my own flame' (pardon) and informally announce that Princeton
and IBM will be jointly sponsoring an APL2 short course for
experienced APL programmers on 14-16 July 1986; topics and speakers
will be posted formally soon, but the course will be an introduction
to the new features just mentioned and some discussion of how to
use them effectively.
David M. Laur
Strike while the iron is. Bitnet: 6006118@PUCC
UUCP: allegra!psuvax1!pucc.BITNET!6006118
KW Heuer
>I disagree. "if/then/else" would be very useful in APL. You wind up
>using go to (->) instead. This is bad for the same reason it is bad in
>other languages. The data structuring somewhat reduces the need for such
>things, but not all that much -- particularly for complex applications.
Suppose there were no MIN primitive, and we wanted to implement it. The
straightforward approach would yield (uppercase denotes APL symbols)
DEL z IS x min y
[1] GOTO (x > y)/4
[2] z IS x
[3] GOTO 0
[4] z IS y
DEL
However, one can also write
DEL z IS x min y
[1] z IS ((x LEQ y) MULT x) + (x > y) MULT y
DEL
(or variations thereon), which I would consider attrocious programming in a
conventional language, even in a dialect of BASIC that has the same rules.
(No flow control except GOTO, but relational operators yield a value.) But
in APL, the second method is preferred, because it uses scalar primitives
only -- and hence will work properly when given two compatible arrays.
I just wanted to show that it's not always appropriate to compare APL to a
conventional language, and that if/while is often the wrong way to think
about a problem.
Of course, there are real examples where flow is necessary, which currently
require a GOTO. The APL equivalent of "do this block n times" is especially
ugly. I don't know if adding flow control is a good idea or not. (Some
would argue that the language is so hard to read that proper flow control is
irrelevant.) I think that it's probably better to graft the useful features
of APL (terse high-level array manipulations) into another language than to
try to fix APL.
>One advantage of a proper implementation of variable declarations is that
>one would be able to define a function as operating on, say, two scalar
>arguments; if invoked with two arrays of the same dimensions, it would
>automatically be called for each corresponding pair of scalars.
Yes. It would also make it much simpler to write a compiler; currently when
an expression like "foo - 3" is encountered, the interpretation of the "-"
depends on the (unknown) arity of "foo": "foo() - 3" if it's niladic (or a
variable), "foo(-3)" if it's monadic, run-time error if it's dyadic. There
are compilers for APL, but they have to "guess" -- and have a backup plan in
case the guess is wrong.
Lee Dickey
> >using go to (->) instead. This is bad for the same reason it is bad in
> >other languages.
But APL already *has* the "if/then/else" in direct definition. The
beauty of direct definition is that if your off-the-shelf micro APL
does not have it built in, you can easily implement it using Standard
APL.
I think that the power of APL is in the notation, the language itself.
Someone has said that Iverson invented the language as a tool with
which to express algorithms, and that he did not at first expect it to
be implemented as an interpreter. When some engineers discovered that
the entire 360 architecture could be described in one page of APL code,
they became excited about APL and decided to implement the language as
a development tool.
The name of the first APL was APL\360. In APL, "\" is the "expand"
function. APL\360 certainly did expand the 360!
Frank Adams
>> >I disagree. "if/then/else" would be very useful in APL. [Frank Adams]
>
>But APL already *has* the "if/then/else" in direct definition. The
>beauty of direct definition is that if your off-the-shelf micro APL
>does not have it built in, you can easily implement it using Standard
>APL.
Could you explain what you mean by this? What is "direct definition"?
Andrew Koenig
Direct definition is where you type
identifier: expression
and that defines a function named "identifier." Any variables
assigned in the expression are made local. Arguments are referred
to by the alpha and omega symbols for left and right arguments,
respectively. For a monadic function you can use all alpha or all
omega. So:
SQRT:alpha*0.5
You can also write
identifier: e1 : e2 : e3
where e1, e2, e3 are expressions. This means the value of the function
is e1 unless e2 is true, in which case it's e3. Thus:
FACT: alpha x FACT alpha-1 : alpha=0 : 1
Note that colon is not a function -- it effectively has lower precedence
than function symbols.
Lee Dickey
The concept of direct definition of APL functions was invented by
Dr. Kenneth Iverson, the inventor of APL (now working with I.P.Sharp
Associates in Toronto). There are two general forms of definition.
They are
fun : expr
fun : expr_f : cond : expr_t
Direct definition always creates a function that returns a result. For
the first form, the value of the result is the value of the expression "expr".
For the second form, there are two possibilities, depending on the value of
the condition. If "cond" is true, the value of the result
is the value of "expr_f". Otherwise it is the value of "expr_f".
Functions defined either way can be dyadic, monadic, or niladic.
A dyadic function (one with two variables) is defined if both the symbols
"a (alpha) and "w (omega) are present in the condition or the expressions.
for the variables. A monadic function (one variable) uses the
"w but not the "a . A niladic function (no variables) does not
include either the "a or the "w .
Here are two simple examples, written for a simulator. The function
that simulates the Direct Definition is called "ddef" and it accepts
a character string. (On a system that has real direct definition,
the "ddef '" and "'" are omitted.)
ddef 'plus: "a + "w '
2 plus 3
5
Here is the second example. It shows a uses of the second form,
creating the mathematical FACTORIAL function.
ddef 'fact : "w "x fact "w -1 : "w =1 : 1
fact 1
1
fact 3
6
fact 4
24
fact 5
120
Here the "x stands for APL multiplication. Sorry about the need
for escape sequences.
Both of these example are dyadic; you can have 4 other types, in addition
to the two types given above.
Ian Kemmish
>using go to (->) instead. This is bad for the same reason it is bad in
>things, but not all that much -- particularly for complex applications.
When APL was all I knew, I used to think it had data structures, and that
nested arrays, when they eventually arrived, would be even better.
Then I started playing with Lisp and Smalltalk, and I began to get
suspicious. I started calling what APL had "data aggregates".
Now I earn my bread & butter playing around in C, I *know* that APL
doesn't have structured data! I don't think I could possibly go back
now.
What I want to know is, am I a lone voice crying in the wilderness,
or do other people who've moved on from APL feel the same way??
Disclaimer: I'm not out of touch: I have APL on my PC at home, but
I only ever use it for the screen editor; I have just helped
port a groovy modern APL onto our MG-1 workstation product,
and I only ever use *that* when the pop-up calculator runs out
of steam.
Ian Kemmish
____
\ \ \ \ / Whitechapel Computer Works Ltd.
\ /\ \ /\ / 75 Whitechapel Road
\/ \___\/ \/ London E1 1DU
"Makers of the fastest (and slowest) workstations in Britain"
Andrew Koenig
> the condition. If "cond" is true, the value of the result
> is the value of "expr_f". Otherwise it is the value of "expr_f".
Incidentally, I've never seen a clear definition of the meaning
of "true" in this context. When I implemented a direct definition
function, I decided that "true" meant "has no zero elements."
This means that the null vector is "true."
Frank Adams
Thanks for the description. This wasn't around back in '76, when I was
writing APL for Sharpe.
The concept is interesting and useful. It certainly eliminates the need for
some if/then/else uses. I still think a genuine if/then/else would be a
valuable enhancement to the language. Some sort of loop construct would also
be valuable.
rob...@uiucdcsb.cs.uiuc.edu
I've felt the same way. Now for a question: Suppose you did want to
add C/Pascal style structured data to APL. How would you do it? What
new operators or functions would be necessary? I've been working on
an FP implementation that has exactly the same problem: ``data aggregates''
which are not really structured. It's easy to group data into lists
to simulate records, but the lists don't have field names, so
type-checking and legibility both suffer.
- Arch D. Robison
University of Illinois at Urbana-Champaign
Tom Haapanen
>When APL was all I knew, I used to think it had data structures, and that
>nested arrays, when they eventually arrived, would be even better.
> ...
>Now I earn my bread & butter playing around in C, I *know* that APL
>doesn't have structured data! I don't think I could possibly go back
>now.
>
>What I want to know is, am I a lone voice crying in the wilderness,
>or do other people who've moved on from APL feel the same way??
When APL was all *I* knew (actually APL and FORTRAN), I thought that the
arrays were quite sufficient for keeping data around. You'd have a bunch
of arrays for keeping all the information about a set of items. Arrays of
records? What? Linked lists? Who?
And yet, after having been converted to C (and to Pascal and WSL), I spent
last summer programming a large project in APL. Oh, I missed the data
structures, but you can manage without them. It's very easy to insert
elements into the middle of an array dynamically, and nested arrays allow
you to keep different types of data objects in one array. Alas, you can't
refer to elements by name, although using 'constants' to do indexing is
possible.
I felt a bit crippled going back to APL, but, then, there was that feeling
of power, being able to manipulate matrices with a single keystroke!
--
\tom haapanen looking glass software ltd.
syn...@looking.UUCP waterloo, ontario, canada
watmath!looking!syncro (519) 884-7473
"These opinions are solely mine, although even I would like to deny them..."