World: r3wp

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...

If I understand new proposed syntax correctly with my very limited 
REBOL brain :-), we will be probably able to "reassign" functions 
(not only), providing shortened argument block, hence dissallowing 
rest of arguments, and binding such new function to the body of the 
original one, so creating some kind of wrapper around the original 
one?

If you remember, once I used a trick to achive the same effect to 
enhance the BIND function

(in R2)

Pekr, that's almost it, but not quite:

- All functions are a wrapper around a spec and a body, though the 
body of natives is internal.

- You will be able to make a new function derived from an old one, 
with a new spec, body or both, or just the same.

- When the spec isn't changed in the derived function, it will likely 
get a copy of the old spec, not the original.

- When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.

- When you make a new native function (action!, native!, command!, 
maybe op!) it will call the same code, not a copy.


We'll have to see what changes we can safely make to specs without 
breaking functions. Right now we know we can change doc strings and 
typespecs, but we'll have to see if we can change argument ordering, 
naming and number. I expect that more changes will be possible with 
REBOL functions than there are with natives, due to the new function 
getting and rebinding its own copy of the code block. And natives 
might need some more internal type screening in order for this to 
not be a problem.

still pretty nifty.  except for javascript I are there other languages 
which can do this?

You can't do this in Javascript.

Javascript function derivation is like object derivation.

is es5 you can derive functions and manipulate them...

which is semanticely the same... IMHO

functions are first order types in JS  afaik.

although the syntax in R3 is pretty, in JS is very ugly  :-)

Ah, I must look into this. I knew they were first-order types from 
the beginning, but not that the code and specs had themselves become 
data.

es5 adds a lot of new tricks for playing around with values.  the 
args list can be retrived, applied, changed, etc.  I'll admit the 
part about the code body is a bit fuzzy in my mind, but I seem to 
remember that you could play around with it in some way too.
 

playing around with the functions isn't exactly the same but the 
end results are very similar IMHO. 

especially since hot-patching isn't allowed in R3 anymore.

switched to the right channel

one thing that ES5 does which I still long for in REBOL is how they 
have opened up the accessors, for everything as well as management 
of object keys, and member attributes like writeable, replaceable, 
public, etc.

oops, yeah sorry.

When you make a new REBOL function without changing the body, the 
new function will have a deep copy of the body, not the original.
 - why the copy?

BrianH: maybe it was not practically usefull, but removing hot-patching 
capability from REBOL - haven't we lost some level of reflectivity?

Because it has to be rebound, and because inline series data is modifiable.

haven't we lost some level of reflectivity?
 - Yes. The unsafe parts have been removed.

I would prefer an optionnal mechanism

R3 is being built to be able to run untrusted code. Still a goal 
rather than a reality yet, but it's a *design* goal.

And you have an optional mechanism: You can derive a new function 
and replace the references to the original. If those references aren't 
protected.