r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Geomol
31-Jul-2009
[16433]
ok, I'm not too familar with transcode. Let me make another example. 
This works today:

>> load "a ,0"
== [a 0.0]

What should this return:

load "a,0"
BrianH
31-Jul-2009
[16434x2]
Sounds like it should return [a 0.0].
Steeve, a period is usable, but not used (in general). And the period 
being usable is likely why the comma is an error.
Geomol
31-Jul-2009
[16436]
Today it's an invalid word. You suggestion would turn something invalid 
into being valid.
Sunanda
31-Jul-2009
[16437]
comma can be _used_ in words, but not in words that have to be serialised 
and then reloaded

    to-word "a,"    ;; this works  
    == a,

    to-word ",a"   ;; there are some limits
    ** Syntax error: invalid character in: ",a"

Don't serialise and reload O:
    o: make object! reduce [to-set-word "a," 1]
    == make object! [
        a,: 1
    ]
Geomol
31-Jul-2009
[16438]
lol, good ones, Sunanda!
BrianH
31-Jul-2009
[16439]
Sunanda, TO-WORD "a," being allowed sounds like a bug. Report it.
Geomol
31-Jul-2009
[16440]
It's the general thing, we've talked a bit about before, that TO 
some datatype should put the result through LOAD or something, so 
valid REBOL comes out of it.
Sunanda
31-Jul-2009
[16441x2]
But it's R2 compatible :)

There are other edge cases -- Latin-1 chars that can be _in_ a word 
not not _start_ them, and do not serialise well.....I did a script 
and found them all once
not not ==> but not
BrianH
31-Jul-2009
[16443x2]
We've already put restrictions on the character set of words - Sunanda 
just found a hole in those that needs repairing.
But it's R2 compatible :)
 - See bug#666 :)
Geomol
31-Jul-2009
[16445]
Some languages only allow 7-bit ascii in the source except for strings.
Sunanda
31-Jul-2009
[16446]
re: 666 -- I'll dig that script out and run it tomorrow :)
Geomol
31-Jul-2009
[16447]
I could use 8-bit danish letters in my REBOL source, if I would:

>> ęble: "apple"
== "apple"


But I don't do it. I'm not sure, if it's a good idea to allow this. 
I guess, 8-bit values are allowed, because it makes the lexer faster.
BrianH
31-Jul-2009
[16448x5]
All standard functions and syntax in REBOL fit within 7-bit ASCII, 
which is why R3 source is UTF-8.
UTF-8 encoded binary!
Adjusted #537 to reflect the post-alpha-39 behavior of TRANSCODE 
(can't believe I forgot to do so before now).
Geomol, please take another look...
Sunanda, #1167 created for that to-word "a," error.
Ladislav
31-Jul-2009
[16453x4]
{Is there a problem with getting operators?

>> get to word! "="
** Script error: = word is not bound to a context}


This is not operator-specific, no variable can be handled like that:

a: 1
get to word! "a"
** Script error: a word is not bound to a context
{>> get to-word '=
== op!}

- in the above code the usage of TO-WORD is just a no-op
{Brian knows the internals.} - see the http://www.rebol.net/wiki/Comparisons
article containing the general principles
{>> get to-word quote <>}

- again, TO-WORD is just no-op above
BrianH
31-Jul-2009
[16457]
Knowing the internals isn't hard. I haven't seen the native source 
- I've just seen the mezzanine source, followed the conversations, 
and read sites like the onee Ladislav linked above. The rest is deduction.
Ladislav
31-Jul-2009
[16458x3]
{so making string to words and making lit-words to words isn't quite 
the same, it seems!?
>> (to word! '=) = (to word! "=")}

- again, the first TO WORD! is just a no-op
{What's the need for QUOTE, when we have the get-word syntax?} - 
it serves a totally different purpose, e.g.:

quote (1 + 1) ; == (1 + 1)

for comparison:

first [(1 + 1)] ; = (1 + 1)

(1 + 1) ; == 2
another QUOTE:

quote  'a ; == 'a

(another way how to obtain that would be e.g.):

first ['a] ; == 'a
BrianH
31-Jul-2009
[16461]
I *really* like the new :a parameter behavior in R3 that makes QUOTE 
possible :)
Ladislav
31-Jul-2009
[16462x5]
yes, that makes the thing really useful :-)
Or, since the get-word syntax was mentioned:

quote :x ; == :x
, so, the most useful property is consistency; it always does the 
same (actually nothing)
{while other operators work ok as lit-words:
>> '=
== =}


- just a note; in the above example there is no operator, just a 
lit-word, that is handled as "valid" by Rebol loader in this case 
(as expected)
the power/simplicity of QUOTE is, that even in case the lit-word 
syntax isn't handled correctly, QUOTE works as expected:

quote <> ; == <>
Geomol
1-Aug-2009
[16467x2]
I think, the lit-word syntax should be fixed anyway.
I wasn't aware, that this doesn't work in R3:

get to word! "a"


So it's not a problem with operators, but a general change. The above 
code is valid R2 code. I can't judge, if it's a needed change or 
not, but it will trigger thoughts about R2 compability. I guess, 
the change will break a lot of R2 code!?
Henrik
1-Aug-2009
[16469]
that would be because words aren't bound by default in R3.
Geomol
1-Aug-2009
[16470]
I see. Does it make sense to not bind words by default? I feel, Carl 
might have a blog about this. :-)
Henrik
1-Aug-2009
[16471]
I think this was quite a big topic a while ago. It has something 
to do with modules.
Geomol
1-Aug-2009
[16472x2]
I came across another funny thing. Are << and >> planned as operators?

>> ? >>
No information on >>

So >> is a valid word. But >>> is not:

>> ? >>>
** Syntax error: Invalid "word" -- ">>>"
I think, the lit-word syntax should be fixed anyway.
Same can be said about get-word syntax.
BrianH
1-Aug-2009
[16474x3]
Yes, it makes sense to not bind words by default. Carl has written 
many blogs about this, going back more than a year.
There is no one shared global context anymore, so which context to 
bind to is a policy decision. Default needs to be unbound to do this
>> and << are likely allocated for user-defined operators. Please 
don't allocate >>> and <<< - it would be too hard to discourage their 
use if they are allowed syntax. We don't want REBOL to become a write-only 
language like Perl.
Sunanda
1-Aug-2009
[16477]
Any reason why NONE acts as an honorary empty block in each of these 
under R3:
    a: none forskip a 1 [print a]
    a: none forall a [print a]
    foreach a none [print a]
R2 would not be happy!
Oldes
1-Aug-2009
[16478]
Why not.. it seems to be logical to me.
Sunanda
1-Aug-2009
[16479]
Logical, maybe. Harmless, perhaps. But odd ..... and inconsistent 
with REPEAT:
    repeat a none [print a]

    ** Script error: repeat does not allow none! for its value argument
So I am wondering if it is a deep feature, or an oversight.
BrianH
1-Aug-2009
[16480x2]
The REPEAT behavior sounds like an oversight - but the none argument 
was left out of MAP on purpose, so who knows?
As for the other functions, it is an intentional change from R2, 
which reduces special-case code wrapped around FIND and SELECT.
Sunanda
2-Aug-2009
[16482]
Thanks -- I'll add a curecode so the possible oversight is on the 
checklist.