World: r3wp

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.

You all have that need.

if it made general purpose sense then it probably would be looked 
at, but with the amount of discussion here, how generic is it exactly? 
it helps with some code examples that significantly reduce the code 
size in a general way.

I vote against the proposed change to CONSTRUCT. I believe the need 
is better served with a mezz. If it becomes popular and useful, then 
consider making it part of the standard distro.

I'll add the solution to another power type mezz package.

Tbat is what is great about NO!

Anyone know how Lua handles this?

http://host4.altme.com/altweb/rebol3/chat771.html

sorry

wrong place to paste

trying to do a bit of marketing/advocacy

There is a plan to create a library of community-supplied modules 
full of useful code that isn't generally useful; we've been calling 
it R3/Plus. Code that would go in /Plus is called library code, as 
opposed to code that gets built into R3 itself, which is called mezzanine 
code. Paul's suggestion seems like a good candidate to be library 
code.

Carl, if you make RETURN and EXIT definitionally scoped, it would 
help if the throw: attribute would disable that, so functions like 
USE would work properly. Also, please keep BREAK, CONTINUE and THROW 
dynamically scoped - most of the functions that they break out of 
don't do definition, so making them do so would add unwanted BIND/copy 
overhead.