What Are APL's Paradigms? 
Author Message
 What Are APL's Paradigms?

[repost; last one didn't get through? slightly modified]

I think a _focused_ debate is overdue, on what are APL's essential and
nonessential paradigms.  Much of comp.lang.apl's proceedings are arguments
for or against certain styles of programming, or certain features of the
language or proposed extensions.  If current and "future" paradigms can
be delineated, it might help us understand eachother's perspectives, in
order to find a common ground.

Possibly, some paradigms can or must be sacrificed (to some extent),
in order to introduce new ones (such as compilation).  Or, some paradigms
might be strengthened without affecting others.  We need to understand
how they interact--through reinforcement or checks-and-balances?  If one
wishes to propose a new paradigm, one should say clearly what it _is_, and
how it would impact existing ones.

I'll start:

(0)  Notational simplicity and expressivity that allows APL to be used
     as a tool of thought as well as experimentation.

(1)  Use of defined or primitive derived functions to transform data objects;
     these transformations are conceptually the basic units of work.

(2)  Use of nonprimitive operators or functions to express functional objects.

(3)  Declaration-less dynamic binding allows fluid, evolutionary programming.

(4)  Efficiency in most cases means low interpretive overhead, and is
     achieved through expressive, myriad uses of primitives and idioms.

Among these, (2) is not yet well established practice except in some dialects.
The others are pretty essential in my opinion, although (3) and (4) can be
antithethical to compilation, a potential source of machine efficiency.  

Nonessential paradigms (which does not mean bad) might be (in my opinion):

(5)  International symbols (with a few exceptions).

(6)  Single-letter or (J) two-letter primitives for terse expression.

(7)  Simple line-oriented execution model and function structure.

(8)  Simple workspace structure as flat collection of functions and data.

(9)  The infamous one-liner (a consequence of all of the above).

A consequence of (7) "no nested blocks" is the goto.  
A consequence of (8) "no nested functions" is dynamic binding.

I don't know where the following goes, or how to make it less vague:

(?)  Primitives obey a simple "algebra" (NO exceptions) so their use
     in combination can be understood and the effect predicted.

Perhaps this is (0').  Also,

(?)  Mix of functional and imperative programming (e.g. subarray assignment).

Comments?  Which do _you_ consider essential?
Please post, or email to me and I'll summarize.


p.s. Eventually this can go into the FAQ?



Sun, 23 Mar 1997 00:26:34 GMT  
 What Are APL's Paradigms?
Quote:
 (William Chang) writes:

>Nonessential paradigms (which does not mean bad) might be (in my opinion):
>...
>(7)  Simple line-oriented execution model and function structure.

>(8)  Simple  workspace structure as flat collection of functions and data.
>...

I consider the above features to be essential.
[7] The simple interactive line-oriented execution model makes the APL system
interactive; you type in an expression, and immediatly get back a result.  
[8] The workspaces allow APL code to be maintained in an interactive fashion.

Kim



Sat, 22 Mar 1997 23:55:58 GMT  
 What Are APL's Paradigms?

Quote:

> (William Chang) writes:
>>Nonessential paradigms (which does not mean bad) might be (in my opinion):
>>(7)  Simple line-oriented execution model and function structure.
>>(8)  Simple workspace structure as flat collection of functions and data.

>I consider the above features to be essential.
>[7] The simple interactive line-oriented execution model makes the APL system
>interactive; you type in an expression, and immediatly get back a result.

Thank you for responding.  I raised this CRITICAL issue more than a month ago
(and got Eke in agreement); perhaps we should discuss it a bit more.

I think, really, that yours is a valid viewpoint.  The simplicity of line-based
APL is most beguiling.  I love(d) it.  But it has (had) three very unfortunate
consequences:

(A) it fostered and justified the use of goto for control flow;
(B) it fostered and justified the use of string as a control structure;
(C) it created a myth that function arrays are all that APL needs for control.

So we ended up with 25 years of controversy and inaction over what, if anything,
needs to change.  Indeed we got our thread to prove it.  Now to reprise:

A consequence of line-based is no nested blocks--how does one physically nest
lines, strings, or function arrays?  Yes it is possible, in fact _easy_, but
how many APLers ended up thinking it is "unnatural" to nest, or "essential"
not to nest?  The problem is not technical but psychological.  APLGOL, APL90,
and APL*PLUS III all nest; execute should have been defined to take a matrix;
function arrays can be nested in alternating "series-parallel" fashion.

I hope Kim is not still favoring dynamic scope for "first class functions"
(aka function arrays).  Such beasts we already have--they are called strings.
They are UNSAFE because references (including function and operator names)
can be shadowed or lost; UNSTRUCTURED because definition and use can be
_anywhere_.  In fact, they are exactly like strings.

Okay.  We all know better now, thanks to Manugistics.  Lines and blocks can
coexist; a block is just a bunch of lines, delimited.  Now all we need are
lexically (i.e. naturally) scoped local functions and a way for operators
to return them.

Quote:
>[8] The workspaces allow APL code to be maintained in an interactive fashion.

Same thing.  It started out flat, and people became beguiled by its simplicity.
No reason really why the workspace cannot be nested--indeed our problem is
not _no_ nesting, but _different_ means of nesting from each of the vendors.
Why is there a need to create new proprietary structures, when EVERY MODERN
COMPUTER already has (the same) one?  Why can't the workspace be a Unix, DOS,
or Mac directory?

So... when one starts the interpreter, objects in the current directory are
loaded into memory (default).  Because Unix is not object-oriented, there needs
to be "invisible" files, for example .x is the binary of x.  "Path" variables
can be defined for accessing other directories or subdirectories; or, one can
move around, look at stuff and load them in.  "Lazy" load on demand can be
implemented.  A subdirectory can be "mapped" to an object, either an array or
a (first class) function with environment.  Temporary objects (including stack
frames) reside in memory, so functions can be re-entrant or recursive.  When
one exits the interpreter, globals are saved back in the directory(ies),
possibly along with a "memory dump" .continue for suspended stuff.  Basically,
the workspace will have the LOOK AND FEEL OF THE NATIVE PLATFORM, Unix, DOS,
or Mac.  What can be simpler?




Tue, 25 Mar 1997 01:35:13 GMT  
 What Are APL's Paradigms?

Quote:

> (William Chang) writes:
>>Nonessential paradigms (which does not mean bad) might be (in my opinion):
>>(8)  Simple workspace structure as flat collection of functions and data.
>[8] The workspaces allow APL code to be maintained in an interactive fashion.

I think, what Kim means is that a subfunction can be modified (or even defined)
while the parent function is suspended.  This is obviously useful (essential)
but I don't think it rules out nested ("nonflat") subfunctions.  If Kim is
concerned about line numbers, all the interpreter has to do is treat each
(nested) subfunction independently.  Something like

  ` foo
[1] ...
[2] ...
    [1] f(X): {
    [2] ...
        [1] g(Y): { ... }
    [3] }
    [1] h(Z): { ... }

The editor can properly renumber lines after checking syntax (the APL*PLUS III
editor rejects malformed control structures upon exit).  A better way is to
have an "outliner" that shows or hides subfunctions on demand.  This is useful
in general, for viewing arrays or business presentations (!).

It is certainly a valid viewpoint, to want a simple debugging interface,
at least as it appears to the user.  Manugistics solves the problem of
suspending a control structure that is embedded in a long line very simply:
treat the line as a sequence of diamond separated virtual lines.  For example,
the following can be suspended at various points inside the line.

:if (...) <> :if (...) <> ... <> :endif <> :for ... <> ... <> :endfor <> :endif

(At least I think this is the case.  Question: can such a line be "executed"?)




Tue, 25 Mar 1997 23:04:59 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. 'who am i' from unix

2. Workspace transfer between STSC's and DIGITAL's APL

3. I-APL, Vanguard APL, and APL.68000

4. I am not deaf, but am I mute?

5. I can't believe I am learning Clipper

6. Where am I wrong?(this has to be wrong, it can't be so simple)

7. Fixed point math in asm -HELP ME I 'am dying here

8. Just the facts ma'am (Re: Link on _TRUTH_)

9. Reminder for APL'95 Posters

10. Any APL's that support imaging?

11. Phone # for APL '95?

12. APL'95: Fortran-90

 

 
Powered by phpBB® Forum Software