[REBOL] Re: PREBOL questions
From: greggirwin:mindspring at: 24-Nov-2002 11:36
Hi Robert,
RMM> Now we have PREBOL. It's already a cool script but how do you use it
RMM> while developing? I don't want to run PREBOL each time. So I need
RMM> something like a native "include" (I'm currently just using DO). It
RMM> works but I'm not sure if there aren't better ways to do it. Any
RMM> comments?
Graham and I just mentioned this on IOS/Developer. I want to be able
to run things interactively, but then build from the same source.
There's no good solution for that using PREBOL at this point. What I
do now is have a little script that does the build and runs the
processed script. Mine is separate, unlike Volker's, so my source
doesn't get modified when built.
Building is plenty fast, but I did mod PREBOL so it doesn't output any
info to the console if everything goes OK.
RMM> Further I would like to be able to write the PREBOL directives while
RMM> developing. But adding #include to my scripts won't run it with the
RMM> normal Rebol interpreter. So how about using ;#include for PREBOL? It
RMM> shouldn't be to hard I think.
I don't think using a comment will be so easy because PREBOL does a
LOAD/ALL so it can find the directives as issue! values. Comments
would never show up for it to process, right?
RMM> AFAIK PREBOL will include the whole file. Is there any way to find our
RMM> what stuff is used from an include file and to strip the unused code? At
RMM> the moment I'm using one big library file. So even for small scripts,
RMM> everything is included. I know that Rebol is very dynamic etc. but
RMM> maybe it's possible to write a trace-log, that can later be used by
RMM> PREBOL for filtering. What do you think? Robert
There's also not an easy way to find out if something has already been
#included. Right now I'm using a dual system that doesn't thrill me. I
have a main script that contains the #includes for everything and all
the secondary scripts (i.e. #included scripts) use VALUE? and DO to
load things they need. That won't hold up long term on a large scale
though.
Ultimately I think I'll want, and need, a good dialect to handle all
this. Building an optimizer would be a good bit of work I think.
--Gregg
-- Gregg
