AltME groups: search

FYI, your latest release works for me, Win 7 64 bit, Radeon 5770 
with 10.10 drivers, in the sense of not crashing, but the actual 
3D shape being drawn is not really visible. It is vaguely visible 
as the drawing surface is rendered and you see flickering bits of 
the surface, here and there

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

(simple when we don't want AA... requiring AA probably needs a bit 
more work, since we usually have to chose between what is available)

to get glass for R3 is a big endeavour, but after the holidays, possibly 
starting in february, I will be working on this.  


right now I've got a very stable glass for R2 which just needs to 
get its last touches applied to current skin and refurbishments for 
the tutorial I had already started building which is now a bit out 
of date with current state of glass.

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.

yes, I might github it, but I'm still a bit noob with git, so won't 
do this right now.

RMA, panel doc :

The light gray text on white background that you use for code block 
is nearly unreadable. Please darken the text a bit !

I somehow agree with Ashley, though I can understand that you have 
some structure set. The top level menu simply does not show - Docs 
directly. So intuitively I went to Code, and then - huh, what's Level-1? 
If I would not read more about your infrastructure, I would feel 
a bit lost probably :-)

Thanks to both Kaj and Andreas for taking up the 0mq task. Since 
Andreas made it so easy to try, with prebuilt binaries, I already 
played a bit, and it works fine here. Very exciting stuff guys.

-r set it back a bit

Yes, but a bit much for just looking at the clock every five hours

Maybe. Anyway - it is a bit confusing name, as we know Altme Worlds. 
Maybe a World language woul be better, but - dunno ...

I expect it to be a bit like Lua.

Max continuead a bit:
----------------------

part of what I want to attempt for my host code work is to implement 
liquid and globs natively in R3.  with access to AGG I could build 
the single most powerfull canvas engine in any language...


 we'd have absolutely nothing to envy to ANY other language, not even 
 Apple's engine... as long as the AGG can render a few more things 
 and add filters to AGG strokes.


globs use AGG and allow events to be sent to individual AGG strokes. 
 so you can "slide" a single line by clicking on it. the cool thing 
is that the input mask and display are separate... and you can implement 
any number of layers per display element that you want.

to me VID always very easy to use.  making it pretty & dynamic ... 
well that's a bit (a lot ;-) more painfull.

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.

Reposting from R3 chat (which seems a bit quiet lately).


I've been looking at the rich text gob! functionality and it seems 
the following dialect commands are supported:

	anti-alias logic!
	bold [off]
	italic [off]
	underline [off]
	size integer!
	left|center|right
	drop integer!
	font object!
	para object!
	caret object!
	scroll pair!
	string!


Are there any I've missed? Any doco on this yet? I havn't figured 
out how to use drop or caret yet. Anyone have any working examples 
for these?


A design question: is there any reason for retaining font and para 
support given that we could move the few remaining unsupported words 
out of those objects and into the dialect itself? (e.g. have the 
dialect directly support font names and valign words).


Also, it would be nice if we had control over the default font name, 
size and alignments [at the very least]. Perhaps a system/view/text 
object?

Got caret working, but it's overly complex IMHO, as in:

s: "A bit of text."

c: make object! compose/deep [
	caret: copy [[(s)] (tail s)]
	start: copy [[(s)] (at s 3)]
	end: copy [[(s)] (at s 6)]
]


show append clear system/view/screen-gob make gob! [text: [s caret 
c]]

regarding the caret obect:

the CARET, HIGHLIGHT-START and HIGHLIGHT-END fields must be defined 
as block! of the following format:
[block! string!]


the first block! value must be the gob/text block! at the index position 
of the text element


the second string! value must be string of the text element at specified 
position


You cannot just copy the first block as in your example above. You 
have to set the block to the position where the text element really 
is in the dialect block(this way the text engine can use the index). 
This part is a bit tricky but it was decided after long discussion 
with Carl. I proposed to use simple integer! for the index, but Carl 
wanted it to be this way which is easier as you can manipulate the 
block index easily without the need to use INDEX? to get the integer.

Ashley, yes, we just have a bit deeper abstraction layer in R3. Things 
like MAKE-GOB can still be useful for other things.

