peterr@utcsrgv.UUCP (Peter Rowley) (04/09/84)
It is finally generally accepted that positional parameters in command
languages are to be avoided. The difference between UNIX(tm Bell Labs) and
JCL or CDC NOS command syntax is testament to this. It is time to apply
this lesson to programming languages.
The general rule is that positional parameters should be replaced by
keyword parameters. For example, Lookup("frodo", i) could be
written as Lookup(name:"frodo", symIndex: i) or
Lookup(symIndex: i, name: "frodo"). The keyword is exactly the formal
parameter of the procedure-- no change in procedure declaration syntax
is needed.
Exceptions to the general rule could be provided for situations in which
the role of the parameter(s) is obvious. For example, sqrt(a) would suffice.
This scheme has important advantages. When one is writing code, it is easier
to remember mnemonic keywords than arbitrary parameter positions. When
reading code (and remember that 80% of the programming task is maintenance),
it is even more important-- the keywords provide useful information about
the input and output of the procedure, right where it is needed in the
program text. This latter advantage is even more important for programming
languages than command languages, as program code is read so much more.
The disadvantage is that one has to type more to specify a procedure call.
The redundancy of having to specify the keyword verifies that one knows the
role of each parameter, however.
Still, the added typing, with increased chance of typos, *would* be a
nuisance. Fortunately, the technology is with us to avoid this extra
typing. A language-based editor can easily maintain a database of
procedure parameters and present a procedure call template on demand.
For example, if one types Lookup( then it could complete the
statement, resulting in Lookup(name: _____, symIndex: ______)
and position the cursor at the first field (type and parameter kind
(pass by value, value-result, reference, etc.) information could also
be presented).
Another advantage to the scheme is that it allows simple omission of
parameters, letting them assume default values. It is also easy to
retrofit to existing languages, as one can easily write a processor
to convert a program written in positional notation to one using the
keyword notation.
If anyone knows of a programming environment that supports such a scheme,
I'd be grateful to hear about it. Ada and, I believe, Mesa support keyword
parameters, but I don't know if the APSE or Cedar environments have
procedure call templates... does anyone out there know?
peter rowley, University of Toronto Department of C.S., Ontario Canada M5S 1A4
UUCP {linus ihnp4 allegra floyd utzoo cornell decwrl uw-beaver}!utcsrgv!peterr
CSNet peterr@torontojfarrell@sun.uucp (Jerry Farrell) (04/10/84)
Mesa does indeed allow keyword parameter lists, although I had to check my manual to convince myself -- I don't think I ever saw one in 3 years at Xerox. Cedar does its templating by abbreviation expansion combined with forms fill-in, so the answer to whether procedure call templates exist is time- and user-dependent. But your scheme supposes no procedure call is written before that procedure's declaration has been read -- that's some system!
darrelj@sdcrdcf.UUCP (Darrel VanBuer) (04/11/84)
MIT Lisp Machine Lisp (available in commercial versions from Symbolics and
LMI) has a mixture of positional and keyword parms (so did JCL and assembler
macros in IBM 360 and successors). Generally the convention is that the
arguments used all the time (and thus somewhat well known) are usually
positional, while the usually large number of "optional" arguments are
done with keywords. The value of missing arguments defaults to NIL or
to a value which is part of the procedure declaration (defaults in 360
macros were zero and the null string unless specified as DSORG=PS or
DENSITY=2 etc).
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPAmike@rice.ARPA (04/20/84)
From: Mike Caplinger <mike@rice.ARPA> The R^n programming environment for Fortran that we are working on here at Rice supports full subroutine call templating as you describe. Program comments are stored for each parameter, and the comments and data type, as well as the name of the parameter in the defining routine, are displayed when you insert a call to that routine. The editor is structured, but has a number of text-like features like text positioning and text expression entry. The editor uses the philosophy that convenient language usage can be provided by the editor rather than by the language. Overuse of declaratory syntax, as in Ada, just renders the language difficult to use, and even obstructionist at times. By using a structured editor, we can bypass all of that syntax and provide a better user interface too. It currently supports just Fortran, but I am working on a project to support other languages using a common intermediate language. It runs on Sun Workstations under Unix, and one of these days we may distribute an early version to interested universities. - Mike