On Wed, 2009-05-27 at 13:40 +0200, Michele Simionato wrote:
> On Wed, May 27, 2009 at 1:24 PM, Derick Eddington
> <[email protected]> wrote:
> > My (xitomatl include) is fully portable.
> 
> What I meant is: even if Aziz performs some magic such that (xitomatl
> include) works on Ikarus
> with auto-caching enabled, there is no guarantee that (xitomatl
> include) will work the same on Ypsilon,
> unless Fujita adds the same magic to Ypsilon.

Don't you mean recompiling when dependencies change and not
auto-caching?  IIUC, that's what Aziz said he is looking into extending
so that the timestamps of the source files are not the only possible
dependency, the timestamp of an included file, or whatever you wire-up,
can also be made a dependency whose change will be detected and cause
recompiling instead of using a stale pre-compiled file; in other words,
you'll be able to define what stale means.  (So I'm assuming.)
Auto-caching is orthogonal (I think).

Anything related to compiling or caching is inherently non-portable, so
I don't see how Aziz could make it more unportable.  Scheme is
intentionally designed to allow different implementation designs.

Aziz's philosophy is that code should work the same whether it's
pre-compiled or not, and extending the stale library detection helps
users accomplish that.  Pre-compiling is only a convenience to avoid the
start-up time of compiling.  Scheme systems with less helpful stale
library detection are just less helpful at helping users deal with what
is their unavoidable responsibility.

(xitomatl include) will still be fully portable and work the same on all
systems.  The difference will be that on Ikarus changing an included
file will cause recompilation of pre-compiled libraries, but systems
without the same ability will use a stale pre-compiled file.  This is a
behind-the-scenes issue not related to portability of code.

> But whatever, I have no
> strong opinion on this point,
> since I use include very rarely.

I've used include a lot when porting code.  I include the original,
often unaltered, code into an environment made for it.  This makes it
much easier to diff when the author makes updates, and it separates
licensing and makes it clear who made what.

-- 
: Derick
----------------------------------------------------------------

Reply via email to