World: r3wp

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"
]]

And add more datatypes to the spec as testing determines them to 
be safe.

Wait.... I need to disgest that insanity at first... make :make...

I'm tired.... You could give me some time...

Compare spec-of :make to see the difference.

If might help the insanity to know that you can't do this yet. After 
copying the above message to the clipboard:
>> do clipboard://
Script: "Untitled" Version: none Date: none
** Script error: invalid argument: [[
        "Constructs a specified datatype."

        type [datatype! any-object!] "The datatype or example value"
        spec [any-type!] "The attributes of the new value"
    ]]
** Where: make catch either either applier do
** Near: make :make [[
        "Constructs a specified datatype."
   ...

I'm willing to bet that that is internal rebol initialization code 
that we won't be able to use.

According to the blog it looks like a newly available feature, not 
working with older interpreter versions...