Re: Octal and Binary Literals
Pete Lomax wrote:
>
> Implementation should be based on the following, in order:
> 1: Unambiguity and Least Surprise
> 2: Zero impact on legacy code
> 3: Minimal performance impact
We should put this up on the wall somewhere. :)
> Option 1: Use a Suffix character.
> NNo -- octal, N is 0..7
> NNh -- hex, N is 0..9, A..F, a..f
> NNb -- binary, N is 0 or 1
> Notes: the NNb case would need to be followed by a delimeter, ie in "1bh"
> the 'b' does not terminate the token since it is followed by a valid
> hex char, and is equal to "27".
Not if it's a lowercase b. But that might be a bit more confusing than
we'd really like.
> This would probably yield the highest performance impact, simply
> because you have to check for o/h/b after every number.
We'd have to change the scanner, to be sure, but the performance hit might
not be so bad.
> Option 2: Use the leading 0 trick from C.
> Notes: this means that 012 == 10. Any legacy code with leading zeroes will
> be broken.
Yes, it's a fairly common pattern, but I think we may end up breaking a
lot of stuff.
> Option 3: Use the 0X style notation.
> 0oNN -- octal
> 0xNN -- hex
> 0bNN -- binary
> Notes: This would be my personal choice.
I like this. Presumably, now we'd have 2 ways to specify hexadecimal.
What about using lowercase for hexadecimal numbers of this format?
Probably too confusing, but would be consistent with C.
> Option 4: As 0X, but use #.
> #oNN -- octal
> #xNN -- hex
> Notes: There is no obvious way to specify binary numbers as the 'b' (and to
> a lesser extent a 'd' for explicitly decimal) clash with legacy use.
> This would probably yield the lowest performance impact, since the
> only compiler changes are needed after it has detected a # character.
> Options 2 and 3 occupy the middle ground, having to check for
> leading 0.
But all hexadecimal digits have to be uppercase, so while it may be opening
the door for typos, it's not ambiguous.
> It may also be sensible to allow a 'd' to explicitly state "this is decimal",
> so that in option 1, NNd (with same delimeter note) is equal to NN, or in
> option 2 and 3, 0dNN, but not apparently possible under option 4.
>
> I have a need to specify octal numbers for an assembly project. I want to use
> "bytewise octal" whereby each byte is represented by exactly 3 octal digits,
> ie FFFFFFFF(hex) = 377377377377(octal).
> Can anyone think of a problem with using "NNob", "0obNN", or "#obNN" for this?
> If you take specific exception to that going into "official Eu", then please
> take a moment to consider whether you could properly justify your objections
> and/or what factors might lessen them.
>
> For strings, I think the best option is "\#NN". I doubt there is much call for
> octal codes anymore. I also think we should force it to be exactly two hex
> digits,
> no more and no less. For example, suppose I want {7,'H','e','l',l',o'} then
> I might code "\#07Hello". Any objections to that? Obviously someone is bound
> to mention Unicode, so is there a sensible way to say "a two digit hex no" vs
> "a four digit hex no" etc? Otherwise "\#0700000" becomes ambiguous, meaning
> either {7,'0','0','0','0','0'} or {#700,'0','0','0'}.
I agree with "\#NN". If you're putting things in quotes, then we're
presuming that you're building a string. Euphoria doesn't support
Unicode (yet?). But if you were trying to build, say, a UTF-8 string,
then you're still working with bytes. Even UFT-16/32 would lend
themselves to this. You'd just need to string multiple "\#NN"s
together.
Matt
|
Not Categorized, Please Help
|
|
