Alpha updated

[Brian Rice]

Fixes to the Nil-in-Set feature have been included, along with raising 
requires:/provides: up to Namespace traits, to help with load: calls on 
non-lobby namespaces.

The pre/post-load files were renamed to pre/post-bootstrap and cleaned 
up a little.

Also, NumericMixin and Tuple.slate were moved into the post-bootstrap 
list.

More ideas are brewing, but that's what is ready to use.

On Mar 16, 2005, at 1:06 AM, Brian Rice wrote:

>
> (1) Nil in Sets:
>
> A feature that crept into my last alpha post without my intention was 
> a patch that I had experimented with for containing Nil elements in 
> Sets. It adds one extra slot per Set, but it seems to work. The 
> downside is that if you want to play with Nils (which none of the 
> existing Set users do), you'll run into problems if you don't just 
> stick with the basic operations, add:, remove:, do: (and aggregate 
> methods built on it), and includes:.
>
> I may later "optimize" it to lazily allocate the slot when queried. 
> There's also a slight tweak which is in the alpha branch but not 
> bootstrapped yet which make add: and remove: return Nil instead of the 
> containsNil slot value.
>
> Note that our current unit tests do survive this alteration, and 
> bootstraps are not impaired, so only code that really makes use of 
> this will see an effect. Beware (slightly)!
>
> (2) Namespace-specific loads:
>
> load: got a new keyword, &in:. Alternatively, a Namespace may call 
> load: and get the same effect (e.g. "load: 'test' &in: Test" vs. "Test 
> load: 'test'"). Basically the parser results are called with 
> evaluateIn: that namespace instead of the normal evaluate. There are 
> also a couple of things I messed with in namespace.slate. I fixed 
> flattened, and added import:from: which just calls addSlot:from:. 
> These may get fancier or get more protocols soon.
>
> Note that this use of load: is likely going to cause the parsed code 
> to break for various reasons, mostly because we don't have a quick 
> facility to generate a distinct but polymorphic variant of the lobby. 
> requires:/provides: for example will break, and any other namespaces 
> that the code refers to need to be aliased in the one where the 
> loading occurs. If your code doesn't do much of this (most code 
> doesn't), it'll be easy to adapt the code or the namespace to work 
> together. But it sounds like an interesting task for anyone to mess 
> around with (new facilities to mock up lobbies). :-)
>
> Enjoy!
--
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/