Ashley, "just trying to understand why we still need the concept 
of faces under R3." - The role of faces in R3 are just what they 
were in R2, a collection of features and functions inside an object, 
but instead of the underlying View system being closed, they are 
now linked to a fixed set of GOBs, that we eventually can extend 
with all sorts of features. So:

R2:

Layout -> Face tree -> View

R3:

Layout -> Face tree -> GOBs -> View


Faces are what are generated by the layout. So the "face factory" 
is still needed and styles are the "molds" or prototypes. Within 
the face factory, the GOB factory exists. I would assume this separation 
makes HW acceleration or replacing GOBs with a different structure, 
much easier later. GOBs are redrawn using DRAW-FACE and that is handled 
inside the styles.


Styles use resources like fonts, colors, materials and standard draw 
blocks. This eventually helps skinning and abstracts these things 
away from the styles themselves.


The obscure FEEL object is replaced with a set of on-* actors that 
are run at specific times in specific sequences during runtime. They 
are more fine grained, so you can determine what you want to do, 
for example during various stages of face initialization.


The relationship between the layout dialect and faces is a bit different 
than under R2: you can't access the whole face in R3, only facets. 
For example the GOB itself, is not a facet and neither are internal 
states. So in order to change a deeper element of a style, you need 
to create a new style. This seems cumbersome, but is badly needed 
for large layouts, where we are semantically separating appearance 
from purpose. VID allowed this to be an organic mess. We may figure 
out a way to make creating derivative styles a bit easier.

Better to be prepared for a flood of reports. I suspect the GUI might 
be a bit popular.

It's good to see someone going over the gui docs - the existing ones 
got a bit scrambled when someone reorganized the wiki with no understanding 
of the gui model. Docs for Gabriele's and Carl's guis were mixed 
together and the result made no sense.

I'm also kind of expecting that the R3 GUI no longer uses objects 
for panes. That simplifies the code a little bit.

you should look at the REBOL3 /library group... quickly... give a 
bit of feedback on a proposed API I will start work on shortly.

And as for Max, he is a bit fanboying here :-) I see absolutly no 
reason to not coordinate with Carl, and it was already taken care 
for :-)

I have to tell you... I feel like the way-open-wiki was a bit of 
a failure.

So you started styling from scratch? Looks a bit different to your 
initial work, no?

I guess we need some more public tasks, to keep moving. We're contemplating 
messaging between faces and I've written something up in the specs 
document, although I think it's a bit too complex. How does one face 
communicate with another in a simple way? The trick is to both keep 
it simple inside the style design and layout specification. Ideas?

The way it's done now, it's treated as a bit of a special case: when 
a scroller occurs, it will try to attach itself onto a face that 
has a specific actor, on-scroll (I think it is). I don't like this 
method as it only reveals itself through the style code as a special 
case. There can be hundreds of other ways to attach styles to eachother, 
so there needs to be a generic way to do it.

Maxim, I have hacked together(in fact it was lurking on my hdd for 
couple of weeks but I got to publish it here today) a test of one 
concept which IMO could solve part of your requests regarding 'access 
to DRAW elements' etc in R3. It can be also handy when you need to 
manipulate content of complex DRAW blocks...or even be a base for 
scalable vector graphics editor...or....I think there is relative 
big potential of usage :-)
Just try to run:
do http://www.rebol.cz/~cyphre/scripts/r3/tests/draw-shapes.r
in your R3 console.

BTW The demo also features pixel precise object masking and optimized 
redrawing of DRAW objects just to prove we can do lot of things even 
at the higher level.

The file contains couple of predefined objects but the main code 
is very small like 4kB so it should be easy to see my point. Hope 
this could help a bit to someone.

Robert and I are discussing field persistence, i.e. tieing fields 
directly to database tables in a layout. Going to be a bit about 
our conclusions in the R3 GUI specs soon.

i optimized it a litlle bit (removed the "change copy/part image" 
that eats memory)

yes, but it has developed quite a bit since the fork

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issues, although usefull ...

isn't it a bit of an overhead for a GUI itself? I mean - those are 
application (higher) level issue

 - actually no, they should not be that, and this is quite a misconception 
 that you want this level of control in most apps.


It's what prevents us from creating complex forms in minutes, where 
you don't have to think much about how the form interacts with a 
database.


When you think of it, most of the code you write, when writing boring 
business apps, and beyond writing styles, is writing, and worse: 
debugging and testing such code. Wouldn't it be nice to have this 
built into the GUI, all debugged and tested for you?

