World: r3wp

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.

not sure if hot patching was any usefull. I used it just to show 
my friends, that I can modify my func from inside its code block. 
But you can dynamically eventually build copy of function, etc., 
so not sure not having a hot-patching is a problem ...

If the references *are* protected, then that means that the code 
using those references expects the code to be the same, to run the 
same, or else. The ability to hot-patch that code destroys that trust.

hot patched code can be difficult to read :-)

Ugh, agreed Henrik :(

Pekr: "when is A98 going to be released?"

I don't know. I thought soon, but then Carl went wild with fixes 
and core semantic changes like the 'self stuff. It may still be soon, 
since those are done. It depends on how many more magic tricks Carl 
wants to pack into this release.

rebol 3 are you around ?
shandwolf pokes rebol 3 .. hum ? still breathing ?

OH COMON I WANT R3 FULL RELEASE BEFORE XMAS 2010 !!

in advance thank you

Funny :)  We missed your input in the huge flurry of R3 development 
last week though.

There is an ongoing discussion about REBOL3 objects and accessors 
ongoing into the "Other Languages" section. BrianH and Maxim have 
discussed and a proposal has been made at http://www.rebol.net/wiki/Objects_enhancements.

This proposal is only of their side and we request the other GURUs 
to partecipate to build up other POV.
Then the proposals will be submitted to Carl.

Please partecipate ! The object  heart is open right now and in the 
hands of Carl ! :-)

I see it as a matter of priorities, and declare, that it is not my 
priority.

Ladislav,  we see Carl focusing on some or some other part of REBOL. 
This time he is working on the object part of the language. It would 
be good to have your (and the other) respected opinion about this 
topic now. Maybe we will be able to close this topic which has been 
opened in the blog in the distant year of 2006.
However, no one is forcing anyone to do anything...

what's 'filter-error? It's undefined in R3 .... http://www.rebol.com/r3/docs/errors/internal-bad-path.html

I expect that it is just some adhoc function that Carl rigged up 
in order to be able to generate the examples on the error pages.

Yes, Giuseppe, understood, what I wanted to say (to not sound rude) 
is, that I prefer to not "distract" Carl with this, seeing other, 
more "urgent" problems in CureCode...

I would especially like to see is the problem of Throw, Break, etc. 
solved, and the problem of function Return (comprising other issues) 
solved.