AltME groups: search

pekr... wrt wait, cause I didn't have time to add MM timers to the 
host yet.

not timers... counter... not the same thing.   precise counters use 
the Clock frequency to measure time differences.

ah... what complicated... 

timer/mode label delay or time function.

note that a lot of this is covered in more details in the various 
ReadMe files I took the time to write prior to release.

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

yeah ... I had to write my own, would have saved me some time

I'll probably be using my holiday free time to finally release R2 
glass and make a preliminary release of Remark which is tightly coupled 
to cheyenne.

(now if I had a mini gui, I could make Rebamp:) I should invest some 
time to the view part as well.

I will alter the commit... I should give it more time.. at least 
the tab incosistency is confusing.

btw..... Thanks everyone for all the cheers, it feels good for some 
of my work to finally have a bit of instant gratification  ;-)


I also want to say thanks to everyone who's taking the time to test 
GLASS.

Henrik, ssolie already got that update at the time he worked on the 
Amiga port so this is nothing new for him.

About disreb: Sorry to be unclear originally. At the moment, it's 
R2 only (I'm currently sticking with the latest version of R2 because 
I understand that it has a more stable GUI), however I am very willing 
to incorporate changes for R3. I'm not yet sure what the best fashion 
of collaboration with the Google code site is, but hopefully I'll 
have some time to investigate tomorrow. Sorry for the late reply, 
but I have imperfect access to AltMe (it's firewalled at work and 
I forgot my password (ha!) so I don't have it working on the computer 
I'm programming disreb with). @Oldes, I hope you find it useful should 
you chance to use it! Thanks!

Kaj, when cloning your fossil repository:
fossil: *** time skew *** server is fast by 13.1 seconds

You might want to fix the system time on this machine.

Strange, not for me, and the time of my workstation is routinely 
off

My systems are properly time-synced.

The difference is most likely that my systems have a synced time, 
whereas your workstation has not.

You can easily replicate my problem: sync your system time properly.

It does not, but it'll give everyone with a synced time a warning 
on each and every clone/pull.

The time on your server is off, simple as that.

Or actually more likely, it doesn't care about absolute time, but 
only about the relative time of the server and the local machine

Relative time between check-ins.

It doesn't depend on time stamps. Each file has an SHA1 hash, like 
Monotone, Git and Arch 2

It can use time stamps to detect file changes, but you can turn that 
off if you want

I've turned off Modified Time detection. Can you tell me if that 
makes a difference in the warning?

syllable server seems to have msntp available. running "msntp -a 
ntp1.nl.net" would sync your server's time against.

server time seems still off, maybe it's too off for adjtime() to 
be used

indeed, thx GrahamC

$ nc time-a.nist.gov 13

55676 11-04-25 16:30:36 50 0 0 433.9 UTC(NIST) *

that is the exact reason I am coding Liquid in C and not in C++. 
 my project will build on anything out there, or can be easily converted 
to any other language.   furthermore, C allows me to do more advanced 
OOP tricks than C++ allows... things like run-time class mutation 
(required for liquid)

wow what a fail!  they could have built it as an "update this group" 
button which the group owners have a time lapse to activate or then 
its archived.

people I know who know about google + tend to prefer its ideas so 
far.     A lot of people I know don't like facebook at all (it just 
wastes so much time) but don't really have an alternative.  


The fact that Google plus is tackling the problem of separating your 
social circles *FIRST* is, to me, a good indication that they've 
done their homework into how they can compete which facebook.

for sure their interface will improve, But I think Google has a much 
better record for making things better in time... 


IMHO, Facebook hasn't really changed at all in years.  Its all cosmetics, 
and even then I can't really tell you what its improved.  I've still 
got a useless stream of hundreds of posts a day which I can't *easily* 
manage.  configuring **anything** in FB is tedious to say the least. 
  


And the idea of "annoy everyone you know" and "give your personal 
data to unknown companies, without my conscent" is not something 
I readily enjoy. 

even friend lists are limited in length!   basically, the whole UI 
is a disaster.

Will this language be an open or closed source project?


Question has been noted. I'll collect questions and make a QA here 
in AltME around release time. The countdown might answer questions 
and/or inspire people for new questions.

I recall you pushing for the inclusion of layers, Pekr, but we already 
had them at the time.

