World: r3wp

but i'm not really sure of the advantage...

if it's just to be english-like, we can beat them any time with a 
simple dialect :)

I think, performance should win over expressiveness. I'm think, we 
don't have
action unless condition

in REBOL, because it'll cost in performance to check, if there is 
an 'unless' after the action. As it is now, the REBOL intepreter 
knows what to do most of the time. Operators are the exception of 
the rule.

It could be interesting to know, how much better performance would 
be, if REBOL didn't have infix operators. Carl probably did some 
tests.

what is interesting here is, that infix operators are in fact faster 
in REBOL than prefix equivalents ('+ vs. 'add ...)

i don't think performance would change a lot

the point is that that is just syntactic sugar

Since REBOL requires a programmer to 

think differently", in general what type of person, skill set, and/or 
background is required for a person to be a good REBOL programmer?" 


You just have to be open minded, and I think it helps to be curious. 
You also need to understand that REBOL is high level, but not safe 
in the sense of being dumbed-down so you can't do dangerous things. 
You can do *very* dangerous things in REBOL. You don't have direct 
mem access, so the risk is mainly to your own app, but since it's 
almost infinitely flexible, you can create works of art, or hideous 
beasts.


 "what attracted everyone on this newsgroup to REBOL? And, in general, 
 what type of applications are people trying to build?"


The small size, built-in GUI, and tiney-but-powerful demos are what 
attracted me initially. To be able to download the EXE, install it, 
and run 5 or 6 GUI demos in a couple miuntes just blew people away 
in 2001 when I showed it to them. What keeps me here is that there's 
nothing else that's as much fun to work in (for me). It can be frustrating 
too, I won't lie about that, but the benefits so far outwiegh the 
negatives for me, that I hate having to use other languages now. 
I also love the community. I would count some of the people here 
as close friends now, and it's very satisfying to collaborate with 
them, even just on fun little projects.


What *really* excites me, though, is that I think we're still only 
tapping about 5% of REBOL's potential, maybe less. If you write code 
in REBOL like other languages, there are benefits but they aren't 
earth-shattering. When we get to the point that 10% of REBOLers write 
dialects, and 90% of REBOLers use them, and use REBOL as an interchange 
format, then we'll really be taking advantage of REBOL.

Rebolek, it shouldn't be too surprising, that performance is about 
the same, whether you use + or add. When you use 'add', REBOL still 
have to be prepared, if you put in an operator after each word. REBOL 
can't evaluate the final result after
add 1 1
because what if you wrote:
add 1 1 + 1

When real penalty for allowing infix operators can only be measured 
with a version of REBOL, that doesn't have them.

*The* real penalty ...

It may be better shown in this example:
divide 4 1
is ok, but
divide 4 1 - 1

gives an error. The performance hit for infix operators may not be 
too big, but it would be interesting to know.

This might give a hint:
>> rule: ['add set a number! set b number! (a + b)]
>> time [loop 1000000 [parse [add 4 5] rule]]
== 0:00:04.880101

>> rule: ['add set a number! set b number! opt ['+ set c number! 
(b: b + c)] (a + b)]
>> time [loop 1000000 [parse [add 4 5] rule]]
== 0:00:05.541085


The rule without infix + seems to be 10-20% faster than the one with 
infix +. This is only a hint! It might be different, if the language 
were changed.

If I allow infix + after each number, the result of course get worse:

>> rule: ['add set a number! opt ['+ set c number! (a: a + c)] set 
b number! opt ['+ set c number! (b: b + c)] (a + b)]
>> time [loop 1000000 [parse [add 4 5] rule]]
== 0:00:06.360697

geomol, your model of the performance hit may not be correct, because 
rebol is not evaluating things that way.

Yeah, I would assume something like that. :-) I have to ask Carl, 
I guess.

Why did I join this community? The primary reason is to be part of 
a small, smart and passionate group who think differently


That's basically the same reason I joined this community.  Like many 
others here I found REBOL through the Amiga community.  I had access 
to an Amiga 2000 when I was in elementary school and I loved it. 
 When I decided to start programming I played with some Perl, some 
VB, some C and then I signed up to the Amiga Developers List in 2001, 
through which I found this community and I've never looked back...

