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?