World: r3wp

About remove-each in R3, I dislike the new given output (numbers 
of values removed).
What the point to discard the most powerful feature of Rebol ? 
- Chaining operations on series.

Besides, To count how much values have been removed is trivial to 
do and a very rare use case.

Pekr, note that he said "I think we need to add back to R3 a struct-like 
datatype (or function.)". I think that the function option would 
be more powerful and less awkward to use.

Steeve, the ticket for REMOVE-EACH is #931. Please make your comments 
there.

Either way you are discarding a feature. The question is whether 
the remove count or the chaining is more important. You and I seem 
to prefer the chaining, Carl seems to need the remove count (for 
reasons not given). Between the two, the chaning is easier to work 
around not having than the remove count is.

ChristianE, It seems like an oversight to me. We aren't doing the 
SQL-style "null doesn't equal anything, even other nulls" model in 
REBOL.

Pekr, sorry, you did mention "or function" :)

:-)

BrianH: time to push protect related bugs for implementation, no? 
Aren't they keeping us back from having security fixed?

about time ... empty? none

yes, done ...

hmm... diffferent solution from my NEUTRAL? suggestion.

Yes, protect bugs, but not for a98. It's actually been good to put 
them off: It's given us more time to really think about them. Security 
is a hard topic. Unfortunately, my proposed changes are flexible 
enough, but will need a lot of chaining to get the right pattern 
and recommended chaining patterns will need documenting.

I use this 

something?: func [ o [any-type!]][
    all [ o not empty? o ]
]

I would like to come up with a simpler solution that anyone can get, 
but I'm afraid this is likely not possible given the topic.

Graham, you would need to either refine the code or the typespec. 
That's not right for most types, and not safe for function types.

I just use it for series

something?: func [ o [series! none!]][
    all [ o not empty? o ]
]

Ah, good, then it's the typespec that would be refined :)

bette?

(you beat me to it) Yes :)

With the revised EMPTY? you could do this: false = empty? o

something is better than nothing

nothing? is not something?

Something is only better than nothing in some circumstances. "What's 
wrong?", "Something" :(

for me nothing is an empty series or null

actually I would prefer that empty? also is true on a series containing 
spaces only ...

when proceessing input

It's good that you have that function then. I prefer to think that 
an empty series or a series full of spaces is something, and that 
none is nothing.

However, it may not be the something you want.

Basically when doing forms you need to detect if the user has entered 
something

and a series of spaces is not something

it might be the cat walking on the space bar

Yup. Different topic than what EMPTY? covers though.

Yeah ,... much to do about nothing

:)

Graham - then use empty? trim value to remove spaces :-)

trim is destructive

trim copy then :-)

I know that copy is an overhead, but forms are of finite length, 
so I would not worry about performance. I used empty? trim copy value 
idiom in the past ...

Wait, your user input functions don't allocate a new string each 
time? Why else should you care if trim is destructive?

more then just keyboard input ...

Sorry, nevermind then.

Carl just posted this code, to be the new definition of EMPTY?:
empty?: make :tail? [
    [

        {Returns TRUE if empty or NONE, or for series if index is at or beyond 
        its tail.}
        series [series! gob! port! bitset! map! none!]
    ]
]

This means two things, one minor, one major:

- Minor: TAIL? won't take none, so we have an option of triggering 
the error if need be.

- Major: *You can do that kind of thing at all*. This opens a *lot* 
of possibilities :)

make tail?

interesting

Wow, i like this strick, I will use it everywhere i can

I wonder what the effect will be on function! and closure! functions, 
whether there is body copying. It seems like a really interesting 
way to do optional arguments to commands though.

But it's a litlle obfuscated.

I expect that the best use will be either making is-it-an-error-or-not 
changes like the above, or simplified versions of functions, perhaps 
for sandboxing. So remember this: If you have a nice, friendly native 
function with some advanced, evil options, put the most evil ones 
at the end of the list, so they can be hidden later if need be.

Or, alternatively, we may have to block this in sandboxed code so 
it isn't used to break the sandbox.

safe-make: make :make [[
    "Constructs a specified datatype."
    type [datatype! any-object!] "The datatype or example value"
    spec [any-type!] "The attributes of the new value"
]]