Comments on: Pushing the edge of ISSUE! for hex representations
In REBOL, we use the binary! datatype for binary values, and they are represented in source code in variations of the form:
#{01020304...}
In R2, we wanted to easily support integer representations in hex, such as those used for HTML color values. So we allowed the use of the issue datatype, in the form:
#01020304
And, we supported simple conversion to integer:
to-integer #01020304
That made some code easier, so we decided we would also support:
to-hex 1234
to return an issue for that integer, in hex format.
That's as far as we went in R2. It should be noted that issues are not a binary datatype, they are a string (character) datatype. This is legal:
#REBOL
In R3, we allow conversion to binary of other scalars, such as:
>> to-binary 1.0
== #{3FF0000000000000}
>> to-binary $1.0
== #{7F800000000000000000000A}
and, as a result, this casual usage of issues has grown:
>> to-hex 1.0
== #3FF0000000000000
>> to-hex $1.0
== #7F800000000000000000000A
But, this was a bit accidental. It did not come from a design goal.
We need to debate this practice and make a conscious decision if it should be supported or not. Although this form looks simple enough to convert, it actually isn't (because issues are strings, not binaries). So, allowing these issue formats adds more code to the REBOL executable than you'd expect. They are not freebies.
Let's decide this.
10 Comments Comments:
Brian Hawley
15-Jul-2009 14:19:58 |
I'm OK with going back to the R2 limit of integer!, and maybe adding tuple!, since issue! syntax for those values are used in HTML/CSS color attributes. Beyond those two cases it just seems to be an unnecessary and confusing way for people to save the typing of two characters: { and }.
If you need to print a hex representation of a value, or other bases, do this:
>> enbase/base to-binary 123456 16
== "000000000001E240" | -pekr-
15-Jul-2009 15:22:21 |
Well, I really don't know, but for me, REBOL was always kind of difficult to use for me in regards to easiness of conversions! IIRC vectors were supposed to somehow help the situation. I am not sure I want to use such "complicted" enbase/base example just to get binary string representation.
When I worked with wrapping DLLs, I could see 0x0010, which for me was always just equivalent of #0010 in "string" form, and #{0010} in binary form. Any other result for me is wrong.
Now look at recent weirdness:
>> to-binary 16
== 64#{AAAAAAAAABA=}
;should be #{10} or padded, but still 10
>> to-issue #{0001}
== #??
;should be #0001, so that passing to to-string would work
Any other result is not acceptable for me, and is usability nightmare. If I am not able to get above result, I would better forbid such conversions altogether. I tell you - if it confuses me for years, it will confuse other possibly too. And the easy of usability should be our priority, as it was the reason why e.g. VID was rewritten, right?
| meijeru
15-Jul-2009 15:55:52 |
I am perfectly OK with to-hex working on integers and tuples only, and conversely only to-integer and to-tuple accepting hex issues | Brian Hawley
15-Jul-2009 16:34:07 |
Pekr, your recent weirdness is old weirdness.
In the first case it appears that your system/options/binary-base got changed to 64, likely by R3 chat. That setting only affects the MOLD function that displays the binary, not the value of the generated binary.
In the second case, upgrade to alpha 72 - that bug was fixed there.
As for using issue! for conversions, just don't. There will be better ways to do conversions, and better uses for the issue! type. | Brian Hawley
15-Jul-2009 16:42:04 |
The ENBASE and DEBASE functions are used for generating or translating from display values, not for binary conversions. You don't work with the display values, you work with the binary values.
A binary value is generated with TO-BINARY, ENCODE and other conversion functions, some of which have yet to be written. DECODE, TRANSCODE, TO-BLOCK and other conversion functions create values based on binaries. We'll have more. | -pekr-
15-Jul-2009 16:43:58 |
Brian - I do use a72 and am getting above result in above case. And even more - if "to-binary #10" generates and error, I am not expecting "to-issue #{10}" producing any result - make it an error too. I think that conversion should be symmetric.
Can't wait to see some conversion functions ... | Brian Hawley
15-Jul-2009 17:42:21 |
Pekr, you are right, that is not the a72 fix, my bad.
I hadn't noticed that you were saying that there should be some kind of equivalence between #{0001} and #0001. Since that would break the other primary purpose of issues - keywords in dialects like the #include in prebol - that should never happen. Hex digits in issues is an HTML/CSS syntax thing, not a REBOL syntax thing.
Balance would be nice though, using the string! rules like this:
>> to-binary #1234
== #{31323334}
I also look forward to the conversion functions. They haven't been a priority yet because we have had to focus on lower-level stuff lately, to get plugins working. Plugins that can contain conversion functions, for instance. | -pekr-
15-Jul-2009 22:46:02 |
Yes, the equivalence, so that just #{0001} is exactly the same like #0001, just without {}. So in your example:
>> to-binary #1234
== #{1234}
... any other result is imo wrong and confusing ... | Gregg Irwin
15-Jul-2009 23:54:29 |
I don't think we need to support anything new in this area. If we want to add it later, we can. If we do it now, removing it later may break things.
I do have a bit of code that uses the R2 to-hex behavior with integers. | Normand
16-Jul-2009 9:23:04 |
For my part, I do not see the point of using the # symbol for some not_that_usefull binary to string conversions of browser color schemes. And there exists some other color schemes, too; so, that choice is already too constrained, however pervasive. A remapable adhoc datatype for colors would be more indicative of the domain of its pertaining syntax.
As said by Carl, # already has for domain strings. Would # be used for preprocessing - as in some other languages - and be used for deep linking in plugins, I would not complain of a breaking change. |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
