Duane Rettig wrote: [1999-08-26 20:03 -0700]
|...|
> Of course, it truly is the case that the incremental disk expense for
> this "program" is only 1444 btyes, but to be fair, the memory cost of
> starting the second copy of the lisp is much more than that - you would
> have to account for any per-process data that is re-allocated.
In many cases I think people would be glad to have a running Lisp process
that would execute the Lisp program in the executable file, rather than
start a new Lisp process each time. (In fact, this is roughly what happens
with MCL, as Rainer Joswig has already explained.)
I don't see any problems with that in principle, especially if the Lisp
implementation is multi-threaded (and can accept requests for execution
before the previous program has terminated). I would not be surprised
if some implementation already provides this capability as an extension
`out of the box.'
Under Unix, the program that is named after the ``#!'' in the beginning
of the file would be a small intermediary that connects to the running
Lisp `server' (using sockets, it need not be on the local machine, though
things would then become more complicated with respect to file
system operations).
All of this is fairly obvious, I suppose, and if such functionality is
available, I guess in many cases it would satisfy those that want
`standalone' programs.
Vassil Nikolov. (See header for additional contact information.)
Abaci lignei --- programmatici ferrei.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <·····················@195.138.129.116>, Vassil Nikolov <···@einet.bg> wrote:
> Duane Rettig wrote: [1999-08-26 20:03 -0700]
>
> |...|
> > Of course, it truly is the case that the incremental disk expense for
> > this "program" is only 1444 btyes, but to be fair, the memory cost of
> > starting the second copy of the lisp is much more than that - you would
> > have to account for any per-process data that is re-allocated.
>
> In many cases I think people would be glad to have a running Lisp process
> that would execute the Lisp program in the executable file, rather than
> start a new Lisp process each time. (In fact, this is roughly what happens
> with MCL, as Rainer Joswig has already explained.)
On the Macintosh files have the idea of a *creator* and a *type*
(the type is not related to the pathname).
The creator is a signature for the application with should
be used with this file. So, normally a FASL file on the PowerMac
has the creator CCL2 and the type PFSL. If you open the
file the MacOS sends an "open" message to an application with the
signature CCL2 (this would be MCL) with the file as the argument.
MCL then executes a handler that determines what it wants
to do with a file of the type PFSL. You could
add behaviour for different types - MCL could display
a JPEG file as a graphics for example.
If you want to create your own application based on MCL,
you might want to define for the application a new signature
and define new file types. Double clicking on those
files would just open these with your new
application - nobody would even know it is a Lisp
application. Additionally you can define icons for
your application and it's file types that show up
in the Finder - your Lisp application will even more
look like any other application. Further your application
might be based on it's own class, have it's own
menubar, it's own toplevel and it's own error handling
(don't show your users a Lisp debugger). The result is a GUI-based
application look like any other graphical application
on the Mac.