what Robert describes also sounds like something they could easily 
adapt to have a web viewer for.   a bit like a .net approach where 
you can build tools and distribute them in different architectures, 
suiting client needs.

it's a bit, actually :-)

so far we're not even taking 100% advantage of AGG, so there's a 
bit of juice left in it.

hmm... yes. I still don't see how you are able to do that. From what 
I can gather, it's not much different from VID in that face names 
are set as they are laid out, and when that's done, you can use the 
face. Talking about the *speed* at which widgets are instantiated 
worries me a bit. :-) That should never be an issue unless you are 
doing some form of multithreading.

- Cyphre is implementing remaining DRAW commands in hostkit.
- Ladislav has been working on resize code for a bit

- I'm studying whether it's possible to replace arguments for reactors, 
an esoteric, but necessary part of dialogs.

ok, backpedalling a bit :-)

It may sound a bit cryptic, but LAY simply exactly states that we 
are going to somehow layout the elements

I think I would reword the doc string a bit for grammatical consistency.

It looks like it should be either "Set" and "perform", or "Sets" 
and "performs".

I am  not criticizing the work from the R3 team, far from it, but 
trying to provide a little bit more depth on the issue.

Hmm, now that you say it. The vertical alignment of the Arabic also 
looks a bit off.

The problem with creating artwork now is that there is not a good 
method to implement it, other than by having to get your hands dirty 
and write the styles. There's no easy way to shove photoshop images 
into the R3 GUI. Maybe that will happen at some point. Feel free 
to post imagery if you like, but I'm afraid it's a bit of a waste 
of time right now.

steeve is doing an irc mini client like ... the font is well designed 
but a gamma correction 2.0 isn't it a bit too clear ? why 2.0 and 
not 20.0 ? seems something completly arbitrary again a speudo hack 
to solve a lack of real work ...

A bit of status: Lots of work on resizing right now, specifically 
a bug that occurs on maximize.

Probably a bit different topic, albeit related - in one DOS app generator 
I worked with, there was a possibility to e.g.:

- init form values (e.g. when you create new record)

- set 'update trigger - you could have multiple update actions (it 
was quite primitive, but sufficient - operators like +, -, replace), 
so e.g. entering some value into 'amount field, could trigger an 
update into other field on the form, or later during the commit, 
to even a different table.

- getting/setting values of the form/panel is surely going to come 
IIRC

there is a method to restrict the window size. perhaps it is a bit 
too aggressive, but the option is needed in some cases.

With a107 (that I build with the MS compiler), go.r3 seems to run 
quickly when launched, but slows down dramatically after just a little 
bit of mouse movement. If I stop moving, the speed resumes after 
a little while. I don't remember seeing this in older builds. Has 
something changed wrt event processing?

another question.  if I have a region of ram which contains rgba 
pixel data as an array.    what is the function I need to call within 
the compositor::cp_process_gobs() func so that I can copy that array 
within a gob's pixel buffer?


I've been running around the source and its a bit complicated... 
there are so little comments in the agg code... I'm not sure what 
does what.


I was thinking that the clue lies somewhere in the undefined code 
within 
case GOBT_IMAGE:

it has a selection of ~ 10 filters, and it can render at any bit 
depth, as well as supporting all image formats known to man, and 
even a few video formats too.

field is weird a bit ... it places caret out of the box on the left 
side by default ...

Vista 32 bit here ...

it is indeed a bit too small, but the text alignment stays inside 
the field for me.

I'm using Win 7 64 bit - getting the same kind of offset as Petr, 
but not exactly the same - in his screen cap, the "ddddd" is almost 
touching the border of the field and is on top of the shadow. For 
me, the text is just under the shadow, but is still offset

It looks like the feature for keeping several draw blocks in the 
same style was removed or changed by accident. this means that the 
validation icons won't work, so I have to find a different way to 
test validation. I want to separate the dialog code from validation 
and then make a proper validation test window, so you can look at 
the code and see how it works.


Furthermore, there is a database extension, I want to test more: 
Parts of validation (the scoping part) was inspired by this one and 
I think it would be good to get this out in the open, as it can be 
extended either to a file database or any SQL database by the community. 
The point of it is to make it very simple to connect the logic of 
a form to a database record and it works a bit differently from setting 
up a regular form.

