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).
|