On 11/19/13 19:13 , Eliot Miranda wrote:
> I would argue that in fact the best way to deal with differing UNIX
> implementations is this approach.  For example, ioctl defines, socket
> constant defines, struct layouts, etc, etc all differ markedly between
> UNIX implementations, and hence one easy way to extract exact
> information is to generate, compile and either run or load a program
> that reveals the implementation details.

It's not clear to me how an arbitrary interpretation mechanism would 
reveal what function to call to invoke e.g. malloc(), assuming that's 
all there is to it.  The mechanism would have to deal with arbitrary 
macro code expansion, arbitrary code without source code provided by the 
compiler itself, and on some platforms such as OS X the behavior of 
malloc() could depend on the value of environment variables at the time 
the binary is loaded (as opposed to the time when the interpretation 
mechanism looks at said variables).  Similarly, it's unclear what that 
interpretation mechanism would do in the general presence of things like

#if defined(FOO)
...
#endif

To me, avoiding writing a few lines of C does not justify the effort of 
correctly rewriting and maintaining (parts of) a C compiler in Smalltalk.

Generally, I agree that one could carefully and consciously write 
comparatively small primitives and/or plugins.  Then, one could compile 
those with a C compiler in a compilation environment compatible with 
that of the VM.  And then, one could call those primitives and/or 
plugins from the image with the expectation (within reason) that they 
should work.