AltME groups: search

I just found Henrik's summary. I think it is the post I had in mind:
---------------------------------------------

Indeed VID3.4 is far from done. You can probably use it for a few 
things, like getting a name from a user in a text field or submit 
a very simple form, but not much more than that. To reiterate the 
state of the UI:

- No unicode yet in graphics (when Cyphre gets around to it).
- Resizing acts like a drunken sailor. (Carl)
- Skin is not published. (Me)
- Style tagging is not implemented. (Carl)
- Reasonable requesters are not yet implemented. (Carl or me)
- Layers are not yet implemented. (Carl)
- Guides are not yet implemented. (Carl)

- Better font rendering. We are not taking advantage of what AGG 
can do. (Cyphre again)
- Event system is from Gabriele's VID3. (Carl)
- Many features are untested, like drag&drop. (Me, I guess)
- Proper material management for skin. (Me).
- Many styles are not implemented, especially lists (Me).
- More elaborate animation engine (Carl or Me).
- Form dialect (Carl talked about this).
- More/better icon artwork (Me).


Plus, Maxim has some ideas for DRAW, to greatly speed up rendering, 
but I don't know if they can be implemented.


The overall design of the GUI engine is very good. Whenever a change 
or addition is made, you alter 3-5 lines of code in one place, and 
it works. I doubt the entire engine will be rewritten.


You won't see GUI bug reports in Curecode for a while. There could 
easily be 2-300 reports, once we get to that point.


My work regarding skins is rather big: I need to work out the basic 
styles first, so we have a reasonable way to build compound styles. 
These are being done using a very simple, but pixel accurate GUI 
using plain colored surfaces. This is easier for testing out, as 
draw blocks are small, but as Pekr likes to complain: They are not 
pretty to look at. Once the real skin goes into place, the draw blocks 
will grow a lot.


I would love to see a low-level GOB management dialect, like Gabriele's 
MakeGOB.

The way I see it, there are at least four ways to build an R3 GUI 
[based on gobs]:


1) Heirarchical, where gobs are grouped into faces, which are in 
turn grouped into windows

2) Flat, where a DOM-like object maps all gobs (i.e. removes the 
need for intermediate faces/windows)

3) Draw-based, where each window consists of a single gob with the 
entire window rendered in a draw block

4) Image-based, similar, but the draw block is pre-rendered into 
an image.

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.

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.

Shadwolf,

re glyph engine in R2: The glyph manager is used inside DRAW dialect. 
But the internals were never exposed at the REBOL laguage level. 
Should I really explain why? I hope not.


R3 text improvements: As I wrote week ago here to you on AltMe there 
are no limits for you to make it happen. You can already build your 
own font engine+dialect in C/C++ or whatever and use it as EXTENSION 
for prototyping your contributions. If I was able to protoype using 
R2 dll interface you have now even more possibilities. So where is 
the problem?

glayout already implements 90% of what we want to build for VID 3.4, 
down to the dynamic layout engine, which is just about the same.

It's important to lift the UI out of the domain of appearance and 
into the domain of meaning. When your UI intelligently finds the 
default window close button or the first field in a form automatically, 
and automatically assigns correct keyboard navigation shortcuts, 
because of the underlying architecture's emphasis on meaning, there's 
no need to write any code to handle that at all. It's just there. 
You build your styles to adhere to the meaning that was setup by 
the GUI system. In the VID extension kit, this is done through flags 
and powerful face handling features. You don't need to add any code 
for that in the dialect.

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.

No, not wrong attitude. Styles are built by experts, i.e. people 
separated from those that build layouts. In VID, you don't have this 
distinction as you can manipulate styles directly in the layout, 
but you do, somewhat, in RebGUI.

btw - what I liked about Gab's VID was gob dialect to build multigob 
composited styles ... but maybe Carl's VID does not need that ...

Cyphre, Henrik, Ladislav and I are going to pic up the current VID34 
code and drive it forward. Our goal is to get it into a shape that 
it can be used to build apps.


We will try to sync with Carl about our steps to avoid that we fork 
away. Overall we want to solve the current stuck situation and move 
forward.


