
Scheme 9 interpreter ported to Plan 9 (again) - nils-m-holm
http://t3x.org/s9fes
======
vruiz
Nice to see Plan 9 making a bit of a comeback these days (at least in HN). I
would certainly be glad if some of the ideas behind it became more popular
today.

~~~
allodium
Which ones? I would like to know more about Plan 9.

~~~
xiaq
Plan 9 makes extensive use of pure-text IPC, more commonly known as file
writes and reads. This is facilitated by the fact that each process sees its
own filesystem hierarchy.

For instance, GUI programs are built by reading from files like /dev/cons and
/dev/mouse and writing to files under /dev/draw. Now it seems that this will
end up in a mess when you try to run multiple GUI programs, but that is not
the case - a WM can provide virtualized versions of these files, and each
program still feels that it is using the entire screen and does not need to
know about the WM at all. My description is likely not very accurate because I
haven't really tried it, but you can find the whole story in the related man
pages:
[http://man.cat-v.org/plan_9/3/cons](http://man.cat-v.org/plan_9/3/cons)
[http://man.cat-v.org/plan_9/3/mouse](http://man.cat-v.org/plan_9/3/mouse)
[http://man.cat-v.org/plan_9/3/draw](http://man.cat-v.org/plan_9/3/draw).

Another example is the authentication facility of plan 9. Instead of being a
dynamically-linked library, it is a separate process that can be reached via
IPC. Russ Cox et al have a talk on this
([https://swtch.com/~rsc/talks/nauth.pdf](https://swtch.com/~rsc/talks/nauth.pdf)).

This is also why Plan 9 has no dynamic linking, since those things are done
with IPC instead.

~~~
cwyers
I am not sure I understand why that's desirable. Why is reading plain text out
of /dev/mouse and writing plain text to /dev/draw an improvement over how
Linux or OS X or Windows does it?

EDIT: I get that Plan 9 is "more UNIX than UNIX" and that this is an extension
of how UNIX behaved. I view that as a philosophical, rather than practical,
point though.

~~~
thristian
Under Windows, to run a program on one host and display and interact with it
on another requires a special "remote desktop" client and special hooks into
the graphics driver and kernel.

Under Plan 9, the tool you use to redirect output from one machine to another
is just "mount": mount /dev/mouse and /dev/draw from the other machine onto
this one, run the command you want, and they appear on the remote machine - no
changes required to the kernel or graphics drivers or any other part of the
system.

Of course, remote display is just one application - since Plan 9 exposes just
about everything as a filesystem, you can mount a remote machine's TCP stack
or editor session or authentication keys or even actual ordinary file storage,
transparently and easily.

~~~
cwyers
Okay,but what does this buy you other than some leaky abstractions? A local
file is not the same thing as a remote file, a local mouse is not the same
thing as a remote mouse, and a local file is definitely not the same thing as
a remote mouse. All that code in Windows that Plan 9 'doesn't need' contains a
lot of logic for dealing with remote displays and input devices that is
probably going to have to reside in your application if the OS isn't providing
it. Simplicity is only a virtue if it's real; false simplicity is just kicking
the can down the road for the next poor bastard to deal with.

~~~
vezzy-fnord
Please actually try researching the concepts and papers about Plan 9 and
Inferno before making such sophomoric statements as "A local file is not the
same thing as a remote file." As if no one has thought about this before.

~~~
agumonkey
As much as I love the way p9 modeled the world, I agree a tiny little bit
about cwyers, in that the notion of file is stretched a little too thin. I do
love the consistency but these aren't files anymore but namespaced objects,
unless a file is a pipe `or` a register `or` a document `or` container of
files.

~~~
vezzy-fnord
Which is the point. Files may be synthetic references to resources and not
actual on-disk files, it's a general abstraction.

~~~
agumonkey
It's just a vocabulary thing, `file` is not that generic.

~~~
typedweb
A file is an object that supports the methods open(), read(), write(), and a
few others. That's about a generic as you can get.

~~~
agumonkey
If I write <data> /dev/net/tcp can I read and get <data> back ?

Can I append <data> /dev/mouse ?

Sharing {open,read,write,close} interface, but with exception and different
semantics leads to a weird flavour of genericity.

------
akkartik
I was most interested in the toolkit for dynamic languages providing garbage
collection, bignums, etc.:
[http://t3x.org/s9fes/s9core.pdf](http://t3x.org/s9fes/s9core.pdf)

------
copsarebastards
Gambit Scheme compiles to portable C, so I see no reason it couldn't be
compiled on Plan 9 (I haven't tried, though).

------
myg204
The good think of portable ANSI C, compile anywhere there is a C compiler.
Very nice.

~~~
aap_
The Plan 9 C compiler isn't even 100% ANSI conformant. But quite close.

~~~
myg204
yes, yes, reasonably close.

