World: r3wp

Paul, set-word!s are syntax for SET. [a: b: 2] is syntactical short-hand 
for [SET 'a SET 'b 2]. SET returns sets a word to a value and returns 
that value. If you don't want to pass the result of (SET 'b 2) as 
argument to SET 'a, then just don't do it.

The block argument doesn't have to change at all - just the handling 
of it.

Yeah, Andreas, you would have thought I woulud have figured that 
out since I have been doing REBOL since 1998.  That must be something 
new.  ;-O

Now for real, it was just a request for something rather not as complex 
as the fear around it.

Great, then write /as-is as a mezzanine for now and propose it to 
be included.

Paul, you're basically asking for REBOL to do a fundamental change 
to its syntax inside construct.

with 2 blocks it's easy, one for the definition, one for the assignement.

>> assign: funco [spec vals][append construct spec vals]
>> assign [a: b: c: d:][c: 2]
== make object! [
    a: none
    b: none
    c: 2
    d: none
]

Explain what you mean by fundamental?

Am I asking for the construct code to be change - duh!

That you want a peculiar change to set-word! semantics.

Never said that Andreas.  Just in how it wants to handle the processing.

The block wouldn't be passed to set directly is all

Which block?

The code in construct would have to parse the block

From (a: (b: (c: 2))) to ((a:) (b:) (c: 2))

That's a fundamental change...

so what is an unfundamental change?

Writing an intermediate solution for special cases...

its code that never gets executed unless the refinement is set.

no different than an either.

unchain: func [spec] [forall spec [if all [set-word? first spec not 
tail? next spec set-word? second spec] [insert next spec :none]] 
spec]

And now I would ask you why add that function to R3 when you already 
pass a spec to contruct in the first place?

I guess that's what you want. Now adding that as refinement to construct 
is a question of wether it would be of general utility. If not, it 
would just be bloat.

My point is that if we just adding your entire function to R3 verse 
a refinement to construct - we would be adding MORE bloat

I personally think that neither that function nor the refinement 
should be added.

You fear change?

Nope. I just don't see any general utility of it.

See I do.

That's why it probably is best kept alongside your code, to cater 
for your special purpose needs.

So if I went to falcon or Lua and said do that and they did they 
could say they could handle such code safer than REBOL could.

That's not an safety issue.

The hell it aint.

Maybe your confortable with it.  Oh well.  But if you don't think 
the chain evaluation should be a safety concern then I think your 
not being rational.

let's say you have a service oreient protocal that is sending unencrypted 
blocks of data that is getting sent into contstruct on the other 
end.   All I have to do is capture it midstream alter the block and 
forward on and I can cause your code to behave differently.

why is that a safety concern? in that case REBOL would be one big 
security hole as this is standard syntax.

Are you saying it isn't true Henrik?

Paul, construct is using standard REBOL syntax in this case. If that 
is a safety concern for your purposes, that's outside the scope of 
CONSTRUCT.

If you're already iterating through your block to convert every second 
word to set-word, then why not also neutralise any set-words that 
should be - seems that is where the flaw is...

..should not be...

But what if I'm not the one doing it.

Paul, you don't create services that carelessly evaluate data that 
is potentially manipulated by an attacker. That's a security hole 
and bad coding. That's one of the good things about dialects.

Agreed, and that's what this is - a dialect - as Rebol's sop is chaining...

I'm not saying to stop chaining am I?

I'm saying to offer a case where we don't chain.

But obvoiusly you guys are not in favor of options.

Why not also offer a case where we drop all strings encountered?

Or a case where we double all integers?

Are the strings a concern?

are single integers a concern?

We have build in code to handle those things don't we?