I digged following from Max in the past:
---------------------------------

My pet peeve about R3 view is that we still don't have access to 
the actual AGG elements directly within rebol.

We still have to go through a clumsy interface called draw dialect.

The dialect is fine (great actually) for initialisation, but after 
that, its not adapted to actual manipulation of what is going on 
inside, you have to go trough a rebol -> agg convertion stage at 
each refresh.

It's not the speed, it's the fact that it's complicated cause you 
have to create "virtual" draw components and then assemble them on 
the fly reducing blocks and stuff.
I'd love to be able to do:

a: draw [circle 30x30 15]
a/radius: 30
a/offset: 100x100
show a


If graphic elements where first class datatypes, we could completely 
ignore the gobs, and build real canvases, uber fast.

Another example, more appropriate:

; this draws a box...
draw [s: polygon 10x10  30x10 30x-30 10x-30]

; make it a house outline
insert at s/vertices 4 20x-40

; raise the "roof" 
s/vertices/4/y: -50


The problem is that to edit draw blocks, you have to create a slew 
of things before creating the draw block, then you have to store 
references to all of those things somewhere, everytime you want to 
add a "dynamic" attribute its pretty tedious.

The first-class gel datatype would allow AGG to edit its internals 
directly using binary C code through its accessors.  no need to go 
through rebol funcs and reducing blocks, etc.

The use of  "show a" above could intrinsincally know that it only 
needs to refresh the region that this element affects, just like 
all graphic cards do when evaluating the graphic pipe rendering.

So many things like flash games which become soooo heavy in AGG would 
be real-time and use much less CPU resouces.  in most games only 
a small part of the canvas really changes interactively.

He's right. While:

	g: make gob! [draw: [pen red line 10x10 20x20]]
	g/draw/pen: blue
	view g


is fine for small draw blocks, it's a pain for example setting the 
2nd pen to a different color ... or moving a logical group of draw 
operations around. In reality you are quite often forced to dynamically 
regenerate draw blocks each time ... which forces you to split big 
draw blocks up into discrete gobs (e.g. one gob to draw a blue circle, 
another a red box, etc). This is an issue with draw not gobs (which 
have been very well designed IMHO).

Yes, we want REBOL being an ultimate media engine :-) Do you remember 
Carl stating Multimedia is his second name? One point at the time 
we were even teased with REBOL/Media :-)

there's only a single column list available at this time.

cyohre i noticed the glyph engine years ago in AGG C++ version and 
i asked at that time why that wasn't existing in view adaptation

though I haven't played around with the latest versions...  and its 
been a very long time, so it could be that I tested it just before 
my vista install crapped out.

As we still have the chance to make some changes to R3 GUI, I would 
like to get the opinion of the community for this idea: R3 is designed 
for development-in-the-large, this means modularity is key.


IMO a GUI system where widgets just send messages and where I can 
register handlers for a widget-name/mesage combination would help 
a lot.


Such a system could call several handlers in a chain, it could be 
re-configured at run-time, etc. Further I think a concept like a 
(virtual-) finite-state-machine can help a lot here.

I've spent a bit of time going over R3/View and believe it now has 
all the "building blocks" required to build a modern/fast gob! based 
GUI. The amazing thing is that these building blocks are the 10 natives 
that View adds [to Core]. They are:

	gob!
	caret-to-offset
	cursor
	draw
	effect
	map-event
	map-gob-offset
	offset-to-caret
	show
	size-text


With these 10 natives (gob! is actually a type!) we should be able 
to construct simple but powerfull gob!-based GUIs with a smaller 
mezz footprint than R2. My preliminary conversion of RebGUI to R3 
seems to take about 50% the code to do the same thing [compared to 
R2] ... very promising at first glance.


To get a feeling for how tight the code can be the next post is the 
entire [skeleton] source of a working gob!-based GUI.

lack of time. building it should be fairly trivial.

I was just reading about upcoming new Facebook facelift ... and following 
the discussion I found out, that one person suggests very cool Facebook 
client done in Silverlight. I needed to download SL beta 4. Then 
I tried that mighty app. Guy, I can tell you - we can do it in View 
anyday. Its not any faster, any better, and I would really like to 
see the ugly code behind the app. My long time suggestion to popularise 
View is to wrap known services - gmail, FB, etc. E.g. especially 
on my Winmobile, ther's a FB client done by MS, and you can't even 
read more than 1 reaction to your post. I imediatelly can imagine 
Winmobile client in R3 :-)


