[Openmcl-devel] "Smalltalk Model" related questions

[Hamilton Link]

On Jun 1, 2004, at 3:59 PM, Dan Knapp wrote:

> Sebastian,
>
>   None of your questions, actually, are specific to OpenMCL.  The 
> following
> information holds for most Lisps.
>
>   A Lisp image captures the entire state of a running Lisp process 
> (except,
> ordinarily, for open files and tcp connections).  In technical terms, 
> it is a
> copy of the contents of the heap.  Loading a saved Lisp image 
> automatically
> creates all the packages, functions, variables, and whatnot which 
> existed at
> the time it was saved.
>
>   Because the image comprises the *entire* heap, you cannot load an 
> image
> into an already-running Lisp; if you could, you would lose all the 
> packages,
> functions, and variables which were in the already-running Lisp, 
> because they
> would be replaced with the saved ones.  Instead, you load it at the 
> time you
> invoke the Lisp process.
>

I would also add that fasl files ("fast-loader" files whatever their 
extension, in openmcl it's .dfsl or .pfsl, MCL uses .cfsl, ACL uses 
.fasl, etc.) contain loadable representations of functions and data. My 
mode of operation doesn't involve generating new lisp heap images all 
the time, but rather firing up lisp and loading a bunch of fasl files 
to put more stuff into the heap. This doesn't replace the heap as might 
loading an entire image. Loading fasls is very much like loading the 
lisp files they were created from (by compile-file) but without 
invoking the compiler.

>   Many Lisp implementations (all of them?) use a saved image, 
> containing
> the entire standard library, to boot themselves with.  Saved images 
> can also
> be created as a means of preloading some large library or a user
> customization.
>
>
>   It is sometimes possible to retrieve the source code for a function 
> by
> using the standard, portable function function-lambda-expression, ie,
> (function-lambda-expression #'foo).  However, implementations are
> permitted to discard the source code if it is inconvenient for them to
> keep it around, and most (all?) implementations discard it at the time
> a function is compiled.

Most lisp environments also have "meta-dot" i.e. alt-. bound to 
find-definition, however it is implemented it usually opens the file 
for a function, macro, class, variable, etc. and takes you to the 
source code.

>
>   This is in no way as powerful as Smalltalk's development environment,
> which is integrated with its runtime system.
>
>   There is no way, without writing code which inspects the internals of
> the system, to look up functions or methods by the classes of their
> parameters.
>

One reason for this might be that lisp has multiple dispatch, i.e. 
generic functions are polymorphic over more than one argument; they're 
also first-class objects (are they in smalltalk? probably, everything 
else is...). This means there's no notion of classes owning methods as 
there is in C++ or smalltalk. Doesn't mean you couldn't have an 
implementation add backpointers from classes to methods, though... 
probably some implementations keep such backpointers but as Dan says 
getting that information would be implementation-specific.

>   There's not particularly a Lisp equivalent of the Smalltalk way of 
> doing
> things; I'm not aware of any language not a dialect of Smalltalk which 
> has
> a system like that.  However, there are two different Emacs packages,
> iLisp and Slime, which provide some level of integration.  Slime is 
> the one
> which aspires to do the sort of thing you're talking about.  You could 
> look
> into those.
>
>
> -- Dan Knapp
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>