Hex Flt Constants at CRI

Tim Peters uunet!ksr.com!tim
Tue Aug 31 22:13:57 PDT 1993


> > Overall, it's less work and less disruptive to other tools if you don't
> > change the syntax of the language. ...

> ... However, I believe the _transfer intrinsic is also _new_ syntax.
> It's not like I can write the _transfer routine and put it in a library
> for those implementations that don't support it as a builtin.  It's new
> syntax.

_transfer is not new syntax in the sense that the abstract grammar
doesn't change:  to just about everything except the compiler, it _looks
like_ a function call (whether it can be _implemented_ as a function call
is not relevant to this point).  E.g.,

kaos 32= echo x+0xf-3 | cparen
(x+0xf)-3
kaos 33= echo x+0xf.-3 | cparen        # cparen is unhappy with 0xf. notation
cparen: syntax error
kaos 35= echo 'x+_transfer(0xf,1.0)-3' # but handles _transfer fine
(x+(_transfer(0xf,1.0)))-3
kaos 36=

I think the compiler costs are trivial for both approaches, but only God
knows how many half-baked tools you're going to confuse.  You really need
to change the _grammar_ to introduce new literal forms, and the
consequences can be ubiquitous.  That's one of the reasons I remain
opposed to X3J11.1's new slew of line-noise comparison operators (they'll
break a hundred tools, while all the functionality could be captured
easily via vanilla functional syntax).

> 	_transfer ( 0xffffffff , double )
> [vs]
> 	_transfer ( 0xffffffff , 1.0 )

I like the first form better too, but failed to convince X3J3 to do it
that way in F90; the latter is good enough, & will at least be familiar
once F90 conquers the world <cackle>.

> I believe the reason CRI chose the new hex constants is because we were
> trying to solve a specific problem with a small feature that could be
> implemented in a short amount of time. ...

Implying _transfer is a large feature and/or hard to implement <wink>?

> (The union tricks you mention are _not_, technically speaking, blessed
> by the C standard.)

Of course not.  Had they been blessed, I would have called them
"techniques".

stickler-for-correct-moral-judgement-ly y'rs  - tim

Tim Peters   timaksr.com
not speaking for Kendall Square Research Corp



More information about the Numeric-interest mailing list