http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> wrote in message news:<··············@intech19.enhanced.com>...
> http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
There are no serious difficulties in using C++ in the Linux kernel.
It's not clear what point you are trying to make here.
For a while some years ago, the kernel was even compilable with g++.
If your point is that Lisp hackers should be challenged into bringing
Lisp into the kernel, take a look at this:
http://vxe.quercitron.com/Overview/overview.html
``VXE description (VXED) is small LISP program (set of functions)
which use declarative description of acceptable parameters for
different system calls. This VXED loaded to the kernel, controls
system calls parameters from the specified subsystem. So VXEDs are
dynamically loadable modules, handled by the small LISP interpreter,
inserted into the kernel.''
Also, look for something called Movitz, a new project to develop a
Lisp kernel running on bare hardware.
http://common-lisp.net/project/movitz/movitz.html
Camm Maguire wrote:
>
http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
Uhm, it's an article about C++. In the kernel.
This is not comp.lang.c++ or anything halfway similar, so why did you post
it? I'm honestly curious.
Greetings!
Svein Ove Aas <·········@aas.no> writes:
> Camm Maguire wrote:
>
> >
> http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
>
>
> Uhm, it's an article about C++. In the kernel.
>
> This is not comp.lang.c++ or anything halfway similar, so why did you post
> it? I'm honestly curious.
I just admired the initiative that partisans of c++ demonstrated in
reducing the overhead of their favorite features in their favorite
language, features which have close analogs in lisp (e.g. dynamic type
checking, etc.), and in the Linux kernel no less. Perhaps lisp on
Linux could benefit from support at this level?
Take care,
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire wrote:
> Greetings!
>
> Svein Ove Aas <·········@aas.no> writes:
>
>> Camm Maguire wrote:
>>
>> >
>>
http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
>>
>>
>> Uhm, it's an article about C++. In the kernel.
>>
>> This is not comp.lang.c++ or anything halfway similar, so why did you
>> post it? I'm honestly curious.
>
> I just admired the initiative that partisans of c++ demonstrated in
> reducing the overhead of their favorite features in their favorite
> language, features which have close analogs in lisp (e.g. dynamic type
> checking, etc.), and in the Linux kernel no less. Perhaps lisp on
> Linux could benefit from support at this level?
>
Oh, I see.
I must admit that personally I got stuck in disbelief at the possibility of
C++ being used in the kernel, considering the complexities (and not good
ones) in that language. Not that it isn't a good language in its domain, I
just don't think the kernel is that domain.
Of course, if what they're actually using is a proper subset of C++, then
those selfsame complexities don't really matter at all - nothing's forcing
them to implement the entire language, which, in fact, they aren't.
Sorry for misunderstanding. Maybe next time you could include the subject in
the message body, though, since I didn't see it.
As for the subject of Lisp in the kernel, well...
A few other projects have already been pointed out, and there was indeed a
push to include a Lisp a few months back. Didn't go anywhere, but I'd like
to point to Movitz as an example that Lisp doesn't merely work in the
kernel peripheries, but can in fact make up the whole thing.
Camm Maguire <····@enhanced.com> writes:
> http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
A couple of Google searches produce these:
<http://www.abstractnonsense.com/schemix/>,
<http://vxe.quercitron.com/>.
On Thu, 28 Oct 2004 16:31:05 +0100, Bruce Stephens wrote:
> Camm Maguire <····@enhanced.com> writes:
>
>> http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
>
> A couple of Google searches produce these:
> <http://www.abstractnonsense.com/schemix/>,
Heh, yeah, that was my "I've just been laid off" project. I sometimes
almost wish I had been unemployed longer so that I could have spent more
time working on it... on the other hand, being unemployed did *really*
suck.
Cheers,
Bill.
--
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." -- Guy Steele
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> Camm Maguire <····@enhanced.com> writes:
>
> > http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
>
> A couple of Google searches produce these:
> <http://www.abstractnonsense.com/schemix/>,
> <http://vxe.quercitron.com/>.
Yes, the question is why C++ in the kernel comes years after Lisp in the kernel?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Greetings!
Pascal Bourguignon <····@mouse-potato.com> writes:
> Bruce Stephens <············@cenderis.demon.co.uk> writes:
>
> > Camm Maguire <····@enhanced.com> writes:
> >
> > > http://developers.slashdot.org/developers/04/10/27/2110228.shtml?tid=156&tid=190&tid=106
> >
> > A couple of Google searches produce these:
> > <http://www.abstractnonsense.com/schemix/>,
> > <http://vxe.quercitron.com/>.
>
> Yes, the question is why C++ in the kernel comes years after Lisp in the kernel?
>
I just scanned these projects, but, to my admittedly crude
understanding, the point is not being able to write kernel stuff in
language foo, but rather to have the kernel be intelligent when
running compiled and optimized user space code in language foo.
Does the like exist for lisp?
Take care,
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> Voting Democrat or Republican is like choosing a cabin in the Titanic.
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> writes:
[...]
> I just scanned these projects, but, to my admittedly crude
> understanding, the point is not being able to write kernel stuff in
> language foo, but rather to have the kernel be intelligent when
> running compiled and optimized user space code in language foo.
That's not my understanding of the projects. The C++ one is to allow
parts of the kernel, in particular loadable modules (I guess, anyway),
to be written in C++ (probably a slightly limited C++).
The others (the lispy ones) just build in interpreters together with
some convenient bindings to that one can play around with things from
lisp. I think one uses a form of lisp as its configuration language.
So neither seem to be about user space at all, unless I misunderstood
the projects.
> Does the like exist for lisp?
Not that I know of. What kinds of things could a kernel provide that
would be useful for lisp?
[...]
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> > Does the like exist for lisp?
http://www.abstractnonsense.com/schemix/
As I wrote, yes, for a long time. The question still is why C++
support in kernel comes so late?
> Not that I know of. What kinds of things could a kernel provide that
> would be useful for lisp?
http://www.abstractnonsense.com/schemix/faq.html
--
__Pascal Bourguignon__
Pascal Bourguignon <····@mouse-potato.com> writes:
> Bruce Stephens <············@cenderis.demon.co.uk> writes:
[...]
>> Not that I know of. What kinds of things could a kernel provide
>> that would be useful for lisp?
>
> http://www.abstractnonsense.com/schemix/faq.html
That's kernel space:
* How does Schemix work?
Schemix is implemented entirely in kernel space. [...]
The question was about user space:
Camm Maguire <····@enhanced.com> writes:
> I just scanned these projects, but, to my admittedly crude
> understanding, the point is not being able to write kernel stuff in
> language foo, but rather to have the kernel be intelligent when
> running compiled and optimized user space code in language foo.
Bruce Stephens <············@cenderis.demon.co.uk> writes:
> Pascal Bourguignon <····@mouse-potato.com> writes:
>
> > Bruce Stephens <············@cenderis.demon.co.uk> writes:
>
> [...]
>
> >> Not that I know of. What kinds of things could a kernel provide
> >> that would be useful for lisp?
> >
> > http://www.abstractnonsense.com/schemix/faq.html
>
> That's kernel space:
>
> * How does Schemix work?
> Schemix is implemented entirely in kernel space. [...]
>
> The question was about user space:
>
> Camm Maguire <····@enhanced.com> writes:
> > I just scanned these projects, but, to my admittedly crude
> > understanding, the point is not being able to write kernel stuff in
> > language foo, but rather to have the kernel be intelligent when
> > running compiled and optimized user space code in language foo.
Either I understood the contrary or somebody else did.
The OP cited a URL that leads to:
C++ In The Linux kernel
^^
Programming
Operating Systems
Linux
Posted by timothy on Wednesday October 27, @05:47PM
from the kitchen-sink-and-jacuzzi dept.
An anonymous reader submits "A researcher at Reykjavik University
Network Laboratory (netlab.ru.is) has just released a Linux patch
allowing for complete kernel-level run-time support for C++ in the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^
Linux kernel, including exceptions, dynamic type checking and global
^^^^^^^^^^^^
objects (with constructors and destructors) The implementation is
based on the C++ ABI in GNU g++, but contains various kernel level
optimizations, that reduces the cost of throwing exceptions by an
order of magnitude, thus making C++ exceptions viable in several
scenarios. Furthermore, the Linux module loader is extended to handle
weak symbols in C++, so that dynamic type checking is reduced to a
pointer comparison, in contrast to string comparison."
I don't see what the kernel could do more to help the programs be
programs. What intelligence do you want the kernel to show when
running compiled and optimized code in any language?
I could imagine a multi-processor system where the kernel would try,
analyzing the *compiled and optimized user space code in language
foo*, to guess what will be the next syscall with what argument and
try to perform it before it occurs to optimize time. Or perhaps, it
could try to guess that such and such page won't be used anymore
despite the fact that the user space process did not call munmap, and
throw away the data to optimize space. Is that what you want?
--
__Pascal Bourguignon__
Pascal Bourguignon wrote:
> I don't see what the kernel could do more to help the programs be
> programs. What intelligence do you want the kernel to show when
> running compiled and optimized code in any language?
Some possibilities:
- Tight integration of the VM subsystem with the garbage collector.
- System calls that accept and return values of a rich set of
types, rather than coercing everything into C-like strings,
small integers and simple structures.
- A richer model of persistent storage than the traditional
bag-o'-byte filesystem.
- An IPC mechanism better suited to high-level languages.
I don't claim that all (or even any) of these are good things,
let alone worth the trouble to do. Some of them I've described
vaguely and may not even make sense when examined closely :-).
But I don't think any of them can be rejected out of hand, so
it's far from obvious (to me) that there's nothing that could
be done to make the kernel more friendly to compiled code in
high-level languages such as Lisp.
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> writes:
> Pascal Bourguignon wrote:
>
> > I don't see what the kernel could do more to help the programs be
> > programs. What intelligence do you want the kernel to show when
> > running compiled and optimized code in any language?
>
> Some possibilities:
>
> - Tight integration of the VM subsystem with the garbage collector.
> - System calls that accept and return values of a rich set of
> types, rather than coercing everything into C-like strings,
> small integers and simple structures.
> - A richer model of persistent storage than the traditional
> bag-o'-byte filesystem.
> - An IPC mechanism better suited to high-level languages.
Implement all of that and you don't have a unix system anymore. Fancy
a Lisp Machine?
> I don't claim that all (or even any) of these are good things,
> let alone worth the trouble to do. Some of them I've described
> vaguely and may not even make sense when examined closely :-).
> But I don't think any of them can be rejected out of hand, so
> it's far from obvious (to me) that there's nothing that could
> be done to make the kernel more friendly to compiled code in
> high-level languages such as Lisp.
You know, the kernel is not even friendly to C. They too have to
provide a library to interface C-friendly with syscalls...
--
__Pascal Bourguignon__
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Challenge for lisp lovers....
Date:
Message-ID: <87k6t3403o.fsf@qrnik.zagroda>
Gareth McCaughan <················@pobox.com> writes:
>> I don't see what the kernel could do more to help the programs be
>> programs. What intelligence do you want the kernel to show when
>> running compiled and optimized code in any language?
>
> Some possibilities:
>
> - Tight integration of the VM subsystem with the garbage collector.
It would be interesting. I don't view this as a fault of people
working on the kernel though. Is it really known how it should look
like, to be not tied to a single HLL implementation (Lisp Machines
don't count because of this)? Is there some research on this?
> - System calls that accept and return values of a rich set of
> types, rather than coercing everything into C-like strings,
> small integers and simple structures.
What types? More complicated types means harder interoperability
with other languages. There is no chance that a structured type
with pointers would match the representation demanded by a random
implementation of a HLL.
For example currently a file size is reported in 64 bits (if I use
a modern API). I can translate it to my representation of fixnums +
bignums which use my favourite bignum library. If it was represented
as typical to Lisp implementations, i.e. a tagged union of fixnums
and some representation of bignums, conversion would be harder, not
easier, especially in the bignum case. Unless the representation
already matched exactly, but this would be unlikely. Or do you say
that all languages must use the same bignum representation? Which one?
Richer types would only be an advantage if all HLL implementations
decided on a common runtime, like .NET is trying to do. I don't
believe people are able to design a universal runtime suitable for
diverse languages, especially one which will not become obsolete in 10
years. .NET itself is good for C# but poorly suited for dynamically
typed languages (you can't have a sensible tagged union of fixnums and
bignums, you would have to keep fixnums on the heap). I'm afraid C is
better for implementing their runtimes. The C-based Unix API has 30
years and is still alive. It undergoes evolution, like adding switches
to enable 64-bit file offsets, but it does not change the level of
abstraction. People didn't invent a sufficiently universal runtime
yet. Forcing an ill-suited runtime would be worse than allowing to
implement them in the low level.
> - A richer model of persistent storage than the traditional
> bag-o'-byte filesystem.
Which model would be better? The power of the bag-o'-byte mechanism
is that it's not trying to constrain the structure of files. It means
that other protocols are built on top of it, they don't need to
replace it in case some predesigned structure was ill-suited for
a particular problem.
> - An IPC mechanism better suited to high-level languages.
Which mechanism? CORBA? SOAP? Anyway, they are user-level, built on
top of kernel-level streams of bytes, which I consider a good thing.
The higher level protocols come and pass away, and the underlying
mechanisms of transferring bytes don't need to be replaced every 10
years. I see no gain in putting higher level protocols in the kernel.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Gareth McCaughan <················@pobox.com> writes:
>
>>> I don't see what the kernel could do more to help the programs be
>>> programs. What intelligence do you want the kernel to show when
>>> running compiled and optimized code in any language?
>>
>> Some possibilities:
>>
>> - Tight integration of the VM subsystem with the garbage collector.
>
> It would be interesting. I don't view this as a fault of people
> working on the kernel though. Is it really known how it should look
> like, to be not tied to a single HLL implementation (Lisp Machines
> don't count because of this)? Is there some research on this?
If anyone was saying that the absence of any of those things
is "a fault of people working on the kernel", then I missed it.
I don't know what research there is. What there is is probably
in Lisp machines, though.
In response to the other things I mentioned, Marcin has
asked some interesting questions. Before I try to answer
them, I'd just like to quote something I wrote in the
grandparent of this article that got snipped:
| I don't claim that all (or even any) of these are good things,
| let alone worth the trouble to do. Some of them I've described
| vaguely and may not even make sense when examined closely :-).
>> - System calls that accept and return values of a rich set of
>> types, rather than coercing everything into C-like strings,
>> small integers and simple structures.
>
> What types? More complicated types means harder interoperability
> with other languages. There is no chance that a structured type
> with pointers would match the representation demanded by a random
> implementation of a HLL.
The question was: "What kinds of things could a kernel
provide that would be useful for Lisp?". If the kernel
provides something that's useful for implementations of
Lisp targeted at that kernel, that's enough to be an
answer to the question, even if it's not also useful
for a random implementation of a random language.
(Why worry about *random* implementations, anyway? Do
people generally write language implementations at random?
If some OS kernel provided features that made it possible
to make better Lisp implementations, then authors of
Lisp implementations could adjust the implementations
to use the kernel's features.)
> For example currently a file size is reported in 64 bits (if I use
> a modern API). I can translate it to my representation of fixnums +
> bignums which use my favourite bignum library. If it was represented
> as typical to Lisp implementations, i.e. a tagged union of fixnums
> and some representation of bignums, conversion would be harder, not
> easier, especially in the bignum case. Unless the representation
> already matched exactly, but this would be unlikely. Or do you say
> that all languages must use the same bignum representation? Which one?
The question was: what could a kernel provide that would
be useful for Lisp? If using bignums for file sizes were
a win (which it's not clear that it would be) then that
feature, if done right, could be useful to people implementing
Lisp on that platform.
It might, indeed, make life harder for users of other
languages. That would, indeed, be a reason not to do it.
But suppose you didn't care about any language other than
Lisp; then it's pretty clear that you can make a better
OS kernel *for use with Lisp* -- that's what the Lisp
machines had, and there's every indication that it worked
very nicely for them.
> Richer types would only be an advantage if all HLL implementations
> decided on a common runtime, like .NET is trying to do. I don't
> believe people are able to design a universal runtime suitable for
> diverse languages, especially one which will not become obsolete in 10
> years.
I agree.
> .NET itself is good for C# but poorly suited for dynamically
> typed languages (you can't have a sensible tagged union of fixnums and
> bignums, you would have to keep fixnums on the heap).
It's not *that* bad for dynamic languages. There's an
implementation of Python on top of the .NET virtual machine
that runs appreciably faster than the implementation in C.
Which isn't all that surprising, and doesn't indicate that
you could build a really good Lisp implementation on .NET,
but (as I say) it's not all *that* bad.
>> - A richer model of persistent storage than the traditional
>> bag-o'-byte filesystem.
>
> Which model would be better? The power of the bag-o'-byte mechanism
> is that it's not trying to constrain the structure of files. It means
> that other protocols are built on top of it, they don't need to
> replace it in case some predesigned structure was ill-suited for
> a particular problem.
Sure. But there's a cost to doing that. For instance,
the OS doesn't know much about what you're keeping in
that bag o' bytes, which may hamper its ability to
do a good job of cacheing and/or prefetching useful
things.
Again, the bag o'bytes may in fact be exactly the optimal
abstraction for a filesystem given the limitation of our
ability to foresee what others will invent. But it's not
clear that it is. Especially, again, if for some reason
we're only interested in the question "how good can we
make this for Lisp?".
>> - An IPC mechanism better suited to high-level languages.
>
> Which mechanism? CORBA? SOAP?
Dunno.
> Anyway, they are user-level, built on
> top of kernel-level streams of bytes, which I consider a good thing.
So I gather :-). And you may well be right. But it's not
obvious that you are.
> The higher level protocols come and pass away, and the underlying
> mechanisms of transferring bytes don't need to be replaced every 10
> years. I see no gain in putting higher level protocols in the kernel.
I think it's clear that there are gains. The question is
whether the (equally clear) losses outweigh them.
--
Gareth McCaughan
.sig under construc
From: Marcin 'Qrczak' Kowalczyk
Subject: Re: Challenge for lisp lovers....
Date:
Message-ID: <87lldih246.fsf@qrnik.zagroda>
Gareth McCaughan <················@pobox.com> writes:
> If using bignums for file sizes were a win (which it's not clear
> that it would be)
It's clearly a win to be able to represent offsets larger than 2GB
on 32-bit machines. I assumed that a Lisp on a 32-bit machine would
represent all integers which don't fit in 32 bits (minus tag) as
bignums, instead of as unboxed 64-bit values like C, because it's
easier to pass to code which doesn't know types statically. OTOH in C
it's clearly better to use a fixed-size arithmetic type, as long as
its size suffices. So we have different representations to match.
I claim that the "low level, C specific" representation makes more
sense in an OS interface, because it is easier to adapt to whatever
representation of numbers a particular language implementation uses.
A representation better suited for Lisp would be better only if most
languages in the system used the same representation of numbers.
A more constraining implementation would have to be extremely well
engineered to pay off.
> It might, indeed, make life harder for users of other languages.
> That would, indeed, be a reason not to do it. But suppose you didn't
> care about any language other than Lisp;
Sorry, I do care about other languages. I don't believe that a desktop
computer system (i.e. with a wide spectrum of applications) which
promotes a single language at the cost of putting all other languages
at a disadvantage would survive (except perhaps if made by a firm as
strong as Microsoft). Lisp Machines were almost tied to a single
language and did not survive.
You could argue that Unix is tied to C. Well, many languages have
their runtimes implemented in C because C is so low level, because
it puts few constraints on data representation, memory management,
dynamic type system, implementation of threads, implementation of
exceptions - precisely because it does not provide its own. Thus these
runtimes are free to experiment with e.g. novel GC algorithms, and
they have a common language to talk to the OS.
If the OS or some common runtime provides something, it is an
advantage only as long as it's very flexible, adaptable to needs of
the whole spectrum of languages. IMHO .NET tries to provide a bit too
much. Microsoft doesn't care that languages have to be changed in
order to be ported to .NET, and that they will have trouble deciding
whether immutable UTF-16 strings with a particular choice of methods
is exactly what they want their string type to be mapped to, or a
custom class must be used which will make interoperability harder.
In C at least all languages have equal disadvantage :-)
Microsoft doesn't care about other languages. For standalone, compiled
applications, it really cares only about C# and Visual Basic, where C#
was designed to fit .NET, and VB has been changed to fit .NET. It can
afford to not care because it's big and rich, and can force enough
people to use languages it chooses for them.
Now you would want to do the same, but with Lisp in the place of C#.
Implementors of all other languages would have to stand on their heads
in order to fit them to the world tuned for Lisp. Sorry, it will not
work if you are not Microsoft :-)
> that's what the Lisp machines had, and there's every indication that
> it worked very nicely for them.
And they did not survive!
> It's not *that* bad for dynamic languages. There's an implementation
> of Python on top of the .NET virtual machine that runs appreciably
> faster than the implementation in C.
Because the C implementation of Python is *very* slow, even compared
implementations of Perl and Ruby. It could be faster. Guido must have
other priorities.
GC could be faster (it uses reference counting). Exceptions could be
faster (it uses explicit NULL check after each function). Ints could
be faster (hey, I just noticed that in December 2002 they finally
started allocating their 105 preallocated ints eagerly, rather than
lazily, thus saving a conditional on *every* return of a computed int).
Method invocation could be tried to be made faster (I don't know
where it spends most of the time, but I recall it has been reported
to be surprisingly slow). Common operations like arithmetic could be
specialized for types like ints, leaving the generic dispatch for
other cases.
Indeed, .NET is good if you don't try hard enough to beat it,
especially if you don't have resources to tune everything and at
the same time care for functionality. With .NET you don't have
much choice.
Maybe I'm wrong and since demands from the runtime are so big these
days (a good GC, threads, shared libraries, dynamic compilation etc.),
only big companies are able to implement them well, and thus advantages
of using a generic runtime are larger than disadvantages of being
forced to fit our language into a world designed for statically typed
OO languages with a particular standard library. Time will tell.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
On Thu, 04 Nov 2004 01:47:05 +0100, Kowalczyk wrote:
> Microsoft doesn't care about other languages. For standalone, compiled
> applications, it really cares only about C# and Visual Basic, where C#
> was designed to fit .NET, and VB has been changed to fit .NET. It can
> afford to not care because it's big and rich, and can force enough
> people to use languages it chooses for them.
Much as I dislike Microsoft, since when do they /force/ anyone to do
anything?
I don't use MS software, and I haven't yet had the Microsoft Police
show up threatening to do me harm. Never heard of anyone who has.
>> that's what the Lisp machines had, and there's every indication that
>> it worked very nicely for them.
> And they did not survive!
But not because they used Lisp.
--
Let me control a planet's oxygen supply and I don't care who makes the
laws.
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Marcin Kowalczyk wrote:
[I said:]
> > If using bignums for file sizes were a win (which it's not clear
> > that it would be)
>
> It's clearly a win to be able to represent offsets larger than 2GB
> on 32-bit machines.
[etc]
Oh yes, of course. What I mean is simply that I'm inclined to
agree that for this particular use a fixed-size type is probably
more appropriate.
> > It might, indeed, make life harder for users of other languages.
> > That would, indeed, be a reason not to do it. But suppose you didn't
> > care about any language other than Lisp;
>
> Sorry, I do care about other languages.
Well, duh, so do I. Did you perhaps forget that the original
question was "what could a kernel do to make things better
for Lisp programs?"?
> I don't believe that a desktop
> computer system (i.e. with a wide spectrum of applications) which
> promotes a single language at the cost of putting all other languages
> at a disadvantage would survive (except perhaps if made by a firm as
> strong as Microsoft). Lisp Machines were almost tied to a single
> language and did not survive.
It is not at all clear that the downfall of Lisp machines
had anything much to do with the fact that they were designed
primarily to run Lisp, or even with the fact that they
were designed primarily to run a single language.
> You could argue that Unix is tied to C. Well, many languages have
> their runtimes implemented in C because C is so low level, because
> it puts few constraints on data representation, memory management,
> dynamic type system, implementation of threads, implementation of
> exceptions - precisely because it does not provide its own. Thus these
> runtimes are free to experiment with e.g. novel GC algorithms, and
> they have a common language to talk to the OS.
Sure. And the null operating system offers even more freedom
to programs. :-)
In other words: I agree that an OS that provides rich services
at the expense of tying down how everything has to work can be
constraining; but, contrariwise, an OS that provides impoverished
services so as not to tie anything down can be a pain, too. It
happens that the OSes that are currently dominant mostly occupy
similar places on this continuum; I don't think it's at all clear
that other places (in either direction) aren't better.
> Now you would want to do the same, but with Lisp in the place of C#.
This is not true. I've made it as clear as I know how to make it
that I am *not* saying that any of the things I mentioned would
actually be good ideas overall. Let me quote *again* what I said:
| I don't claim that all (or even any) of these are good things,
| let alone worth the trouble to do. Some of them I've described
| vaguely and may not even make sense when examined closely :-).
(Having now posted that three times, I am beginning to wish
that I'd taken more trouble to phrase it more elegantly. Oh well.)
I am saying *only* that they are features (or vague adumbrations
of possible features) that might make life better for Lisp
programs. Nothing more than that.
> > that's what the Lisp machines had, and there's every indication that
> > it worked very nicely for them.
>
> And they did not survive!
See above.
> > It's not *that* bad for dynamic languages. There's an implementation
> > of Python on top of the .NET virtual machine that runs appreciably
> > faster than the implementation in C.
>
> Because the C implementation of Python is *very* slow, even compared
> implementations of Perl and Ruby. It could be faster. Guido must have
> other priorities.
The C implementation of Python is not in fact much slower
than those of Perl and Ruby. (I'm fairly sure this is true
for Perl, at least; less sure about Ruby.)
[SNIP: litany of ways the Python implementation could be faster]
Yep, it certainly could, although (as I say) I'm not sure
it's as slow as you think it is.
> Maybe I'm wrong and since demands from the runtime are so big these
> days (a good GC, threads, shared libraries, dynamic compilation etc.),
> only big companies are able to implement them well, and thus advantages
> of using a generic runtime are larger than disadvantages of being
> forced to fit our language into a world designed for statically typed
> OO languages with a particular standard library. Time will tell.
Yes.
--
Gareth McCaughan
.sig under construc
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Gareth McCaughan <················@pobox.com> writes:
>
>> - Tight integration of the VM subsystem with the garbage collector.
>
> It would be interesting. I don't view this as a fault of people
> working on the kernel though. Is it really known how it should look
> like, to be not tied to a single HLL implementation (Lisp Machines
> don't count because of this)? Is there some research on this?
Yes. Let the process intercede before some pages are swapped out, or let
it choose which ones get swapped out, or let the process know beforehand
that there is some memory pressure, so you should start GCing now to
reduce that pressure.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist