World: r3wp

I think it's worth "rocking the boat" a little. Anyone care to add 
more comments?

Not yet. (The force of the explosion increases the more you try to 
contain it.)

Pekr, what was the digg link?

REBOL: Programming - all-the-bad-things - many-needed-tools

Make Rebol 3 popular.. add php, javascript, ruby etc dialects.

do you think it is easy to emulate those languages?

Brian - http://digg.com/programming/REBOL_3.0_development_announced

Cheaper to port rebol to java? Php, javascript will be there afaik.

or javascript with rebol-syntax?

How do you best support other languages from REBOL (if you want to)?

- Directly parsing other languages with their syntax from REBOL is 
a way to make old programs written in those languages run. You need 
to parse strings for this to work, and that may not be very fast.

- Making new dialects based on those languages, but with the minimal 
REBOL syntax may be good for new programs, written in those languages. 
One thing, that irritates me in other languages (also C) is their 
syntax. You have to write so much unnecessarily, and it's easy to 
make a mistake (e.g. put a ';' in a wrong place), and your program 
then doesn't work as inteded. All the extra also makes it less easy 
to read programs, written in those languages.


It's possible to make cross-compilers, that'll read old programs 
and produce a new format.

With REBOL, I feel, I can concentrate on the problem and not the 
technology, implementation, syntax or other things.

yes, REBOL seems to be the most  *productive* language I have ever 
used.  from design to delivery, it always seems to be much quicker 
in REBOL.

REBOL has saved me from doom quite a few times. Last time was yesterday 
when I lost a database of people signed up to a town party race (a 
system written in REBOL), when the power cord to all the PCs was 
pulled. The database was partially wrecked, but (believe it or not) 
by creating a LIST-VIEW and querying the database, it was possible 
to view and print out the contents. REBOL is so damn wonderful, it's 
almost hard to believe.

so I often use REBOL in times where I need a utility belt to rescue 
data. it's a nice swiss army knife where other tools may be too slow, 
unavailable or hard to use.

I use rebol often as a shell replacement (not much intensive work), 
but e.g. parsing some info ... mostly simply in console session, 
without even writing a script :-)

I use rebol to make money.

I use rebol to manage my money.

(keep track of it, anyway)

guys - just please bring us good list-view base for R3. I mean - 
engine - not complete system. Yesterday e.g. I could not use Rebol, 
as user wanted simple scrollable table of raw data - many columns 
(h-scroll missing badly) - just an example how one small corner could 
be limiting sometimes ...

I don't use rebol for making money, but saving me a time by doing 
very small utils, which save time .... and so maybe money? :-)

pekr, I may have a closer look at horizonal scrolling soon, because 
I need list-view now for tables with 30-40 columns

:-) cool ...

Would it make sense to use words in tuples? Like:
a: 4
1.2.3.a
The tuple should then reduce to 1.2.3.4
Or is that crazy?

If it means, that tuples will be slow, then I'm against it.

>> a: 1 b: 2 c: 3
== 3
>> to-tuple reduce [a b c]
== 1.2.3

I gues this would slow down tuple!s

I noticed that tuples can be used for simple math operations on multiple 
values. I think it would be nice to expand that to blocks.

2.3.4 * 5 = 10.15.20

I'd like to see: [2 3 4 5 6 7] * 5 = [10 15 20 25 30 35]

Uhhh, parallel vector processing! If you get that working and can 
use the hardware to do the actual calculations, then you'll get lots 
of speed!

interesting discussion regarding modules starts, and some points 
are raised, mainly because of security.

Geomol, tuples are currently an immediate value like an integer, 
rather than a block-like value. This is why they are fast.

Yes, I realize that. It was just a crazy idea, that would make it 
easier to work with colour values. But we better keep tuples the 
way, they are. Fast!

Something to consider for REBOL 3: The current implementation strategy 
for symbols in REBOL has significant limits to the possible number 
of symbols available at one time. It might be a good idea to try 
a red-black tree for symbols instead - newLISP uses that strategy 
and can handle millions of unique symbols efficiently.

I'm just putting the idea out there - I'm not familiar enough with 
red-black trees to know whether they would be possible to use in 
this case, just that another language with similar implementation 
size uses them and it works for that language.

Any news on user datatypes ? I've just realised they would be very 
useful to me to implement an interpreter.

Just wondering if it would be possible for richtext command sequences 
to also fit into a word!, so symbols can have their own colour and 
font when molded into a richtext field. eg:
	word: to-word "/bPhrase"
Now when I mold word I see it rendered with bold text.

My concern is just to make sure that all the command sequences (like 
/b in the example) are allowed in a word!, and possibly also still 
allow  loading as a word! directly. eg:
	type? load "&bPhrase" ;== word!
(assuming the richtext escape character is & )

This could mean an editor could render symbols with their formatting, 
for instance. (I'm also thinking of implementing an interpreter within 
rebol).

for R3 View group. I just did my homework, trying to get PythonCard 
working. It seems to me Python plus PythonCard is not enough, so 
I needed wxPython - total install is 55MB :-)

but that is not the point. I just first could not follow, how they 
work with widgets, and then I found out - they have separated code 
and widget definitions. At first it looks strange .... it is like 
having 'feel(s) , event maintanance, app logic, without seeing what 
actually you are working with. But I do understand, why they keep 
widget defs outside in external file, which is kind of simple (as 
VID is), with static positioning - it is very easy to import to visual 
GUI builder ....

so just for the sake of inspiration, to think about - can you imagine 
having screen painter, taking your layout block, and enabling you 
to change the postions/size etc. params for our widgets, without 
actually being dependant upon running the app with live data?

btw - how do we refer to instantiated style - still a 'style? Or 
will we adapt widget name too?

you mean using the layout as kind of a "dead skeleton"?

yes ....

they have e.g.:
{'type':'TextField',
  'name':'Profile',
  'position':'170,110),
  'size':'(307,-1),
  'editable':True,
  'foregroundcolor':(0,0,255),
}

just dunno what they do, if the want some kind of comuted values? 
Maybe they import just what is defined, you change layout, and after 
the widget is drawn, they can adjust, dunno .... just an idea, we 
imo need visual screen editor in future ...

I believe this is how Cocoa works and have seen the technique referrd 
to as "freeze-dried widgets".

widgets and their functionality are defined in .nib files for a cocoa 
program. this is because much of the binding between the widgets 
and the code is created during runtime. this is also why Interface 
Builder is able to create much of the initial functionality for a 
Cocoa GUI, just by defining attributes to widgets and let you test 
the interface to a fairly high level without compiling any code.

BrianH, do you know what structure rebol currently uses for holding 
symbols ? Red/Black trees are complex, so it will take a fair effort 
to implement and debug.

red-black trees are 2-3 trees implemented as binary trees

or they were when I studied them

As far as I can tell, REBOL currently uses a hash table. I am not 
the one to ask though.