REBOL 3.0

Comments on: Decided - MOLD char!

Carl Sassenrath, CTO
REBOL Technologies
17-Feb-2008 6:02 GMT

Article #0010
Main page || Index || Prior Article [0009] || Next Article [0011] || 6 Comments || Send feedback

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?

Decision

By default, the character will be in its native encoded format. In other words, a Greek alpha will appear as #"α".

There will be an option added to force MOLD to output the ^(1234) escaped format when needed.

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:

Name:


Comment:

 
  Note: HTML tags allowed for:b i u li ol ul font a p br pre blockquote

REBOL 3.0
Updated 22-Jul-2014 - Edit - Copyright REBOL Technologies - REBOL.net