[Openmcl-devel] Re: "Smalltalk Model" related questions

Sebastian Nozzi sebnozzi at gmx.net
Wed Jun 2 02:56:01 PDT 2004


Dan Kanpp wrote:

>    A Lisp image captures the entire state of a running Lisp process 
> (except, ordinarily, for open files and tcp connections).

And that would include processes (threads) too, right?
I mean, are they saved? What is saved of them? 

What happens with them when the image is loaded?
(Do they get partially/completely restored?)

>    Because the image comprises the *entire* heap, you cannot load an 
> image into an already-running Lisp; 
> Instead, you load it at the time you invoke the Lisp process.

Thanks, I wasn't sure about this.

> 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.

Is it a common practice among lispers?
Or you prefer to boot some typical image and then load files?
Are there advantages in either approach?

>    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.

And this isn't desirable / needed? (see below)
Lisp programmers appearently neither need nor want this, and I was wondering
why... I seem to be missing something.

> 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.  

Thanks, I'll look into it.

Gary Byers wrote:

> The other sense in which a function's "source code"
> can be accessed is by retaining information about what source file
> (and possibly location information within that source file) and making
> that available to the development environment, and most Emacsy-Lispy
> development environments usually make that functionality available via
> the "meta-."  key binding.

That sounds good.
So basically the development of a big lisp application is file-based, not
unlike other languages. It's up to the developer(s) to keep track of the
contents and locations of the files he/she needs (as is the case with
documentation, appearently). If this is so, then one of my questions is
answered.

Hamilton Link wrote:

> 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.

Interesting!

> One reason for this might be that lisp has multiple dispatch, i.e. 
> generic functions are polymorphic over more than one argument; 

Yes, what I had in mind was something like "find-method" without having to
specify the method name. You could search by the parameter you wanted, not
just the first.

What I wanted to know if lisp programmers don't have the need to see what
methods / functions they have at their disposal to interact with some
instance of class FOO, or to solve a specific problem. 

How do you proceed when looking for solutions for this kind of problems in a
so liberal and not as integrated (as Smalltalk) environment that is Lisp?
(don't mean to criticize, just learn your "modus operandi")

Thanks again for all your answers,

Sebastian

-- 
"Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen!
Jetzt aktivieren unter http://www.gmx.net/info




More information about the Openmcl-devel mailing list