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 language or programming environment that supports such
a scheme, I'd be very interested in hearing about it.
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@torontogsp@ulysses.UUCP (Gary Perlman) (04/10/84)
The S system for data analysis allows a combination of positional and keyword parameters. For example, you can type: plot(height, weight, type='points') The first two are encoded positionally, the next is labeled. About 100 default graphical parameters are assumed. You could also write the command in the form: plot(x=hight,y=weight,type='points') For optional arguments, the labeled parameters seem like a big win. They are also easier to read, assuming memorable keywords. Gary Perlman BTL MH 5D-105 (201) 582-3624 ulysses!gsp
mark@harvard.UUCP (Mark Lentczner) (04/10/84)
-=-
The SmallTalk-80 equivelent of `function calls' are based on
a form of keyword parameters. When a message (roughly similar to
a function call) is passed the parameters (including the reciever
of the message) are each preceded by a keyword. For example:
rotate: car-object about: x-axis by: 45.0
On the otherhand, SmallTalk-80 does not allow for the relative
positions of the keywords to change, in other words the message:
rotate: car-object by: 45.0 about: x-axis
is actually a different message. Despite this, I think that
SmallTalk-80 model gives a nice place for departure in this realm.
I myself am working on a language & environment, EAMES, that does
various forms of patteren matching to execute messages.
My hope is to achieve an even greater freedom via a loosening of the
one keyword per parameter constraint and a flexible default system.
Thus, all of the following would incurr the same action:
rotate car-object by 45 degrees about x-axis.
rotate car-object about x-axis 45 degrees.
about x-axis rotate car-object (PI / 2.) radians.
and allow the following to invoke similar actions (via defaults):
rotate car-object PI radians.
rotate car-object about y-axis.
I would be interested in discussion and/or info & pointers on
other programming environments that have take other than the strict
"Macro-Expansion" approach to fitting action invocations with action
definitions.
- Mark Lentczner
Harvard Electronic Music Studio
Music Department
Harvard University
Cambridge, MA 01238
decvax!genrad!wjh12!harvard!marksteven@mcvax.UUCP (Steven Pemberton) (04/10/84)
There is already a language that has most of the features mentioned, namely the new language 'B' (no relation to the predecessor of C: the name is a working title). All commands in the language use keywords (eg PUT a IN b is the assignment command) and this includes procedure calls (eg MOVE gold FROM cave TO building). The language is part of a programming environment that includes an editor that knows about user-defined commands. Thus assuming the existence of the above MOVE command, when you type the initial M (which you don't have to type in upper-case) you get something like M_OVE ? FROM ? TO ? Pressing the tab key accepts the suggestion and takes you to the first parameter position. If you don't want the MOVE command, then you type more letters, and if the editor knows a command beginning with what you've typed it suggests that. Things like closing brackets and closing quotes are also supplied for you. It is also worth mentioning that the programming environment is self- contained. B serves as both programming language and job-control language. Furthermore, since you are always in the editor, there is no need for short cryptic commands (like 'rm') since for instance D[tab] gives you DELETE (the equivalent of rm). There is an implementation for Un*xes, and a newsletter; if you're interested mail me. More details on the language in SIGPLAN Dec 1982; on the environment in the newsletter; on the implementation in the proceedings of the last Uniforum conference. Steven Pemberton (steven@mcvax) POB 4079, 1009 AB, Amsterdam, The Netherlands
rabin@sdcsla.UUCP (04/11/84)
Smalltalk procedure invocations alternate keywords and actual parameters, as in array at: i put: 'string' . The args are really positional (you can't give them in the opposite order), but quite mnemonic. The procedure to be called is determined by the combination of the type of the object stored in variable "array" and the message name "at:put:". The normal programming language equivalent is Declare ARRAY array; array(i) = 'string' ; The Smalltalk programming environment uses a database of object types and message names to catch typos, incorrect argument specifications, and so forth. References: Adele Goldberg, Smalltalk-80: The interactive programming environment, Addison-Wesley, 1984. Adele Goldberg and David Robson, Smalltalk-80: The language and its implementation, Addison-Wesley, 1983. ------------ Dan Rabin University of California, San Diego (sdcsla on Usenet).
holtz@clan.UUCP (Neal Holtz) (04/11/84)
For those who might be interested, the next official Fortran (Fortran 8X) will likely have keyword and positional paramters. Don't hold your breath - the ANSI standard is still several years away. Unfortunately, that Fortran might also have almost anything else that anyone thought might be useful in a language, except rationality. Will make PL/1 look small and simple. Neal Holtz Dept. of Civil Eng., Carleton Univ., Ottawa.
kvc@scgvaxd.UUCP (Kevin Carosso) (04/13/84)
Ada provides for "keyword parameters". They are called named associations
(at least in the Young book). Positional and named parameters can be
mixed as long as the positional guys come first. For example, assuming
procedure do_something (par1 : integer; par2 : string) is ...
then
do_something (par1 => 6, par2 => "a string");
do_something (6, "a string");
and
do_something (6, par2 => "a string");
are all equivalent.
/Kevin Carosso allegra!scgvaxd!engvax!kvc
Hughes Aircraft Co.phipps@fortune.UUCP (Clay Phipps) (04/17/84)
I believe that LIS, designed by Jean Ichbiah and others
(at IRIA ?) in the mid-70's, had keyword parameters
(I can't provide a reference for any papers on it at the moment;
send me mail if you would like me to dig for it).
I have no idea whether they had a development environment
in which that style was ingrained.
I think that Ichbiah is now at ALSys, an Ada-oriented company
somewhere in Europe, these days.
IBM's proprietary internal systems programming language
PL/S (or its macro processor) also had keyword parameters,
but there were no tools that embodied that style.
It was difficult enough just to get the division responsible for it
(the mainframe people in Poughkeepsie) to maintain it.
-- Clay Phipps
--
{cbosgd decvax!decwrl!amd70 harpo hplabs!hpda ihnp4 sri-unix ucbvax!amd70}
!fortune!phipps