kwh@bentley.UUCP (KW Heuer) (05/14/86)
In article <1418@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In article <788@bentley.UUCP> kwh@bentley.UUCP writes: >>I can feel the flames ("More operators? It's getting as bad as APL!"). > >"More operators? It's getting as good as APL!" -- except that it still >falls way short in this respect. I'm serious; APL does *not* have too many >operators. It does have too little structure. The primitive functions in APL correspond roughly to C operators *and* the entire runtime library. I agree that APL does not have a problem there. APL has its own character set; C is restricted to a subset of ASCII. The size of the alphabet is not a serious problem since new operators in C may be multi-character; however, this may make them less mnemonic. (Of course, some of the APL characters are not all that mnemonic either: "x" for signum is a good example.) The reason APL can deal with having so many primitives is that they all have the same precedence. Adding that many operators to C would be a disaster. You say APL has "too little structure". If you mean things like "while" and "if", I think they may be unwelcome. Put in a "while" loop, and people will start using it to implement a matrix multiply. (For those who don't get it, APL has a builtin matrix multiply, "+.x".) The language doesn't need much program structure, because it has data structure in its place. Now, I *would* like to see some improvement in the data structure. It's now practically impossible to write a function which expects, say, three string (character vector) arguments. I like the grounded tree model, myself, as a fix for this. Also, APL is *severely* in need of *variable declarations*! Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint *** Please restrict followups appropriately! {net.lang.c|net.lang.apl} ***
ljdickey@water.UUCP (Lee Dickey) (05/16/86)
There are several APL's that admit data with tree structure. An older example of one of these is Honeywell's GCOS APL, which since the early 70's ran on its 66 series machines, and now runs on its DPS 8 line. GCOS APL allows things of the sort a <- 'now is the time' b <- 'next one' c <- 'the third' list <- (a;b;c) and more. A list may contain, as an element, any other list. You can construct a tree. Honeywell is not agressive in marketing this product. Today, there are two newer APL's that use strand notation, APL2 and STSC's production APL. Perhaps the best known of these is IBM's product: APL2. There, one uses "strand notation" and one types something like list2 <- 'now is the time' 'next one' 'the third' or list2 <- a b c Of course, allowing this sort of statement introduces a lot of power in the data, but introduces new complications in the syntactic analyzer. On the other hand, another new implementation is the one done by I.P.Sharp Associates. There one builds arrays in which each element of the array is a scalar (same as in APL). But there are new primitives called enclose and disclose. The result of enclose is always a scalar. Disclose is a left inverse of enclose. Then, for any data object, BLAT, BLAT <---> disclose enclose BLAT A fourth implementation is NIAL (Nested Interactive Array Language) developed by Mike Jenkins at Queens' University in Kingston. His language runs on UN*X machines and on IBM PC's. It appear to be a super set of APL, and uses keywords. It has rooted trees, and it has Pascal like structured statements. Perhaps the Sharp version is the most esthetically beautiful and has the simplest theory. The strand notation supported by APL2 may be easier to use if the for trees are simple, but I am told that some trees can not be modelled in this APL. NIAL has the advantage that it does not have to have a special keyboard, it has all the power of APL, and it has structured control statements. ---------------- Yo pays yer money an' yo takes yer choice.
franka@mmintl.UUCP (Frank Adams) (05/20/86)
In article <812@bentley.UUCP> kwh@bentley.UUCP writes: >You say APL has "too little structure". If you mean things like "while" and >"if", I think they may be unwelcome. Put in a "while" loop, and people will >start using it to implement a matrix multiply. (For those who don't get it, >APL has a builtin matrix multiply, "+.x".) The language doesn't need much >program structure, because it has data structure in its place. I disagree. "if/then/else" would be very useful in APL. You wind up using go to (->) instead. This is bad for the same reason it is bad in other languages. The data structuring somewhat reduces the need for such things, but not all that much -- particularly for complex applications. People can write a matrix multiply using go to right now. There is no cure for idiocy, and only one for ignorance. >Now, I *would* like to see some improvement in the data structure. It's now >practically impossible to write a function which expects, say, three string >(character vector) arguments. I like the grounded tree model, myself, as a >fix for this. Also, APL is *severely* in need of *variable declarations*! I had both program and data structure in mind when I made that statement. One advantage of a proper implementation of variable declarations is that one would be able to define a function as operating on, say, two scalar arguments; if invoked with two arrays of the same dimensions, it would automatically be called for each corresponding pair of scalars. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108