Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
February 15, 2012 Hex floats | ||||
---|---|---|---|---|
| ||||
What's the original rationale for requiring that hex float literals must always have an exponent? For example, 0xFFi obviously must be float, not integer, so why does the compiler (and the spec) require an exponent?
Also, the specs say:
FloatLiteral:
Float
Float Suffix
...
Float:
DecimalFloat
HexFloat
Suffix:
FloatSuffix
...
FloatSuffix:
f
F
This is ambiguous, since you could interpret 0xFFp0F as either 0xFFp0 followed by the suffix 'F', or 0xFFp0F with an exponent of 0x0F no suffix.
T
--
It is widely believed that reinventing the wheel is a waste of time; but I disagree: without wheel reinventers, we would be still be stuck with wooden horse-cart wheels.
|
February 16, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | On 15/02/12 22:24, H. S. Teoh wrote:
> What's the original rationale for requiring that hex float literals must
> always have an exponent? For example, 0xFFi obviously must be float, not
> integer, so why does the compiler (and the spec) require an exponent?
The syntax comes from C99.
|
February 16, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 16/02/2012 12:04, Don Clugston wrote:
> On 15/02/12 22:24, H. S. Teoh wrote:
>> What's the original rationale for requiring that hex float literals must
>> always have an exponent? For example, 0xFFi obviously must be float, not
>> integer, so why does the compiler (and the spec) require an exponent?
>
> The syntax comes from C99.
Do you mean the syntax has just been copied straight from C99 without any thought about making it more lenient?
Stewart.
|
February 16, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | On 16/02/12 13:28, Stewart Gordon wrote:
> On 16/02/2012 12:04, Don Clugston wrote:
>> On 15/02/12 22:24, H. S. Teoh wrote:
>>> What's the original rationale for requiring that hex float literals must
>>> always have an exponent? For example, 0xFFi obviously must be float, not
>>> integer, so why does the compiler (and the spec) require an exponent?
>>
>> The syntax comes from C99.
>
> Do you mean the syntax has just been copied straight from C99 without
> any thought about making it more lenient?
>
> Stewart.
Yes. There would need to be a good reason to do so.
For the case in question, note that mathematically, imaginary integers are perfectly valid. Would an imaginary integer literal be an idouble, a ifloat, or an ireal? I don't think it could be any:
foor(float x)
foor(double x)
fooi(ifloat x)
fooi(idouble x)
foor(7); //ambiguous, doesn't compile
fooi(7i); // by symmetry, this shouldn't compile either
|
February 16, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 02/16/2012 05:06 PM, Don Clugston wrote: > On 16/02/12 13:28, Stewart Gordon wrote: >> On 16/02/2012 12:04, Don Clugston wrote: >>> On 15/02/12 22:24, H. S. Teoh wrote: >>>> What's the original rationale for requiring that hex float literals >>>> must >>>> always have an exponent? For example, 0xFFi obviously must be float, >>>> not >>>> integer, so why does the compiler (and the spec) require an exponent? >>> >>> The syntax comes from C99. >> >> Do you mean the syntax has just been copied straight from C99 without >> any thought about making it more lenient? >> >> Stewart. > > Yes. There would need to be a good reason to do so. > > For the case in question, note that mathematically, imaginary integers > are perfectly valid. Would an imaginary integer literal be an idouble, a > ifloat, or an ireal? I don't think it could be any: > > foor(float x) > foor(double x) > fooi(ifloat x) > fooi(idouble x) > > foor(7); //ambiguous, doesn't compile > fooi(7i); // by symmetry, this shouldn't compile either static assert(is(typeof(7i)==idouble)); |
February 17, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On 16/02/12 17:36, Timon Gehr wrote:
> On 02/16/2012 05:06 PM, Don Clugston wrote:
>> On 16/02/12 13:28, Stewart Gordon wrote:
>>> On 16/02/2012 12:04, Don Clugston wrote:
>>>> On 15/02/12 22:24, H. S. Teoh wrote:
>>>>> What's the original rationale for requiring that hex float literals
>>>>> must
>>>>> always have an exponent? For example, 0xFFi obviously must be float,
>>>>> not
>>>>> integer, so why does the compiler (and the spec) require an exponent?
>>>>
>>>> The syntax comes from C99.
>>>
>>> Do you mean the syntax has just been copied straight from C99 without
>>> any thought about making it more lenient?
>>>
>>> Stewart.
>>
>> Yes. There would need to be a good reason to do so.
>>
>> For the case in question, note that mathematically, imaginary integers
>> are perfectly valid. Would an imaginary integer literal be an idouble, a
>> ifloat, or an ireal? I don't think it could be any:
>>
>> foor(float x)
>> foor(double x)
>> fooi(ifloat x)
>> fooi(idouble x)
>>
>> foor(7); //ambiguous, doesn't compile
>> fooi(7i); // by symmetry, this shouldn't compile either
>
> static assert(is(typeof(7i)==idouble));
Ooh, that's bad.
|
February 17, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Don Clugston | On 02/17/2012 10:45 AM, Don Clugston wrote:
> On 16/02/12 17:36, Timon Gehr wrote:
>> On 02/16/2012 05:06 PM, Don Clugston wrote:
>>> On 16/02/12 13:28, Stewart Gordon wrote:
>>>> On 16/02/2012 12:04, Don Clugston wrote:
>>>>> On 15/02/12 22:24, H. S. Teoh wrote:
>>>>>> What's the original rationale for requiring that hex float literals
>>>>>> must
>>>>>> always have an exponent? For example, 0xFFi obviously must be float,
>>>>>> not
>>>>>> integer, so why does the compiler (and the spec) require an exponent?
>>>>>
>>>>> The syntax comes from C99.
>>>>
>>>> Do you mean the syntax has just been copied straight from C99 without
>>>> any thought about making it more lenient?
>>>>
>>>> Stewart.
>>>
>>> Yes. There would need to be a good reason to do so.
>>>
>>> For the case in question, note that mathematically, imaginary integers
>>> are perfectly valid. Would an imaginary integer literal be an idouble, a
>>> ifloat, or an ireal? I don't think it could be any:
>>>
>>> foor(float x)
>>> foor(double x)
>>> fooi(ifloat x)
>>> fooi(idouble x)
>>>
>>> foor(7); //ambiguous, doesn't compile
>>> fooi(7i); // by symmetry, this shouldn't compile either
>>
>> static assert(is(typeof(7i)==idouble));
>
> Ooh, that's bad.
>
Indeed. But the implementation of complex and imaginary numbers is pretty much broken in the front-end anyway. For example, double and idouble are type combined to double iirc.
|
February 17, 2012 Re: Hex floats | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | On Fri, Feb 17, 2012 at 02:41:10PM +0100, Timon Gehr wrote: > On 02/17/2012 10:45 AM, Don Clugston wrote: > >On 16/02/12 17:36, Timon Gehr wrote: [...] > >>static assert(is(typeof(7i)==idouble)); > > > >Ooh, that's bad. > > > > Indeed. But the implementation of complex and imaginary numbers is pretty much broken in the front-end anyway. For example, double and idouble are type combined to double iirc. Hmph. So complex literals are deprecated, right? So I should disable them in my lexer? I assume Phobos doesn't use them anymore? T -- Without geometry, life would be pointless. -- VS |
Copyright © 1999-2021 by the D Language Foundation