parse and datatype
[1/3] from: rotenca::telvia::it at: 5-Jul-2001 0:54
At last I've found the solution for my datatype! problem. I must do:
rules: load mold rules
it was a context problem, i think, but i'm not so in deep with Rebol to
understand exactly what happens in Load.
Help speak of "converts external data" and perhaps is this the reason Bind was
not sufficient.
I think that Bind does not change the context of datatype but only of words
(?).
I'd like to have a debug routine which can explicit the context details of all
words in a block.
These errors are so difficult to catch, for me.
Perhaps Ladislav Mecir, after HighFun.r, could help?
What I do not understand is why the routine does not give the same result with
integer! or string! datatype.
Corrected routine follows.
---
ciao (my english is bad)
romano paolo tenca
---------------
REBOL[]
inb: [34]
rules: copy []
bn: 0
foreach tok inb [
mytype: type? tok
bn: bn + 1
append rules 'set
append rules to-word join form mytype bn
append rules mytype
]
rules: load mold rules ;<<<-------- the solution, but with
integer! things seems OK
print ["*** Block is:^/" mold inb]
print ["*** Rules are:^/" mold rules]
print ["*** Rules application give:^/" parse inb rules]
print "^/^/Now with decimal..."
inb: [34.1]
rules: copy []
bn: 0
foreach tok inb [
mytype: type? tok
bn: bn + 1
append rules 'set
append rules to-word join form mytype bn
append rules mytype
]
rules: load mold rules ;<<<-------- the solution
print ["*** Block is:^/" mold inb]
print ["*** Rules are:^/" mold rules]
print ["*** Rules application give:^/" parse inb rules]
halt
[2/3] from: brett:codeconscious at: 5-Jul-2001 11:36
Hi Romano,
I've been tracking down the problem you refer to.
It appears that you have been a victim of a bug in possibly PARSE.
This one has been obviously lurking for some time (I've tested it back as
far as Core 2.3). It appears your particular experimentation has pushed it
out into the open. I'm impressed :)
Here's a demonstration. Each of the following should return true:
>> parse [34] reduce [type? 34]
== true
>> parse [34.1] reduce [type? 34.1]
== false
>> parse [34] reduce [type? 34]
== false
>> parse ["a"] reduce [type? "a"]
== true
>> parse [34] reduce [type? 34]
== true
>> parse [34.1] reduce [type? 34.1]
== false
>> parse [34] reduce [type? 34]
== false
As you can see it looks like some state travels between one invocation of
parse and the next causing very unpredictable problems.
Now these should have looked like the following:
>> parse [34] reduce [integer!]
== true
>> parse [34.1] reduce [decimal!]
== true
>> parse [34] reduce [integer!]
== true
>> parse ["a"] reduce [string!]
== true
>> parse [34] reduce [integer!]
== true
>> parse [34.1] reduce [decimal!]
== true
>> parse [34] reduce [integer!]
== true
So there is also some strange interaction between "type? x" and parse...
I've sent this information to feedback so that Rebol Technologies can fix
it.
Regards,
Brett.
[3/3] from: rotenca:telvia:it at: 6-Jul-2001 10:37
Brett Handley
<[brett--codeconscious--com]>
> I've been tracking down the problem you refer to.
> It appears that you have been a victim of a bug in possibly PARSE.
>
> This one has been obviously lurking for some time (I've tested it back as
> far as Core 2.3). It appears your particular experimentation has pushed it
> out into the open. I'm impressed :)
Thank you for the help, i was start thinking that Rebol is too exoteric (why
to do load?).
> So there is also some strange interaction between "type? x" and parse...
>
> I've sent this information to feedback so that Rebol Technologies can fix
> it.
I had sent the original example to them.
> Regards,
> Brett.
ciao
romano paolo tenca