World: r3wp

No Andreas, this is not passing about the passing of the arguments 
but the handling of the arguments.

The same argumet can be passed but it is how it is handled.

Chris, I had an issue where I was putting data into a block dynamically 
and then had a skip pattern over it so that every other word was 
turned into a set-word and then passed to construct.

As you can imagine that did a chain evaluation that I didn't want.

Then make sure to prepare a block that does what you want.

There was actually a bit more that it did in removing some data but 
anyway the point is that it cause some values to get the next value 
in the chain.

Yes Andreas could do that but your missing the point.

The point isn't about whether or not I can do that.  I already do. 
 The point is that it offers more for the construct function to do 
at what I believe would be less cost with more to gain.

This the way you guys should think about REBOL.

Shouldn't always be about - just creating a new mezzanine.  Think 
about the cost of the mezz verses an enhancement to existing code.

Paul what you are asking is that the construct function should rather 
arbitrarily rewrite the block argument it is passed.

huh? - not at all.

construct/as-is [a: b: 2]

Why would that be so difficult?

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?