[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dynamic binding implementation issues
- To: RRRS-Authors
- Subject: Dynamic binding implementation issues
- From: Gyro@Reasoning.COM
- Date: Fri, 8 Dec 89 16:58 PST
- In-Reply-To: <8912082232.AA00730@Neon.Stanford.EDU>
Date: Fri, 8 Dec 89 14:32:28 -0800
From: Andy Freeman <andy@Neon.Stanford.EDU>
Deep binding solves your objection. One load/store to invoke a
continuation is not a significant cost. Nothing else gets copied or
done unless/until you use them.
Shallow binding won't work on multiprocessor architectures and
isn't necessarily faster on uniprocessors even if continuations
aren't first-class citizens.
Okay, fair point: the force of my implementation-related objections is
somewhat reduced by the fact that deep-binding implementations are
possible and would not suffer the problems I mention. I will grant that
the implementation issues I raise are really arguments against shallow-
bound implementations. However, I quote an earlier message of Pavel's:
-- Given ``dynamic-wind'', a portable shallow-binding implementation of the
proposal can be written for all single-processor implementations of Scheme.
It was suggested at the BASH meeting that something like this be done and
placed in the library. As stated in earlier messages, multiprocessor
implementations will have to implement it more primitively; Jinx has
pointed out, however, that two simple procedures for accessing the
process-specific dynamic environment suffice.
It's clearly the sense of the community at the moment that the default
uniprocessor implementation use shallow binding. If I can't talk people
out of dynamic binding entirely, perhaps I can succeed in making
shallow-bound implementations unpopular.
My modularity-based objections to any form of dynamic binding stand.