Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!decvax!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: The D Programming Language
Message-ID: <2636@haddock.ISC.COM>
Date: 18 Feb 88 20:47:20 GMT
References: <11702@brl-adm.ARPA> <558@naucse.UUCP> <2523@haddock.ISC.COM> <2595@haddock.ISC.COM> <580@naucse.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 44

In article <580@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes:
>In article <2595@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
>>It sounds like you're thinking of the expression equivalent of `switch',
>>which would evaluate exactly one of [its right operands].
>
>Actually, no.  However, I wasn't thinking of this as an exact replacement
>for the ',,' operator, just as something that does equivalent work.  You
>can evaluate all the operands and then fairly easily make an arbitrary one
>of them available.

Yes, you can implement it as
  (temp[1]=x1, temp[2]=x2, ..., temp[n]=xn, temp[i])
if you're willing to live with the space requirement.  (This was noted in the
first draft of my earlier article, but I cut it before posting.)

>I suppose that ... there is the overhead of verifying that 'i' evaluated to
>the proper range ...

Actually, it would be well within "the spirit of C" to let an out-of-range
selector be an undefined condition.  Then the verification can be omitted.

>Of course, the evaluation order for ',,' is well defined, while the
>evaluation order (in 'C' at least) for 'i(...)' would match the evaluation
>order for function calls, which is much messier.

And in private correspondence:
>Also, note that, in 'C' at least, the types of e1,...,en
>must match (this isn't true in Icon).

This is important.  If we add this `pick' operator but not `,,' on the grounds
that the former can simulate the latter, we would have to assert that
(a) `pick' guarantees to evaluate its right operands left-to-right, and
(b) the right operands must all have the same type if the left operand is
nonconstant, but may be of varying types if the left operand is constant.

(a) is an arbitrary restriction that shouldn't apply to `pick' for the same
reason that it shouldn't apply to function calls (we should let the compiler
do whatever is the most efficient thing), and (b) is a kludge of the same
magnitude as the recently-proposed enhancement to "++" for non-lvalues.

It looks like the best solution is to add both operators!  (After all, we're
talking about a hypothetical `D' language here.)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint