World: r3wp

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.

Ladislav's INCLUDE has a /check refinement that does the same thing.

yes, INCLUDE/CHECK refinement for "ordinary call", #include-check 
directive to put into the file

Good to hear. ;-)

Would using urls be any better than issues?  You can dedicate a whole 
name space to them, use path notation, still are neutral and parseable 
values:

	sdk:include
	sdk:include/check
	sdk:do

hi Chris, I am afraid, that the main objection Carl had was, that 
he didn't like the fact, that the keywords were in fact string-like 
series. (so no symbols) This does not change, if we switch from issues 
to URLs, unfortunately

But it would switch if issue! was changed into a word-like type. 
That decision has not yet been made.

How about paths?  You could anchor all the commands to one word, 
parse can still distinguish:

	sdk/include
	sdk/include/check

brian that would be a great idea... as long as all of the current 
functionality remains... convertions and allowed symbols  :-)

Ladislav, your INCLUDE already looks very settled, so I'm late with 
the following suggestions. I really like the function and used it 
a lot, but always found the wording a bit unrebolish.


I'm wondering why it's INCLUDE/CHECK or #INCLUDE-CHECK for the "ordinary 
call", as you'd put it above.  Wouldn't it be more convenient to 
have INCLUDE work like the /CHECK-refined call and use INCLUDE/AGAIN 
to again include files already included before?


Also, having INCLUDE/PATH returning the path as a block, wouldn't 
it be easy to APPEND INLCUDE/PATH %ANOTHER without having a seperate 
INCLUDE-PATH next to INCLUDE. It may even be called IMPORT/FROM.

INCLUDE/CHECK   ->  INCLUDE
INCLUDE         ->  INCLUDE/AGAIN
INCLUDE-PATH    ->  INCLUDE/PATH or INCLUDE/FROM


Carl is always picky with names and wording, so having that sorted 
out would probably make it easier to convince Carl to include INCLUDE 
in R3. Which is what I'd really like to see happen, functionality-wise.

More likely is to have prebol rewritten to be module-aware.

dump prebol and make include module-aware.

I think just about every reboler out there agrees that include should 
replace prebol and let it adapt to R3, instead of prebol.

carl won't have to maintain that aspect anymore, and as a result, 
R3 will move ahead faster.  ladislav is VERY thorough in the tools 
he writes... Carl even admited that ladislav is more thorough than 
he  ;-)

and I'm sure Ladislav is more than willing to improve/modify/extend 
include as to make it compatible with Carl's ideals.

why it's INCLUDE/CHECK or #INCLUDE-CHECK for the 

ordinary call", as you'd put it above" - hi, Christian! I picked 
this to be compatible with the PREBOL dialect, which uses #include

INCLUDE/PATH: you are using an old version, I suggest you to switch 
to this one: http://www.fm.tul.cz/~ladislav/rebol/include.r, which 
does not use the /PATH refinement any more. Instead, a special variable 
called INCLUDE-PATH is used

aha, regarding INCLUDE-PATH: maybe I did not understand your proposition

so, you propose a new refinement? (I think I had such a refinement 
once, but removed it...)

what does BrianH think about this? How it should be done to make 
it the most comfortable for the users?

I prefer an issue! keyword dialect, the changing the issue! type 
to be word-like withot the binding. I don't like INCULDE as a function 
name because that would preclude its use as a set operation the opposite 
of EXCLUDE (but that's just me) - using #include and such as issue 
keywords is fine.


An extended prebol dialect like Ladislav's include would work, if 
renamed and made module-aware. When you have modules most of the 
keyword directives go away in practice, since the module scripts 
can be converted to MODULE calls.

how does the module path interface look, Brian?

Just a block of file! and url! paths for now. The file paths of the 
original files can be used at preprocessor time, but would be unnecessary 
at runtime since MODULE doesn't use them. Once the module is loaded 
its load path is irrelevant, and doesn't even have to exist anymore.

The default:
>> system/options/module-paths
== [%./]

yes, that is OK, sure

The preprocessor would need a directive to set module import paths 
that would be used during the preprocess - it probably shouldn't 
use the standard paths in the preprocessor's running process, since 
that would get the modules the preprocessor is using mixed up with 
the ones it is processing, which would prrevent cross-platform processing.

you mean something like (currently used): #do [append include-path 
%this]

Yeah, but with its own official directive. Preprocessor directives 
are friendly - code patterns requiring #do are not. Adding module 
support to the preprocessor means doing it for real.

yes, sure

I'll be back this afternoon (It's still morning here).

Yes, want I wanted to say that I prefered the old INCLUDE/PATH over 
INCLUDE-PATH because it's one word less to "pollute" the global namespace 
(is there such a notion in R3? I'm not so sure now) and it's one 
word less to remember - the refinement will always be easy to learn 
about with HELP INCLUDE.

Re: "INCLUDE as a word" - isn't IMPORT an option, too? We have no 
EXPORT to conflict with, have we?