World: r3wp

btw - Python is going to get 3.0 version too, release mid 2008, and 
Guido says it will break many code. So our schedule is still ok, 
although Python is already ahead in some areas ...

Carrot? So are we going to call a release Rabbit? :-) Knoc knoc, 
Neo ... and Neo sees rebol console on his monitor :-)

Geomol, well, hehe, to me R3 seems to be like a painting. When exactly 
is it done? :-)

John, READD would probaly be called SUM.

Question: How useful would you find the following, and what other 
aggregate funcs would you find most useful? 

fold: func [
	block [any-block!] "Block of values"
	accum "Accumulator value" 
	f [any-function!] "Function to apply"
][
    foreach val block [accum: f :accum :val]
]
sum: func [block [any-block!]] [fold block 0 :add]
product: func [block [any-block!]] [fold block 1 :multiply]
average: func [block [any-block!]][
    if empty? block [return none]
    divide  sum block  length? block
]

geomol, that kind of function is called FOLD, and we're hoping to 
have it as a mezz in R3.

our deadline is August 1st. of course, it's not impossible for us 
to miss it, but we don't want to miss it. (Henrik, Carl is quiet 
because he's away.)

ah, i see gregg has posted fold already :)

and, please remember that august 1st is our internal deadline, not 
a public statement. so, there has been no announcement about the 
beta being august 1st. i hope it will be around that date because 
that is our deadline. only Carl makes official announcements, unless 
noted otherwise. :)

What is best? To have new functions like SUM, PRODUCT, etc. or having 
already present functions operate on blocks also?

One big force of REBOL is the datatypes, so isn't the second option 
the best?

Is there a theoretical difference between FOLD and MAP?

If you choose new functions like SUM, someone might argue, that JOIN 
with a block as second argument should be another function taking 
only one argument:
JOINALL ["a" "b" 2]
or REJOIN (that we have) if the block should be reduced.

I guess, it comes down to temperement and programming style. Expanding 
existing functions would mean:
add 4 [1 2 3 5]
adding new functions could give:
sum [1 2 3 4 5]

New functions means more words to learn and remember. Benefit is, 
that it's maybe easier to read the code. hm

SUM is a standard term, and a common aggregate func. It could be 
a shortcut for "add number block". Generally, I like the idea of 
"overloading" funcs to make them smarter, e.g. a dialected version 
of EXTRACT is high on my list, but it's a fine line, and each choice 
has to be made carefully.

FOLD vs MAP - FOLD accumulates, while MAP applys the func and returns 
a series of results.

I find 'collect very usefull lately,thanks for that 8-)  will it 
be part of R3?

:-) We can hope.

i'm secretly using it in vid proto so to make the chances of it being 
in higher ;)

geomol: the problem is, that there are at least two things that add 
4 [1 2 3] could do. and, i think the most "natural" would be for 
it to result in [5 6 7].

also, FOLD is a generic construct, as opposed to having special handling 
in all the natives.

Gabriele - how goes VID prototyping? What is its status? :-)

Gabriele, good point with ADD!

pekr, let me post a nice screenshot for you: http://rebol.hmkdesign.dk/r3/VID3/vid3.png

auto-resizing pleasssssee...

is there

It's a little buggy ATM and needs more features, but the resize algorithm 
resizes the UI, no matter what you resize: the window or an element 
in the UI. So if you have a box in the middle of the window with 
stuff around it, and you make it bigger, the other elements are automatically 
displaced.

what's missing?

Proper even spacing between UI elements. I think the window also 
sometimes does not resize properly, if content is resized. I may 
have missed some ways to do things in the layout dialect, so I may 
be wrong.

still in the prototype stage, so some things will probably change.

how compatible is the vid3 dialect with current vid?

Gabriele should answer that...

He's gone for the night

well, some layouts can be used, but things like ACROSS, BELOW, PAD 
are not in VID 3 (yet?).

Ok, so largely the same then

the principles are the same, just allows for resizing, so some new 
words to handle that are in there.

an evolution of Vid rather than a revolutionary product

hopefully also FEEL hell will be either gone or at least very reduced.

what do you FEEL about porting list-view ?

auto resizing needs imo to support - resizing in x, or y axis, or 
both. Then we need anchoring - I wont e.g. button corner to be always 
aligned to area bottom-left point. Then we need the ability to turn 
reizing off for certain elements. Then we need limits for particular 
elements, to aviod unwanted resizing sizes ... etc.

Graham, I don't think I FEEL quite up to it yet. :-) I don't even 
know yet how to code with GOBs properly, as they are a bit harder 
to manage than faces. There will hopefully be a solution to that.


There is a much better text list already in VID3 than in the old 
VID. It even has columns. :-)

nice screenshot. But at first sight I miss on some fundamental elements 
- no accelerator keys yet? No visual focus representation? Is there 
focusing system inside already?

the current look of the ui is a bit ugly.

partial focusing is there, but these things you mention are still 
in the design phase.

what's wrong with the UI look? :-) I think it's perfect. ;-)

I just really hope that new VID will be fully featured GUI system, 
and that it will support most things needed to do larger business 
apps ....

It looks like mix of Amiga OS and some old kind of unix flavor .....

Pekr, the prototype feels a lot more feature scalable, if it's any 
comfort. No real dead ends as in R2 VID.

My understanding is that Vid will be incomplete again

and it will be up to the community to complete it

I hope so ... as for actual look, I don't care much yet, as it can 
be fixed by some gfx artist later. I care more about subsystem as 
keyboard support (focusing), visual representation of focusing, disabling/enabling 
ui elements, flexible resizing, on-something handlers rather than 
one feel func, and self-encapsulated styles - no external dependencies 
....