Are we writing functions or programs
Author Message
Are we writing functions or programs

I follow with great interest the discussion on program structures in APL.  I
first saw APL back when the variable names were limited to one letter and a
big workspace was 28K.   It took me a long time to grasp the concept that
APL was not just another programmming language, but a different concept in
programming.

APL is an array oriented function driven language which now has added
a set of reserved words beginning with : which is advertized as structures.
(the other reserved words begin with del or quad).

The two major programming structures of APL are the workspace and
the function.  To me the workspace is the application and the function
is something that does one thing.  As I read the mail each evening I
get the impression we are starting to write programs in our functions
instead of the workspace.  I have noted in the workspaces accompaning
the commercial software functions of 100 lines or more.  I can't believe
they do just one thing.

APL is a 'tool of thought'  using the standard routines of other
languages in APL is not always the best way to work in APL.

This week we had discussed the numbers of Leonardo of Pisa which
is often given as an example of recursive programming.  However we can use
a non recursive function that would probably run faster if you used the
structures of APL III  this program is in APL II but runs in APL2 and is
a fortran type approach.

{del} Z{<-}FIB N;A;B;I
[1]   (A B I){<-} 0 1 2
[2]   LP:{->}(N=I){reshape}END
[3]   (A B I){<-} B (A+B) (I+1)
[4]   {->}LP
[5]   END:Z{<-}A+B
{del}

Or another approach just build up a line and exectue it on the fly.

{del}  Z{<-}FIB1 N
[1]  Z{<-}1{drop}{execute}((3{times}N){reshape}'{reverse}+\'),'1 0'
{del}

Speed wise this line is quite fast and is a non-traditional way of
thinking that APL allows.

John R. Clark

Tue, 11 Mar 1997 21:13:12 GMT
Are we writing functions or programs
John R. Clark:
:    The two major programming structures of APL are the workspace and
: the function.  To me the workspace is the application and the
: function is something that does one thing.  As I read the mail each
: evening I get the impression we are starting to write programs in
: our functions instead of the workspace.  I have noted in the
: workspaces accompaning the commercial software functions of 100
: lines or more.  I can't believe they do just one thing.

I've seen this, too.  I've even had occasion to do such things.

I would charactarize the problem as one of documentation.  It's much
easier to say to a user: )COPY this function into the workspace, its
interface is...  Than, )COPY this list of functions into your
workspace, utility A has interface ___, utility B has interface ___,
etc. And, the driver function you probably want to use is X, and its
interface is ___.

The issues are: namespace pollution (clashes with other usages), size
and complexity of documentation, and minimizing typing for the user.
The tools provided by APL to address these problems are:

(1) use unmeaningful names
and
(2) wrap everything up into one function

Both of these could be handled by a decent implementation of lexical
scoping.

......................................................................

There is another issue here, buried in the mush.  That's one of
reusable utilities.  Reusing utilities is good because (when the
utilities are simple and elegant) they can make the code easier to
understand and (when they are fast and compact) can make efficient use
of the machine.

Tools I've seen used to address this problem include:

[A] Extending the language.
[B] Databases of code (which span workspaces).
[C] Compiled utilities (for speed).
[D] Careful understanding of the problem, the language, and the
existing code.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

NB.  public e, n, y
x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q

Tue, 11 Mar 1997 23:33:31 GMT
Are we writing functions or programs

Quote:
>The issues are: namespace pollution (clashes with other usages), size
>and complexity of documentation, and minimizing typing for the user.
>The tools provided by APL to address these problems are:

>(1) use unmeaningful names
>and
>(2) wrap everything up into one function

>Both of these could be handled by a decent implementation of lexical
>scoping.

One way to add "lexical context" to a subroutine is to embed it textually
inside another function.  Another way may be to use "links", i.e. hypertext.

Wed, 12 Mar 1997 02:00:57 GMT
Are we writing functions or programs

Quote:
>I follow with great interest the discussion on program structures in APL.  I
>first saw APL back when the variable names were limited to one letter and a
>big workspace was 28K.   It took me a long time to grasp the concept that
>APL was not just another programmming language, but a different concept in
>programming.

>    APL is an array oriented function driven language which now has added
>a set of reserved words beginning with : which is advertized as structures.
>(the other reserved words begin with del or quad).

>   The two major programming structures of APL are the workspace and
>the function.  To me the workspace is the application and the function
>is something that does one thing.  As I read the mail each evening I
>get the impression we are starting to write programs in our functions
>instead of the workspace.  I have noted in the workspaces accompaning
>the commercial software functions of 100 lines or more.  I can't believe
>they do just one thing.

I think we would all like to have "each function do just one thing".
The purpose of our discussion is to make it _easier_ and _safer_.
We all have a distaste for 100-line functions full of gotos, but they
exist in large part because of shortcomings in APL (the programming
language, not the notation).  I think, a 100-line function that is
partitioned into nested blocks and lexically scoped local subroutines
would not be so bad.  (Hypertext linked "safe" subroutines would be
swell.)  There is a huge difference between gotos and subroutines.

Quote:
>   APL is a 'tool of thought'  using the standard routines of other
>languages in APL is not always the best way to work in APL.

But sometimes, it is...

- Show quoted text -

Quote:
>   This week we had discussed the numbers of Leonardo of Pisa which
>is often given as an example of recursive programming.  However we can use
>a non recursive function that would probably run faster if you used the
>structures of APL III  this program is in APL II but runs in APL2 and is
>a FORTRAN type approach.

>   {del} Z{<-}FIB N;A;B;I
>[1]   (A B I){<-} 0 1 2
>[2]   LP:{->}(N=I){reshape}END
>[3]   (A B I){<-} B (A+B) (I+1)
>[4]   {->}LP
>[5]   END:Z{<-}A+B
>   {del}

>Or another approach just build up a line and exectue it on the fly.

>  {del}  Z{<-}FIB1 N
>[1]  Z{<-}1{drop}{execute}((3{times}N){reshape}'{reverse}+\'),'1 0'
>  {del}

>Speed wise this line is quite fast and is a non-traditional way of
>thinking that APL allows.

Trivia: In the 1990 version of Dyalog APL for the Sparc, FIB is 3X faster
than FIB1.  That's right.  (Line [3] as B<- A+B <> A<- B-A <> I<- I+1.)
About 60 milliseconds to compute FIB 78 (16 digits).

Fri, 14 Mar 1997 23:51:47 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages