addSlot complicating module handling

[Brian Rice]

On May 8, 2005, at 8:56 AM, Mark Thoma wrote:
> Hello,
>
> why did you choose Slate to not group object slots statically  
> (somehow like C
> structs) in contrast to the current dynamic addSlot scheme? How do  
> you want to
> track which modules are safe to be unloaded and which might modify  
> the slots of
> other prototypes?

Hm. I think you have not figured out that Slate is a dynamic language  
yet - we have started this system with the initial perspective of  
letting things happen dynamically within a live-object image. Slate  
is similar to an OS, where the inability to add a file to a directory  
without rebooting the OS (the equivalent of not having addSlot:  
features) would be considered inexcusable. You could also think of it  
as a live-object database.

Type-safety and static analysis are intended to be done in sub- 
contexts of this general system where there are invariants like "no  
one's adding slots arbitrarily". We're not there now, but will be  
sometime in the future.

> Does this level of dynamicity not introduce more problems - esp.  
> with dynamic
> module loading/unloading, but also speed - than it solves?
> Has it proven to be so useful?

Of course, just as it's useful to be able to create a new file in an  
OS file system directory without rebooting the whole system, or to be  
able to add table rows and columns and stored procedures in a  
database without restarting or rebuilding it.

As for modularity, the Self system came up with a module concept  
oriented to slot-separability which is somewhat detailed here (in  
slide mode, click through for the rest of the explanation): http:// 
research.sun.com/self/release_4.0/Self-4.0/Tutorial/Language/ 
ImportantObjects/Modules.html

(Top-level of that tutorial: http://research.sun.com/self/release_4.0/ 
Self-4.0/Tutorial/index.html)

And, yes, there is an optimization/binary-compilation framework in  
Slate already, but it is not ready for deployment - see src/mobius/ 
optimizer/ and related directories (mapped out in README). We've been  
focussed on design issues before speed.

> Regards,
> Mark