[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Jul 18 06:18:08 1995 
Subject:What's clutter in the design of a prog. language? [was: Minor 
From:Patricia Wilson 
Volume-ID:950719.01 

conditionals]

Scott, thanks for replying to my posting.

I'll recap this for the Pop-11 users to whom I'm cross posting.

pw= s398960@uottawa.ca

pw>My first suggestion is that unless should be allowed to take else and 
pw>elseunless clauses, in a manner analogous to if conditionals.
pw>
pw>unless (test) consequent
pw>	[elseunless (elseunless-test) elseunless-consequent]
pw>	[else alternate]
pw>end [unless] =>values
pw>
pw>
pw>My second suggestion is slightly more general and encompasses the 
pw> first: that the Dylan language should allow if and unless to be pw> 
expressed together, i.e.:
pw>
pw>[if|unless] (test1) consequent
pw>	[elseif | elseunless (test2) consequent2]
pw>	[else alternate]
pw>end [if | unless]
pw>
pw>Since Dylan already has both constructs, and it's cheap and useful to combine them,
[as Pop-11 does]
pw> I think it's worth it.

swm = swm@harlequin.com
swm>   >It would be silly to add it to the language spec.

swm>   [...]Why force every programmer to
swm>   add this trivial macro should he want to use it (as I said, from experience

swm>Because it just clutters the base language.  I personally think there
swm>are 50 things I'd add to the language first, but haven't proposed them.

I guess that's a difference between a language like Pop-11 and Dylan. 
Pop-11 evolved slowly  through over 20 years of research. Dylan people 
are in a big rush to define and freeze the  language. Scott, you want to 
to make the major modifications quickly; and rather than merely  saying 
that you are just postponing minor additionsoewhich would be quite 
legitimate because  of time constraintsoeyou reject legit ones as 
clutter. Of course, there are proposals that are just  clutter, but my 
(admittedly low priority) proposal just combines logically related 
constructs in a  natural way that (I conjecture) 99% of programmers 
will use in most of their programs. No new  term is added, the syntax is 
merely enriched.  Rather than argue about the particular merits of this 
minor proposal the interesting question that is up for grabs is:

	How does one disguish between clutter and a good language design 
proposal? The question applies both to very minor modifications, and 
major ones too. 

This question should of course be interpreted in the light of the Dylan 
language objectives (cf DIRM).