Here's the screenshot - http://xidys.com/pekr/facebook-silverlight.jpg

One shouldn't need to access faces directly. In time, I think GET-FACE 
and SET-FACE will do this, but you might need to pass the window 
face first:

get-face window my-form


Carl already has used a /field refinement, but I'm not sure what 
it does.

I wish I had the time to review the GUI code right now, but I'm working 
on LOAD of compressed scripts/modules.

I pretty like the idea of a more reactive VID made and maintained 
by the community   something with really open source that I could 
acces any time solve the bugs that's slows my  dev and share the 
patch i made. I'm better at finding solutions to existing problems 
than inventing new problems

Robert i think 2 years ago the reply from carl was christal clear 
VID3.4 is not what he wanted  drop it he would do VID alone when 
he get the time and in the mean time 2 years 24  month  we lost  
an opportunity to motivate ourselves to get VID 3.4  tuned up

Carl seems to have some specific stuff in mind for vid direction 
but he is just not going to get to it anytime soon...I do not see 
a prob with you guys coming up with an alternate vid (rebgui for 
r3) in the mean time...each gui may be addressing different needs 
anyway. Carl's VID, when ready, can become the defacto and distributed 
with R3 but in the mean time we can use the alternate to push R use 
forward.

Guys, remember that Carl WANTS help?  that means accepting ideas. 
 especially from like-minded people.

AFAIK, Henrik is closest to the source as to how Carl wants VID to 
evolve.  So if you (Henrik) want to put time and effort while the 
next host gets released, I say GO!  


Its time this community stops asking "what does Carl want" all the 
time.  He wants REBOL to be used.  he wants his last 15 years of 
life to mean something to more than himself.


Everything going into R3 is a direct response to what WE have been 
asking for the last decade.  He wants R3 to be what WE need, within 
a few guidelines we all agree to in the first place.


He wants REBOL to grow, and like a child that has grown... Some parts 
of REBOL will grow without him, others will grow with his counsel.

well, I think we want realistic use-cases for each tag. HIDDEN might 
be useful in the context of "don't render this as it's hidden, it's 
a waste of time"

I use hidden panels and buttons all the time .. to reduce GUI clutter. 
 When the user does something that satisfies some condition, I then 
show these hidden buttons, panels.

graham yeah but in fact most of the time when you write a software 
you make it first to feel your need or the need of your client ... 
then you don't think out of the box if that guy will be able to run 
your script on his I-phone with the same posibilities that you initially 
planned

no multitouch wit threading  ( you can't have several sources of 
 event and treat them at the same time without threading system)

There are tons of questions and things to do around R3 but let's 
not fragment our time. Let us concentrate on it and get it done, 
than move on. All necessary side-effects that need to be fixed are 
in scope. All other things IMO not.

Carl, you posted a specs document to me some time ago regarding guides, 
layers and better layout capabilities. I lost it. :-) Can you post 
it again?

