dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (08/25/89)
In article <10731@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes: >APL is the infamous right-to-left language. (APL hackers know that >theirs is the only correct language, because right-to-left prioritizing >is the same as in English. [stuff deleted]) >Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) I was told that due to the many operators of APL, it is very hard (read: impossible) to assign them a priority. So what they did was saying: let's give them all the same priority and evaluate an expression like: x <- 3 * 4 + 5 (the '<-' in APL is '=' in C) x becomes what is right of it, which is 3 times what is right of it, which is 4 plus what is right of it, which is 5 and nothing to the right. In other words: x <- 3 * (4 + (5))), or x = 27 (where in C x would be 17). So, the evaluation is from left to right, but the result is easier to understand when you read it from right to left. For those unknown to APL: do you know that APL is so compact that an algorithm to get the first N primes can be written in just *ONE* expression (of about 25 characters), including the reading of N from the terminal ? Another interresting thing of APL is that it is impossible to write a compiler for APL, and that is why there are only interpreters for APL. -- Dolf Grunbauer Tel: +31 55 432764 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands
ark@alice.UUCP (Andrew Koenig) (08/26/89)
In article <230@ssp1.idca.tds.philips.nl>, dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: > Another interresting thing of APL is that it is impossible to write a > compiler for APL, and that is why there are only interpreters for APL. Not true. There are compilers for APL. Hewlett-Packard had a very impressive one a dozen or so years ago. -- --Andrew Koenig ark@europa.att.com
henry@utzoo.uucp (Henry Spencer) (08/27/89)
In article <230@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >For those unknown to APL: do you know that APL is so compact that an >algorithm to get the first N primes can be written in just *ONE* expression >(of about 25 characters), including the reading of N from the terminal ? Yes, and a month afterward, even its author can't understand it without half an hour of study. I recall seeing an APL guru -- I think it was Iverson himself, in fact -- turn a straightforward algorithm (polynomial multiplication, I think) into a single line of APL. Quite impressive. Also impressive that said line was quadratic in space and exponential in time, where the original was linear in both. (I may have some details wrong, this was long ago.) >Another interresting thing of APL is that it is impossible to write a >compiler for APL, and that is why there are only interpreters for APL. There are some quite impressive APL compilers, actually. As with many such languages, the interpreter has to be around in the general case, but most real programs can be compiled quite satisfactorily. A really aggressive compiler can even produce something quite efficient. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
schwartz@shire.cs.psu.edu (Scott Schwartz) (08/27/89)
Henry Spencer writes: | Dolf Grunbauer writes: | >For those unknown to APL: do you know that APL is so compact that an | >algorithm to get the first N primes can be written in just *ONE* expression | >(of about 25 characters), including the reading of N from the terminal ? | | Yes, and a month afterward, even its author can't understand it without | half an hour of study. Just for fun, here it is: P <- (2=+ /- 0=(iN)o.|iN)/iN Where "<-" and "/-" are overstruck, "i" is iota, and "o" is the little open circle. It takes about 10 minutes to read the page long explaination in the handout I copied the expression from. Believe it or not, I once had a physics professor who went through "The C Programming Language" and translated some of the examples into APL, and scribbled them in the margins. Now _that_ was scary. -- Scott Schwartz <schwartz@shire.cs.psu.edu>
tgoodman@bbn.com (Todd Goodman) (08/28/89)
In article <1989Aug26.221107.25606@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >In article <230@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >>[ How one expression can be written in APL to compute the first N primes. ] >Yes, and a month afterward, even its author can't understand it without >half an hour of study. That's funny because I've heard a COBOL programmer say the same thing about C. All those weird operators you know. :-) >V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology >1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | Todd Goodman, BBN Communications, Inc. tgoodman@bbn.com | | Disclaimer: I never speak for anyone but myself. | +=-=-=-=-=-=-=-=-=-=-=-= "Right theory, wrong universe." =-=-=-=-=-=-=-=-=-=-=+
diamond@csl.sony.co.jp (Norman Diamond) (08/28/89)
I wrote: >>APL is the infamous right-to-left language. (APL hackers know that >>theirs is the only correct language, because right-to-left prioritizing >>is the same as in English. [stuff deleted]) In article <230@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >I was told that due to the many operators of APL, it is very hard (read: >impossible) to assign them a priority. So what they did was saying: >let's give them all the same priority [...] Yes; this was moderately reasonable. But why right-to-left instead of left-to-right? Take a look at the original APL manual, if you can find one. They state the reasoning which I cited, with even more details. >For those unknown to APL: do you know that APL is so compact that an >algorithm to get the first N primes can be written in just *ONE* expression >(of about 25 characters), including the reading of N from the terminal ? This is true indeed. Q. How many APL programmers does it take to change a light bulb? A. 35, and they all have to be in one line. Incidentally, a few years ago, I.P. Sharp (now part of Reuter) mentioned that they were embarrassed by the historic excesses of APL programmers, and they practice better software engineering techniques now ... even in APL. -- -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
evil@arcturus.UUCP (Wade Guthrie) (08/28/89)
henry@utzoo.uucp (Henry Spencer) writes: >In article <230@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >>For those unknown to APL: do you know that APL is so compact that an >>algorithm to get the first N primes can be written in just *ONE* expression >>(of about 25 characters), including the reading of N from the terminal ? >Yes, and a month afterward, even its author can't understand it without >half an hour of study. Well, this is not entirely true. My second language was APL; the thing that I learned above all else was documentation. When one works with, and learns to think in, a language that is inherently unreadable even to the least casual observer (:->), he tends (in some, rare, instances) to compensate by documenting the poo out of the code and striving for ways to express himself clearly. Yes, even APL can be made to be readable, although I would not call it an altogether pleseant or trivial exercise. I think that learning APL at such an early (and impressionable) stage in my programming career was an extremely valuable prelude to programming in C; consider expressions like: blah = *((char * (*)())snarf(*stuff)); (it's been a while, the syntax probably stinks, but you get the idea. . .) Wade Guthrie evil@arcturus.UUCP Rockwell International Anaheim, CA (Rockwell doesn't necessarily believe / stand by what I'm saying; how could they when *I* don't even know what I'm talking about???)
richard@aiai.ed.ac.uk (Richard Tobin) (08/29/89)
>There are some quite impressive APL compilers, actually. As with many >such languages, the interpreter has to be around in the general case, Or else the compiler has to be around. I don't know if there are any such APLs, but there are lisp systems without an interpreter at all - when you type in an expression, they compile it and execute the code immediately. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nsfnet-relay.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) (08/29/89)
In article <9828@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >In article <230@ssp1.idca.tds.philips.nl>, dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >> Another interresting thing of APL is that it is impossible to write a >> compiler for APL, and that is why there are only interpreters for APL. >Not true. There are compilers for APL. Hewlett-Packard had >a very impressive one a dozen or so years ago. > --Andrew Koenig > ark@europa.att.com I think it is possible to have some sort of a precompiler for APL, which does syntax and semantic checks for most functions basically to speed up the actual interpretation. I expect APL works like this. But, as it is possible in APL to build text strings and execute them as APL code, you will need to compile (or interpret) this string at runtime. The same thing applies to input, as input for APL can be the result of an APL statement, including using the global variables. In this case the input has to be compiled and executed (like in: "RHO n" to get an array). This means that during runtime of an APL program, you will still need the compiler/interpreter of APL. This is different from languages like C, where you can (for example :-) throw your compiler away and your compiled program still works. When you do this with your APL compiler, probably most of the APL programs will work, but not all. This is why I think (an to be true: was told) it is not possible to have an APL compiler, in the sence of a C or FORTRAN compiler. I think Henry Spencer meant this problem when he wrote: > There are some quite impressive APL compilers, actually. As with many > such languages, the interpreter has to be around in the general case, > but most real programs can be compiled quite satisfactorily. A really > aggressive compiler can even produce something quite efficient. -- Dolf Grunbauer Tel: +31 55 432764 Internet dolf@idca.tds.philips.nl Philips Telecommunication and Data Systems UUCP ....!mcvax!philapd!dolf Dept. SSP, P.O. Box 245, 7300 AE Apeldoorn, The Netherlands
ray@philmtl.philips.ca (Raymond Dunn) (08/29/89)
In article <818@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >.... there are lisp systems without an interpreter at all - >when you type in an expression, they compile it and execute the code >immediately. This just shows that a very hazy line separates "compilers" and "interpreters". There are many of us who would still call such an incremental compiler an interpreter. -- Ray Dunn. | UUCP: ..!uunet!philmtl!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090
diamond@csl.sony.co.jp (Norman Diamond) (08/30/89)
In article <818@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >>.... there are lisp systems without an interpreter at all - >>when you type in an expression, they compile it and execute the code >>immediately. In article <673@philmtl.philips.ca> ray@philmtl.philips.ca (Raymond Dunn) writes: >This just shows that a very hazy line separates "compilers" and "interpreters". >There are many of us who would still call such an incremental compiler an >interpreter. There is a difference. The compiled code can be executed again without requiring compilation again. 1000000 * (execution time) + 1 * (compilation time) usually < 1000000 * (interpretation time). -- Norman Diamond, Sony Corporation (diamond@ws.sony.junet) The above opinions are inherited by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo or Anterior, then their administrators must have approved of these opinions.
jpd00964@uxa.cso.uiuc.edu (08/31/89)
/* Written 1:21 pm Aug 27, 1989 by tgoodman@bbn.com in uxa.cso.uiuc.edu:comp.lang.c */ /* ---------- "Re: Right-to-left (was: Re: entry a" ---------- */ In article <1989Aug26.221107.25606@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >>In article <230@ssp1.idca.tds.philips.nl> dolf@idca.tds.PHILIPS.nl (Dolf Grunbauer) writes: >>>[ How one expression can be written in APL to compute the first N primes. ] >>Yes, and a month afterward, even its author can't understand it without >>half an hour of study. > >That's funny because I've heard a COBOL programmer say the same thing about >C. All those weird operators you know. :-) And they are right. That's why everyone comments there code. Don't You? I also flowchart (stop snikering), don't you? Seriously, All of the people under me are told to comment there code. I tell them at least once a week if not more. So far, I've gotten about 15 lines of code commented. Most of the comments are worthless. Any lingo is hard to follow if there are no comments. Michael Rutman Softmed disclaimer: I am high enough up that I don't need one. Anyone got a grudge, bitch to me!
mcdonald@uxe.cso.uiuc.edu (08/31/89)
In article <818@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >.... there are lisp systems without an interpreter at all - >when you type in an expression, they compile it and execute the code >immediately. and ray@philmtl.philips.ca replies: >This just shows that a very hazy line separates "compilers" and "interpreters". >There are many of us who would still call such an incremental compiler an >interpreter. There is an obvious distinction between an incremental compiler and an interpreter: an incremental compiler generates actual machine code of the CPU at hand (NOT pseudocode) and then executes it. As an example of the importance of the distinction, it is very easy to write an interpreter for just about any language in C. (Well, easy in concept.) BUT, the C standard does not guarantee that it is even POSSIBLE to write an incremental compiler in C. Not that it prevents it, just that it does not guarantee that the code you generate can be executed. It appears that there are a very few machines (&OS's) where incremental compilers are indeed actually impossible. Doug McDonald
ray@philmtl.philips.ca (Raymond Dunn) (09/02/89)
>In article <818@skye.ed.ac.uk> richard@aiai.UUCP (Richard Tobin) writes: >.... there are lisp systems without an interpreter at all - >when you type in an expression, they compile it and execute the code >immediately. and ray@philmtl.philips.ca replies: >This just shows that a very hazy line separates "compilers" and "interpreters" >There are many of us who would still call such an incremental compiler an >interpreter. then mcdonald@uxe.cso.uiuc.edu writes: >There is an obvious distinction between an incremental compiler >and an interpreter: an incremental compiler generates actual machine >code of the CPU at hand (NOT pseudocode) and then executes it. > > [goes on to say you can nearly always write an interpreter in 'C' but > have no guarantee that you can generate and execute real machine code > in 'C'] I'm sorry, I've got us bogged down in semantics. (:-( I've no problem with the substance of the above argument, I have a problem with the narrow use of the word "interpreter". To me, there are many shades of implementations which fall under the interpreter umbrella, including those which start from source every execution, those which save pseudo code, and those which actually produce code which is executed, whether it is saved for the next time each statement is executed or not. Even the boundary between pseudo code and real code is fuzzy. There are systems which, instead of producing actual pseudo code produced a sequence of subroutine calls which is executed, or a minimal code set like push,pop,call and jump. Putting it another way, it is possible to chose a "pseudo" code which is directly executable. Hey, who cares huh? All I'm contending is that the line where these systems stop being "interpreters" and start being something else, is fuzzy. Follow-ups to comp.lang.misc. -- Ray Dunn. | UUCP: ..!uunet!philmtl!ray Philips Electronics Ltd. | TEL : (514) 744-8200 Ext: 2347 600 Dr Frederik Philips Blvd | FAX : (514) 744-6455 St Laurent. Quebec. H4M 2S9 | TLX : 05-824090