Talk:APL (programming language)/Archive 1
This is an archive of past discussions about APL (programming language). Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
Air Traffic Control System
APL is renowned for ... being able to express an air traffic control system in two lines of code.
I suspect this may be an exaggeration. --Brion 22:08 Sep 20, 2002 (UTC)
- Probably, but it's not too far from the truth, and may well be literally true for some appropriate definitions of "line" and "traffic control system". It really does capture something of the flavor of the language; I'd be inclined to call it a colorful way to express that, or a rhetorical exaggeration. I don't think figures of speech like that are entirely out of place here. --LDC 22:23, 20 September 2002 (UTC)
- Well, the quote about shuffling and dealing a deck with four non-standard characters is most certainly an exaggeration. The program is (I think) "13 4⍴52?52". Besides, that's just for four players, and a program for Rook would be three times as long. Quamaretto 15:41, 28 February 2006 (UTC)
J is not APL
J is not a successor language, continuation, or update to APL. It is a separate entity with a life of its own. J shares with APL the name of Ken Iverson as a designer or implementor, but as far as APL is concerned, a brief note that Iverson went on to create J and a link to the page is all that is appropriate. Any other information about J belongs on the J page. With all due respect to the individuals who started and created J, unless they have had some influence on APL development, their names belong on the J page.
Specifically, I find the following lines out of place, if not wrong:
In the early 1990's Iverson, along with Roger Hui redesigned the APL language, calling the update the J programming language. J removed the requirement for the special character set, fixed some ambiguous syntax, and added support for John Backus' functional programming ideas.
(Can I order a J update for APL2 from IBM?)
Around the same time, a sentence to the effect of APL featuring a custom character set disappeared. Presumably, this so-called Update to APL eliminated, in one fell swoop, the nagging character set problem which has plagued APL all these years. Credit for this belongs to J, which is not APL.
A little later:
In 1989-90 Iverson and Roger Hui collaborated on an update to the APL language called J [1]. J removed the requirements for APL's special symbols, using the ASCII character set for all functional symbols. In addition, J improved upon APL's function-level programming features, allowing true value-free algorithm definitions. Compiled binaries (but not source) for the J language interpreter are available at no cost at [2]
(The question of update aside, this information belongs in the J page)
What is a "value-free algorithm"? One free of any value, i.e. worthless? I've written plenty of programs like that. Does the author mean "lambda expression"?
I'm sure that the author meant well, but to me, this is just plain incorrect.
Dinsdale Doug Piranha (talk) 08:37, 4 June 2008 (UTC)
From Vector, Vol 9, No, 4, An Implementation of J, Roger Hui's presentation to the British APL Association on 12 February 1993
One of the questions raised by a member of the audience was:
Q: Is J APL? A: Yes - it is obvious that J is advanced APL thinking.
Cowznofski (talk) 20:53, 2 July 2008 (UTC)
He's at it again!
In the late 1980s Ken Iverson and Roger Hui collaborated on an update to the APL language which they called the J language. The updates were intended to fix some of the issues that Ken had encountered over the years with APL, such as the difficulty of supporting an non-ASCII character set, and array indexing syntax, among other things. Ken intended that the J language be an improved dialect of APL. Today, the J interpreter is still one of the few completely free array languages, available from J Software
Again, this information, though not altogether wrong, doesn't belong on this page. This information belongs on Ken Iverson's page, Roger Hui's page, and on the J page. This information is about J.
APL Keyboards (Less is More)
I feel excessive discussion has been devoted to APL keyboards. Unless this is a computer (and terminal) in a museum somewhere, no APL implementation has required the user to overstrike two characters for at least 25 years. Today, very little of this discussion is relevant, as this is distant history. Anyone remember the HDS terminals? Did they even survive into the 1990s?
Since the introduction of the IBM PC in 1982, the sales of standalone, dumb terminals, APL or otherwise, has mostly collapsed. The IBM PC was the new dumb terminal, and as it was far from dumb, the APL vendors took liberties to build better keyboards. The earlier ones were called the Union or Unified keyboard, the idea was that "normal" characters were in "normal" positions, and APL glyphs were accessed by an ALT-gr sequence without any dead keys (European and other keyboards feature dead keys to put accents on or under letters in a manner not entirely unlike overstriking). The union keyboard was based on the IBM 3270 APL keyboard, which was overstrike-free. Also mostly irrelevant today.
Today, nearly all vendors feature a variant of the Union keyboard. The problem is that each is a bit different. The existing link to a Union keyboard is, in reality, a picture of the A+ keyboard, which is a sort of outlier with respect to the other vendors' keyboards.
More recently, vendors have been placing a "language bar" in the user interface. Like the choose symbol featured in Microsoft Word, instead of tediously hunting for a particular APL glyph on the keyboard, you click the one you want. Bravo! This silly problem is finally gone.
APL and Unicode
More vendors are adopting Unicode as the standard. Especially when it comes to input of APL glyphs, this concept seems to be widely misunderstood.
Both EBCDIC and ASCII featured a 256 character set, the number of glyphs which would fit into a 28 number. As APL had new glyphs of its own, references to them were traditionally placed in unused or seldom used positions in said 256 position vector. This was usually called []AV. Naturally, all []AVs were different, one vendor (Sharp) had underscored small letters in their []AV, most others had line drawing characters.
With Unicode, the restriction of 256 characters has been increased to 65536 (or more), which is hopefully enough to accomodate Kanji, Mandarin, Cantonese, (all of these should have a large set in common), Hiragana, Katakana, Hangul, Thai, Hebrew, Cyrillic, and APL. In principle, []AV should go away, as it now should return every glyph in Unicode.
Whether it prints is a question of whether a unicode font exists and its completeness.
The presence of unicode does not materially improve entry of APL glyphs. This is still the vendors' problem.
The presence of unicode, however, greatly improves situation which require the transmission or display of APL characters outside the traditional APL environment. You can today more or less cut and paste code between some APL systems, such as APL2000 or Dyalog. A few glyphs are not correctly mapped, such as zilde, but by and large the bulk of the text makes it over successfully. With Unicode, however, one can cut an paste code directly into an email message, web page, or whatever text repository with the guarantee that it will come out exactly as put in. Provided whatever Unicode feature is installed.
APL character set
The current table doesn't do much for me, and I know I have Unicode installed. LaTeX has most, if not all, of the characters (I'm still figuring out how to get the sort function to work in LaTeX). Meanwhile, here's an APL keyboard layout image.... I'm working on permissions.
-- UtherSRG 15:55, 12 May 2004 (UTC)
I've commented out the table again. Perhaps some explicit instructions how how to ensure readability would be good. I know I have Unicode installed, but I can not see most of the APL symbols. - UtherSRG 14:24, 13 May 2004 (UTC)
- Instructions will depend on the system you use. Some browsers (e.g. Mozilla and Lynx under Linux) show all APL characters without any additional setup whatsoever. There is no reason to hide the table, because it is not essential here. Perhaps it will prompt readers to get an APL-compatible font if they are really interested in APL. — Monedula 14:48, 13 May 2004 (UTC)
- I'm really interested in APL and I can't figure out what's wrong. I have MSIE 6.0.2. I have Unicode installed. What else is required?
- Leaving the table there and broken for the majority of folks is not acceptable withouth giving good instructions on how to view it. When I asked Rex Swain (owner of the keyboard image) to use his image, he visited the page and said he couldn't view the table. There aren't many folks more interested in APL than he is. - UtherSRG 15:01, 13 May 2004 (UTC)
- The broken table has made you aware of a problem? It is very good!
- Now the instructions. In MSIE go to menu, press Tools, then Internet Options. In the dialog box press the button Fonts.... The "Fonts" dialog box appears. In the Language script box select "Latin based". Now in the Web page font box select a font what contains the APL symbols. One of such fonts is Arial Unicode MS. This font is supplied with "Microsoft Office" — if you have istalled it, then you should have the font. If not, copy this font from someone else's machine. Or get any other font that is both APL- and Unicode-compatible and install it, and then select it in the Web page font box.
- In any case, displaying characters is the browser's problem, not Wikipedia's. Wikipedia supplies information, browser displays it. Do not break up this division of labour. — Monedula 15:31, 13 May 2004 (UTC)
Outdenting...Thanks for the instructions. As things stand, I have the following fonts that should display the APL symbols: Lucinda Sans Unicode, SImPL, VectorAPL, and SILDoulosUInicodeIPA. Of these, only SImPL displays the APL characters in the table, and the font is ugly for regular text. I've now installed Arial Unicode MS and things are good.
I'm fully in agreement with the division. It's just that when the information is only viewable if the user performs a reconfiguration, then it isn't really information, only raw unintelligible data. Doubly so when there are no instructions on how to perform that reconfiguration. - UtherSRG 15:57, 13 May 2004 (UTC)
Now, to complaints about the table's contents. It seems this table is far from complete. While the table has many overlayed characters, it doesn't have all of the individual characters used in the overlays, only the special characters. I think it wouldbe beneficial to have all of them, including the "common" characters like ?, (, and ). - UtherSRG 16:04, 13 May 2004 (UTC)
- If we include ? and ( ), then probably we should include A-Za-z and 0-9 also?
- As to browsers: I believe that future versions will display a much wider range of characters, perhaps downloading fonts automatically when they encounter something new. — Monedula 18:10, 13 May 2004 (UTC)
May I make a suggestion? Start with the current ("Unified") keyboard, and work backwards through time. The old stuff, although interesting, is not as important as what is currently done.
The current keyboard table and the previous one (from Rex Swain, the black letters and lines on sort of a buff background) reflect the way it was in 1966. I've seen the picture hundreds of times over the last 30 years, it's a picture of an IBM Selectric, known today as the "Classic" APL keyboard. Since then, the following has happened:
- APL/ASCII printer terminals came into the picture (a few new characters) - mostly Diablo-style daisywheel printers
- Dot matrix printers and video display terminals, Decwriter, Datamedia, HDS, others
- IBM 3270 family with its alt keyboard
- IBM PC comes out, STSC APL/PLUS*PC shortly afterwards. The latter includes a character generator chip
- Special (Non-IBM) APL terminals etc. rapidly become extinct
- Paul Berry (or someone like that) at IPSharp develops the "Union" keyboard. The big idea is to leave the usual ASCII characters in the usual ASCII places, and make the APL symbols available with alt key sequences. Suddenly we see APL code with lower case letters. This would have been in the early 1980s.
- STSC comes out with their PC product and this has the "Unified" keyboard. Not sure what the real differences between "Union" and "Unified" are.
- STSC also drops (and a good thing too) the idea of undescored letters, and uses upper and lower case instead.
- Slowly the world switches over to some kind of Unified keyboard. I was a late bloomer - didn't make the switch from Classic Keyboard to Unified until 1998 or so.
Cowznofski 16:24, 10 February 2007 (UTC)
What do you think of the language J as an APL renewal? Marc Venot 02:24, 3 Aug 2004 (UTC)
- J is very, very impressive. If you haven't tried it, give yourself a chance and download it: it is free. IMO, it is more powerful and much more orthogonal than any other APL I've seen. The only unsatisfied wishes I can think of when I use it are:
- I miss the user data type features provided by Backus FL (several of the more powerful J ideas come from FP via FL)
- ditto for the exception handling mechanism in FL
- direct, primitive support for dictionaries (K's handling of its namespaces through standard dictionaries would be very nice to have) and trees.
- pattern-based case parsing at function definition time (à la Miranda or Haskell)
- full, Perl-level, primitive support for regular expressions (currently it is handled through a library)
- the fact that not all primitives work transparently on both dense and sparse arrays (although many do)
- the fact that its Linux version runs on a Java-built interface, instead of, say, Qt
- K's mature support for data warehouses and other OLAP-related tasks
- last, but never least... a different way of encoding the dictionary verbs (J uses the idea of extended base characters for related functions, so that if
+
means something, then+.
means something related and+:
means something else related too... the problem is that all my years of reading have though my brain to see the '.' and ':' chars as separators and it is very hard to learn to see them attached to another character in an undivisible pair... furthermore, there is no lexical distinction between the monadyc and dyadic uses of a verb, making it even more difficult to parse what already are very dense (in the information-load sense) expressions)
- In the end, though, J is the most powerful language I have ever used, and I would not consider anything else (except some kind of J descendant) to use as my main programming tool, at any price. When I work with J, I see things differently, in a fun, always entertaining way. Hope this helps a bit. — danakil 02:44, Sep 6, 2004 (UTC)
quote by dijsktra
"APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums". (Edsger Dijkstra)"
I have removed the quote by dijkstra on the following grounds:
- The criticism was made towards the early versions of APL, particularly targeting its lack of support for structured and modular programming, at a moment where these two disciplines were taking over the world by storm.
- Computer science was an explodind, intensely competitive field at that time, and thus it was then much more common for computer science luminaries to express themselves in ways that might have been customary then, but that today would be less acceptable for a serious researcher.
- Finally, I will cite another quote by Dijkstra, criticizing another (now well respected) programming language for which I will initially remove the name calling it 'X' (note, please, that I have the greatest respect of Dijkstra's capabilities, and this is just to show that it is easy to obtain a quote supporting almost any topic from any great mind's past):
- "X had its serious shortcomings: what became known as "shallow binding" (and created a hacker's paradise) was an ordinary design mistake; also its promotion of the idea that a programming language should be able to formulate its own interpreter (which then could be used as the language's definition) has caused a lot of confusion because the incestuous idea of self-definition was fundamentally flawed. [...] My first introduction was via a paper that defined the semantics of X in terms of X, I did not see how that could make sense, I rejected the paper and X with it. My second effort was a study of the X Manual from [Academic Institution] which I could not read because it was an incomplete language definition supplemented by an equally incomplete description of a possible implementation; that manual was poorly written that I coud not take its authors seriously, and rejected the manual and X with it." (Dijkstra, Computer Science: Achievements and Challenges)
- Guessed which the language is? Right. Lisp. This should throw some light into the issue of how much weight can be given to his previous quote regarding APL. Dijkstra was a genius at computer science, but Iverson's and McCarthy's genius lay somewhere else, in the specific field of languages and systems that help people think. — danakil 02:25, Sep 6, 2004 (UTC)
- Based on reading a fair amount of his writing throughout his career, as well as from personal interaction with Dijkstra, I disagree with some of your reasoning. First, I see no reason to believe that his negative judgment about APL would have been any less negative for the latest version. Second, while his style of criticism may not be PC, it is nevertheless the style he used throughout his entire career. You can find comments at least as blunt (or inflammatory) throughout the years. The notion that this quotation reflects the early days of computer science only is simply incorrect. By the way, that doesn't mean I disagree with removing the quotation; I just want to disagree with the comments you made about that action. Paul Koning 21:01, 3 July 2007 (UTC)
quote by David Given
Is the "shuffling cards in four characters" quote true, or is it just a joke? If the former, the four characters should be given in the article; if the latter, maybe a comment to that effect would be nice.
The expression 52 ? 52 will give you a pseudo-random permutation of the numbers from 1 to 52 (or 0 to 51, depending on the current index origin). This can reasonably be called "shuffling cards" although to display this list of values as symbols for cards would take a little more code. This is 5 characters, but only 3 symbols, as i would call a single number a single symbol, no matter how many digits it needs to represent it. In fact, this function is called "deal" which makes the suggested use tolerably obvious. Of course all of these characters appear on a standard keyboard.
To represent dealing 52 cards to 4 players, one might write something like:
D {gets} 4 13 {reshape} 52 ? 52
That is 11 characters, two of which are non standard: {gets} which represents the left-pointing assignment arrow, and {reshape} which represents the shape/reshape primitave function, a version of the greek character rho in a standard AL character set.
Do you think this like of code, perhaps in an image foramt should appear in the article to clarify (and in part debunk) the quote? DES 18:09, 21 Feb 2005 (UTC)
Actually, I meant it as a joke. I am slightly bemused at how an off-hand remark I made in 1998 on Usenet found its way into Wikipedia (original post), but that's Usenet for you... David.given 19:19, 20 January 2007 (UTC)
One sense in which the quote is both true and illuminating is that a deck "D" can be shuffled into ordering "S" by the vector indexing operation D[S] - 4 characters - an excess of 1 that Iverson later decided could be expressed in just three. But they are standard typewriter characters, all the more perplexing because, even as late as 1998, few formal languages defined indexing as generally as APL did. It was certainly the kind of trick that tended to dazzle Fortran programmers in the 70s. 67.184.17.36 (talk) 00:01, 8 December 2007 (UTC) Greg Jaxon
Humourous Rhyme
Tis the dream of each programmer Before his life is done, To write three lines of APL And make the damn thing run.
I remember seeing this posted prominently in someone's office at Sharp Special Systems in Toronto in the early 1980s. The Special Systems guys were not APLers, but rather programmed in something like C or Fortran. Except that the dream was to write two lines of code, not three.
I never found this particularily funny, mostly because I always felt that APL was so incredibly easy. However, I feel that this rhyme is well placed and belongs here.
--Cowznofski 29 Nov 2006
Overview
The line used to read:
As APL has so many nonstandard primitives (functions, operators, or features built into the language and indicated by a single symbol or a combination of a few symbols),
APL has built-in functions and operators, and that's about it. As far as other symbols ("features built into the language and indicated by a single symbol"), they are few:
- Branch Arrow - not a primitive really, but a bit of punctuation. More like a control structure.
- Diamond - this is a statement separator. Not a function. No version of IBM APL had this until fairly recently.
- Semicolon - used to separate a list of local variables in a function header or list of subscript expressions in old indexing.
- Colon - used to indicate a line label.
I have changed this sentence accordingly.
--Cowznofski 10 Dec 2006
Examples
Why explain APL sentences from right to left? In practically all programming languages execution of the parsed text results in execution from right to left, complicated by the rules of precedence. I never saw anybody explaining a Fortran sentence from right to left, although that is precisely what happens during execution. If I remember well the "APL360 Primer" explicitly stated that APL statements should be read from left to right. The absence of function precedence makes interpretation quite simple: apply the function to everything that follows.
If we take the example , the comments don't tell us "what" the statement does but only "how" it does it. It certainly is not an illustration of the traditional definition of a prrime which is "only divisible by itself and by 1". Looking from left to right however we see that a selection is made of the elements within (BTW it is considered very bad APL programming practice to have a variable reassigned within the same statement, unless for sound reasons. <iota N> would have been cleaner than <iota R>). The selection part within parentheses tells us that "all elements of R are selected which are not present in" ( ) "all the possible pairwise products of elements of R" ( ). In other words a prime is defined as "an integer which cannot be represented as a product of two integers smaller or equal to itself and larger than 1". All one needs is knowledge of traditional mathematical and logical symbols, the APL representation of outer product and knowledge of the select operator. In fact only the select operator is new, all the rest can be considered as "public domain knowledge".
Starting from the traditional definition of primes and knowing that a divisor A of B is smaller or equal to B and leaves a rest of zero and that, for the natural numbers, the rest is the result of a modulo-division ( ) the statement "select from R all elements where 2 equals the sum of all its divisors" (including 1) we get immediately where is read as "sum" (the [1] is a technicality since, in a matrix, sums can be made either along rows or along columns). When reading the statement from left to right the only difficulty is knowing that represents "all divisors".
For a beginner, the main difficulty in reading APL from left to right lies usually in the "." operator which defines a generalized inner and outer product and hence a plethora of idioms like in the sort example ("sum of all characters/numbers not equal to"). These idioms are sometimes difficult to formulate in normal speech and, more often than not, need complete subroutines in traditional (i.e. almost all) computer languages.
--Gvandor 19:29, 4 July 2006 (UTC)
On the one hand, this classic code fragment shows "APL's expressive power", but is also an interesting example of another, less publicized, and more insidious weakness of APL: Overcomputing. Granted the APL approach is to avoid iteration, here the problem is that a huge intermediate result is generated. Clearly, other algorithms exist, but without the theater. Brevity can be a two-edged sword.
As for innner products, i.e. +.=, ^.=, a more correct view for the beginner would be to view these compositions as functions in their own right, an idiomatic approach. Many interpreters even work this way. Operators take functions as arguments and produce derived functions. For purposes of learning, however, viewing +/ as a sum function is upwards-compatible with the operator - function - argument hierarchy.
--Cowznofski 24 Nov 2006
I think the new examples which recently (around 10 Feb 2006) appeared were very appropriate and quite suitable for inclusion. However, I think that in all fairness to the guy who might want to type the code fragments in and give them a try, the examples should be vendor-neutral wherever possible. Both examples could easily be expressed without the dynamic function {} and commute "~ operator, as a courtesy to the guy who wants to try the example on his colleague's APL2000 or APL2 system.
Cowznofski 08:43, 10 February 2007 (UTC)
- APL is read from right to left because that's how the language is defined. So why does it do that? I believe it is to allow the same operator associativity rule to apply for all operators. Most languages associate left to right except for assignment, which is right to left. APL is consistent -- everything is right to left. That's also rather confusing. The programming language POP-2 solved this issue in the opposite way: everything is left to right. That includes assignment, which is a right-pointing arrow with the variable being assigned on the right hand side. Paul Koning 21:03, 3 July 2007 (UTC)
Sort Example
I cannot see whether it is correct or not (since indeed APL is a write-only language) -- but at least: where is the SORT operator?? --217.245.7.251 12:39, 5 Feb 2005 (UTC)
The primiive functions grade up, and grade down ((“) and (”) view with an APL font) -- they are not operators in APL terminology -- sort arrays of numeric values. If the array is multi-dimensional, a multi-way sort will be performed. The result is the set of indicies needed to reshape the array into a sorted form. Sorting of character data is also provided by these functions, but a left arguemt giving the collating sequence to be used must be supplied. A complex sequence (for example, upper and loewr case letters rating as identical unless needed to break ties) can be provided by using a multi-dimensional left argument. DES 17:50, 21 Feb 2005 (UTC)