Re: [Swarm-Support] Followup: found work-aroundfor missing~/swarmarchiver.scm too

[Marcus G. Daniels]

Bill Northcott wrote:
> I am well aware of the difficulties, but I cannot see that as a reason 
> to put up more.
> [..]
> There are large and growing libraries of Objective-C code, do you not 
> think these are worth being able to access?
> [..]
> We say the language is Objective-C but with this significant change to 
> the behaviour of nil it is no longer Objective-C but Marcus' 
> Marvellous Language.
Swarm aims to be a language for modeling.  Originally, a tool for 
thinking about `life as it could be'.  It happens to need an Objective-C 
compiler to build the core library, but it doesn't need one for models. 
 From the very beginning, and before it was ever my responsibility, a 
design decision was made to extend Objective C with extra facilities, 
most notably the idea of method dispatch lists that are constructed at 
runtime.   This is a non-portable extension of Objective-C, and it was 
well understood that it was being made.  (For some time I was frustrated 
myself by this approach, and thought it should be changed.)

In time we found consensus with the premise of separating interface from 
implementation and pressed forward on making the Swarm library 
interfaces abstract and language- independent.  The result of this was 
the Java layer, documentation system, and related multilanguage 
infrastructure.   In a general sense, Swarm makes calls on objects via 
the general notions of object-independent messages or object-dependent 
methods.  To do this, Swarm's interfaces are well defined because they 
have to be to make such a system work at all.  There's a kernel, and 
then language layers around that.  For Swarm `classic' models, that 
language layer is still hooked together using C ABIs and GNU Objective C 
runtime conventions.  For Java, the callouts are simply done with a 
different (not stacked) runtime interface (JNI).   True, Java users have 
the option of using object-independent messages (that happen to be 
implemented with Objective C), but they can also issue calls in a 
tightly bound way as well (suffering less risk of mistakes and costs 
from message lookups). 

Concerning MacOS X and Objective C:   For clarity, given your purposes, 
one way to conceptualize Swarm itself, as say, a network process that 
only uses remote methods via some language-independent protocol.  Forget 
it happens to be compiled by the GNU Objective C compiler.   That being 
said, it should be entirely feasible to layer MacOS X's Objective C to 
Swarm at the *C* level, and without significant performance cost.

Alternatively, just use Swarm as a reference implementation to inspire 
development of a an all new library that uses and follows the language 
you like to the strictness you desire.  
There are many new technologies available for achieving dynamic 
behaviors of the kind Swarm sought with Objective C.   For example, 
dynamic code generation systems like CodeDOM in .NET or dynamic language 
extensions to the JVM (JSR 292 http://jcp.org/en/jsr/detail?id=292).   
Maybe it's time to cast the net a little wider? 

Marcus