guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: r6rs libraries


From: Andy Wingo
Subject: Re: r6rs libraries
Date: Tue, 06 Jan 2009 10:45:32 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Hello,

On Tue 06 Jan 2009 00:40, address@hidden (Ludovic Courtès) writes:

> Hello and happy new year!  :-)

Yes yes! 

> "Julian Graham" <address@hidden> writes:
>
>> * I think it'd be possible to implement R6RS "import levels" using
>> Guile's existing #:export, #:export-syntax, #:reexpport, and
>> #:reexport-syntax keywords -- if it weren't for the `(meta <level>)'
>> option for import specifiers.  It might still be possible, given the
>> allowances of section 7.2.  I don't know, I'm still trying to figure
>> that out.
>
> The problem is that Guile has *no* phase separation whatsoever: macros
> are evaluated at run-time, in the same environment as actual code that's
> executed.

I think we still have what we need for R6RS.

PLT's implementation provides a fresh environment at each meta-level;
thus side effects from one level can't affect other levels. This sounds
nice in theory, but it's not required by R6, and the reason is this:

  Consider an R6RS library that implements `current-output-port'.
  Normally these ports are buffered, so as not to incur syscall overhead
  on each character written. So there is some buffer that is
  side-effected when the port is written to.

  Now consider one library that writes things on the
  `current-output-port' *when the module is initialized*, and one main
  program that writes things on `current-output-port' from level 0. If
  each level has its *own* `current-output-port', there will be multiple
  buffers -- thus (in the absence of level finalizers -- and that can
  get quite complicated) the buffers will be flushed as the ports get
  collected, meaning out-of-order output for something that was clearly
  deterministic.

This might seems contrived, but the need to share state between import
levels is something fundamental, I think, when you get to the level of
language *implementation*. And if you can't implement a
multiple-instantiation R6RS in pure multiple-instantiation R6RS, well,
what a language...

Neither Dybvig & Ghuloum's nor van Tonder's library implementations do
multiple instantiation, AFAIK. PLT's is the only one that does.

Regards,

Andy
-- 
http://wingolog.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]