ianr@cogs.susx.ac.uk (Ian Rogers) writes:
> Date: 19 Jul 1995 09:19:51 GMT
> Organization: University of Sussex
>
> Scott McKay (swm@com.harlequin) wrote:
> > Date: Tue, 18 Jul 1995 01:17:27 -0400
> > From: s398960@aix1.uottawa.ca (Patricia Wilson)
> > How does one disguish between clutter and a good language design
> > proposal? The question applies both to very minor modifications, and
> > major ones too.
> >
> > "Clutter" is stuff that gets added to the language which could have
> > been trivially expressed in the language via a very simple macro or a
> > very simple function.
> .....
>
> But what is the difference between a macro that everybody uses and a
> genuine part of the language?
> ...
> ..
> It's for this last reason that "good" language constructs should be built
> into the explicit syntax of the language, even if they can be implemented
> using macros.
I agree with Ian that there's no sharp dividing line and also that
if something left out of the language keeps getting reinvented as a
macro then that's probably an indication that it should have been in
the language.
The same thing can be said about procedures. Should
reverse(list) -> list
applist(list, procedure)
maplist(list, procedure) -> list
etc. be in the language? Users can very easily define them.
Programmers and language designers often add things because they
THINK others will find them useful. There's not nearly enough
testing of language facilities against real learners and users
(including people responsible for implementing and mainintaining
large systems over a long period, with changing staff.)
I personally think the issue of "unless" is too trivial to be worth
arguing about. The ONLY reason I ever use "unless ..." instead of
"if not(...)" or "elseunless ..." instead of the equivalent
"elseif..." is that I fear the Pop-11 compiler is probably not
clever enough to optimise away the extra procedure call to not. It
SHOULD be!
One reason I would avoid "unless" is that I have often seen that it
causes confusion, and also because there's a tiresome divergence
of opinion as to whether one should write
unless ... then...
or
unless ... do ...
both of which are allowed in Pop-11, which I think is silly and
messy. (Yes I know that some people think one expresses more
accurately what they intend, but a programming language is not
a subset of English. People have to learn to read it.)
I have not looked at the spec of Dylan, so I don't know if there's
anything for it to learn from Pop-11. Perhaps my favourite
suggestions would be
file-local lexicals (actually compilation stream local...)
dlocal (generalised dynamic local expressions)
(Generalises Lisp's unwind-protect ?)
updaters
partial application
The ability to treat properties (hash-tables), arrays and
indexable data structures as procedures
verbose syntax to aid learnability, helpful compile time error
messages, and long term maintainability.
a rich set of iterative constructs
provision of a pattern matcher with segment variables as part of
the list-processing tools
provision of graphical along with control panel/menu and other
GUI procedures.
(These are not well designed in Pop+X at present mainly
because of the decision (totally wrong in my view) to
support the X programming at the level of X resource files
rather than at the level of pop-11 constructs. But at least
they exist and should in any good language. Will Dylan
have graphical and GUI facilities?)
provision to plant VM code for constructs that can't be
expressed well in the language
the use of the stack, e.g. as in this way of building a list
[% for x from 1 to N do f(x) endfor %]
and variadic functions of various kinds.
The last two are probably inconsistent with the language having a
mathematically definable semantics that supports automatic checking.
I don't claim the above is an exhaustive list. Neither is it ordered
in any way.
Just my little diversion from urent administrative tasks!
Aaron
----
--
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs )
School of Computer Science, The University of Birmingham, B15 2TT, England
EMAIL A.Sloman@cs.bham.ac.uk
Phone: +44-121-414-4775 Fax: +44-121-414-4281
|