<br><br><div class="gmail_quote">On Thu, Jul 5, 2012 at 1:27 PM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 2012-07-05, at 19:15, Colin Putney wrote:<br>
<br>
> On Thu, Jul 5, 2012 at 8:11 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
><br>
>> Right. So what you're saying is that if you want proper modules, you<br>
>> need VM support.<br>
><br>
> Not necessarily. For the next experiment, I've been thinking about<br>
> implementing selector spaces. Here's how it might work:<br>
><br>
> • Each environment has its own Symbol table<br>
> • The scanner delegates interning of symbols to the environment<br>
> • When interning a symbol the environment searches its imports<br>
> • If no imported environment has the symbol, it creates one in its own<br>
> symbol table<br>
><br>
> This would mean that an environment could add extension methods to<br>
> classes in other environments, without colliding with other<br>
> extensions. It would also make it possible to create "private<br>
> overrides" where only code in that environment would use the override.<br>
> It might be useful for sandboxing, but might not be sufficient.<br>
<br>
</div>Cool idea. Since the VM just cares about the identity of Symbols, we can have the same selector twice in one method dictionary. Each environment would send only the one from its own Symbol table.<br></blockquote><div>
<br></div><div><span class="Apple-style-span">IIRC the implementation of Selector (might be Symbol?) in David Simmons' AOS and S# systems is effectively two-level. A </span>Selector<span class="Apple-style-span"> is on object with two inst vars, one being its defining environment and the other being the selector's unique string (Symbol?). The latter is what we think of as a Symbol right now, so any two Selector (Symbol?) objects with the same sequence of characters have the same underlying unique string (Symbol?). Selectors are the keys in method dictionaries and the message selectors in compiled methods (and presumably are used in superclass names, but here I'm not familiar enough). David had some complex mechanism whereby selectors could match based on having the same underlying character sequence and choosing the shortest distances between their environments. This sounds complex, but the idea of boxing a Symbol so that there's a reference to its environment looks to me to be a useful one.</span></div>
<div><span class="Apple-style-span"><br></span></div><div><span class="Apple-style-span">One could imagine using only boxed selectors for messages defined in a particular environment. This makes introspecting easy. A Symbol's environment would be the root environment; a Selector's would be e.g. that of its environment inst var.</span></div>
<div><span class="Apple-style-span"><br></span></div><div><span class="Apple-style-span">Note that the VM doesn't (and shouldn't) care what objects are used for selectors; SmallIntegers can be used e.g. to save space.</span></div>
<div><span class="Apple-style-span"><br></span></div><div><span class="Apple-style-span">Just 2˘</span></div><div><span class="Apple-style-span"><br></span></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> I want to stress, though, that this is *not* part of the current<br>
> proposal—it's just some ruminating about what the next experiment<br>
> might be, someday.<br>
<br>
<br>
</div>Yep.<br>
<span class="HOEnZb"><font color="#888888"><br>
- Bert -<br>
<br>
<br>
<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>