Since REBOL requires a programmer to 

think differently", in general what type of person, skill set, and/or 
background is required for a person to be a good REBOL programmer?"


  I think that those most likely to really grok REBOL are those that 
  "think outside of the box."  IMHO, anyone CAN be a good REBOL programer, 
  like Gregg says, what you need most is an open mind.  Curiosity does 
  help....  A lot.  There are a number of simple IQ tests that you 
  can give people to determine their ability to "think outside the 
  box."  The way they approach the problem is as important as their 
  ability to solve the problem because this shows you how they will 
  attempt to solve problems they encounter while programming.


Therefore, would a programmer with a computer science background 
with NON procedural languages like Lisp or ML be more likely to 
grok" and appreciate REBOL?"


From what I have seen, they will pick up REBOL a lot quicker than 
those without the background in lisp or a language like Lisp, however 
this doesn't necisarrily mean that they will be able to write the 
best REBOL code...

Would it make sense to 

hire" a young/new programmer out of college and get them involved 
with REBOL early so they have less "bad habits" to unlearn? Are any 
schools teaching their students REBOL?"


There is a group here, "Rebol School", that we have been using to 
discuss the topic of learning/teaching REBOL.  One of the users here, 
DenisMX, I believe has developed, or is at least working on developing 
a REBOL curriculum.

Geomol, I wouldn't know about R3 but in R2 ops are a little faster 
than their prefix equivalents. The reason is that DO already knows 
which words are ops, while it has to look up other words to figure 
out what they are. This lookup takes more time than just grabbing 
the right action out of the op table. It does have to retrieve the 
index into the op table from the value assigned to the op, but it's 
still faster than general action lookup. Try assigning a non-op value 
to an op word - it will error on evaluation.

Why did I join the community? Because when I joined, REBOL was still 
pretty new.


R2 wasn't there yet - the first alphas for it came a few months after 
I started playing with the language. Most of the low-level behavior 
of the language was completely undocumented outside of RT, and they 
were still trying to position the language as easy to use, easy to 
learn, high level. It still looked like R1 - Scheme with a different 
syntax - but it was different.


A challenge. So I dug in. I tested every function, everything I could 
find out. I asked a lot of questions on the mailing list. If they 
weren't answered, I dug in further and figured it out myself. And 
I got into a lot of really interesting arguments with the people 
on the list, testing and probing the language until all of the undocumented 
stuff became clear.


Those early arguments became the low-level documentation of REBOL. 
And then came the books, and the community got bigger. I started 
using REBOL at work, even when it wasn't the language I was supposed 
to be using - code is easier to generate with REBOL than it is to 
write directly in other languages. More fun too. That's the hook: 
REBOL is fun.


There is a principle I read in a Heinlein essay years ago: The principle 
of Creative Laziness. He wrote about the guy who invented the automatic 
pilot, back in World War 2, because piloting back then was a big 
hassle and he was too lazy to do it. Instead of doing the drudge 
work he did the more interesting task of figuring out how to automate 
it. If necessity is the mother of invention, then laziness is its 
father. Laziness is a virtue.


That's what dialecting is all about: Automating the drudge work and 
wrapping it in a nice little language because it's more fun than 
doing it manually. More efficient too, a lot of the time.


Do you know who REBOL appeals to the most? Engineers, scientists, 
hackers, analysts, problem solvers. People with opinions, people 
with enough of a twisted sense of humor, of the world, that they 
don't want to just sit still and accept the way that they are told 
the world is - they want to figure it out and remake it if necessary. 
Interesting people: REBOL's other hook.

Welcome to the cool kids' table!

Brian, you preach the same thing I do... be lazy. its fun and much 
more productive.

HELLO, do you have a simple solution, I'd like 'z to stay 10, eg 
it should be a local in the function
z: 10

a: func ['word body][

  foreach row [1 2 3][
    set word row

    reduce body
  ]

]

a z [print z]

print z

this works but not in case of path:
reduce replace body word 'row
is it a bindology or parse job?

Look at the source for FOR. If that technique works for you, it will 
lead you to something like this:

