World: r3wp

>> value? first to-block "any"
== false

in that exemple, ANY is not bound

let me check something... it might add to the confusion  :-)

to-block, do like LOAD, except it doesn't bound the words in the 
global context

>> do probe to-block "1 + 1"
[1 + 1]
** Script Error: + word has no context
** Near: 1 + 1

>> value? first to-block "[any {a}]"
== true

this is whacky

lol

>> value? first to-block "any {a}"
== false

I know... very broken.

No,  you must remove the brackets

but my data HAS inner blocks.

this is just plain dumb.

the result is of course correct ..

So, do a double first

>> value? first first to-block "[any {a}]"
== false

and? 'any is a word. It surely does not have a value. What are you 
wondering about?

pekr it aint. if to-block doesn't bind words... it just shouldn't 
.  how am I going to manage loading data from disk and hope it doesn't 
collide with some stray global word

but I realize that all words are bound.

Actually, to-block doesn't bound anything, what the problem so ?

ok, let me try something then.

In the old past days, 
to-block "[any]" was returning only one block.

It's returning a double block since some versions, never understood 
the interest of such change.
>> to-block "[any]"
== [[any]]

ok, so parse is the root of my problem.  it specifically word binding 
for its keywords, but looks up all other words... which is what's 
causing the inconsistency in my code.

specifically *ignores* word

I don't see your point, what you say seems wrong, can you give us 
an example ?

in my code, I was getting different results for some keywords.  any 
is bound to global, but some isn't anything in rebol.

so since I can't create my rules using to-block (cause the parse 
rule is actully changing itself, using pre-bound rules... I'm stuck.

well, just bind yout rules in a specific context.
con: context [
	any: 'any
	some: 'some
	opt: 'op
	...
]

redefines the parse keywords as you want

so what I'll do is follow parse's functioning.  if a word maps to 
a function or a native, ignore it... I know my rules don't bind functions, 
cause they'd fail anyways.

yeah that would work too.

Maxim, BOUND? doesn't bind words to the global context - that was 
done by LOAD. Try this:
>> bound? first to-block "a"
== none

yes yes... that was understood later on.

I'm trying to hack up an UNBIND backport to R2/Forward though.

load is the core culprit here.  I didn't realize that all my rules 
where being bound at application load time, since every word is created 
by load initially.

That was one of the first things changed in R3. If need be you write 
your own loader for R2 that uses TO-BLOCK and then does the binding 
itself - LOAD in R3 is a mezzanine that does the same.

>> d: now/time
== 17:11:08
>> d/1
== 17
>> d/2
== 11
>> d/3
== 8.0
>> d/3: 0
== 0
>> d
== 17:11
>> d: now
== 23-Oct-2009/17:11:37+13:00
>> d/4
== 17:11:37
>> d/4/3
== 37.0
>> d/4/3: 0
== 0
>> d
== 23-Oct-2009/17:11:37+13:00
>> t: d/time
== 17:11:37
>> t/3: 0
== 0
>> d/time: t
== 17:11
>> d
== 23-Oct-2009/17:11+13:00

I can change the second component of a time! but now when it is part 
of date!    ???

but not ...

date doesn't have accessors for individual time values...

once you use d/time, its a new value of type time!

you have to use d/time: t  in order to push it back into the date.

inconsistent

I would have tought R3 would have addressed this, but it hasn't  
:-(

... I just checked

>> date: now
== 23-Oct-2009/19:31:27+13:00
>> type? date/time
== time!
>> date/time/3
== 27.0
>> date/time/3: 0
== 0
>> date
== 23-Oct-2009/19:31:27+13:00

What exactly is the explanation here??

I'm accessing a time value .. not a date value

date is a point in time... 
time is an amount of time...

they aren't the same thing.


you can have time values with 50 hours in them,  but you can't have 
50 hour days.

but I would like to be able to interact with the time within a date 
directly anyways myself.

Lets put it in curecode

yep. it might already be there as a request.