APL slash bang (Repost) 
Author Message
 APL slash bang (Repost)

APL slash bang                                DRAFT 31 December, 1991

I would like to propose an ASCII rendition of APL, to be called
APL/! (a pun on APL\?, itself a pun on APL).  In this scheme, ASCII
symbol combinations that are visually appealing are assigned to
functions that are most commonly used, subject of course to rules
of consistency and operator ambivalence.  In particular, APL's two
Greek letters rho and iota are transliterated to slash / and bang !.
There are two adverbs, a pre-modifier tilde ~ signifying oppositeness,
and a post-modifier dot . signifying extension.  A longer note on the
motivation and design of APL/! will be submitted later.

Logical and Comparison:    
  ~. not   ^. and   v. or      ~^. nand    ~v. nor
  = equal  < less   > greater  ~= unequal  ~< not less  ~> not greater
Structural (shaping, slicing, transposing, shifting):
  , ravel, catenate   / shape, reshape   | take  ~| drop   \ transpose  
  -. reverse, rotate (row-wise)  +. (column-wise)
Special:
  ! initial segment of indices, index of   ? membership
  /. compress, reduce (cumulate)   \. expand, scan (partials)
  ~/. ~\. (column-wise)            # execute  ~# format
  (.f.) outer product   (f).(g) inner product
Arithmetic:  
  + plus   - negative, minus   * sign, times   % reciprocal, divide  
  ^ power  ~^ logarithm
Numerical:
  <. floor, min  >. ceiling, max   ~<. grade up  ~>. grade down
  *. factorial, choose   %. invert matrix, solve   ?. roll, deal

Syntactic:


  =. assignment   -> branch   <> statement separator   <>. o} comment
  & delta  &. delta-underscore   ~& del (define function)  ~&. lock
Unchanged:  
  ;  :  [ ]  ( )  '
Initials for Extended APL:
  c. enclose  ~c. disclose   o. box (objectify)  ~o. open

Some familiar idioms:
  /A "shape A"    //A "rank A"   (/B)/A "B-conform A"
  !10 "initial ten"    !/A "indices A"   B!A "B-indices A"
  ((!/A)=A!A)/.A "A minus duplicates"
      [indices A equal A-indices A, subset A]
  +/.^.\. "find first zero" [cumulative-add all-one left-partials]
  +/.^.\.-.' '=A "count trailing blanks"
      [find first zero, backwards, in space-equal-A]
  (-+/.^.\.-.' '=A)~|A "A minus trailing blanks"
  (-+/.^.\.-.' '=A)-.A "right-justify A"  
      [row-wise circular shift, trailing blanks to front]
  (!10)(.*.)(!10) "ten-by-ten multiplication table"
  A(+).(*)B "matrix product"   A(<.).(+)A "shortest paths, one stop-over"
  ->(COND)/LABEL [goto LABEL if COND]
  ->(CONDS)/.LABELS [goto LABEL corresponding to first true COND]

-----------------------------------------------------------------------------
William I. Chang, Ph.D.
Cold Spring Harbor Laboratory
100 Bungtown Road, Cold Spring Harbor, NY 11724



Sat, 03 Sep 1994 04:13:03 GMT  
 APL slash bang (Repost)
I think the use of greek letters, heavy overloading, and character
combinations in APL is a big mistake, and this mistake is only
compounded by J and the proposed ASCII rendition of APL.

There is little value in compressing the syntax of expressions to the
extent that it is difficult for humans to read.  In contrast, there is
value in compressing the semantics to higher-level operations.  Don't
confuse the two.  I like APL for its semantics; its syntax sucks.

The Lisp community has gone another route which makes a whole lot more
sense to me.  Long, descriptive names are the norm.  It is false
economy to reduce whitespace to the minimum required and save typing
with short criptic names or non-meaningful symbols when large screens,
visual editors, and completion techniques are available.

Instead of yet another cryptic notation, what I want to see is a new
ASCII based APL syntax that uses meaningful names for operators.  (It
could also use commonly accepted precedence for numeric and logical
operators (only) and left-to-right evaluation order, but this is not
as big an issue.)

Dan LaLiberte




Mon, 05 Sep 1994 02:56:03 GMT  
 APL slash bang (Repost)

Quote:
(Daniel LaLiberte) writes:
>I think the use of greek letters, heavy overloading, and character
>combinations in APL is a big mistake, and this mistake is only
>compounded by J and the proposed ASCII rendition of APL.

