On 12/17/2011 1:01 AM, Mouse wrote:
Another
example, from Symbolics Genera (which I've been spending a
fair amount of time with). The Command line in the Lisp Listener
has a few wonderful features [...]
Perhaps _you_ like them. I remember when they
came in and I really
wished I could turn them off entirely. If I'm typing to a lisp
listener, I want everything I type to be taken as Lisp code, never
(mis)interpreted as some kind of funky non-Lispy CLI.
Perhaps I haven't used
it enough, but I've never ever had a problem
with the Genera listener mis-interpreting a lisp form as a command or
vice-versa... do you recall specific examples?
Well, take the example you gave:
"copy file". If I type "copy" to a
lisp listener, I want - expect - to have it taken as Lisp code, giving
me the current global value of the symbol copy, not have it taken for
some kind of CLI command.
Fair enough, though there is a way to tell the command prompt "no
really, eval this as lisp" -- just put a comma before the symbol
(",copy") and it'll treat it as a lisp symbol). Not a huge hassle
though I could see it getting annoying if you happen to have a lot of
globals with the same name as Commands :).
I'm trying to say that I think that a
command-line can be interactive
and helpful, rather than simply passive.
I'm inclined to agree. Difficult to
do under Unix, but that says more
about Unix than it does about what makes a good CLI.
But there seems to be this mindset that what Unix
has is perfect and
cannot be improved upon.
Har! The closest you'll find _me_ getting to that is
"Unix is the
worst OS in the world except for all the others peopl ehave tried", and
even that is putting it way too strongly.
:). That's been my philosophy for awhile.
I much prefer VMS's
privilege model, for example, and, while I don't recall it being done
this way back when I worked on Lisp Machines, I really think
filesystems could be eliminated in favour of other ways of addressing
the needs filesystems satisfy.
Yeah, the LispM has an interesting balance between filesystem and the
Lisp state in the "world". I suppose filesystems as we know them could
be eliminated, but they'd have to be replaced by something to store,
manage and protect user data... which would probably just evolve into a
filesystem again :).
(
As a random aside, historically, LispMs had no native local filesystem
at all. The machines would read in the OS (a "lisp world") either over
the network or possibly stored on a local disk and use other machines --
MIT had DECSystem 10s running ITS, for example, for file stores.
(Genera 8.3 still talks the CHAOS protocol and knows how to deal with
ITS pathnames in the namespace. Anyone have a DECSystem they're looking
to get rid of? :))
Genera 8.3 can still run without a local filesystem (in fact, the
Symbolics UX Lisp machines which are VME cards hosted in a Sun-3 machine
generally have their files stored on the host Sun, mounted over NFS.).
I don't know when the LMFS (Lisp Machine File System, go figure) was
introduced but it's fairly full featured and robust with ACLs, support
for arbitrary file metadata, versioning and the ability to extend the
filesystem dynamically.
)
[...], I doubt anything will change much, things
are too ingrained in
terms of backwards compatibility (both of software and of wetware.)
Yes, I suspect
it will take revolution, not evolution.
In recent years, I've come to the conclusion that POSIX, for all the
good it's done, is not an unmixed blessing; anything that can't be
twisted and bent into a POSIX framework sort of "can't be done". For
example, in 2002 I worked with an experimental encrypted storage
paradigm that really fit the POSIX model very poorly, something I was
very aware of because what I was doing was building a glue layer to
make it mountable as a Unix filesystem.
If you do find [Genera] "stunningly
inconvenient" I'd like to hear
from you :).
Heh. I don't. At least not as of the most recent version I
used; I
expect it to have gotten worse (in my opinion, of course), but it's
highly unlikely to have got to the point of "stunningly inconvenient".
Honestly, i find Genera an amazing programming
environment,
Indeed. Me too.
You mentioned OpenGenera; is this an open-source version or something?
My (rudimentary) web-search skillz end up at pages that give the
impression the "Open" part is a misnomer, so I don't know whether
they're giving me an incorrect impression or whether someone mislabeled
a non-open product as open (presumably in an attempt to - fradulently,
I would tend to say, if so - ride the "Open" bandwagon).
No, it's not open source. It's one of those odd/misleading/meaningless
uses of "Open" from the 90s (like "Open VMS") which does not imply
that
the source is available for free. (Though you do get a copy of most of
the sources with Genera anyway, it's obviously not an open license.)
Open Genera is basically the last gasp of the LispM -- Symbolics, having
reached a point where it couldn't survive in the hardware world,
basically made a virtual lisp machine that ran on the Alpha. (They
basically implemented a software subset of the Ivory processor.) It
runs on Tru64 Unix. I had it running on a PWS 533u for awhile, and it's
very snappy. Brad Parker (who may still be on this mailing list) took
the original VLM code and modified it to emit C rather than Alpha
assembly and made a rough port of it to amd64 Linux. It works fairly
well though it's not trivial to configure properly.
Hopefully, one day the source to Genera will be released to the world,
but I'm not holding my breath that it'll happen soon...
If there really is an open Lisp Machine OS, I think I'd just _have_ to
build a Lisp Machine emulator....
Best of luck to you on that :). I know of a few people who are working
on emulations for the 'bolix machines (both the Ivory and the 36xx
series) but there hasn't been progress in a long time. They're very
complicated machines :). Brad Parker did a nice emulation of the MIT
CADR, which is very fun to play with.
- Josh
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B