> (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.
Agreed. Implementers are responsible to portabilities. However, the magic is not easy to find for me. :-( I hope I can get some luck this time, and successfully remove my headache. ;-) > 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. I understand 'include' is very useful to make clean and maintainable code. :-) -- fujita On May 28, 11:30 am, Derick Eddington <[email protected]> wrote: > 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 > ----------------------------------------------------------------
