Comments on: Decided - MOLD char!

In R3 a char can be Unicode. For example, this is valid:

c: #"^(1234)"

The 1234 is a hex value for the character.

This is also valid:

c: #"***"

Where the *** is a multi-byte UTF-8 encoded character.

However, when we mold such a character, which of the above formats is best? Do we want the hex escaped value or the actual character?

6 Comments

Comments:

Jerry Tsai 17-Feb-2008 8:20:40	I hope it is choice #2, so I can see the actual charater shown in my utf8-compatible editors and edit it easily. Choice #1 is just a bunch of hexadecimal digits, we cannot understand what character that is. For those who have no utf8-compatible editors and related fonts, choice #2 is still a better choice. They can still see ANSI characters and edit them. When they see non-ANSI characters, #1 and #2 are not very different, it's just some meaningless hex digits in parentheses vs. some meaningless characters in quotes. So I vote for choice #2.
-pekr- 17-Feb-2008 9:12:59	Not sure what to expect, I am not experienced in meta-programming, but for me 'mold was always about serialisation of internal REBOL values. So mold the code, load it elsewhere. My question is - does choice #2 allows easy passing of such molded value between systems with different settings to Unicode?
Carl Sassenrath 17-Feb-2008 13:02:09	I think we need both forms. In fact, for these kinds of MOLD options we need more control in general. (Using globals for this kind of thing is not a good programming practice.) I'm considering adding to MOLD the ability to specify its variations: out: mold/with data [...options...] So, the question now is how do we want to specify the options. As a block of set-values such as in an object? Example: out: mold/with data [ unichars: true decimal-point: #"," binary-base: 16 ] In fact, it turns out that FORM internally is now actually just an option for MOLD. So FORM could become a mezzanine. Something like this: form: func [data] [ mold/with data [formed: true] ]
Carl Sassenrath 17-Feb-2008 13:04:23	So, then it is just a matter of deciding the default values. I think we could do the UTF-8 form, as Jerry wants.
Henrik 17-Feb-2008 14:02:09	On mold options: Let's say you have a molded data file that was molded with a range of options, but you don't have the list of options that were used for molding it. Will that be a problem?
Carl Sassenrath 18-Feb-2008 14:13:42	In theory, MOLD should always create an invalid source form. Meaning, LOAD should always be able to correctly convert it back to blocks/values. That means the values you pass to the MOLD/with block would require verification. (E.g. not allow something such as #"/" for decimal-point, etc.)

Post a Comment: