hafer@infbs.UUCP (Udo Hafermann) (05/02/89)
Are there any APL implementations which preserve the function source text as entered by the programmer, instead of just throwing all non-relevant white space away? The way APL functions are reproduced in the literature seems to indicate that this is a non-issue. Nevertheless I find this "feature" to be *very* annoying - and a severe hindrance for newcomers to APL who often complain about the "look and feel" of APL code anyway.
stripes@wam.UMD.EDU (05/03/89)
In article <1193@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes: >Are there any APL implementations which preserve the function source >text as entered by the programmer, instead of just throwing all >non-relevant white space away? The way APL functions are reproduced in All of the APL*PLUS\Unx systems keep it, and so does APL*PLUS II (for 386 MS-DOS boxes... really APL*PLUS\Unx with a nice front-end, and implmenting just about every one of thoes horrid Quad-Pokes), and APL*PLUS\Vax which is also a port of the Un*x version. (Of the three only one supports the Unified keyboard 'tho). I think APL*PLUS\Mac does also, but it's not exactly "the worlds best APL". -- stripes@wam.umd.edu Disclaimer: Josh_Osborne@Real_World,The I no longer work for STSC, but "The dyslexic porgramer" still like (most) of their stuff
rdnelson@phoenix.Princeton.EDU (Roger D Nelson) (05/03/89)
In article <1193@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes: >Are there any APL implementations which preserve the function source >text as entered by the programmer, instead of just throwing all If I understand the question correctly, several do. In particular, the STSC APL for 80286 and 386 allows you to put white space where you want it, and so does MicroAPL's APL.68000 for the Amiga (and probably for Mac and Atari.) Roger Nelson rdnelson@phoenix.princeton.edu
stripes@wam.UMD.EDU (05/04/89)
In article <8102@phoenix.Princeton.EDU> rdnelson@phoenix.Princeton.EDU (Roger D Nelson) writes: >In article <1193@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes: >>Are there any APL implementations which preserve the function source >>text as entered by the programmer, instead of just throwing all > >Roger Nelson rdnelson@phoenix.princeton.edu > >If I understand the question correctly, several do. In particular, >the STSC APL for 80286 and 386 allows you to put white space where There is no 80286 APL*PLUS, if you have an AT you can run the 8088 code. Version 7 of the 8088 code thrashes your whitespace, Version 8 probbly does too. (It's a non-issue at STSC, and if it was there are really people who work there that enjoy haveing their whitspace mangled). You are right about the 386 version (APL*PLUS II), in fact the only STSC APL's that mangle whitspace are their IBM 370 versions, PC, and Pocket APL. -- stripes@wam.umd.edu Disclaimer: Josh_Osborne@Real_World,The I no longer work for STSC, but "The dyslexic porgramer" still like (most) of their stuff
jaxon@uicsrd.csrd.uiuc.edu (05/04/89)
Unisys' APLB preserves everything except for the leading whitespace. I tried to persuade my co-author to keep that, especially since we found indentation standards to be a major help in implementing APLB itself. Without a standard full-screen editor, however, indentation is a nuisance to preserve, so I lost that argument, but found I didn't really need indentation in APL2/APLB. Whitespace is not the most critical problem, though! Numeric literals should be preserved as originally typed, so that the program is as fully portable as it can be. Parentheses should also be preserved for two reasons: While editing a function, a redundant pair of parentheses can become significant; and secondly in APL2/APLB syntax redundancy of parentheses cannot be determined without runtime information, therefore a (static) editor can almost never make a good decision about when they can be dropped. P.S. This also prevents second generation APLs from re-inventing the line text from an internal, parentheses-free representation.
ljdickey@water.waterloo.edu (Lee Dickey) (05/05/89)
>In article <1193@infbs.UUCP> hafer@infbs.UUCP (Udo Hafermann) writes: >>Are there any APL implementations which preserve the function source >>text as entered by the programmer, instead of just throwing all > >If I understand the question correctly, several do. In particular, >the STSC APL for 80286 and 386 allows you to put white space where >you want it, and so does MicroAPL's APL.68000 for the Amiga (and >probably for Mac and Atari.) Please correct me if I am wrong, but I think that the first APL to keep the white space was WATCOM APL for the IBM PC, and STSC was the next to step in line. I discovered this week that SAX APL (Sharp APL for UNIX) does not crush white. I am pleasantly surprised about APL.68000. I have version 6.05c running on my Atari ST, and (unfortunately), it is a white crusher. I hope the next Atari release removes the white crusher. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
hafer@infbs.UUCP (Udo Hafermann) (05/05/89)
In article <8102@phoenix.Princeton.EDU> rdnelson@phoenix.Princeton.EDU (Roger D Nelson) writes: >If I understand the question correctly, several do. In particular, >the STSC APL for 80286 and 386 allows you to put white space where >you want it, and so does MicroAPL's APL.68000 for the Amiga (and >probably for Mac and Atari.) Well, I certainly can't get my Amiga APL.68000 to do it (Version 6.04C), and the ST version doesn't do it either. Actually I was told by MicroAPL that they found it a too difficult thing to implement; I can't really see the problem in having special white space tokens in the internal representation, provided the user accepts the small slowdown involved. They said they might consider keeping spaces at the beginning of lines or before comment symbols (as APL/PC does it).