We need a good enough solution, that is open enough that we can drive 
it forward. At the end of the day, the GUI must fit the developer 
needs. I'm not seeking for perfection (Ok, I do) but for time-to-market 
(because I learned/know that it's more critical these days).

As I see it, you would want to map any facet in face 1 to any facet 
in face 2. Afterwards, you can judge whether that makes sense or 
not. This could be by checking for accepted datatypes in the target 
face at attach-time, but maybe that's too simple?


Also facet attachment should happen on as many faces as you need. 
If you want a slider to control 20 other faces with different facets 
as input and output, that should be possible. It's starting to look 
like a flow engine, so maybe we should take a look at what Maxim 
has done.

so if Liquid is perfect, what's the next step? Henrik needs to evaluate 
it? Does that mean that Maxim needs to spend time going over things 
with Henrik? Does Carl have to approve it himself - i.e. does he 
need to spend some time looking it over?

Also I'm being slowed down because of a project that I'm doing for 
Robert that takes time to finish. But please, continue the discussion.

I have spoken with Carl in the past about liquid, he REALLY likes 
the concept, he was mezmerized when I did a quick demo of it at Paris 
devcon.


But at that time, I wasn't trying to convince him because I didn't 
have enough real-world experience using it, and still had a few reserves 
about it myself.

in my soon to be released application, the dataflow aspect of the 
code is less than 20% of the time spent, yet it represents at least 
80% of the actual usefull software capabilities.  


most of it was fixing View and VID themselves... the styles, the 
event mechanism and bugs, AGG bugs, enhancing http, etc.

(found a way to have time events)

Pekr, not sure what you mean by two modes. I believe in Windows R3 
is using one method using the high-resolution timer using QueryPerformanceFrequency() 
-  http://msdn.microsoft.com/en-us/library/ms644905%28VS.85%29.aspx
Which should be more precise than R2 and it looks it  works OK.


The problem I see is why the CPU should be at 100% when I'm forcing 
the loop WAIT for 10ms which is plenty of free time. Isn't it?

Yes, I'm not talking about precisison..this is not important in the 
tests above. The problem is why empty loop with enough IDLE time 
for CPU is making it at 100%

Right. I thought maybe R3 had an artifact of that, but it doesn't 
seem so. CPU use goes up as you decrease the wait time, there doesn't 
seem to be a magic threshold.

Are you Guys using wait , instead of time events in your GUI ?

yes,  the above discussion is wait command inside loop.
BTW what time events you mean?

like in R2 the time events generated by the rate propertie

there's no rate but you can generate time events aswell

no, it depends of the duration of the process triggered by your events, 
if it takes too much time, it will froze the CPU obviously.

The principle is simple.

At startup, I build an event time!, the I push it in the block located 
at system/view/event-port/state.

And In my global event handler, each time I receive this event, I 
repush it immedialtly in the queue.

I receive 1000 time! events per seconds in My tests, but it mights 
depend of the speed of your UC

i just made
make event! [type: 'time port: port-event]
(yes you need to add the port-event, if not it doen't work)

I'm using the official init-view-system so the sequence looks like:
init-view-system
p: system/view/event-port

insert system/view/event-port/state ev: make event! [type: 'time 
port: p]
...

Amacleod - there was a discussion on ML or elsewhere, about how useless 
email dtype is, if it can't work as email RFC suggests. I was told, 
that I should not mistake datatype, with complicated parser for possible 
correct emails. I still insist - the datatype is useless that way. 
I found some grammar, I even posted it back at that time, but I think 
that someone at RT was simply too lazy to implement it :-)

I think that might be OK. It's just that I need to process some fairly 
large strings 50-100 kb each and it should really happen in near 
real-time, if possible.

ntfs. And yes, I normalise now, just wanted to know, why it's different 
and if it's correct. (because I've spent some time to figure out 
this exists?/delete difference).

There shouldn't be any problems with this particular operation being 
defined, but I haven't done much bug testing since I don't need any 
graphics support most of the time. All I do is core.

A Gob can only have one parent at a time.

Interesting. It's been a long time since I used C++ (there were no 
standard libraries then). It never occured to me that someone would 
use an unstable sort algorithm without checking first whether it 
would be safe to do so. I must have missed that in college.

How to waste his time ? Get ladislav's mergesort working in-place.
--> done

true, however at this time, it's going to be very time consuming.

Does anyone know why modifeid? and info? return a date without the 
time when accessing a file through ftp lon a windows ftp server? 
 Is this a limitation of windows, the ftp scheme, the ftp server, 
or the version of Rebol (I'm using the latest 2.7 - activated ODBC 
connection all dll access)?  Are there any known fixes to this - 
a quick google didn't find anything?

it should return the time, I've got ftp synching routines which use 
info? and use date/time.   so I'd bet its a limitation on the server, 
or its using a non-standard date string in its LIST command.

Here's a working version:

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Yes, I am using xml-parse and then xml-object. My question is something 
that I have dealing with for a long time actually. So is there a 
limit to how far something is reduced in terms of nesting?

Understood. Thanks a lot for the time you spent ;)

so I'm pooped.... time to fire up the PS3.

you have no recourse

 is a polite way of saying "you are out of luck". At least regular 
 programmers would be out of luck there - I'm sure someone like Ladislav 
 could come up with an arcane workaround, or you could give up on 
 RETURN and EXIT and use another escape function instead, like THROW. 
 But I assume that you know what I meant by "recourse", and want the 
 point explained.


