World: r3wp

Does function! and closure! work backwards when dealing with indirect 
values (block!, string!, ...)?

>> f: func [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> f
== ""
>> f
== "1"
>> source f

f: make function! [[/local b s][b: [1 1] s: "11" insert b 1 insert 
s 1]]

>> g: closure [/local b s] [b: [] s: "" insert b 1 insert s 1]
>> g
== ""
>> g
== ""
>> source g

g: make closure! [[/local b s][b: [] s: "" insert b 1 insert s 1]]

Souldn't the functionality be the other way around?

looks correct to me

I got the feeling, closures should work as R2 functions, that would 
remember local variables, after the function returned. And functions 
in R3 are implemented using stack-frames.

ok, I'm under the impression that closures are supposed to do the 
opposite thing.

well it's because inside a closure, all series are copied before 
each new run.
it's like having done:

g: make closure! [[/local b s][b: copy [ ] s: copy "" insert b 1 
insert s 1]]

Perhaps we should ask Carl not to copy deep the series when a new 
calling context is created.
Don't know...

What a closure seems to do (sort of):
func [][
	compose context [
	 (copy/deep body)
	]
]


It's not a correct simulation of R2 functions, which should be something 
like:

context [
	func spec body
]


You see, the context created should be outside, so that it would 
be build only one time and not each time the function is called.

(don't focus on the examples i gave, which are not functional, but 
about the topic)

Actually, it's what i do to create local persistant variable in a 
function. I wrap the function in a context and declare the persistant 
variable in the object instead.

More i think about that, more i think the closure! type is useles, 
at least less than the above case.

My bad, FUNCT is doing that (wrap the function in a context).
So the true alternative is to use FUNC not closures.

* FUNCT i meant

k so lets say that network protocols are not the hardest part so 
far it can wait the last minute ?

Geomol, closures need to do a bind/copy at each call. maybe that 
should not copy strings, though, however, this way it is more consistent 
i guess.

Hehe, what is this? I did not know such func exists :-) I just realised 
it as Carl adressed the stack size:

evoke: make native! [[
    "Special guru meditations. (Not for beginners.)"

    chant [word! block! integer!] "Single or block of words ('? to list)"
]]

example:

secure none
evoke [stack-size 1000000]

2.100.87 out ...

http://www.rebol.net/r3blogs/0262.html

BREAK for PARSE.

btw - what does Carl mean, that BREAK is not yet defined for parse? 
It exists even in R2, no?

Ah, I had the same reaction Pekr.

And i posted the same request than you

PARSE was rewritten from the ground up for a86. I guess he hasn't 
added back break yet.

PARSE break is currently ignored.

A87 helped on the GUI demo at least.

Cool :)

is break ignored? parse "123" ["1" "2" break "3"] throws false ....

It doesn't break loops, which is the only thing it was ever good 
for, barely.

Carl wikified the project plan - http://rebol.com/r3/docs/project.html


I am now suggesting the following aproach - to create October plan, 
describing R3 beta release. My proposal is to discuss particular 
items here and on chat, but the main channel should be blog. There 
we can post our priority lists. Once agreed, we edit the doc.


So hopefully soon enough, we open the discussion. We might already 
start, but save your comments for the blog. This group is moving 
fast with discussions, maybe we could set-up (temporarily?) an R3 
priorities group, and each of us could post his numberred/bulleted 
list of requested features? It would be then easier for Carl to look, 
or for us to gather ideas and repost them to blog, etc.

What do you think?

R3 priorities groups...  Good idea.


go ahead, I'll post righ after... even though you all know what my 
number 1   ;-)

I would also post my callbacks/device code example as a link within 
the wiki so carl doesn't loose it a 3rd time  ;-)

how can I become an editor for the wiki?  I would eventually add 
some stuff for the extensions (from me and others).

The permissions for the manual wiki are based on the R3 chat user 
rank. I don't know what the cutoff is to get editing privileges.

yeah... I'm in  :-)  I did a bit of clueless running around, then 
I got it  :-)

writting up a complete,  revised, and proper document for a devices/callbacks 
spec, which I will link within the projects plan when its done  :-)

We should discuss any changes before they go in. We don't want the 
priorities page to become a war zone :(

the goal is to make it a working document, we (those who care about 
this issue) can pitch in and improve.

this actually is something carl wanted IIRC  :-)

as I said, its a new page, I'm only going to add a link within the 
devices entry....

Agreed, and a few links in the comment column would help here and 
there :)

so carl can easily refer to it.

CureCode priorities haven't been as usefuul as we hoped, though they 
have been quite a bit better than nothing.

its funny that carl complains about people becoming lazy with parse, 
yet the only way to get Carl's attentions really is to make it ubber 
easy for him to access it (read as: it allows him to be lazy about 
it  ;-)

I consider the ability to be lazy to be an advantage :)

priorities are a matrix... everyone does the error of viewing them 
as a list.

I do to...

I work VERY hard to be as lazy as possible   :-D

I have a few security concerns that haven't made the list yet - mostly 
requiring the rest of the PROTECT tickets to be done.

I think, that naturally, such document should be part of CureCode. 
But that is for the future. Simply put - in cure-code, you post a 
wishes too. Those might be dismissed, or accepted. There should also 
be a table called releases, where admin could add version numbers. 
Then fixed-in could use shortcuts as fixed-in 'next release, and 
the correct version would be filled-in, etc. From there, such pririty 
list and milestone releases description could be automated. But - 
we don't need it now ...

I think, that we should go for the R3 priorities, or R3 priority 
group here. We should NOT edit the doc in the wild, unless we discuss 
requests. I think, that the table is also not suited for the small 
bits. If we e.g. want Security to be adressed, we should note  - 
Security - ticket x, y, z

the idea is to be sensible in any case.

like for any part of the wiki.

I'm drafting a really nice document... I have a few new ideas which 
you might like in the proposal...  :-)