This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Gargage collected top-level bindings?


Steve Yegge wrote:
Java and Scheme programmers alike seem to expect top-level bindings to
act like Java instance variables, as if the file contents were contained
within a single Java class.

I don't think it's that simple. The Scheme top-level environment is a *dynamic* environment. Consider the opposite situation: when a module references a variable which is *not* statically visible. Also, if a module does define a binding, when is it visible to other modules?

Also consider fluid bindings.  They are inherently dynamic.  And once
you're using dynamic lookup, things are automatically thread-specific.

Put another way, people expect them to be lexically scoped to that file
(or perhaps module).

People's expectations are not consistent. They expect their code to "work" but they usually can't clearly specify what they want, or see the implications. The situation is complicated by the lack of either threads or modules in R5RS, so we have to work out what makes most sense.

This is the way it has worked historically in the
absence of multiple threads:  you can read and write the bindings from
any function defined in the file, e.g.:

(define my-toplevel-var 10)

(define (my-function)
  (set! my-toplevel-var
	(+ 1 my-toplevel-var)))

Kawa recently changed so that the my-toplevel-var binding is not
accessible to another thread entering my-function.  That's confusing
and unintuitive.

It is accessible if the other thread inherits from the initial thread.


And finally, as I mentioned before, it's not the way it works in
other languages.  So even if Kawa's current semantics for globals
are the "right thing" from some internal design perspective, it will
continue to be a source of confusion, bugs, and mailing list traffic
as long as it remains that way.

So what is your suggestion? Note the solution needs to specify how fluid binds works. Another complication is that (load ...) of a compiled module should behave similarly to loading a source file, and the latter is specified by R5RS.

Sharing top-level bindings among threads will of course necessitate
user synchronization of those variables.  But Java programmers are
used to that, and java.util.concurrent.atomic provides some nice
wrappers to simplify the synchronization.

The issue isn't just synchronization, but what bindings are shared between what threads and what environments?

One possible solution is that initializing a top-level binding sets the
default binding rather than the current thread's. But that means that
initialization and assignment behave very differently, which could leadto other weird behavior. We could also make it easier to share
environments.


I agree the current semantics are awkward.  But it's not easy figuring
out the Right Thing.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]