Pardon me, that question needs some background info. The return models 
are being used to deal with a basic problem of functions catching 
RETURN and EXIT when you don't want them to. This is the case with 
many mezzanine control functions which take and execute a block of 
code. We have been putting requests for new mezzanine control functions 
on hold for quite a while because they can't currently be made to 
pass through RETURN and EXIT, but USE and COLLECT got through before 
we started that, and the restriction is lifted now.


Let's use USE to illustrate, ignoring for the moment that USE *can* 
be rewritten so it doesn't use an inner function.

use: func [
    "Defines words local to a block."
    vars [block! word!] "Local word(s) to the block"
    body [block!] "Block to evaluate"
][
    apply make closure! reduce [to block! vars copy/deep body] []
]


USE uses an inner function to create a binding for its words (the 
closure!). For the dynamic return we have now, the inner function 
catches returns from the body, but even if it didn't the USE function 
itself would catch those returns as well.


One proposal to solve this would be to switch to definitional return, 
which means that RETURN and EXIT would be redefined in the code block 
of a function to return directly to that function, not any intermediate 
function in the call chain. This would solve returns being caught 
by the USE function itself, because the body of code that contains 
the 'return or 'exit words is not physically in the code of the USE 
function, it is only referenced by word. However, that block of code 
is used by the inner function as its code block, so the inner function 
would redefine those words and catch the returns.


If your function uses inner functions like USE does, and can't be 
rewritten to not use them, and you are using definitional return 
without the option to turn it off, then the inner function will localize 
RETURN and EXIT every time.


As a caveat, I wrote that phrase before I came up with the workaround 
in the next section of using direct references to the RETURN and 
EXIT function values instead of referring to them by name, which 
avoids the rebinding issues because no words are involved. See the 
code in http://curecode.org/rebol3/ticket.rsp?id=637to see what 
that workaround makes your code look like.

Thanks for all the effort that went into that doc! I've skimmed it, 
but will have to find time to read it in depth and digest it.

I made some notes here and there, but can't seem to make time to 
really think deeply about all this. Consider these thoughts lightly 
---


The FOREACH trick is clever, but it makes me wonder if things are 
a bit inverted. Should there be a core binding func that does that 
service *for* FOREACH and other funcs that need that behavior.

Even though it's temporary, should this:
    if set-word? first words
be this:
    if find words set-word!

(behavior alterations and 'values being modified ignored due to temp 
status of func)


TRY/EXCEPT doesn't read particularly well to me, because 'except 
sounds like you're leaving something out, rather than catching the 
error.

I have discussed a new page organization strategy for the Exceptions 
page with Ladislav. As time permits, I will try to reorganize. It 
will make these issues much more clear.

PARSE doesn't bind the code in its parens - that's regular REBOL. 
Parse also can't know ahead of time which blocks it will be treating 
as rules, because it uses dynamic scope for the whole dialect.

Yes there is: Definitional breaks redefine BREAK to a definitional 
function, and PARSE relies on BREAK being dynamic because PARSE is 
inherently and necessarily dynamic and doesn't rebind anything in 
the parens, nor should it. For that matter, PARSE rules can be reassigned 
in their productions, so PARSE can't even rely on the rules being 
the same thing the next time round.

Well it comes down to this: Functions are defined lexically. Though 
they are called dynamically, they aren't called until after they 
have already been bound, definitionally. But as a side effect of 
tasking, those bindings are stack-relative, and those stacks are 
task-local. But random blocks of code outside of functions are bound 
to object contexts, and those are *not* task-local. So that means 
that the old R2 practice of calling shared blocks of code is a really 
bad idea in R3 if any words are modified, unless there is some kind 
of locking or synchronization. This means that those blocks need 
to be moved into functions if their code is meant to be sharable, 
which means that at least as far as RETURN and EXIT are concerned, 
they can be considered lexically scoped. The advantage that we would 
get from being able to call a shared block of code and explicitly 
return in that block is moot, because we can't really do that much 
anymore. This means that we don't lose anything by switching to definitional 
code that we haven't already lost for other reasons. At least as 
far as functions are concerned, all task-safe code is definitional.


