Don wrote:
Miles wrote:
Lars T. Kyllingstad wrote:
Neither of the natural candidates, a^b and a**b, are an option, as they
are, respectively, already taken and ambiguous.
I think that a ** b can be used, is not ambiguous except for the
tokenizer of the language. It is the same difference you have with:
a ++ b -> identifier 'a', unary operator '++', identifier 'b' (not
parseable)
a + + b -> identifier 'a', binary operator '+', unary operator '+',
identifier 'b' (parseable)
I don't know anyone who writes ** to mean multiplication and
dereference, except when obfuscating code. People usually prefer adding
a whitespace between both operators, for obvious readability purposes.
I think it is perfectly reasonable to deprecate current usage of '**'
for the next release, and a few releases later, make '**' a new
operator. I doubt anyone would notice.
That doesn't work, because you still get new code being converted from
C. It can't look the same, but behave differently.
Other examples:
a-- - b
a - --b
a && b
a & &b
You didn't respond to my assertion: even if you _could_ do it, why would
you want to? ** sucks as an exponential operator. I dispute the
contention that ** is a natural choice. It comes from the same language
that brought you IF X .NE. 2
I've been translating a lot of FORTRAN code to D lately, and it's
amazing what one can get used to reading. Even X.NE.2. :) The worst part
is translating 1-based array indexing to base 0 (it should be a simple
transformation, but those old FORTRAN coders have made damn sure that
isn't always the case...), and unraveling horrible spaghetti code like this:
100 if(abserr.eq.oflow) go to 115
if(ier+ierro.eq.0) go to 110
if(ierro.eq.3) abserr = abserr+correc
if(ier.eq.0) ier = 3
if(result.ne.0.0d+00.and.area.ne.0.0d+00) go to 105
if(abserr.gt.errsum) go to 115
if(area.eq.0.0d+00) go to 130
go to 110
105 if(abserr/dabs(result).gt.errsum/dabs(area)) go to 115
In the end I just had to admit defeat and define a few labels...
-Lars
