I run all my REBOL scripts using F10 key from my code editor (which launches "rebol -s" on the script), having to use a wrapper script won't fit well my way of working. F11 encaps the current script directly with /Pro, F12 encaps it with /CommandView. :-)
that is not a problem, why there is any problem in using rebol -s %incl instead of rebol -s?
I guess I shouldn't be able to use %do on any such script from console anymore?
sorry: do instead of %do
just use INCLUDE
(it actually even finds the script for you, as opposed to DO which does not have a search capability)
for example, I write:
and do not care where the script is, since INCLUDE finds it for me
How does it avoid collisions between similar script names in different include folders?
It does mean relying on INCLUDE as a normal part of your workflow and approach, but I would have a hard time giving it up now.
You can use the #include-check directive to catch multiple includes, so your include-path gives you control.
it uses the INCLUDE-CTX/PATH search path variable, where the first found first served approach is used. Also, you can adjust your path at any time, which is being done by some scripts to "shrink" the search area
...and you can alway just write: INCLUDE-CTX/PATH: [%.] which uses only the current directory for search
I would like to see INCLUDE be standard, perhaps with a refinment on DO (or just have it work that way by default), simply because INCLUDE doesn't imply execution the way DO does.
Gregg: I use the same workflow for my REBOL work since 10 years...it's uneasy to change that, unless I can convince myself that the gains are worth the effort of changing the habits. :-)
Well, Gregg mentioned that he would not want to give up on INCLUDE because it saves time in a significant way
I'm the same way. It took me a while to transition to INCLUDE, but I'm glad I did.
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.
How much benefit you see will depend on what you're building, too. My two main needs are apps that need to be encapped (often with different features whether for local use or as a rich 'net app), and scripts that comprise elements in larger systems, where there are common infrastructure elements and libraries, but scripts are run dynamically.
I think so, but I could be wrong. :-)
Put another way, is there a reason it couldn't?
In that scenario, I would think about how it would work in the wild, with resources made available on the 'net. An elegant integration of modules, INCLUDE, and public libraries would be a dream come true.