"Ladislav, last question: do you think it is possible (and desirable) to easily build INCLUDE features in R3 in a transparent way for the user? I mean that for example DO would intrinsicly use INCLUDE when having to access a file." - yes, that is possible.
Ladislav "that is not a problem, why there is any problem in using rebol -s %incl instead of rebol -s?"
This would have to be escaped for DOS
I wonder why nobody did it yet then (overloading DO in R2 to add INCLUDE capabilities).
Also, Doc, as far as hot keys from your editor, I do that too. And while it did take a change, I am now used to having a build script as an open file for a project, so I can exec that from the editor easily. Not perfect, but better than nothing.
hmm, I did not need to do it, INCLUDE %timblk.r is still much shorter than DO %/e/Ladislav/REBOL/timblk.r
Gregg: did you find it annoying when working on small script that do not need INCLUDE features, or it is not a problem at all?
There are a number of things I don't do in R2 simply to make it easier for others to use code I may post. Making it clear that INCLUDE is used is easier than "overload DO, and if you've changed DO yourself...)". I just say "Use INCLUDE. If you have a problem, tell Ladislav". :-)
It is a mental shift, and I still have some very small scripts that don't use it. Those are almost gone, because I almost always want library functions at some point, and I don't care about loading extra stuff locally.
"Gregg: did you find it annoying when working on small script that do not need INCLUDE features, or it is not a problem at all?" - let me answer your question as well: not a problem at all
Even my small scripts just start with "do %paths.r" (or a variation for specific projects), which does all the setup.
If I do not need INCLUDE features I am still able to use INCLUDE to run the script (INCLUDE is able to run scripts not needing it)
I also have a project generator that automatically creates all the build scripts and such for a new project.
Thanks to both of you for the answers. I guess I will need to give it a deeper look and try it on some projects to see how it works for me.
That's the best way. The hardest part was getting over the "no external dependencies" mindset for me.
My suggestion is: "always define standalone functions, etc. as standalone files, not cumulate things in one file" that way you are able to use everything as a building block for any new project
That makes sense wrt features INCLUDE offers.
BTW, Gregg, did you consider to add some simple usage examples to
I haven't, but I may. May not happen soon as I have a number of things going on in the next few days.
"I wonder why nobody did it yet then (overloading DO in R2 to add INCLUDE capabilities)."
I think because the more obvious solution is to actually bundle INCLUDE with the standard R2/R3 binaries.
I think Gregg has hit the nail on the head: one of the main reasons for _not_ using INCLUDE is a "no external dependencies" mindset. With INCLUDE being part of e.g. a standard R3 build, this mindset would be at ease.
The "no external dependencies" thing isn't really as big a deal for R3, as long as they're optional, only used by people who need them. But still, the only reason that include wasn't part of the community library is because we haven't set one of those up yet.