World: r3wp

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.

And don't forget how # is used in URLs.

1) - it was Carl who said (in the above discussion), that modules 
are "Not usable for building distributions using INCLUDE method." 
The INCLUDE method is comfortable and sufficient for the tasks it 
is meant to solve, in my opinion.

2) In my opinion preprocessor directives are more like "commands" 
than like location markers

they simply are "dialect keywords" for the PREBOL/INCLUDE dialect 
telling the preprocessor what to do.

de facto everything is possible to do using just one keyword: #do, 
e.g. #include %a-file.r can be expressed as #do [include/only %a-file.r]

Modules are good for code organization and their headers can be taken 
into account by a preprocessor like prebol.

and since we can build modules dynamically, I guess that we could 
do like slim and embed the dynamic version of the module within the 
source code directly.

Hey Ladislav, here is a modules document for High Level Assembly 
that might stimulate some thoughts http://webster.cs.ucr.edu/AoA/Windows/PDFs/ManagingLargePrograms.pdf

Of one thing to note is an INCLUDEONCE directive.  This way if a 
module contains a reference to another module that it isn't called 
more than once.