Author 
Message 
Bill Cha #1 / 40

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 premodifier tilde ~ signifying oppositeness, and a postmodifier 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 (rowwise) +. (columnwise) Special: ! initial segment of indices, index of ? membership /. compress, reduce (cumulate) \. expand, scan (partials) ~/. ~\. (columnwise) # 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 &. deltaunderscore ~& 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 "Bconform A" !10 "initial ten" !/A "indices A" B!A "Bindices A" ((!/A)=A!A)/.A "A minus duplicates" [indices A equal Aindices A, subset A] +/.^.\. "find first zero" [cumulativeadd allone leftpartials] +/.^.\..' '=A "count trailing blanks" [find first zero, backwards, in spaceequalA] (+/.^.\..' '=A)~A "A minus trailing blanks" (+/.^.\..' '=A).A "rightjustify A" [rowwise circular shift, trailing blanks to front] (!10)(.*.)(!10) "tenbyten multiplication table" A(+).(*)B "matrix product" A(<.).(+)A "shortest paths, one stopover" >(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 


Daniel LaLiber #2 / 40

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 higherlevel 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 nonmeaningful 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 lefttoright evaluation order, but this is not as big an issue.) Dan LaLiberte

Mon, 05 Sep 1994 02:56:03 GMT 


Bill Cha #3 / 40

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 higherlevel 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 nonmeaningful 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 lefttoright 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 alternativesbut 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 


Steve R #4 / 40

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 


Sam Sirl #5 / 40

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 


Daniel LaLiber #6 / 40

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 operatorlike 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 


John Ger #7 / 40

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 triplebar. 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 


Raul Deluth MillerRockwe #8 / 40

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 ambiguousFOO 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 wellwritten 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 


Raul Deluth MillerRockwe #9 / 40

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 


L. J. Dick #10 / 40

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 


Page 1 of 3

[ 40 post ] 

Go to page:
[1]
[2] [3] 