z: 10
a: func ['word body /local do-body] [
  do-body: func reduce [[throw] word] body
  foreach row [1 2 3] [do-body row]
]
a z [print z]
print z

works! thank you Gregg! ...tryed to look at 'foreach which is native! 
 8-)

now the [throw] is just in case there is a catch in body, right?

throw re-throws any return in the body

ok thanks!

can anybody explain me this please:
http://reboot.ch/why.png
thank you!

rebol blocks have new-line control after each item in the block. 
 depending on the function being used, these will be lost, kept or 
generated on the fly. usually anything which goes thru a string type 
will loose any previous new-line setup.  and only ONE new-line can 
be kept per item.


the 'NEW-LINE is the function to control this, if you really need 
to (its usefull for files in my mileage so far):
help new-line

(for files... what I mean is to control the look of rebol block values 
when it is dumped into files)

note the /skip refinement is indexed starting at 0  (meaning don't 
skip any items, new-line everyone of them)

does this help you?

Perfect! thank you Maxim 8-)

its fun to have easy questions some times  (note: easy is not synonymous 
to obvious  ;-)

well, I've spent almost an hour trying to figure out.. next time 
I'll go stright to the dictionary!

some functions are not names the same as in CS so even that sometimes 
leads you away from what you'd expect.... in this case the dash in 
the name prevented me from finding it in google for hours.

names = named

and I knew it existed!

It sometimes help to find the right REBOL words by calling help with 
part of the word. Like:
>> ? line
>> ? new

.

What is the best way to get an formatted timestamp that matches IBM 
DB2 in this form: ccyy-mm-dd-hh:mm:ss.nnnnnn

I tried this, but I'm stuck on how to extract out the nanoseconds 
from Now/precise:


Timestamp: rejoin [ now/year "-" now/month "-" now/day "-" now/time 
".000000" ]


Also, if the month or day is less than 2 digits, I need a leading 
zero -- how can I do this easily?

To get the seconds:
third now/time/precise
Use first, second, to get HH MM.
Not sure it is nano-second precise!

This adds leading zeroes to MM or DD -- you could use similar logic:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=to-iso-8601-date.r

precision depends on the OS used, but millisecond precision is displayed 
always, AFAIK.

I got the following when I did this:

rejoin [now/year "-" now/month "-" now/day "-" now/time "." third 
now/time/precise "000" ]

2007-7-17-13:40:36.36.748000 which is pretty close, except the seconds 
are repeated again.

Try this:

 rejoin [now/year "-" now/month "-" now/day "-" first now/time "." 
 second now/time "." thir
d now/time/precise "000" ]

But you may need to add some more trailing zeroes.... a time of 01:02:03.100 
would show in REBOL as 1:2:3.1

That seems to work -- except for adding leading zeroes which can 
be done via above script -- Thanks Sunanda

I have a format func that isn't on REBOL.org (yeah, I know...; it 
requires another func, etc.) if you have to do a lot of formats and 
don't want to roll them all. Anyway, let me know if you want me to 
send it Patrick.

Sure -- Why not  -- I'm learning more and more all the time

OK -- I'm perplexed as to when does things get evaluated.

If I have a variable like Now-TS: to get the formatted time, it will 
be resolved immediately and return the time.

If later, after I wait 1 second, I want to print the new formatted 
timestamp, it returns the exact same value as before, when I know 
the time has acutally changed.  How do I get the time now to be resolved 
again?  Example code:

print now/precise		gives 17-Jul-2007/14:35:21.308-5:00 
 wait 1

 print now/precise		gives 17-Jul-2007/14:35:22.324-5:00	now/precise 
 is evaluated immediately

 Now-timestamp: 
	rejoin [
		Now/year "-" Now/month "-" Now/day "-" 
		first Now/time "." second Now/time "." third Now/time "000" ] 

 print Now-timestamp			gives	2007-7-17-14.35.22.0000	
 wait 1 

 print Now-timestamp			gives	2007-7-17-14.35.22.0000		the exact same 
 time -- not evaluated immediately


Is it this way because Now-timestamp has been assigned and already 
evaluated  -- if so, how do I have it reevaluate it again?

Wrap it in a function.
now-timestamp: does [rejoin [...]]