[Openmcl-devel] Re: "Smalltalk Model" related questions
sebnozzi at gmx.net
Wed Jun 2 05:56:01 EDT 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
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
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
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.
> 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,
"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