World: r3wp

TomBon, here is the purpose of a construct:

>> ct: construct [int: (1 + 1)]
>> ct/int
== (1 + 1)
>> do ct/int
== 2
>>


Notice that it doesn't automatically evaluate /int as an object would 
do.

YES! thx a lot graham and paul. it works.

yepp, just made a check with real data. works fine. again thx for 
help...

Now, you have to tell us why it works :)

you have read my mind graham :-) but to be honest I have no idea. 
does the function preserve the scope?

I have no idea :)

Where is the parent object now?

:-)) well sounds thrustfull to built a comercial software on that 
;-)

I presume it's recreated anew each time the create-template runs

encapsulated within the function space?

You still can't clone from the objects it creates ...  ie. e: make 
a [] has the same problems

the parent object is an unevaluated block

do you think this solution is stable?

it doesn't exist as an object.

so, this is sqlabs solution

the object! will be a central part for the lib I am currently building.

wow, fractal programming at it's best

sure it's stable.

cool

TomBon, keep in mind that you can create the spec for an object and 
use it as your template as well.

>> blk: [a: 1 b: 2]
== [a: 1 b: 2]
>> obj: context blk
>> obj/a
== 1
>> obj/b
== 2

If you look at the source for 'function, you will see that the parameters 
are just 2 blocks ....

yes but the objects also containing functions and nested objects 
etc. graham approach is very compatible with the current codebase 
I have so far but thx for reminding me with this paul.

Your welcome TomBon, glad to see that you got the problem resolved.

What part of this is a bug:

>> val: 'blah
== blah
>> type? val
== word!
>> lit-word? val
== false
>> help val
VAL is a word of value: blah
>> val: to-lit-word val
== 'blah
>> type? val
== word!
>> lit-word? val
== false
>> help val
VAL is a lit-word of value: 'blah

Lit-words reduce to words pretty easily, so try this instead:
	type? :val

Yeah I actually realized that after I posted it.

What was confusing me is assignment and how it works with lit-word

Consider the following:

>> a: 'test
== test
>> lit-word? :a
== false
>> a: to-lit-word 'test
== 'test
>> lit-word? :a
== true

Seems to me that the assignment aspect is still buggy.  i would expect 
to get lit-word? true on the first call in that example.

The way I see it:

In your second post,

'test is a lit-word! being evaulated to a word! before assignment 
to 'a, in the first part

In the second part, the lit-word! 'test is being evaluated to a word!, 
passed into the function to-lit-word, then the lit-word is assigned 
to 'a


In the first post, why "type? val" returns word! on a lit-word!, 
I see as the same as this - the type is a subset:
>> X: %One
== %One
>> type? X
== file!
>> series? X
== true

It just seems inconsistent to me but I suppose it is needed to be 
this way to deal with the manner in which REBOL operates.  For example, 
consider its inconsistency in this regard:

>> string? "this"
== true
>> file? %file
== true
>> lit-word? 'this
== false

Also consider this:

>> a: first ['test]
== 'test
>> lit-word? :a
== true
>>

It's always felt consistent to me - the context is being evaluated, 
and lit-word!s reduce to word!s, word!s reduce to functions and values, 
while other datatypes reduce to themselves:
>> X: [{One} 'Two]
== ["One" 'Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a lit-word of value: 'Two

>> X: reduce X   ;Here is where typing it in on the terminal evaluates 
to
== ["One" Two]
>> ? X/1 ? X/2
X/1 is a string of value: "One"
X/2 is a word of value: Two
>> X: reduce X
** Script Error: Two has no value
** Near: Two

...and the reasoning behind lit-word!/word! acting differently is 
that those are special datatypes where other values can be bound 
to them

My point is that I don't see why the to-lit-word isn't implied when 
performing assignment.  Such as a: 'test

BTW, it is more efficient to assign a lit-word with a: first ['test] 
then it is to use a: to-lit-word 'test.

(I participatted in this discussion already one time and it also 
seems consistent to me)

Paul: I think Brian or Henrik told that time that 'word is "active" 
something and rebol reduces it when encounters it in the same way 
as it would auto-reduce function a: get-two not assign it to a (at 
least that was my compilation of it that time :) )

and we all know that blocs don't get evaluated / reduced by itself 
so [ word ]  stays [ word ] even fi word is undefined or func or 
anything so [ 'word ] also stays [ 'word ]

That makes no sense to me Janko.  By the way it was me and Henrik 
that both thought it was inconsistent.

Janko, this seems consistent to you:

>> lit-word? 'test
== false

it maybe seems odd at first sight, but consistent in the same way 
as this:

>> make-two: does [ 2 ]
>> make-two
== 2
>> function? make-two
== false

Paul, it is consinstent:

read first word - it's >lit-word?<
evaluate it - it's a function that takes one argument

read second word (first and only argument for that function) - it's 
>'test<
evaluate it - lit-word! evaulates to word!
pass it to the function - word! is passed, not lit-word!

Ok, if everyone else thinks so then this is one of those issues where 
its only me that thinks it isn't.  As long as newbies GET IT when 
learning REBOL that is what matters.

I am not so exp. rebol user as you but where do you use lit words 
as they are.. I used them only to pass words (reduced lit-words) 
basically so far ... in blocks never

 write  [  'some 'random 'words ]  but  [ some random words ]  as 
 they don't get evaled anyway

Paul: maybe you have a different usage pattern for them, so this 
behaviour that goes on looks odd/wrong when used that way?

yes Janko but that can be risking if they do get evaluated.  consider 
this [delete %/c/bootmgr]

See I read the documentation on lit-word? and it states:

Returns TRUE for lit-word values.

But you guys tell me that 'test is not a lit-word value.

That is what doesn't make sense to me.