Our goal is to make VID34 useable for big apps. Focus is neither 
minimalistic nor "can be used by a child". This will be for the big 
boys. But still simpe to use and providing a bunch of features you 
need to make enterprise applications.

Cyphre is down with the flu right now and a sporadic internet connection 
due to snow, so I have no immediate status of what he's doing, other 
than waiting for the host kit, but what he's shown me, based on a 
separate AGG build, shows that there are a lot of ideas for what 
to do.

some two or more weeks ago he told me he is working on some demo, 
showing some AGG capabilities. That is probably stuff you saw? Will 
it be demoed? :-) Or is it just internal build to have some ground 
for further architecture improvement talks?

The separate AGG build is just there until he can get a hold of the 
host kit and to test ideas.

Yes, we are on the same page. I see this as built upon a messaging 
infrastructure. It doesn't need to be elaborate today, in what it 
supports, but the design should allow us to extend and build on it. 
i.e. we need a message bus that we can tap into, inside an app, interprocess, 
and distributed.

Liquid is the perfect engine to add to R3 GUI.


After years of use in many different situations, I am now very confidents 
in its capabilities.


Liquid is a generic engine, allowing you to tell DATA to message 
DATA.  


This means you can use the same system that you'd use for the GUI, 
for the data itself, and then just plug it together.


Because Liquid was designed to allow very advanced procedural computation 
at a fraction of the complexity of other systems I've used I'd say 
its the best system we'll ever be able to build for R3.


Wrapping liquids within faces and the view dialect is rarely more 
than 5-10 lines of extra code, but then, you don't need to write 
"action" code afterwards.

liquid even has data filtering mechanism built-in... so you can patch 
type conversion right in you data, for example, and connect any other 
compatible datatype without needing to build ANY extra code.


Did you notice the detail... I didn't say type conversion in your 
GUI... 


so If your age is supposed to be an integer... pluging it into a 
field can actually make the field an integer field, without the field 
knowing anything about integers.   :-)

had I tried to build this system without Liquid... 
  -I'd probably have a very brittle textbox.
  -one that is VERY hard to improve.
  -it would lack a lot of the interactive aspects about it.

but then, I will build agents to optimize arrangements dynamicly

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

AGG does a lot of computation, basically having access to this data 
in a consistent way.  also not having to use composed/reduced blocks 
all the time.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  

getting intersections between complex shapes like splines and polygons, 
xformed.
bounding boxes of things, calculated points of displayed letters.


if there where a unified method which just keeps the persistent data 
and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.

...also not having to use composed/reduced blocks all the time.


If you had look at the concept demo I posted above there is no sigle 
forced compose or reduce(ofcourse except the possible internal native 
parser processing) applied on the DRAW block using this method.


getting info like (x,y) coordinate of current bspline curve at length 
100 pixels from an end.  
getting intersections between complex shapes 
like splines and polygons, xformed.
bounding boxes of things, calculated 
points of displayed letters.


Agreed, being able te get calculated coordinates of bsplines was 
planned addition, though not yet implemented.

Not sure about the intersections. I think you would need to use external/third-party 
code for that.
Bounding boxes, yes that is/was also planned.

But these ale more like helper functions which doesn't need to have 
any 'draw elements' access. It's enough to provide whole/partial 
draw block to get proper results.


if there where a unified method which just keeps the persistent data...


The DRAW dialect block is the persistent data IMO. And you can build 
any other dialect/system over it.

Don't be fooled by the result you are seeing. The internal structure 
of the data is almost identical as described in the DRAW block but 
in different format.

All the calculations are done on-the-fly using diferent parts of 
the pipeline setup. For example:


coordinates(almost same as in DRAW definition)->curve_converter->trasformer->rasterizer->renderer


there is not any persistent storage between 'coordinates' and 'rasterize' 
phases (that would be memory overkill to store all the approximated 
curves etc.)..the result is directly rasterized on the fly.

So in fact there is no static 'list of vertices or whateve' of the 
resulted image, everything is dynamic from the time you pass your 
DRAW definition to the engine.


