World: r3wp

I get a SQLite error when I try to add my first domain address; I 
was able to create an empty group OK

RobertS: hm.. what kind of error, does it maybe says something like 
"database locked" or something else?

Hm.. I see that last 2 users had to have errors as their domains 
didn't get passed to the bots. I will go figuring out tonight what 
caused this.

Great article on parse Ladislav. This was exactly what I first looked 
for when I very first started looking at Rebol. Thanks.

Great article, Ladislav. Just tweaked the grammar and added a link 
to tthe Parse Project at the end - Peta wrote a lot about Parse there.

thanks, mhinson and Brian

please, can somebody improve the look of the table in the article? 
(it looks awful, I think)

I don't think it looks awfull , it fits the general wiki style ... 
only if heading would be bold or something ... but I don't have any 
exp. with wiki syntax for tables  ... you have few CSS examples of 
fancy tables here

I can't wait to read it as I already said like your articles a lot 
and parse vs re interests me a lot.. I just nee to find some peacefull 
time to zone it

zone it = zone in

PeterWood, that string encoding doc and functions look very useful. 
Nice work.

Thanks, Gregg. BTW, sorry for discussing in Announce, my bad.

When I see that "Very simple. Easy to debug. " in the http://www.rebol.net/wiki/Inclusion_Methods
, I am quite confused about the meaning. What is it that is easy 
to debug? (the DO function?)

It perhaps makes sense if you consider what errors you could possibly 
make coding using DO:
	incorrectly spell do
	miss the % from a filename
	omit the REBOL header from a script file
	do an unset word


I guess you could consider debugging those errors as being easy -- 
though I'm sure you can think of many more possible errors with the 
DO function than I :-)

On a quick look at the wiki page, the question "why do modules have 
to be dynamically loaded?" seems to jump out of the page.

hmm, but when I consider, that every build is actually ad hoc, then 
it means, that you have to debug many times, while in case of a standard 
method you just debug the method, not ad hoc script/s

so "easy to debug" versus "no debug"

Do you not think that it is more a case of either "debugging the 
ad-hoc script" or "debugging the input to the standard method"?  
In the sense of debugging either a shell script to compile and link 
a C program or a makefile.

Isn't  the real question is can you sensibly compare the pros and 
cons of elements of ad-hoc methods (DO, LOAD)  with complete standardised 
methods (PREBOL, INCLUDE)?


Perhaps the better comparison would be to compare ad-hoc inclusion 
against standard methods?

Well, that would require a real-life example?

(but it surely is worth considering to produce such an example for 
the demonstration purpose)

Just an idea about ad hoc versus standard debugging: "standard" actually 
means a specialized dialect optimized for the purpose at hand (so, 
easy to debug by definition). Ad hoc script means a general purpose 
language using more than just DO and LOAD, since they do not suffice 
on their own.

I think, that the dialect is the proper way

Personally, I agree with you. I also generally favour "static" inclusion 
over "dynamic". Perhaps I am unusualin Rebol  in that I am happy 
to work with a build then test approach (I usually take a test-driven 
approach to coding.)

my view is that choice is the right answer.  use what makes sense, 
import, slim, include.  I have an even higher level than include 
with distro-bot.  but still use do directly often.

ladislav: under modules in the inclusion methods, you write: "Not 
usable for building distributions using INCLUDE method. "

I see no reason why not... can you elaborate further?

I can't, since I did not write that

ok

(it is either by Carl or by Brian, if I understand the history page 
correctly)

...and the winner is... Carl!

Since Carl seems to dislike the fact, that the PREBOL/INCLUDE dialect 
uses #issues as "keywords", I tried to list other alternatives (words). 
Does any of them look usable to you?

I actually like #issues.

yes, #issues have clear advantages - no conflict can occur

but, it looks to me, that if Carl initially picked a word alternative, 
we would be happily using that without worring about potential trouble

I know, that issues raise the efficiency question (to Carl, I guess), 
but that does not seem to be critical (YMMV)

like many other datatypes, it would be nice to have one that is directly 
usable for preprocessing.

like we have word!, why not keyword! ?

...you mean using the #issue syntax?

(that is what Carl considered and I guess he even asked that on some 
forum)

...but there probabyl were some asking for the current state (all 
#issues are special strings) to be kept, so he probably gave up

Issue might be usable for other things as it was originally not made 
for preprocessing, as far as I can tell. If there was one just for 
this, rather than haphazardly kidnapping other datatypes, that would 
be great.

...and, what syntax would you assign to the keyword datatype, then? 
- it may be a thing Carl is considering

I have no idea. :-) What chars are left to use?

my guess is, that essentially the ones I listed in the article, but 
that would restrict the word! datatype

so, the question may rather be: does anybody use any of the syntaxes 
listed for "regular words"?

I've seen _word used, and I've made use of =word myself.

I avoid strange syntaxes as much as possible.

But from the list on the wiki, I like *include* the most (and in 
fact, I would discourage any of the others, which look like typos).

Is it really a big problem to have #include? No matter what, this 
is most known format from other environments. Does it really pose 
any problem in regards to REBOL interpreter?

no real problem, except for the fact, that Carl seems to dislike 
it

As discussed in SDK, *include* would allow "*include*: :do" which 
would be kinda useful.