World: r3wp

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.

(well, OTOH, the INCLUDE function makes it largely unneded, though)

Is that going to be in R3 by default?

the discussion: http://www.rebol.net/wiki/Inclusion_Methodsis still 
not over, AFAICT. Call for contributions!

New users (like Janko) welcome too, of course.

If it is changed to use word! values, I ask only that the naming 
convention used is carefully considered, with the thought that it 
may be used elsewhere, or other conventions may be used as well. 
For example, I use leading and trailing = on words as a convention 
for parse vars and rules.


The example that looks most natural to me, at a glance, is:  .include.

The question of whether to change issue! to be something like a word 
type without binding wasn't resolved, it was put on hold. As was 
the entire inclusion methods discussion a couple months ago, to work 
on plugins and bug fixing. We'll get back to it.

#words still are the nicest one for me....
$word would probably come in close second.

please no ending symbols...

$word$  the ending $ is useless,  and harder to read.

Well, the fact is, that for this purpose we need only a couple of 
"keywords", surely not many

Let me ask this. In a perfect world--forgetting any pre-existing 
designs--what kind of system would you want? Is a pre-processor model 
the best way to go? Should things like #INCLUDE be "commands" or 
just location markers (i.e. anchors)? And if they are the latter, 
what other uses would there be for such things?

It's a shame some of the useful publishing symbols aren't easy to 
type (e.g. § † ‡), but there are ways to work around that if people 
think they make sense.