This is really just a thought experiment, what would a modern,
semi-mainstream Lisp based OS look like today? Let's assume that the
hardware is mainstream x86 and our hypothetical LispOS occupies a
position similar to that of Linux.
- What would the software ecosystem look like? Today applications
have little reuse of parts and are written in C.
- Would software be easy to distribute in binary form?
- How would seperation of privileges work? Multiple users/super user?
- What will the filesystem look like?
- Would the system be Lisp all the way down?
- How would support for other languages be?
I was born the same year as the Lisp Machines, so I haven't seen this
kind of environment before and I'm interested in it.
My thoughts:
The software ecosystem would be much the same as OSS is today, you can
get source to lots of apps. I think the apps would generally be
smaller in code and binary size because of the libraries that are
already available from the OS. I would hope reuse would be higher
among OSS, because of the nature of all Lisp code running in the same
image.
Support for other languages would probably be pretty good, after all
you just need to compile to Lisp s-expressions and the LispOS can do
the rest - though I bet there would be native compiling languages too.
I'm interested in what people think about this, so please reply.
Cheers
Brad
> This is really just a thought experiment, what would a modern,
> semi-mainstream Lisp based OS look like today?
KnowOS: www.knowos.org or www.biobike.org
"bradb" <··············@gmail.com> wrote in news:1151517200.828579.197240
@b68g2000cwa.googlegroups.com:
> This is really just a thought experiment, what would a modern,
> semi-mainstream Lisp based OS look like today? Let's assume that the
> hardware is mainstream x86 and our hypothetical LispOS occupies a
> position similar to that of Linux.
> - What would the software ecosystem look like?
A smalltalk-like graphical environment would be nice to have.
Today applications
> have little reuse of parts and are written in C.
> - Would software be easy to distribute in binary form?
Binary, intermediate, or source in a packaged jar.
> - How would seperation of privileges work? Multiple users/super user?
Certainly. Perhaps al graphical environments would connect to
a server kernel that would manage access.
> - What will the filesystem look like?
All objects, would be persistent. A process is an object.
Everything is an object similar to ST. The file system
a collection of objects. A collection is an object.
Maybe a tree of collections... ???
> - Would the system be Lisp all the way down?
Mostly but low level code can be done in C++/Assembly.
> - How would support for other languages be?
Through some kind of adaptation layer?
To be able to communicate in the object environment.
The idea is to unify all languages.
> My thoughts:
my $0.02 wish list :)
Stefan Mandl wrote:
> I think Lisp Machines had support for compiling C-programs, didn't they?
I don't think so... Why care about C if you have a machine dedicated to
Lisp?
Sascha
> I don't think so... Why care about C if you have a machine dedicated to
> Lisp?
To run standard code.... KnowOS and BioBike do this wonderfully well!
> I don't think so... Why care about C if you have a machine dedicated to
> Lisp?
Let me quote from here:
http://www.erlang.org/ml-archive/erlang-questions/200302/msg00646.html
The problem was that one machine started at $40K
and they ran up to $150K or so, but they weren't
servers. They were workstations for individual programmers.
Sun was still on the Sun 2 or 3, but they were getting
faster and people were saying Lisp could run almost
fast enough on them. Meanwhile Symbolics delivered
a full C interpreter(!) where you could modify code in
the debugger and resume with new variables defined
or even new functions. C on a LISP machine is a hard
sell.
ok, an interpreter ;)
> The problem was that one machine started at $40K
> and they ran up to $150K or so, but they weren't
> servers.
That was then; this is now. The KnowOS/BioBike runs on standard Linux
platforms- I paid for our main server on my credit card, and it didn't
even hurt!
> They were workstations for individual programmers.
KnowOS/BioBike are fully web serverized, multi-user/timesharing Lisp
enginer (and soon to be (somewhat) Ajaxified.)
From: Stefan Mandl
Subject: Re: KnowOS (Was: What would a modern LispOS look like?)
Date:
Message-ID: <4ggguuF1lerf7U1@news.dfncis.de>
> That was then; this is now. The KnowOS/BioBike runs on standard Linux
> platforms- I paid for our main server on my credit card, and it didn't
> even hurt!
Jeff, I was actually referring to the claim that there was no C-compiler
for Lisp Machines.
I did take a look on the KnowOS-link that you provided in an other
answer in this thread. What I don't get straight in my mind: Is KnowOS
an operating system in the sense that it drives (and abstracts) my
hardware, or is it more like a middle-ware that provides a common basis
for applications but can be run in a number of operating systems, or is
it an abstract concept that describes the idea behind BioBike?
regards,
Stefan
> Is KnowOS an operating system in the sense that it drives (and abstracts)
> my hardware, or is it more like a middle-ware that provides a common
> basis for applications but can be run in a number of operating systems,
> or is it an abstract concept that describes the idea behind BioBike?
This is an interesting question with many possible reponses. First,
there is the "if it look like a fish, and tastes like a fish..."
response (or, alternatively: "I don't know how to define pornography,
but I know it when I see it!"): KnowOS certainly *seems* like an
operating system from the user point of view: It has persistent
objects, multi-user multi-threading, you log into it and run things,
and you don't care what the hardware is... so these things are true at
least as much as for Windows or Linux.
But, then one may wonder if your question is sensible in the modern age
of hundreds-of-layers deep stacks of middleware; are Windows or Linux
any more directly driving of hardware than the KnowOS? We just stick
another layer (ACL) between you and Linux.
On the other hand, one thing that the KnowOS clearly is *not* is
"merely" a programming environment; I know of no programming
environment that comes with built-in content (whereas operating systems
do!), and one usually eventually turns off your programming platform
(losing all state), which you don't do with either the KnowOS nor with
a typical OS. (Or, more precisely, if you do turn it off, when it comes
back up, your content is retained -- although not your process state,
at least in most cases -- there are OSs where process state *is*
maintained through reboots).
[Full disclosure, unless you are running KnowOS on AllegroCache, you
state through reboots is also not retained, however, we nearly never
reboot them; I've had one running for my symbolic biocomputing class
since May 12th, and all of the content and process state is still
there!]
'Jeff
From: Pierpaolo BERNARDI
Subject: Re: What would a modern LispOS look like?
Date:
Message-ID: <op.tbwdhbhnxbm8ci@eraora>
On Thu, 29 Jun 2006 00:30:29 +0200, Sascha Matzke <·············@gmail.com> wrote:
>
> Stefan Mandl wrote:
>> I think Lisp Machines had support for compiling C-programs, didn't they?
>
> I don't think so... Why care about C if you have a machine dedicated to
> Lisp?
http://www.cliki.net/Zeta-C
--
Anything below this line is being added by the newsserver
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Pierpaolo BERNARDI wrote:
> http://www.cliki.net/Zeta-C
>From the Zeta-C manual:
"ZETA-C compiles a C function by translating it
into Lisp and handing the result to the existing Lisp compiler."
A really nice example for the power of Lisp ;-)
Sascha
From: Luís Oliveira
Subject: Re: What would a modern LispOS look like?
Date:
Message-ID: <m2zmfvvptk.fsf@deadspam.com>
"Sascha Matzke" <·············@gmail.com> writes:
> "ZETA-C compiles a C function by translating it
> into Lisp and handing the result to the existing Lisp compiler."
>
> A really nice example for the power of Lisp ;-)
There are Lisp compilers that translate Lisp to C and hand the result to
an existing C compiler. Is that a nice example of the power of C? :-)
--
Luís Oliveira
luismbo (@) gmail (.) com
http://student.dei.uc.pt/~lmoliv/
Luís Oliveira wrote:
> "Sascha Matzke" <·············@gmail.com> writes:
> > "ZETA-C compiles a C function by translating it
> > into Lisp and handing the result to the existing Lisp compiler."
> >
> > A really nice example for the power of Lisp ;-)
>
> There are Lisp compilers that translate Lisp to C and hand the result to
> an existing C compiler. Is that a nice example of the power of C? :-)
No, actually this is also a nice example of the power of Lisp! :-)
On Thu, 29 Jun 2006 19:23:19 +0200, Lu�s Oliveira
<·············@deadspam.com> wrote:
> "Sascha Matzke" <·············@gmail.com> writes:
>> "ZETA-C compiles a C function by translating it
>> into Lisp and handing the result to the existing Lisp compiler."
>>
>> A really nice example for the power of Lisp ;-)
>
> There are Lisp compilers that translate Lisp to C and hand the result to
> an existing C compiler. Is that a nice example of the power of C? :-)
>
That truth be told. Is what has always kept me away from GNU Lisp.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Christopher C. Stacy
Subject: Re: What would a modern LispOS look like?
Date:
Message-ID: <yzlodwcdm11.fsf@OSX663.local>
"Sascha Matzke" <·············@gmail.com> writes:
> Stefan Mandl wrote:
>> I think Lisp Machines had support for compiling C-programs, didn't they?
>
> I don't think so... Why care about C if you have a machine dedicated to Lisp?
The Symbolics Lisp Machine had (what I think was the first, even before Unix)
ANSI (draft) compliant C compiler, and it was used to do things like
compile the X Windown System.
Symbolics also had FORTRAN, ADA, PASCAL, TeX, and some other compiled languages.
This allowed people to have the same wonderful development and debugging
environment, including source-level debugging, fancy stepping, breakpoints,
inspection, and so on, that was offered for Lisp. (Actually, the compilers
and the debugging support for those other languages was, for a long time,
somewhat better than what was available for Lisp on the machine.)
There was also a third-party C compiler which ran on all the MIT-derived Lisp Machines.
None of this is to be confused with various language translators and simulators that
also abounded throughout the history.
"bradb" <··············@gmail.com> writes:
> This is really just a thought experiment, what would a modern,
> semi-mainstream Lisp based OS look like today? Let's assume that the
> hardware is mainstream x86 and our hypothetical LispOS occupies a
> position similar to that of Linux.
> - What would the software ecosystem look like? Today applications
> have little reuse of parts and are written in C.
> - Would software be easy to distribute in binary form?
Why should we allow to distribute software in binary form?
The OS should enforce source form distribution. So the OS AI can
check the sources for malware.
> - How would seperation of privileges work? Multiple users/super user?
Capabilities. Like in eros or coyotos. Of course, it could support
multiple users.
> - What will the filesystem look like?
File systems are figments of your imagination. If you need a file
system, you may create one. But the OS doesn't need files to ensure
persistence of the objects.5
> - Would the system be Lisp all the way down?
Yes.
> - How would support for other languages be?
Why? What for?
--
__Pascal Bourguignon__ http://www.informatimago.com/
PUBLIC NOTICE AS REQUIRED BY LAW: Any use of this product, in any
manner whatsoever, will increase the amount of disorder in the
universe. Although no liability is implied herein, the consumer is
warned that this process will ultimately lead to the heat death of
the universe.
Pascal Bourguignon wrote:
> "bradb" <··············@gmail.com> writes:
>
>
> Why should we allow to distribute software in binary form?
Because not everybody wants to give away their code. In my thought
experiment we aren't living in an ideal world.
>
> The OS should enforce source form distribution. So the OS AI can
> check the sources for malware.
I'm thinking of a current time LispOS, not a future time one. Right
now there is no automatic malware checker for any language, therefore
our modern Lisp OS also doesn't have one.
>
>
> > - How would seperation of privileges work? Multiple users/super user?
>
> Capabilities. Like in eros or coyotos. Of course, it could support
> multiple users.
>
I found http://www.eros-os.org/, but I couldn't see any quick summary.
>
> > - What will the filesystem look like?
>
> File systems are figments of your imagination. If you need a file
> system, you may create one. But the OS doesn't need files to ensure
> persistence of the objects.5
>
Good point. But presumably there would be some global persistant
storage protocol?
>
> > - Would the system be Lisp all the way down?
>
> Yes.
>
>
> > - How would support for other languages be?
>
> Why? What for?
Not everybody loves Lisp :) I imagine there would be interoperability
layers so that the OS exposed a POSIX interface and Unix C programs
could be run.
Brad
"bradb" <··············@gmail.com> writes:
>> Why? What for?
> Not everybody loves Lisp :)
And people who don't love lisp would use lispos for what reason?
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
Pascal Bourguignon wrote:
> "bradb" <··············@gmail.com> writes:
>
> >> Why? What for?
> > Not everybody loves Lisp :)
>
> And people who don't love lisp would use lispos for what reason?
Because they just want an OS without caring about how it works - there
are plenty of Linux users who can't program in C.
Brad
On 28 Jun 2006 13:02:19 -0700, "bradb" <··············@gmail.com> wrote:
>
>Pascal Bourguignon wrote:
>> "bradb" <··············@gmail.com> writes:
>>
>> >> Why? What for?
>> > Not everybody loves Lisp :)
>>
>> And people who don't love lisp would use lispos for what reason?
>Because they just want an OS without caring about how it works - there
>are plenty of Linux users who can't program in C.
Thus the appeal of a specifically *Lisp* -based OS is really more
directly for developers, including application developers, wouldn't
you say?
And so, is this part of the thought experiment really a question
of "Lisp all the way down" or is it perhaps better to ask
"what design improvements can be made at the OS level to better
facilitate Lisp implementation"? The answer(s) may not necessarily
apply to Lisp alone.
--
Jack Unrue
Jack Unrue wrote:
> On 28 Jun 2006 13:02:19 -0700, "bradb" <··············@gmail.com> wrote:
>
> >
> >Pascal Bourguignon wrote:
> >> "bradb" <··············@gmail.com> writes:
> >>
> >> >> Why? What for?
> >> > Not everybody loves Lisp :)
> >>
> >> And people who don't love lisp would use lispos for what reason?
> >Because they just want an OS without caring about how it works - there
> >are plenty of Linux users who can't program in C.
>
> Thus the appeal of a specifically *Lisp* -based OS is really more
> directly for developers, including application developers, wouldn't
> you say?
True, from a developer's perspective the defining aspect of the OS is
that it is Lisp based. For a users that will not be the most important
thing.
>
> And so, is this part of the thought experiment really a question
> of "Lisp all the way down" or is it perhaps better to ask
> "what design improvements can be made at the OS level to better
> facilitate Lisp implementation"? The answer(s) may not necessarily
> apply to Lisp alone.
The reason that I asked about other languages is that Lisp may not be
the right tool for every job. Also, imagine the case where a popular
application is written for Windows in C, and the vendor decides that
the Lisp based OS now has enough market share to make a port
worthwhile. They will probably want a C compiler running on the
LispOS.
Going the other way (LispOS->Windows) may not be so hard, you just need
a LispOS compliant environment running on top of Windows.
Cheers
Brad
bradb schrieb:
Hallo
> The reason that I asked about other languages is that Lisp may not be
> the right tool for every job. Also, imagine the case where a popular
> application is written for Windows in C, and the vendor decides that
> the Lisp based OS now has enough market share to make a port
> worthwhile. They will probably want a C compiler running on the
> LispOS.
Not only C, there are so many others. You can make libs for converting
them all (one by one will be good for sellers), but what will be the
result of doing so? (assume a pyton to lisp, ouou)
> Going the other way (LispOS->Windows) may not be so hard, you just need
> a LispOS compliant environment running on top of Windows.
No. The Win-Clan is kind of monopolist. Don't feed enchant trolls.
Making a lisp-only-OS is good for lisp veterans. But to serve their
claims can be a pain to workout (and, they will create their own tools).
So what? Make another tool-packages first? And when you seem to finish,
the x86 is dead, hm?
stefan
tip (if allowed): do something to threads. (--> massive parallel)
Pascal Bourguignon <···@informatimago.com> wrote:
>"bradb" <··············@gmail.com> writes:
>
>>> Why? What for?
>> Not everybody loves Lisp :)
>
>And people who don't love lisp would use lispos for what reason?
Microsoft will force all manufacturers to deliver it with their
machines. ;)
Pascal Bourguignon wrote:
> "bradb" <··············@gmail.com> writes:
>
> >> Why? What for?
> > Not everybody loves Lisp :)
>
> And people who don't love lisp would use lispos for what reason?
Because developers flock to it for the advantages that they
see and write software for it and user merely follow the
software, not caring if it is writting in Lisp or klingon.
goose,
Pascal Bourguignon wrote:
> "bradb" <··············@gmail.com> writes:
<snipped>
> > - How would support for other languages be?
>
> Why? What for?
>
So that us users of LispOS won't have to rewrite
all the worlds software. I'd very much like to
retain the ability to call code that was written
in other languages; I see no benefit to being
mutually exclusive.
goose
From: Christopher C. Stacy
Subject: Re: What would a modern LispOS look like?
Date:
Message-ID: <yzlk670dlxh.fsf@OSX663.local>
"goose" <····@webmail.co.za> writes:
> Pascal Bourguignon wrote:
>> "bradb" <··············@gmail.com> writes:
>
> <snipped>
>
>> > - How would support for other languages be?
>>
>> Why? What for?
>>
>
> So that us users of LispOS won't have to rewrite
> all the worlds software. I'd very much like to
> retain the ability to call code that was written
> in other languages; I see no benefit to being
> mutually exclusive.
The benefit would be guarantees about that code never ever possibly
crashing or corrupting in certain ways, since some classses of buggy
failures are impossible on the Lisp Machine.
Christopher C. Stacy wrote:
> "goose" <····@webmail.co.za> writes:
>
> > Pascal Bourguignon wrote:
> >> "bradb" <··············@gmail.com> writes:
> >
> > <snipped>
> >
> >> > - How would support for other languages be?
> >>
> >> Why? What for?
> >>
> >
> > So that us users of LispOS won't have to rewrite
> > all the worlds software. I'd very much like to
> > retain the ability to call code that was written
> > in other languages; I see no benefit to being
> > mutually exclusive.
>
> The benefit would be guarantees about that code never ever possibly
> crashing or corrupting in certain ways, since some classses of buggy
> failures are impossible on the Lisp Machine.
Sure. Sadly, thats such a small benefit that its just not worth
eliminating other languages which are just as safe.
goose
Christopher C. Stacy wrote:
>
> The benefit would be guarantees about that code never ever possibly
> crashing or corrupting in certain ways, since some classses of buggy
> failures are impossible on the Lisp Machine.
Ah, the Lisp Machine must have had a static type system then....
From: Christopher C. Stacy
Subject: Re: What would a modern LispOS look like?
Date:
Message-ID: <yzl3bdkhf9g.fsf@OSX663.local>
"Joe Marshall" <··········@gmail.com> writes:
> Christopher C. Stacy wrote:
>>
>> The benefit would be guarantees about that code never ever possibly
>> crashing or corrupting in certain ways, since some classses of buggy
>> failures are impossible on the Lisp Machine.
>
> Ah, the Lisp Machine must have had a static type system then....
I can't hear you through all the static...
"bradb" <··············@gmail.com> writes:
> - How would seperation of privileges work? Multiple users/super user?
As Pascal Bourguignon said, EROS-like capabilities might be possible.
> - What will the filesystem look like?
Again, as Pascal said, there need not be a file system. There also
need not be any protocol for persistence provided that EROS-like
universal persistence is used. Everything would just be persistent by
default.
Actually, persistence might turn out to be a much easier problem than
I had initially thought. Just make sure you have a battery, and make
sure you save all memory to disk before shutdown.
> - How would support for other languages be?
One possibility would be to allow for programs written in unsafe
languages like C, to call such programs as Lisp functions, and to
remap the address space only then.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
"bradb" <··············@gmail.com> writes:
> - Would the system be Lisp all the way down?
I think this question would be better phrased as "what should be the
basic abstractions of the system?" What are the fundamental
assumptions that allow two unrelated units of software to live on the
same machine?
> - Would software be easy to distribute in binary form?
What are the good protocols for managing units of software? Install,
de-install, invoke, inspect, and other operations that users would be
interested in.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> "bradb" <··············@gmail.com> writes:
>
> > - Would the system be Lisp all the way down?
>
> I think this question would be better phrased as "what should be the
> basic abstractions of the system?" What are the fundamental
> assumptions that allow two unrelated units of software to live on the
> same machine?
That's a really good question. I would guess that unit of software
should expect to run in a thread of its own without worrying about
multithread issues. You should be able to load multiple units of
software (or instances of the same software) without getting accidental
interferance from each other.
Deliberately using/manipulating structures from another software unit
should be allowed. Some "core" functions should be protected. I don't
really know though.
Brad
Lisp Newbie, so take it easy on the flames :-)
bradb wrote:
<snipped>
> - What would the software ecosystem look like? Today applications
> have little reuse of parts and are written in C.
I beg to differ; looking around on my system, every non-trivial
(and even most of the trivial) programs reuse bits and pieces
(packaged into libraries).
I'd be happy if you could point out *one* thing in a common
*nix type OS that could be reused but isn't.
> - Would software be easy to distribute in binary form?
Corefiles? Compiled fasl?
> - How would seperation of privileges work? Multiple users/super user?
It *could* work pretty much the same way it works in *nix OSes; a
bitmap on each object sets the priviledges; bitmap for the owner,
another one for group and one more for "world". Object need not
be just a file so this will presumably work even better than the
current *nix bitmaps (which apply only to files).
> - What will the filesystem look like?
As others have replied, objects (and maybe object hierarchy?)
might work satisfactorily.
> - Would the system be Lisp all the way down?
Well,that at the lowest level, it is still just
opcodes; if the lisp compiler generates opcodes which
can be run directly by the hardware, then yes ... lisp
all the way down (this also makes it simpler to distribute
software in binary form) is certainly possible.
> - How would support for other languages be?
>
There would have to be some sort of linkage format; other
languages should just be able to link into the lisp
libraries (much like most languages can link ELF binaries).
> I was born the same year as the Lisp Machines, so I haven't seen this
> kind of environment before and I'm interested in it.
>
> My thoughts:
> The software ecosystem would be much the same as OSS is today, you can
> get source to lots of apps. I think the apps would generally be
> smaller in code and binary size because of the libraries that are
> already available from the OS. I would hope reuse would be higher
> among OSS, because of the nature of all Lisp code running in the same
> image.
There's this reuse thing again, which I don't understand. Reuse
is currently very high on systems written in C merely because
C is the lowest common denominator that other languages can talk
too. Only very new programmers actually roll their own
[zip|crc|gui|etc]
library when the default OS install gives you all of this. I assume
that these same libraries will be rewritten in Lisp for LispOS,
but thats not being "reusable" if LispOS can't (or won't) make
use of non-lisp code.
I fail to see how merely using a *language* gives one a better
metric on the reusability scale[1]. OTOH I have to say that
global reusability is not the most important thing, and perhaps
"local" reusability (reusability within a specific environment
or sets of environments) won't be decreased by switching the
OS language from C to Lisp.
>
> Support for other languages would probably be pretty good, after all
> you just need to compile to Lisp s-expressions and the LispOS can do
> the rest - though I bet there would be native compiling languages too.
>
> I'm interested in what people think about this, so please reply.
>
> Cheers
> Brad
[1] unless that language is C. Writing your spiffy tic-tac-toe-solving
library in plain std C means that it can be used on any platform that
has a conforming C compiler i.e. 99% of platforms. Those platforms that
don't have a C compiler most certainly won't have any other HLL
compiler
either and will be typically programmed in assembler or similar.
Writing that same logic into a library in most other languages limits
you to the platforms that have a compiler and/or environment for that
language.
Hence, I doubt that you would get *more* reusability with using
something
other than C; If reusability is by far the most important thing, don't
write it in C++, Lisp, Java, Python, Basic, Perl, C#, etc.
goose,
goose wrote:
> Lisp Newbie, so take it easy on the flames :-)
>
Sure - I'm a newbie too :)
> I fail to see how merely using a *language* gives one a better
> metric on the reusability scale[1]. OTOH I have to say that
> global reusability is not the most important thing, and perhaps
> "local" reusability (reusability within a specific environment
> or sets of environments) won't be decreased by switching the
> OS language from C to Lisp.
Ok, so *nix and C have very good reuse when it comes to libraries. But
that means that the useful functionality needs to be distilled out into
a library. I am imagining that in a Lisp based system would have all
code running in the same image - probably with boundries of seperation.
But two applications that are running can directly talk to each other
just by calling functions. So, for example you could write an editor
and any other application that needs editor functionality could easily
embed that editor inside itself. So Mozilla could use Emacs for all
its text entry. I don't see that happening very much at the moment.
The closest analogue that I can think of is how KDE shares components -
but the Lisp system could be many times tighter.
Also, C libraries need to be reused in a very specific way - the way
that the original designer thought of. With the LispOS you could
cherry-pick the functionality that you like, possibly shadowing
functions that you don't need.
Cheers
Brad
> Ok, so *nix and C have very good reuse when it comes to libraries. But
> that means that the useful functionality needs to be distilled out into
> a library. I am imagining that in a Lisp based system would have all
> code running in the same image - probably with boundries of seperation.
At the possible cost of sounding like a broken record: This is exactly
how the KnowOS works.
That said (and just to prove that I don't think that KnowOS is Cells
... i.e., the solution to all known problems :-) let me point out this
solution has significant difficulties as well, esp. in terms of
security and stability (if someone changes one of the tools out from
under you).
bradb wrote:
> goose wrote:
> > Lisp Newbie, so take it easy on the flames :-)
> >
> Sure - I'm a newbie too :)
>
Great, lets flame each other and get it over with :-)
> > I fail to see how merely using a *language* gives one a better
> > metric on the reusability scale[1]. OTOH I have to say that
> > global reusability is not the most important thing, and perhaps
> > "local" reusability (reusability within a specific environment
> > or sets of environments) won't be decreased by switching the
> > OS language from C to Lisp.
>
> Ok, so *nix and C have very good reuse when it comes to libraries. But
> that means that the useful functionality needs to be distilled out into
> a library.
That's normally the way it is, yes.
> I am imagining that in a Lisp based system would have all
> code running in the same image - probably with boundries of seperation.
With dynamically linked libraries, you can pretty much achieve the
same thing - a loaded library being used by process A is not reloaded
if another program wants to use that library, but there is a
boundry between the two processes (so that they don't step on each
other).
> But two applications that are running can directly talk to each other
> just by calling functions.
Two applications in any modern OS can do that too; they can request
data from each other, and execute code on each other. Hell, RPC means
that they can even execute code on different machine (not like *that's*
normally usefull without a load-balancer). LispOS will offer nothing
new in this regard.
> So, for example you could write an editor
> and any other application that needs editor functionality could easily
> embed that editor inside itself. So Mozilla could use Emacs for all
> its text entry. I don't see that happening very much at the moment.
It may not be happening at the moment, but it's perfectly possible
*and*
dead easy in addition to being simple and well-understood.
There are presumably reasons that it is not happening at the moment in
spite of being possible, easy and simple[1]. I don't see how switching
to a different language in which it is also possible, easy and simple
to achieve this makes those reasons go away.
IOW, the language is not what prevents this from happening; a different
language may not have much of an effect.
> The closest analogue that I can think of is how KDE shares components -
> but the Lisp system could be many times tighter.
>
> Also, C libraries need to be reused in a very specific way - the way
> that the original designer thought of.
Not really the point. Half the functionality (if not more) on my
system is because of entire programs that are reusable, not just
libraries. For example I have a program called bash (and
another one called echo) that lets me do the following:
for X in 1 2 3 4; do echo $X; done
I also have a program called find that lets bash use it as follows:
for X in `find .`; do echo processing $X; done
I have another program called basename that gets me the name of a file
without directory prefix and another one called cut that lets me get
the name of a file minus the extension like this:
for X in `find .`; do echo $X | basename | cut -f 1 -d .; done
I have yet another program called madplay that lets me use cut, echo,
find, basename and bash like so:
for X in `find .`; do
madplay $X -o `echo $X | basename | cut -f 1 -d .`.wav;
done
Unsurprisingly, I have a program called grep which lets me process
only the mp3 files:
for X in `find . | grep \.[Mm][Pp]3`; do
madplay $X -o `echo $X | basename | cut -f 1 -d .`.wav;
done
All the above programs work *together* (regardless of what language
they may be written in, its only luck that they are all written in
C) to allow me to transform all my mp3 files in the current and
subdirectories into wav files which can be copied to an audio CD.
I can very easily put all of the above into a file called
search_and_convert.sh and execute that everytime I need this
functionality.
I fail to see how a LispOS could improve so significantly on that that
"reusability" comes up as an advertising point, but I'm willing
to be open to examples in a hypothetical LispOS that cannot
be currently *easily* done in a *nix OS. The entire reason I
chose a *nix OS to compare to and not a windows OS is /because/
of the ease with which the components in (for example) a linux
distro can be extended or reused.
> With the LispOS you could
> cherry-pick the functionality that you like, possibly shadowing
> functions that you don't need.
>
I was able to do that above with complete programs. Once again,
I must state that the only thing that facilitates this regardless
of the language being used is the cluefulness of the developers.
Lisp has many advantages over other languages/platforms, but
I'd hardly classify "reusability" as one of it's strengths.
[1] I suspect that the reasons are because developers just
don't bother to design their programs like the way you described.
Using Lisp won't make this problem go away.
"goose" <····@webmail.co.za> writes:
> [1] unless that language is C. Writing your spiffy tic-tac-toe-solving
> library in plain std C means that it can be used on any platform that
> has a conforming C compiler i.e. 99% of platforms. Those platforms that
> don't have a C compiler most certainly won't have any other HLL
> compiler
> either and will be typically programmed in assembler or similar.
>
> Writing that same logic into a library in most other languages limits
> you to the platforms that have a compiler and/or environment for that
> language.
But given that most other programming languages have at least one
implementation written in C, they're actually available on 98.999% of
the platforms too!
--
__Pascal Bourguignon__ http://www.informatimago.com/
PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
Pascal Bourguignon wrote:
> "goose" <····@webmail.co.za> writes:
>
> > [1] unless that language is C. Writing your spiffy tic-tac-toe-solving
> > library in plain std C means that it can be used on any platform that
> > has a conforming C compiler i.e. 99% of platforms. Those platforms that
> > don't have a C compiler most certainly won't have any other HLL
> > compiler
> > either and will be typically programmed in assembler or similar.
> >
> > Writing that same logic into a library in most other languages limits
> > you to the platforms that have a compiler and/or environment for that
> > language.
>
> But given that most other programming languages have at least one
> implementation written in C, they're actually available on 98.999% of
> the platforms too!
>
You're possibly confusing hosted c platforms with
freestanding ones. AFAIK (corrections welcome:-), it's not
possible to have this distinction in a conforming common
lisp implementation, hence "other programming languages
implemented in C" rules out those that are implemented
only in a hosted c environment.
tic-tac-toe written in C can target freestanding
C implementations (all the worlds machines?) while
tic-tac-toe written in another HLL which has an
implementation in hosted C will only run on a small
subset of the computers in the world.
This is all conjecture that assumes that common lisp (the
standard) does indeed have no equivalent of a C freestanding
environment.
FWIW, I don't know of any languages implemented within
a freestanding c environment, but like I said above,
correct me if I'm wrong.
goose,
bradb wrote:
> This is really just a thought experiment, what would a modern,
> semi-mainstream Lisp based OS look like today? Let's assume that the
> hardware is mainstream x86 and our hypothetical LispOS occupies a
> position similar to that of Linux.
> - What would the software ecosystem look like? Today applications
> have little reuse of parts and are written in C.
> - Would software be easy to distribute in binary form?
> - How would seperation of privileges work? Multiple users/super user?
> - What will the filesystem look like?
> - Would the system be Lisp all the way down?
> - How would support for other languages be?
>
> I was born the same year as the Lisp Machines, so I haven't seen this
> kind of environment before and I'm interested in it.
>
> My thoughts:
> The software ecosystem would be much the same as OSS is today, you can
> get source to lots of apps. I think the apps would generally be
> smaller in code and binary size because of the libraries that are
> already available from the OS. I would hope reuse would be higher
> among OSS, because of the nature of all Lisp code running in the same
> image.
>
> Support for other languages would probably be pretty good, after all
> you just need to compile to Lisp s-expressions and the LispOS can do
> the rest - though I bet there would be native compiling languages too.
>
> I'm interested in what people think about this, so please reply.
Okay, now this may be pretty silly, but I'll just come out with it anyway.
I think a lisp OS could actually be really fun for people who like
hacking on operating systems. After all, if the entire operating system
is running in a lisp image then shouldn't you be able to let root access
modify the image during runtime? You can do this in general with lisp
programs so I can't see why an operating system should be different.
Now do you really *want* to be able to hack on the operating system and
change it on the fly? I'm not sure, but with some safeguards built in I
think it could be a fun experiment.
> I think a lisp OS could actually be really fun for people who like
> hacking on operating systems. After all, if the entire operating system
> is running in a lisp image then shouldn't you be able to let root access
> modify the image during runtime? You can do this in general with lisp
> programs so I can't see why an operating system should be different.
> Now do you really *want* to be able to hack on the operating system and
> change it on the fly? I'm not sure, but with some safeguards built in I
> think it could be a fun experiment.
Well, first off, as usual, let me say that: (a) you can do this just as
you describe it in the KnowOS, but (b) please don't! [At least not on
our public servers.] That said, (c) you can probably do this in Linux
as well if you know what you're doing. (If there's some memory state
that needs to be rebuilt, then you might have to reboot, but the same
is true for any program, incl. an OS which, afterall, is just a hairy
program!)