World: r3wp

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?

IMPORT is used in R3 for module management, which (according to Carl) 
is "not usable for building distributions using..."

then there is the system/options/module-paths variable

(in R3)

PREBOL set aside, I really think IMPORT/CHECK is the common case 
and one of the main advantages over a simple DO - preventing circular 
imports and such. I would be deeply surprised if Carl opts for INCLUDE 
(or #INCLUDE or whatever it will be) not having that check functionality 
in the standard case, switched off by a refinement. But that's just 
me and I certainly don't have any extensive build scripts ...

IMPORT - ah, o.k., I didn't know about that.

we may ask him, you can contribute to the discussion article: http://www.rebol.net/wiki/Inclusion_Methods
, ideas welcome

even the notes you mentioned now are good to keep in there

include should be /check by default   and we should add an  /ALWAYS 
refinement to force reload.

@BH - would changing issue! to a word! sub class rule out some of 
its current capabilities?

Yes. We've made many such changes in R3, removing some functionality 
to replace it with better functionality. It wouldn't have to be as 
bad as you might think - we could change it to copy-on-modify and 
most uses of issue! would still be viable. Keep in mind that use 
of issue! for binary conversions will be going away anyways, replaced 
by better methods. We have strings and tuples for most of the rest. 
The only real difference is just a datatype and/or syntax difference.

Chrisitian, R3's module system handles circular imports without need 
for any /check option.,

Ladislav, R3's IMPORT is not suitable for building distributions, 
but the syntax of modules was designed to be so.

qwikitxt - Nice Janko!

Gregg and amacleod : Thanks :)

Oles: I still can't fully get this.. are you building this flash 
game in REBOL? or is there AS3 code + REBOL to for example generate 
some data for game, etc... ?

I'm building it using REBOL (writing code in old but still my favourite 
Crimson editor). Which means I'm producing AS2 bytecode and also 
modify (resize, join...) various swf files with graphic ( on bit-level 
:) I'm using various caching so for example don't have to republish 
the graphic all the time when I just need to change simple logic 
in my code.

are you the only coder in the team?

I mean at this project

yes

all I can say is "Mega WOW"  :)

I made some flash games (in HaXe mostly).. I have no idea how to 
make a game with so many details, animations, sound, things that 
need to work together...what else to do is in REBOL using some dialect

Oldes: the demo is fabulous... congrats!

you should try and market your engine as an alternative to the other 
flash game building tools.