several draw blocks in the same style is a must, or I really don't 
know, how you want to support a bit more dynamic styles ....

Can anyone else confirm that on Windows (at least on Win 7 64 bit) 
the last r3.exe that Henrik posted a link to here, pops up a security 
dialog ("Open File - Security Warning")?  This isn't the UAC dialog 
that you get when you run an executable as administrator, btw. Other 
r3 executables that I had lying around don't do this.

Robert - I can't work with RMA team by writing code etc. My primary 
job makes me come home between 18:00 - 20:00, then I have another 
company where we run 700+ wifi users, some other projects. I am not 
complaining, I like it :-) It is just that a) little of free time 
remains b) you would not want my "code" to oficially accept :-)


But - I don't necessarily be the one, who just talks. Give me something 
specific to test. I think I now will find my way with Henrik/Rebolek 
on my own. It is just the current release format (flattened source) 
is a bit uncomfort to study code segmentation and separation, and 
- difficult to know what changed, if there's no changelog. (I know 
I could use diff on 256kb source, but ....)


So - I think I will let it as it is - it is enough if e.g. Rebolek 
says just few words for the release - e.g. - please test new tab 
... and I can look at it, and givi it a run ...

the ON-VALIDATE actor allows you to modify the face, based on the 
validation result. also simplified the validation process a bit, 
while adding the ability to use ANY for validators, as shown in the 
"Eric or James" field.

I do understand that you want to express the behavioural symmetry 
in PANELS and GROUPS. It's a bit like multiple inheritance: Inherit 
behaviour from PANEL or GROUP, inherit orientation from HORIZONTAL 
or VERTICAL. That's 4 possibilities, and any name chosen is likely 
to overemphasize one aspect over the other.

Henrik - the style browser text-list is somehow flawed :-) I can't 
e.g. see area there - when you drag a scroller a bit, you can see, 
that the list changes, listing styles, which were not available in 
previous view :-)

but the pic I posted is just a very preliminary prototype... though 
it still works well for demoing the idea for the other levels of 
the system which have never been attempted... well only a little 
bit in my latest glass work.

Drag and drop - nice feature, about tab preview, I am not sure about 
that one. It felt a bit distracting last time I saw it. Can it be 
turned off as a feature?

the style-browser I have is a bit old, but it should work. There's 
a link earlier in the group.

btw - will there be added visual representation to field tabbing 
too? It feels a bit inconsistent the way it is ....

