Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!deimos.cis.ksu.edu!uxc!uxc.cso.uiuc.edu!ux1.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!jaxon
From: jaxon@uicsrd.csrd.uiuc.edu
Newsgroups: comp.lang.apl
Subject: Re: Function layout - a non-issue?
Message-ID: <49700011@uicsrd.csrd.uiuc.edu>
Date: 4 May 89 16:42:00 GMT
References: <1193@infbs.UUCP>
Lines: 19
Nf-ID: #R:infbs.UUCP:1193:uicsrd.csrd.uiuc.edu:49700011:000:1027
Nf-From: uicsrd.csrd.uiuc.edu!jaxon    May  4 11:42:00 1989


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.