[movitz-devel] Object sharing between processes

[Janis Dzerins]

Peter Minten wrote:

 > Janis Dzerins wrote:
 >
 >> Peter Minten wrote:
 >>  >
 >>  > I was wondering about how Lisp objects can be safely shared in a
 >>  > hypothetical Movitz LispOS[1]. The problem is the following shell
 >>  > script:
 >>  >
 >>  > (bar (foo))
 >>  >
 >>  > Say foo and bar are both programs, not functions. Foo gives
 >>  > something as output which becomes bar's input. Now I see two
 >>  > problems with a each-process-an-address-space system:
 >>
 >> I don't quite understand what you mean by "are both programs, not
 >> functions"!  What is a program in LispOS?  And "shell scripts"!? I
 >> think other questions may get answered or disappear when we deal with
 >> this one...
 >
 >
 > Hmm, good point. I think one can define a program as a function that
 > runs in another process.

How does that make a function a program?

What you want (I guess) is to bring a lot of concepts of conceptual OSes
to Movitz (LispOS).  What "we" are after, on the other hand, is the
*Lisp* OS.  We don't want programs each having different understanging
of what arguments are and how they are specified -- we have functions
with their calling mechanism.  We want "Lisp down to the metal", with
all the benefits it brings us.  I suggest reading some materials on
existing Lisp OSes (use google, or this link for a start: <URL:
http://www.its.caltech.edu/~weel/lispm.shtml >).

An aside: most things you want to discuss here are not Movitz related --
Movitz is meant as a substrate for the things you discuss.  But since
there's no list for Muerte and Movitz is in its very early days, we can
discuss our dreams here.  The "we" I refer to above is the group of
people I associate myself with who appreciate Lisp and the benefits it
brings as an OS implementation language, and things we now can see in
some particular museums (like this one: <URL:
http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/symbolics.html
 >).

 > On the other hand one could also think of stored functions running in
 > the current process instead of separate programs.

I also suggest you use existing terminology where possible.  I have no
idea what a "stored function" is and I'm quite sure we don't need that
term at all.

 > I think shell scripting in MILOS (to give the thing a name for now)
 > consists mainly of loading stored functions (in fast-load files) into
 > the current process and using them, but sometimes you'll want to run a
 > function in a different thread. Traditionally this is solved by
 > heavyweight threads (processes) and lightweight threads (threads), but
 > given enough flexibility in the threading system of Movitz I can
 > imagine the difference fading.

Exactly.  We are talking LispOS here:

   ;; function invocation
   (some-function foo bar)

   ;; function invocation in another process
   (process-run-function "Foo process" #'some-function foo bar)

The shell is your REPL.  There's no such thing as "shell programming"
(or, it is your plain old ordinary programming in the REPL).

 > If the treading system is able to create threads that have only
 > limited access to the global and special state of their creators, it's
 > possible to pretty securely use stored functions without having to
 > fear the mess up the spawning program.

There's no point in fearing your own programs, is it?  Processes (let's
call them processes, as that's how they are called in current Lisp OSes)
can access *anything* only through the means provided: arguments passed
to the process's function, globals (special) variables, and maybe some
other means and/or low-level implementation things.

 > This would effectively mean you'd get processes, but more powerful
 > since they can share some global state with their parent thread.

How is what you have described more powerful than processes in current
Lisp implementations?  I may be missing something, but overall I have a
sense that you don't quite know what you are talking about...

 > On a related note I think that shell scripting in MILOS will not be
 > different from writing a program. For example this is how a simple
 > script could look like:
 >
 > (uselib "text") ;if not loaded load and use
 > (format t "~&Word count of file /data/foo = ~A.~%" (wc $/data/foo))
 > (write *standard-output* ($/bin/ls $/data))

How about:

   (require 'text-utils)
   (format t "...whatever: ~A..." (wc #p"/data/foo"))
   (do-whatever (ls #"/data"))

?

 > Here you can see two ways of using stored functions. In the wc form
 > the function comes from the text lib which is explicitely loaded at
 > the start of the script. In the ls form the ls function is stored on
 > disk, but since it's used in a function context it's automatically
 > loaded and used. The wc form is more efficient if used often (loaded
 > once, instead of ls which can be loaded every time it's used), but the
 > ls form allows better quick-and-dirty scripting. The $... is a reader
 > macro that expands into (file ...) to make it easy to work with files
 > in a script.

Leave "scrpiting" (i.e., whatever that is) to script-kiddies.
Programmers do programming.  Actually, I don't quite want to discuss your
just-invented reader macros and functions because it looks like you want
to invent too many wheels at once.  I don't want to discourage you from
doing anything, or discussing your ideas.  It's just that I'll be very
hesitant to participate in them if it goes on like this.

-- 
Janis Dzerins

   Common Lisp -- you get more than what you see.