Note that -b base is not useful for you (it's for me) because schemes 
are not yet init'd.  It's a bit like booting an OS without the file 
system.

Despite what the blog says, unnamed modules are a bit of an advanced 
feature in the R3 module system. Normally modules should be named. 
But yes, the bug was in the criteria that determined that private 
import should be done, and all unnamed modules do the private import 
method (in alpha 110+ at least).

Any name improvements (the 'cc name looks a bit unnatural)

Very understandable, but a little bit too long for my taste

How about a C-AWARE name, it looks a bit shorter, would it sill be 
acceptable?

well... enbase just converts binary (8-bit) data to a form that is 
ascii printable. it does not say anything about what the 8-bit data 
contains.

On the other side, to answer your question, it's related to SELECT 
and should probably support most, if not all, of SELECT's refinements, 
too. That's a bit of a stretch, because for ports UPDATE probably 
needs to be very fast and can't be thwarted by too complicated refinement 
handling?

Can anyone suggest a free tool that can be used to decrypt files 
that have been encrypted using Rebol's Rijndael using a 128 bit key?

b/("a"): b/("a")  + 1
is the winner as it's a little bit faster and shorter.

Steeve, my measurements suggest, that your previous version was a 
bit faster (is it caused by the fact, that you have to provide also 
for :lesser-or-equal?

Just for starters.....This does it with 12 XORs (three per swap).

But the tricky bit may be pre-computing the from-list and to-list 
mapping

;; function to do the swap

swap-items: func [
   data [block!]
   from-list [block!]
   to-list [block!]
   /local
    ind1
    ind2
 ][
 for n 1 length? from-list 1 [
     ind1: from-list/:n
     ind2: to-list/:n
 
     data/:ind1: xor data/:ind1 data/:ind2
     data/:ind2: xor data/:ind1 data/:ind2
     data/:ind1: xor data/:ind1 data/:ind2
     ]
     return data
    ]

;; Sample run    
     block: [4 5 6 1 2]
     probe swap-items block [1 2  1 1] [3 4 5 2]
    [1 2 4 5 6]

This would be similar to what MAKE does on an object's spec block! 
but a bit smarter as you need to dive into function! values (MAKE 
doesn't do that AFAICT). You need to see the distinction between 
"unevaluated code" (source form) and "evaluated code" (reduced form) 
to get a clear picture on this issue.

Another option:

>> do http://www.fys.ku.dk/~niclasen/rebol/libs/bit.r
>> enhex 100 
== #{00000064}

So you might need to do a bit of tweaking for the R2 version, but 
it's a start.

Maybe a good place to start if you want to play around a bit.

A "concise summary" may be a bit problematic, as distributed version 
control really is a bit of a paradigm shift compared to CVS or SVN.

... but you would not have to constantly announce it - it could save 
you a bit of work, no?

Quick notes:


I downloaded via the Git link that Oldes posted above. It's ~12MB 
(reasonable.)


Installed fine on XP.  Yes, this is a shell version, which is fine 
with me since I like to use scripts anyway for merges, builds, and 
releases.


I have yet to try git with github. It would be great if someone could 
post the magic command line to checkout  the existing repository 
(anonymous currently),


Regarding GUI version: it would not be difficult for someone to wrap 
a few REBOL calls it to give you a bit more GUI feel. Not perfect 
of course, but something clickable.

I know it's hard to use an unfamiliar tool, and I empathize with 
BrianH's observations about how Linus's Git implementation does have 
a hefty dependency stack (if you don't use Linux where all that stuff 
is taken for granted).  If you're trying to stage a revolution in 
software methodology it might seem a bit like you're sleeping with 
the enemy...

I saw the .reb thing.  They would probably do that.  They've already 
given Rebol .r2, .r3, and .rebol ... tekkub and I seem to have a 
little bit of a rapport now so I could probably ask him to do .reb 
too

Brian, the only trouble with letting git do the line ending normalisation 
is that it is a bit troublesome. It's generally easier to just have 
git not touch the line endings at all and use a properly set-up editor 
instead.

A few examples there are a bit out of date, though.

The rebol/sandbox is just if you want to play around a bit with Github.

USE's inner function is not erroneous, not in the slightest bit. 
The whole point of it is to rebind the code block passed to USE.

ok, I've read the whole exceptions document and a few (very old!) 
tickets at least 3 times now.


I'll start by being honest and saying that some of this is going 
a bit deep into some details and I'm pretty sure that I'm not graping 
all implications.  The background for all the discussion hasn't "sinked 
in" yet, so its a bit hard to be totally conclusive about my evaluation 
thus far.


this being said... when I arrived at 5, i.e. "Definitional return 
only, with an option to not redefine RETURN and EXIT", it suddently 
starts making sense overall.  6. seems to be redundant and maybe 
even harmfull if we keep THROW dynamic.  This is scaled with CC#1744 
"fixed" and a wider use of THROW, encouraged, since it now allows 
custom escape/exception modeling by non guru-level Rebolers (and 
by guru I mean one of 3-4 rebolers on the earth... maybe not even 
including Carl ;-).


this means, that return does one thing, throw does another.  they 
become two completely different things, clear and conscice in all 
code.


the only real issue I have is that we seem to loose return in parse, 
 but if we keep throw dynamic, then that is moot, and we can just 
use THROW instead.  In fact, woudn't that be preferable, since its 
more accurate?  we are pre-empting the parse return and providing 
our own... which is what throw should be doing ... its more consistent 
overall.


so go ahead rip my arguments appart... it will only help me understand 
this completely.  :-)

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.

Re: "things are a little bit inverted" - yes, I think so, now, the 
problem may be, that Carl hesitated (maybe still does?) to give us 
such "low level stuff"

(that formulation is a bit unfortunate, meaning, that I would not 
have used it, but, in essence, it means: "don't ask what the value 
of dynamic variable is, when the function is not running")

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.

I know, "iterate" is a bit academic too, but at least it's one word.

Regarding the above "self issue", I am still a bit at odds, whether 
it wouldn't be preferable to have it as in R2, where all contexts 
were selfless, objects just containing the word 'self.