On May 28, 2009, at 5:30 AM, Derick Eddington wrote:
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).
This is all correct. Details below.
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,
to the extent possible, yes
and extending the stale library detection helps users accomplish that.
That's the goal.
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.
Correct. Without support from the implementation, you'd have to resort
to external means (e.g., makefiles, etc.) to accomplish this. Meaning,
every time you include a file in another, you have to also modify your
makefile. Ikarus's --compile-dependencies *is* like make with preset
rules. The added functionality allows you to extend the rules as you
see fit.
(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.
All in all, this is a quality-of-implementation issue. If this added
functionality is useful, it will propagate to other implementations.
Other implementors may have better ideas about how to go about doing
this which might (or might not) be better than what I came up with.
[I think one good outcome of R6RS is that library writers form a
bridge between implementors who would not be collaborating otherwise.]
Anyways, the details from the latest push:
revno: 1796
committer: Abdulaziz Ghuloum <[email protected]>
branch nick: ikarus
timestamp: Thu 2009-05-28 09:02:47 +0300
message:
- Added stale-when:
syntax: (stale-when guard-expr e* ...) ;; in definition context
(stale-when guard-expr e e* ...) ;; in expression context
semantics:
When a stale-when form is encountered while expanding any code
(expressions, macros, macros in macros, etc.) in a library
body, the guard-expr is expanded (but not evaluated) and
serialized along with the library. When the library is later
reloaded from fasl and before it is installed, the guard-expr
is evaluated. If guard-expr returns true, the fasl content is
ignored and the library is recompiled afresh from source.
Two things I forgot to say in the commit log:
* The guard-expr is a "meta" expression: it cannot reference lexical
variables but can reference macros and imported variables. This is
because the guard expression is evaluated "out of context" and before
the library is loaded and/or initialized.
* The e e* ... are spliced/sequenced in place of the stale-when form
(just like how begin works in definition and expression contexts).
For now, I have added a warning message that's printed whenever a
library is considered stale. (we should have a "warnings policy")
Comments, questions, and feedback welcome.
Aziz,,,