Loops are also defined lexically, more or less, and the rebinding 
ones are also task-safe because they are BIND/copy'd to a selfless 
object context that is only used for that one call and thrown away 
afterwards. And most calls to loops are task-safe anyways because 
they are contained in functions. However, the LOOP, FORALL, FORSKIP 
and WHILE loops do not rebind at the moment. We actually prefer to 
use those particular loops sometimes in R3 code because they can 
be more efficient than *EACH and REPEAT, because they don't have 
that BIND/copy overhead. Other times we prefer to use *EACH or REPEAT, 
in case particular loop fits better, or has high-enough repetitions 
and enough word references that the 27% overhead for stack-local 
word reference is enough to be more than the once-per-loop BIND/copy 
overhead. Since you don't have to move blocks into *loops* to make 
them task-safe, you can use blocks referred to by word to hold code 
that would be shared between different bits of code in the same function. 
This is called manual common subexpression elimination (CSE), and 
is a common optimization trick in advanced REBOL code, because we 
have to hand-optimize REBOL using tricks that the compiler would 
do for us if we were using a compiled language. Also, PARSE rules 
are often called from loops, and they are frequently (and in specific 
cases necessarily) referred to by word instead of lexically nested; 
most of the time these rules can be quite large, maximizing BIND/copy 
overhead, so you definitely don't want to put the extensive ones 
in a FOREACH or a closure.

Switching to definitional break would have three real downsides:

* Every loop would need to BIND/copy, every time the loop is called, 
including the loops that we were explicitly using because they *don't* 
BIND/copy.

* Code that is not nested in the main loop block would not be able 
to break from that loop. And code that is nested in the main loop 
would BIND/copy.

* We can in theory catch unwinds, run some recovery code, and send 
them on their way (hopefully only in native code, see #1521). Definitional 
escapes might be hard or impossible to catch in this way, depending 
on how they are implemented, and that would mean that you couldn't 
recover from breaks anymore.


The upside to definitional break would be that you could skip past 
a loop or two if you wanted to, something you currently can't do. 
Another way to accomplish that would be to add /name options to all 
the loop functions, and that wouldn't have the BIND/copy overhead. 
Or to use THROW or THROW/name.


The situation with THROW is similar to that of the non-binding loops, 
but more so, still task-safe because of functions. But CATCH and 
THROW are typically the most useful in two scenarios:

* Escaping through a lot of levels that would catch dynamic breaks 
or returns.

* Premade custom escape functions that might need to enforce specific 
semantics.


Both of these uses can cause a great deal of difficulty if we switched 
to definitional throw. In the first case, the code is often either 
broken into different functions (and thus not nested), or all dumped 
into a very large set of nested code that we wouldn't want to BIND/copy. 
Remember, the more levels we want to throw past, the more code that 
goes into implementing those levels. In the second case definitional 
throw would usually not work at all because the CATCH and the THROW 
would contained in different functions, and the code that calls the 
function wrapping the THROW would not be nested inside the CATCH. 
So you would either need to rebind every bit of code that called 
the THROW, or the definitional THROW would need to be passed to the 
code that wants to call it like a continuation (similar concept). 
Either way would be really awkward.


On the plus side of dynamic (whatever), at least it's easy to catch 
an unwind for debugging, testing or recovery purposes. For that matter, 
the main advantage of using THROW/name as the basic operation that 
developers can use to make custom dynamic escape functions is that 
we can build in a standard way to catch it and that will work for 
every custom escape that is built with it. The end to the arms race 
of break-through and catch.

Note that the definitional BIND that functions do when created is 
*not* a BIND/copy, it modifies. Same thing with closures when they 
are created, though they also do something like a BIND/copy every 
time they are called.

...and, the biggest disadvantage of the dynamic return is the opposite 
- the fact, that knowing the lexically closest catching construct 
does not tell you, which construct will be the closest one at run 
time

Well, but don't forget about the binding being done anyway, which 
makes the binding time actually negligible

The binding time is *not* done anyway by all loops. It is only done 
by REPEAT and *EACH, and we now often avoid using those functions 
*because* they rebind. REPEAT and *EACH are mostly used for small 
loop code, because of that binding time *and memory use*, which is 
even more significant than time in a lot of cases.

Though FORSKIP is used a lot too. LOOP, REPEAT and WHILE aren't used 
much anymore, and I can't remember the last time I saw FOR used in 
real code, though I use it a lot in adhoc file management code.