>There is little value in compressing the syntax of expressions to the
>extent that it is difficult for humans to read.  In contrast, there is
>value in compressing the semantics to higher-level operations.  Don't
>confuse the two.  I like APL for its semantics; its syntax sucks.

>The Lisp community has gone another route which makes a whole lot more
>sense to me.  Long, descriptive names are the norm.  It is false
>economy to reduce whitespace to the minimum required and save typing
>with short criptic names or non-meaningful symbols when large screens,
>visual editors, and completion techniques are available.

>Instead of yet another cryptic notation, what I want to see is a new
>ASCII based APL syntax that uses meaningful names for operators.  (It
>could also use commonly accepted precedence for numeric and logical
>operators (only) and left-to-right evaluation order, but this is not
>as big an issue.)

>Dan LaLiberte



Thanks for your reply!  You have stated your position very clearly
and tersely, much like a good APL program in my opinion :-)

Sure it is arguable whether succintness a la APL is a "disease",
but apparently enough of us like it that APL has managed to survive.
I like it because I can spend more time thinking instead of typing;
can fit an entire program on a sheet of paper so I can visualize
all the components at once; can read and write idioms more easily.  
Sure, in this age of large screens, macro expanders, etc. these
advantages may be less important than they used to be.  Still,
there isn't another language I would rather use.

