World: r3wp

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?

Do we?

I don't know of a construct refinement that drops all strings.

Then we just make sure they get assigned to the proper place don't 
we?

yes, we do. with PARSE and dialects.

And that's what you should do too, Paul.

I do Andreas, I have to currently use more bloat just like all of 
us do to handle it.

That's not bloat, that's application specific code.

And no, it's not "all of us", as none of us have those specific needs.

Just as you don't seem to have the need to drop all strings ...

bloat is in the eye of the beholder.  To me where it takes more code 
to do something that could be done elsewhere is bloat in my book.