...and we can move it around/manipulate it without needing to store 
it as a block of dialect, I could build my own specific and much 
cleaned up dialects or graphic engines without needing to go through 
the draw dialect like I do know.
 

See the concept demo. I'm using one single DRAW block for all the 
objects and I can access/manipulate them without any complex code. 
There are no limits.


Myself, I have no use for most of the draw dialect, it just complicates 
my work, by getting in my way.


ok, so show me example of the form you would like to use for drawing. 
Is there any existing system which uses your expected behaviour?

My main idea (Already tried in the past ) is to build enough small 
primitives to allow to constuct all the standard styles without the 
need to add bloated hand written code.

The primitives are context sensitives, meaning that blocks of primitives 
can be shared between several face without the need to bind/copy 
them for each face.

When will we be able to build more complex styles, as tabs, grids? 
I mean - is all infrastruture inside already?

instead of just hard coding those, I'd rather build a scheme to perform 
automatic shape/size/color/transparency transitions.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

I use this to merge effects with existing draw blocks (it's called 
by the constructor of each animation).

It's up to you to merge the effects with inner gobs if the style 
got many.


The VID, I build, doesn't matter if the style contains several gobs.
Thanks to my propagation model of events.

I use the same idea than R2, events are propagated from inner gobs 
to outer gobs, so that i can have only one reactor on a parent gob 
(the container) which trigger the same actions on all its inner gobs.

It's the thing i don't like in the current VID and it's why styles 
can't deal easly with several children gobs to my mind.

I've been working on docs (a dialect for image annotation in docs, 
actually) for a program, so not much here. Some things are actually 
very difficult to do in DRAW. I could use a pure alpha overwrite 
mode. I've posted a report in the AGG group about a bug in TRANSLATE.


I might add something to specs, which I've been working with as part 
of writing docs: A way to use a layer to provide editing tools, i.e. 
box handles, rotate handles, swipe selections, moving and resizing, 
like you have in many graphics editors. I think this can be done 
in a generic way and would make it easy to build any kind of graphics 
or GUI editor.


This is not something that we want to add now, but it's nice to think 
into the design, so that it's simple to do later (and to remove, 
when Carl announces that he doesn't like it).

the bug has already been fixed, so this will be available in an upcoming 
R3 build.

Goal is to create all internal tools with R3 now (we call them Level-2 
= L2 tools) and build the Level-3 (libs, frameworks, extensions, 
...) in parallel.

I studied KHTML back when I thought we were going to build a new 
AWeb around it. it was incredibly much simpler than Gecko at the 
time. Don't know about webkit, though.

pekr, if we have 10 GUI frameworks its a good thing.   each one adapted 
to different needs.


its also a good way to attrack new developpers.  look, this language 
has several complete GUI layers.

I'd even like someone to build a native OS GUI extension.   some 
people *require* that for their work.


RT has one it advocates directly, but any others are a boon to the 
language.

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.

AdrianS: I don't think you can convert the Web people to Rebol easily 
just by replacing the JS in a browser. Better to build some 'cool' 
product based on Rebol with modular interface so people can play 
with it and build own 'gadgets' using dialects etc. I believe there 
are still some 'oportunities' to do it on misc embedded systems but 
first you need HostKit source and fully abstracted Rebol dll versions 
compiled for such systems.

people are also impressed when I build a parse dialect in ten lines 
in 5 minutes and show them that its actually spitting new structured 
data out of other data.

Remark is my solution for web stuff..  its basically what you describe 
above.   One engine to manage all aspects of a web application.  
Using rebol dialects compiled in real-time, you can build any data. 
 but the Dialects can be embeded within any other file, using a twist 
on the html friendly <tag> notation.

that's what I mean... but it also means that we could build nice 
web dev tools using R3, which could cross-compile as desktop and 
web apps.

I'd like to know, inter alia, if one can build a progress meter for 
downloads

Some resulting exes:

07/10/2010  12:45 PM           267,776 r3.exe
07/10/2010  12:46 PM            28,672 r3core.exe
07/10/2010  12:34 PM           393,216 r3lib.dll

You can build an R3/Core without AGG.