I would agree though that greek letters and heavy overloading have
been mistakes.  I arrived at this conclusion as I spent several days
and nights "inventing" APL/! and thinking about translation among APL
dialects.  The short answer is, overloading makes automatic translation
impossible, at least in theory if not in practice.  Greek letters would
be acceptable to me were there no alternatives--but in my mind at least
APL/! (it really isn't that cryptic :-) is quite feasible, so why greek?  
(Yes APL symbols and keyboard are nice, but we all have horror stories
to tell...  I finally got everything working on my Mac, as a terminal
emulator, with capslock as APL toggle.)

It is trivial technically to give "names" to APL operators, and this
has been done many times.  The fact that no such scheme is actually
used by people suggests it doesn't work as well as one hoped.  There
is even a language Nial, rationalized APL so to speak, whose inventors
(Jenkens, Michel, More) were authorities on nested arrays as a "theory"
and gave careful thought to those names.  (I used to be able to prove
axiomatically important identities in this "language" of array theory,
so I think it is certainly feasible as a tool of thought if not quite
as a programming tool.)  Unfortunately the implementation of Nial was
not as refined (read: fast) as the theory, and Nial never caught on.

There hasn't been interest on comp.lang.apl in a serious discussion
on the future of APL.  Perhaps the time is now?




Tue, 06 Sep 1994 01:25:16 GMT  
 APL slash bang (Repost)

Quote:

>I think the use of greek letters, heavy overloading, and character
>combinations in APL is a big mistake, and this mistake is only
>compounded by J and the proposed ASCII rendition of APL.

>   .... more on the general subject of reducing the number of
> keystrokes being a silly goal at the expense of readability ...

>Dan LaLiberte



Absolutly, positively correct.  I fail to see the point of reducing
the whole suite of operators to every possible combination of
punctuation marks.  Is this really supposed to be a language for
Stephen Hawking, who is forced to "type" at less than a character per
second?

Come on guys, what is the point?

Steve Roy



Tue, 06 Sep 1994 02:19:46 GMT  
 APL slash bang (Repost)

|> I would agree though that greek letters and heavy overloading have
|> been mistakes.  I arrived at this conclusion as I spent several days

Doesn't overloading include the use of "+" for scalars and arbitrary
arrays? I wouldn't want to get rid of that. Are you objecting to cases
like the use of "/" for reduction and compression?

|> It is trivial technically to give "names" to APL operators, and this
|> has been done many times.  The fact that no such scheme is actually
|> used by people suggests it doesn't work as well as one hoped.  There

Actually I think people use them all the time (even here!). The fact
that they're reinvented many times shows their necessity.

|> There hasn't been interest on comp.lang.apl in a serious discussion
|> on the future of APL.  Perhaps the time is now?

This is interesting, but how do we avoid the usual name calling that
happens whenever the most important issue - generalized arrays - comes
up?

--
Sam Sirlin



Tue, 06 Sep 1994 03:03:14 GMT  
 APL slash bang (Repost)

Quote:
>   The opinions expressed in quotations (1) and (2) appear to be dominated
>   by lack of experience.  Those who have studied higher mathematics,
>   APL, or J, will have learned the power of expressiveness of notation
>   used in these languages.  

I'm familiar with the power of expressiveness, and indeed APL and J
are powerfully expressive in the sense of condensing much semantics
into a small space.  (APL was my first language, almost 20 years ago.)

The problem isn't the compression itself, it's (in part) the
inappropriate medium of linear ascii text.  Mathematical notation,
which Whitehead and Babbage were referring to, has long ago branched
into 2 dimensions and the use of visual, iconic, or graphical
notations to help the reader perceive the relationships between
components.  In fact, it is important to carefully typeset (in the TeX
sense) mathematical notation to give it that clean look that lets the
reader transcend the medium to get the message.

Now, as long as we are stuck with linear ascii text, we have to make
the best of it.  We have very few barely meaningful operator-like
characters to work with, so I think it better to use them sparsely
rather than jumbled together to confuse the eye.

         By relieving the brain of all unnecessary work,
         a good notation sets it free to concentrate on
         more advanced problems, and in effect increases
         the mental power of the race.
                                          A.N. Whitehead

Excellent quote, but what is the "work" we are talking about here?
The initial learning curve is one thing, but I'm not too concerned
with that as long as it isn't too steep, and the height achieved makes
it worth while.  Much more important is that it be uniform and
statically parsible without complex context sensitivity so that one
can get into the flow of an expression without stumbling on the
notation.

As a general guideline, I think C and Icon make good use of most
operator characters.  The density of notational noise in those
languages is about as much as most people care to see.  A language
like Perl has gone too far in my opinion.

One important problem for an APL notation (to remain anything close to
the original APL concept) is to treat user defined functions in the
same way as infix and prefix operators.  Smalltalk has relevant ideas
here.  Functional languages have ideas for notations of operating on
functions as objects.

Dan LaLiberte




Wed, 07 Sep 1994 07:32:38 GMT  
 APL slash bang (Repost)
From an historical perspective I can't really see that dumping the
symbol set in favor of ASCII would necessarily do much for easing
the task of automatic transliteration among dialects.  Language
designers might just as well seize on the same keywords for semantically
different concepts as they did on the same symbols.  If I remember
correctly, all of the generalized array approaches had a function  
called "enclose" to start with.  Then semantic differences led to
qualifications in the literatature to "strict", "permissive", etc.
It was relatively late into the fruitless and tragic APL War of the Roses
that "box" came along.

Even among relatively similar dialects this can happen.  I distinctly
remember a visit by Bob Smith (designer of STSC's NARS system) to
reconcile with Jim Brown its differences with APL2 and, of all
things, there was no agreement about the definition of the result
of the "depth" function.  The debate was cordial, but in the end
no one was convinced and the two system went on separately.  Although
it cannot be proven, I believe the result would've been the same
if the function was literally spelled "depth" instead of symbolically
represented by the monadic use of the equivalence triple-bar.

Anyway, there's plenty of good debate in the ASCII v. symbol discussion
without this sidetrack.

--
/John



Tue, 06 Sep 1994 11:02:50 GMT  
 APL slash bang (Repost)
Bill Chang:
   I'm refering to using the same glyphs for related monadic and
   dyadic operators.  ... But the real cost of this is a syntactic and
   semantic ambiguity that cannot be resolved except at run time.  An
   expression like "FOO iota BAR" is inherently ambiguous--FOO can be
   a (global) function or a free variable (defined in some calling
   environment) that shadows such a function.

And strand notation makes this problem 10 times worse...

But it's not that hard to resolve the problem, even _with_ strand
notation [which I'm not arguing for, but am using as a worst case]:

[A] It can be assumed that all names which have current definitions
will continue to have that definition in the future.

[B] It can be assumed that all names which are assigned [in an
explicitly defined function] will always have the properties of that
assignment.

[C] It can be assumed that if the programmer wants some other behavior
(s)he can make an explicit interpreter call.

These rules only apply to compiling well-written programs.
Transliteration of dusty deck programs [which may be very badly
written] is another problem entirely.  Probably the best thing to do
in this circumstance is run the program under an emulator to collect
statistics about the program -- and feed this statistical information
into a compiler.  But there's no single solution to badly written
code...

Finally, if you don't mind looking at j, it's instructive to look at
how some of its program transliteration adverbs work.

--



Tue, 06 Sep 1994 20:24:50 GMT  
 APL slash bang (Repost)
Daniel LaLiberte:
   One important problem for an APL notation (to remain anything close
   to the original APL concept) is to treat user defined functions in
   the same way as infix and prefix operators.  Smalltalk has relevant
   ideas here.  Functional languages have ideas for notations of
   operating on functions as objects.

This may be an important problem, but it's also a solved problem.
J has some extremely powerful functional concepts built into its
notation.

To address some of the comments I've seen in this newsgroup in the
last couple days...  If you wish to guarantee that a function is only
used monadically, you can use
        fn : ''

Likewise, if you wish to guarantee that the function is only used
dyadically, you can use
        '' : fn

Armed with this piece of information, here's a routine to multiply two
'polynomials' [represented as vectors of coefficients]:

        sum=:  +/ : ''              NB. insert '+' between elements of arg
        fan=:     /.                NB. operator: apply fn on diagonal slices
        op=:   '' : (*/)            NB. outer product

        product=: sum fan X op Y    NB. multiply polynomials

Here, 'X' and 'Y' represent vectors, and 'product' is also a vector.
Alternatively, you could say:


        Prod=:  sum fan   compose op    NB. polynomial product

In this case, Prod is a function, and
        product=: X Prod Y
should give you the same result as before.

--



Wed, 07 Sep 1994 13:30:41 GMT  
 APL slash bang (Repost)


 (1)--------------------------------------------------------------------
 |   I think the use of greek letters, heavy overloading, and character
 |   combinations in APL is a big mistake, and this mistake is only
 |   compounded by J and the proposed ASCII rendition of APL.
 |
 |      .... more on the general subject of reducing the number of
 |    keystrokes being a silly goal at the expense of readability ...
 + ---------------------------------------------------------------------


 (2)---------------------------------------------------------------------
 |   Absolutly, positively correct.  I fail to see the point of reducing
 |   the whole suite of operators to every possible combination of
 |   punctuation marks.  Is this really supposed to be a language for
 |   Stephen Hawking, who is forced to "type" at less than a character per
 |   second?
 |  
 |   Come on guys, what is the point?
 + ---------------------------------------------------------------------


 (3)--------------------------------------------------------------------
 | The "point" is (to quote Kenneth Iverson):
 |
 |    "Applied mathematics is concerned with the design and analysis of
 |     algorithms or PROGRAMS.  The systematic treatment of complex algorithms
 |     requires a suitable PROGRAMMIWNG LANGUAGE for their description, and
 |     such a programming language should be concise, precise, consistent over
 |     a wide area of application, mnemonic, and economical of symbols..."
 |
 | This is the introduction to "A Programming Language" and shows that the
 | "greek" characters are mathematical in origin.  The conciseness is that of
 | mathematical ideas.  Yes, I could write 5+5+5, but that is interchangeable
 | with 3x5.  The "point" is to have a language that readly facilitates the
 | manipulations of mathematical ideas.
 + ---------------------------------------------------------------------

I agree with Mr Davis and Dr.Iverson.

The opinions expressed in quotations (1) and (2) appear to be dominated
by lack of experience.  Those who have studied higher mathematics,
APL, or J, will have learned the power of expressiveness of notation
used in these languages.  In particular, the "silly goal" mentioned
above, is not to find just the minimal number of strokes to express
ideas, but to be able to solve larger problems.  To Davis's quotation
of Iverson, I would like to add these two, which come from a philospher
and from the the builder of a computing engine.

      By relieving the brain of all unnecessary work,
      a good notation sets it free to concentrate on
      more advanced problems, and in effect increases
      the mental power of the race.
                                       A.N. Whitehead

      The quantity of meaning compressed into small
      space by algebraic signs, is another circumstance
      that facilitates the reasonings we are accustomed
      to carry on by their aid.
                                       Charles Babbage

--
Leroy J.{*filter*}ey, Faculty of Mathematics, U of Waterloo, Canada  N2L 3G1





Wed, 07 Sep 1994 02:42:05 GMT  
 
 [ 40 post ]  Go to page: [1] [2] [3]

 Relevant Pages 

1. APL slash bang (Repost)

2. APL/! (APL slash bang)

3. APL slash bang

4. APL! (APL bang)

5. APL! ("APL bang") and examples (REPOST)

6. To bang or not to bang

7. APL Newsreader & c.l.a Archive [REPOST]

8. APL Newsreader & c.l.a Archive [REPOST]

9. APL Newsreader [REPOST]

10. APL character set (Sun xterm solution) REPOST

11. APL Newsreader [REPOST]

12. APL Newsreader [REPOST]

 

 
Powered by phpBB® Forum Software