Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!akgua!mcnc!decvax!harpo!ihnp4!zehntel!hplabs!sri-unix!Masinter.pa@Xerox.ARPA
From: Masinter.pa@Xerox.ARPA
Newsgroups: net.works
Subject: Re: WORKS Digest   V4 #18
Message-ID: <12373@sri-arpa.UUCP>
Date: Sun, 15-Apr-84 19:54:00 EST
Article-I.D.: sri-arpa.12373
Posted: Sun Apr 15 19:54:00 1984
Date-Received: Mon, 23-Apr-84 01:39:25 EST
Lines: 43

In reply to the message from Peter Rowley

Peter,

The history of programming language design is one going back and forth
trying to achieve incompatible goals. In this case, the goals are that
programs should be both easy to read and easy to write; easy for novices
and people unfamiliar with the program they are working on, but also
easy for experts and those intimately familiar with the program.

Keyword parameters are nice if you are reading a program with calls to
subroutines you don't recognize, or if you are writing in a language
where you remember the procedure names but not the argument order.

Keyword paramters areso nice because they tend to make programs more
verbose, and require you to type a lot of stuff that would otherwise be
irrelevant.

Making them optional doesn't help much, because the keywords tend to
help the novice and get in the way of the expert, both of whom might be
working on the same program.

As you mentioned, a language-based editor can help quite a bit. For
example, Interlisp has a command, "?=", which  means 'show me the
argument names'), in a variety of contexts. If you are typing something,
it will show you the argument names for the function you are in,
including the correspondence between formals and any actuals you've
already typed.  If you are reading a program with the editor and want to
know what arguments are being passed to what, you can find out again
using the "?=" command. This is different than your suggestion, because
the names don't actually appear in the program; it is just that the
environment makes them visible when you want to see them. 

Similar facilities could exist in other interactive programming
environments, as long as you were able to separate the 'text' of the
program some from its structure and the system was willing to parse what
you were typing as you typed it.  One could possibly extend this in
interesting ways, e.g., allow the programmer to type procedure calls in
either way (keywords or not) and display them either way depending on
some modes in the editor. The key is to separate out the 'program' from
the characters that represent it; given the same program, you can look
at it in a variety of different ways, none of which is necessarily
canonical.