i think cairo can be fun  but then the question is always the same 
will the dialect build to interface it with rebol will cover the 
whole thing or just cover the ground capabilities

actually it's an older build with some modifications. I'm not sure 
how useful it is in general.

when it gets important enough to fix. right now the priority is to 
get things working in the first place. we have an app to build and 
sell.

so once again: complaints about issues that have no relevance to 
the current state of the R3 GUI. I would rather have wishes for dialog 
handling, form validation, how the help system should work and how 
to build more intelligence into the GUI.

Our primary concern is that RM Asset needs to use R3 very soon for 
a production app for a customer, so the focus is to make all things 
that are normally handcranked in VID and RebGUI, such as form validation, 
handling of database records and a complete UI test framework fully 
automatic. If it takes 2 days instead of 7 to build and test a GUI, 
Robert saves money and can ship earlier.


Over the past year, with the rather big RebGUI app, NLPP, that RM 
Asset has built, we've learned exactly where we need to make things 
better and what works OK and certain delays, because of GUI architecture 
limitations have cost money. It's no longer for convenience or for 
advertizing the GUI as easy, but hard money savings are involved.

no, it's both things. The GUI system must be easy and quick to work 
with. That's how we build apps.

it'll be a while yet. have been busy moving projects to RM Asset's 
SVN server and now am working on a build system, which is why I was 
asking for prebol for R3 in the REBOL3 group.

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

R3 GUI now builds and runs with the new build system. Nice and clean. 
:-)

it's not a formal release. I decided to do this, because the build 
system became available for use internally today.

graham, and I posted all the relevant information to validation and 
dialogs a week ago, the build system 2 weeks ago. zero feedback.

Henrik, sorry to ask but where is the build information? I scanned 
back to mid-August but didn't find it.

new build released at http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


This one contains material system and some bug fixes. Requires A105.

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?

a question... is there a single place where a gob is destroyed (maybe 
a callback or some method) within the host-kit?  just so its more 
invisible, when I need to detach a gob from the OpenGL rendering 
context... at this point I have all I need to build an OpenGL gob.. 
but nothing to get it automatically cleaned up.

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3


Newer version too. Sorry about the ballooning in size, but this is 
due to a change in the build system.

I'm working on the build system right now.

re build system - will we be able, in future, to bundle only styles 
being found in source-code, or selected ones? I can imagine having 
library of tens of widgets/styles, while my app might not require 
all of them? So far, R3-GUI is still small, so it does not matter, 
hence regard my question being just theoretical :-)

the build system will allow that, but the question is if the source 
will be published like that. I hope it will, but I would not rule 
out that many styles will depend on eachother in the future.

I'm preparing a different build script, so it will appear uncompressed. 
Should be up within a day or so.

new build is up with uncompressed source:

http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3

style building has only changed with regards to resizing (which I 
haven't entirely figured out yet), but otherwise remains the same, 
so feel free to build some styles.

yes, correct, however, I'm going to provide a new build in just a 
moment.

uncompressed build is very welcome - we can look at sources here 
or there, if there is a need ...

REBOL [
    title: "Untitled"
    build-date: 24-Sep-2010/8:46:56+1:00
    build-flags: [console log]
    revision: 0
    release-type: release
    language: en
]

the revision 0 thing in the header will be fixed, once the build 
system can get a revision ID from SVN. if anyone knows how to do 
that, I would appreciate it.

yes, I'm sure just something was disabled. I built a new version 
today, but it's less stable than the current build, so I'm not going 
to release it.

Tried some latest build today, and the problem with wrong placement 
of caret is gone now ....

Henrik - new build possible? Rebolek told me, there should be new, 
improved version of area available. I would like to test :-)

public repository is not likely to happen, as RM Asset keeps private 
sources in the same repository as the R3 GUI to accommodate private 
projects and build system, but I will continue to release the r3-gui.r3 
file until a better arrangement is made.

We are still buildin a bunch of infrastructure on our side, so that 
we can release stuff faster, know it will build for you, generate 
automatic change-logs etc.

Pekr, just worked toward getting the validation examples working. 
Fixed some bugs in this regard. If anything, try to build your own 
validation example. I'll be working on updated docs, so they correspond 
to this prototype.

