[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jul 20 17:51:26 1995 
Subject:Re: What's clutter in the design of a prog. language? [was: Minor 
From:Aaron Sloman 
Volume-ID:950721.02 

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