public CVS
rdf export
home
SITENAV
meetings
what's new?
whiteboards
post article
frontpage
downloads
ORIENTATION
legalisms
history
glossary
participants
BACK-ENDS
udanax-green
udanax-gold
ALGORITHMS
coordspaces
enfilade
ent
OLD MANUALS
XIA
HELPING
puzzles
needs
funding
site-traffic
admin
|
 Re: Seeking Reference Material on Certain Obscure Programming Terms |
 |
Posted by Mark S. Miller on Sun Feb 02 21:04PM CST 2003
from the udanax mailing list dept.
At 06:26 PM 2/2/2003 Sunday, Jeff Rush wrote:
>* stepper
> obviously some kind of iterator; used as a base class in Udanax Gold
> but no definition of stepper is present; must be built-in to their
> flavor of SmallTalk. There is some confusion over whether the
> collection over which we are iterating can be mutated or not; hints
> are that a stepper insulates the caller from mutations, which is
> uncommon in iterators in other languages (C++, Python).
Came from us, not from Smalltalk. There should be a root class "Stepper"
somewhere in the sources defining this type. As I recall, there was at least
a message "step" that returned the next element and advanced. If I recall,
when you ask a mutable collection for a stepper, either
* it gives you a stepper over a copy, or,
* if the collection is mutated, any outstanding steppers are invalidated, or,
* the collection can't be mutated until all outstanding steppers are closed
or something.
I don't remember which it is, but any of the above preserve correctness. The
common iterators you refer to are examples of the kind of fragile
abstraction we tried to avoid building -- if you use them wrong, they don't
even blow up reliably, but just do the wrong thing.
>* passe
> seems to be a method invoked on "self"; does it pass the call to
> the parent class, trigger an exception as "subclass must
> implement" or something else? If the parent lacks such a method
> does it quietly do-nothing or raise an exception?
This either meant "deprecated" or gone/retired. I don't remember which. Also
our coinage.
>* fluid and emulsion
> apparently references to an old LISP object persistence mechanism
> that has found it's way into Udanax Gold/SmallTalk; I'm familar
> with the persistence mechanisms of Python (pickles) and CORBA,
> but I'd like to understand how fluid/emulsion compare.
"fluid" refers to fluid variables and dynamic scoping, as in
http://srfi.schemers.org/srfi-15/srfi-15.html .
"emulsion" was our coinage derived from fluids. I think it was part of our
implementation of fluids. On the C++ side, if I recall, at static
initialization time we strung together all the fluid variable "declarations"
on a linked list, and calculated the current size of all the fluid state.
Then, for each thread we allocated a frame that big. I think that frame was
the emulsion. Each fluid "declaration" would also calculate its offset into
that frame during the same static initialization phase. A fluid variable
access was then an access to the current thread's emulsion at the offset
calculated by that variable's "declaration".
I know you're working on the Smalltalk side, but I just don't remember what
we did there, except that it had adequately similar semantics.
>Jeff Rush, A Xanadu Curator of
>http://www.sunless-sea.net
Thanks! Keep up the good workD!
----------------------------------------
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
<
Forum for bugs/patches
|
Seeking Reference Material on Certain Obscure Programming Terms
>
|
|
|
|
| Reading List |
|
As We May Think,
1945
Vannevar Bush
Augmenting Human Intellect:A Conceptual Framework,
1962
Doug Engelbart
Literary Machines,
1981, 87, 93
Ted Nelson
Engines of Creation, Chapter 14
The Network of Knowledge,
1986, 87
K. Eric Drexler
Hypertext
Publishing and the Evolution of Knowledge,
1986
K. Eric Drexler
SF:EarthWeb,
1999
Marc Stiegler
|
|
 |
 |
 |
|