that's already limiting in my POV.   elixir actually allows you to 
build the system that you describe interactively  (In theory, not 
in practice, since its really not done yet(

with elixir you can build google-wave like concurrent user apps with 
just a few nodes.  then you can wrap them in a pool and just provide 
the pool as the data to another node.


it is even project that we will be able to reverse-script a pool 
and provide its structure as an output, so that you can actually 
share the pool's structure in real time along with the data it is 
linked to.

this is known as a "process" in elixir... scripts which build up 
nodes and link them up in a specific way.


tools are processes which have a persisten interface (cli or graphical)

http://94.145.78.91/files/r3/gui/247.png


Tab boxes now support drag and drop. I'll provide a built version 
tomorrow as I found a build problem tonight, so you can try it out.

seems there are some issues with LOAD and SAVE in A110, so no r3-gui 
build today.

I cannot build right now, so you might as well play with that one.

Pekr, A110 doesn't work with the build system, so no new releases 
recently. Pace is the same as before.

Anyway: Just start using the GUI now. The style browser is built, 
I have a build system test GUI also and both work fine, so what we 
need is input on things that are silly or missing in the GUI now.

It may be good idea to build new one. Keyboard navigation improved 
a lot and can be good for testing key events.

ok, I'll try to build with A109 to circumvent the build problem.

I would try to build A110, but I am not able to get sources from 
Carl's git. I tried to download his .zip archive, changed to TO_WIN32 
in the .h config file, but it does not build - probably a linux distro 
...

You'll need a "/View" build of A110, such as:
http://94.145.78.91/files/r3/gui/r3.exe
http://94.145.78.91/files/r3/gui/r3lib.dll

Henrik, so far there is no difference in the 'about' output when 
you build r3/Core or r3/View exe. Even system/product is always set 
to 'core . Something that needs to be solved by beta.

You need to get a GUI build and download Henrik's compiled R3 GUI 
code. Look above here for the links.

Over the last day I have been fleshing out the test suite for the 
new module system. Almost all features have corresponding tests now. 
As soon as we have complete coverage I will try to get the tests 
published somewhere official. FYI, alpha 109 fails a lot of the tests, 
but also in the last day I fixed all of the errors that were causing 
test failures. In theory - I need a new build with the fixes to be 
sure, but code tracing says the behavior matches the tests. In any 
case, the test suite will have full feature coverage before alpha 
110 comes out.

Ok, so the subject of the discussion is how to move the host-kit 
build and its related processes to a more manageable method.

And from there on, we can have build bots which pick up any new export 
and build it for their platform. Build results are reported back 
somewhere (email, static website on the bots which gets aggregated 
elsewhere, a simple CGI, R3 chat, ...).

Which is why it's also important to realise that those build bots 
need not necessarily be public. They could well be Carl's own machines 
standing at home which put the final binary in a central place for 
Carl to use.

If that's not immediate, you can obviously still use your own build 
stuff (Visual Studio projects, whatever), and as long as you regularly 
keep the sources up to date by committing, the builders will notify 
you anyway if the external build mechnisms got out of sync.

Use msysgit on Win32 and the packages provided with your system (or 
build from source) on everything else.

Pekr, that's simply a snapshot, which takes a minute to do, thanks 
to our build system.

once we have ssh on r3 (in whatever form) I think we should be able 
to build the entire git toolset with REBOL at a fraction of msys 
stuff.  I already did a complete source control system (though with 
a completely different model) called distro-bot and its hardly 1GB!

Yes, but on topic for managing the build process. Hence the question.

So, failed to obtain git binary or build git from source.

It should be possible to build it from source.  I need git on at 
least one primary build system here.

I can write a small REBOL script to sync the source over to the other 
build systems... which will probably never have the ability to run 
git.

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.

You don't lose anything that you haven't already lost for other reasons, 
and it is possible (in native code) to build in acceptable workarounds 
for its weaknesses, so there's no significant downside to definitional 
return (except the work Carl would have to do to implement it).

I am thinking that SELFLESS could be used to build classes if we 
specified self as a word.