On Wed, 2009-05-06 at 07:02 +0200, Michele Simionato wrote:
> On Wed, May 6, 2009 at 6:18 AM, Derick Eddington
> <[email protected]> wrote:
> > On Tue, 2009-05-05 at 14:31 +0200, Michele Simionato wrote:
> >> I find more intuitive and natural the
> >> semantics such that all imported modules are instantiated
> >> (say once and only once per OS process).
> >
> > To accomplish implicit phasing, Ikarus determines when instantiation is
> > needed based on at what phases references to imported bindings occur.
> > The on-demand semantics is a result of Ikarus's implicit phasing.
>
> No, Ypsilon does implicit phasing but it instantiates the imported
> modules always.
Yes. Aziz told you:
On Tue, 2009-05-05 at 12:06 +0300, Abdulaziz Ghuloum wrote:
> Being different was not a design goal of the system; you understand
> that. It's a byproduct of dropping the "for" syntax from the import
> form and disassociating its purpose as a scoping mechanism from its
> use for instantiation.
I was talking about Ikarus. Before I posted last time, I did know
Ypsilon does what you say. I say Ypsilon is doing implicit phasing
wrong.
> > E.g., for the below, do you think (macro-helper) should always be
> > instantiated?
>
> Yes.
>
> > (library (foo)
> > (export x)
> > (import (rnrs) (macro-helper))
> > (define-syntax s
> > (lambda (stx) (helper stx)))
> > (define x (s)))
> >
> > When (foo) is separately compiled, (macro-helper) needs to be
> > instantiated for phase 1, but when pre-compiled (foo) is separately
> > used, (macro-helper) does not need to be instantiated. Since it doesn't
> > need to be instantiated, why should it be?
>
> Because the module macro-helper could have side-effects, such
> as registering objects at compile time (I am still thinking of the
> use cases in the Compilable and Composable Macros paper)
But I was talking about run-time! A library which does something at
compile-time isn't going to do it at run-time, by definition. My
example above for explicit phasing is equivalent to:
(library (foo)
(export x)
(import (rnrs)
(for (macro-helper) expand))
(define-syntax s
(lambda (stx) (helper stx)))
(define x (s))
(display "(foo) invoked\n"))
and PLT does *not* instantiate (macro-helper) at run-time:
$ cat macro-helper.sls
#!r6rs
(library (macro-helper)
(export helper)
(import (rnrs))
(define (helper _) 1)
(display "(macro-helper) invoked\n"))
$ cat foo.sls
#!r6rs
(library (foo)
(export x)
(import (rnrs)
(for (macro-helper) expand))
(define-syntax s
(lambda (stx) (helper stx)))
(define x (s))
(display "(foo) invoked\n"))
$ cat use-foo.sps
(import (rnrs) (foo))
(write x) (newline)
$
$ plt-r6rs ++path . --compile use-foo.sps
[Compiling /home/d/t10/implicit-phasing/use-foo.sps]
[Compiling /home/d/t10/implicit-phasing/foo/main.sls]
[Compiling /home/d/t10/implicit-phasing/macro-helper/main.sls]
(macro-helper) invoked
(macro-helper) invoked
$ plt-r6rs ++path . use-foo.sps
(foo) invoked
1
$
$ ikarus --compile-dependencies use-foo.sps
(macro-helper) invoked
Serializing "./foo.sls.ikarus-fasl" ...
Serializing "./macro-helper.sls.ikarus-fasl" ...
$ ikarus --r6rs-script use-foo.sps
(foo) invoked
1
$
> > Extrapolate this example to an import set (including all its transitive
> > imports) with multiple libraries utilized only at (> phase 0) -- do you
> > really want those libraries instantiated and consuming memory at
> > run-time even though that's totally unnecessary?
>
> Yes, all the languages I know work in this way, and nobody
> complains about the waste of memory.
None of those languages let you import at compile-time, so your comment
above is irrelevant. And as I thought you've noticed by now, Scheme is
not like other languages, which is a wonderful thing because they all
suck.
> I see this as a questionable
> optimization that makes more difficult to reason with libraries.
The "optimization" simply results from the nature of compilation. Do
you expect things used by a compiler of other languages (e.g. its
parsing and AST processing) to necessarily always exist in the run-time
of a separate program compiled by that compiler, just because the
compiler used those things? Of course not. Macros have been described
as "extending the compiler", and libraries used at compile-time are part
of the compilation process. If they're not used at run-time they're not
needed, just like in other languages.
> In Ikarus a library can be instantiated or not (with
> observable effects) depending if I reference an identifier
> or not. This is confusing.
It's still confusing you because you're refusing to be un-brainwashed
from retarded Python. (I used to like Python once upon a time...)
> Suppose I am importing a library
> purely for its side effects
That is a major misuse of importing. Importing is purely a lexical
scope thing. It's far more confusing to have to figure-out that a
lexical import is being done to implicitly cause side-effects at
execution time. If you want to execute something in an imported
library, say so (in code), like you would for a zillion other cases.
> If I try
> to debug it, I may try to print the value of some variable
> exported by the library. Adding a (display some-variable)
> expression for debugging purposes makes the library suddenly work
> with side effects, but when I comment out the line the side
> effects stop working again. Can you see how confusing is
> this?
No, because you're making-up a fake case. If you're importing purely
for side-effects, why would there be any imported bindings?
--
: Derick
----------------------------------------------------------------
