I'm developing a small operating system and want to do something very
neat on it with Lisp: I want to have an interpreter/compiler/both for a
small Lisp dialect that will work with only enough OS support to run a
text terminal, I want the capability to build it up to a normal Common
Lisp, Scheme, or other "normal" Lisp, and I want to make the interpreter
the actual shell for the system.
What I'm wondering is how to go about this. Are there any dialects
already useful in a situation like this? I'd like to reuse as much of
my own and other people's code as possible here, because progamming an
entirely new Lisp interpreter from scratch will bore the heck out of me.
The operating system features the interpreter will have access to are
extensible data segment (sbrk() or the like for a heap); inter-process
communication; standard input, output and error; multithreading; and
timers. From these it will be possible to build up things like
filesystem or networking support, but they shouldn't be required parts
of the interpreter since someone might want to write the filesystem or
networking support in Lisp ;-).
For the shell feature, I'm looking at how Scsh handles this. I was
thinking about shells to port and thought "all a shell does is take it's
first token off the command line, treat it as a program and run that
program with the other tokens as arguments, printing the output." Then
it hit me that by making standard output the "primary value" and
standard error and the numerical error code "secondary values" shell
commands could be treated like Lisp functions. From there the idea of
using a Lisp interpreter as a shell, with programs treated as functions,
was obvious.
Appreciating the knowledge and flamewars that shall engulf this thread,
Eli Gottlieb
bradb wrote:
> Are you aware of Movitz? http://common-lisp.net/project/movitz/
>
> Brad
>
Movitz is for bare metal, right? So I guess I could take off some of
the top layers of Movitz code and port them to run on my kernel.
Still, I don't want to see this thread die here.
Eli Gottlieb wrote:
> I'm developing a small operating system and want to do something very
> neat on it with Lisp: I want to have an interpreter/compiler/both for a
> small Lisp dialect that will work with only enough OS support to run a
...
> For the shell feature, I'm looking at how Scsh handles this. I was
> thinking about shells to port and thought "all a shell does is take it's
> first token off the command line, treat it as a program and run that
> program with the other tokens as arguments, printing the output." Then
> it hit me that by making standard output the "primary value" and
> standard error and the numerical error code "secondary values" shell
> commands could be treated like Lisp functions.
I don't want to divert this into a Lisp OS pipe dream discussion, but
what you are describing here with numerical error codes (and even shell
commands, actually) is very much a UNIX design. Common Lisp has a great
condition system, you should consider using it, or, if you want UNIX,
run a UNIX-based Lisp.
> From there the idea of
> using a Lisp interpreter as a shell, with programs treated as functions,
> was obvious.
··············@hotmail.com wrote:
> I don't want to divert this into a Lisp OS pipe dream discussion, but
> what you are describing here with numerical error codes (and even shell
> commands, actually) is very much a UNIX design. Common Lisp has a great
> condition system, you should consider using it, or, if you want UNIX,
> run a UNIX-based Lisp.
The numerical error codes would come from "functions" which were
actually external programs. Though perhaps creating a condition that
went off on a non-success error code...
Anyway, native Lisp functions would behave like they always do.
Eli Gottlieb wrote:
> ··············@hotmail.com wrote:
> > I don't want to divert this into a Lisp OS pipe dream discussion, but
> > what you are describing here with numerical error codes (and even shell
> > commands, actually) is very much a UNIX design. Common Lisp has a great
> > condition system, you should consider using it, or, if you want UNIX,
> > run a UNIX-based Lisp.
> The numerical error codes would come from "functions" which were
> actually external programs. Though perhaps creating a condition that
> went off on a non-success error code...
Exactly: you need to clarify what you mean by "running an external
program" vs. "calling a Lisp function." Why are they different, and if
they are different, exactly how?
External programs might be blocks which you want to restrict in some
way; e.g., guaranteed not to see or stomp on your memory, or only in
certain ways, or sharing memory in a copy-on-write fashion, perhaps
with a different level of priveleges in accessing machine resources or
making "system calls" (whatever those would be), etc., etc., etc.
Your (run-external-program blah) feature in Lisp could raise conditions
including cases where your external-program violated some OS
restriction or exceeded priveleges, or whatever. In which case, that
abnormal condition is passed back to the calling run-external-program
function in a way that is checked, and then run-external-program is
defined to raise a condition.
Or, these kinds of violations could *automatically* raise Lisp
conditions, and your OS "signals" through the same underlying
mechanism. In which case it would be nice to have a
run-external-program feature which handles the conditions by something
like ignore-errors, and returns a simple flag for success or failure.
Basically, you have to think like an OS designer: what are the things
doing work, how do they use system resources, and how do these
process/threads/tasks/whatever launch each other, communicate with one
another, share resources, etc., etc. Then, you have to determine how
many of these things are expressed as part of your Lisp implementation,
and how the other things are expressed in Lisp.
··············@hotmail.com wrote:
> Eli Gottlieb wrote:
>
>>··············@hotmail.com wrote:
>>
>>>I don't want to divert this into a Lisp OS pipe dream discussion, but
>>>what you are describing here with numerical error codes (and even shell
>>>commands, actually) is very much a UNIX design. Common Lisp has a great
>>>condition system, you should consider using it, or, if you want UNIX,
>>>run a UNIX-based Lisp.
>>
>>The numerical error codes would come from "functions" which were
>>actually external programs. Though perhaps creating a condition that
>>went off on a non-success error code...
>
>
> Exactly: you need to clarify what you mean by "running an external
> program" vs. "calling a Lisp function." Why are they different, and if
> they are different, exactly how?
They are different in that "running an external program" means running a
file somewheres (like a shell does) as a separate process. Its return
values as a function are its standard output (primary) and numerical
return code (secondary). I fail to see how that is so complicated.
> External programs might be blocks which you want to restrict in some
> way; e.g., guaranteed not to see or stomp on your memory, or only in
> certain ways, or sharing memory in a copy-on-write fashion, perhaps
> with a different level of priveleges in accessing machine resources or
> making "system calls" (whatever those would be), etc., etc., etc.
External programs are their own processes with their own address spaces.
Arguments are taken from the command line, I/O streams can be
redirected and environment strings are copied from the shell/Lisp unless
the user otherwise specifies.
> Your (run-external-program blah) feature in Lisp could raise conditions
> including cases where your external-program violated some OS
> restriction or exceeded priveleges, or whatever. In which case, that
> abnormal condition is passed back to the calling run-external-program
> function in a way that is checked, and then run-external-program is
> defined to raise a condition.
Instead of (run-external-program blah arguments) I'm going to use (blah
arguments). Anyway, the Lisp interpreter/shell will capture the output
it gets back from the program. The shell will keep a variable
*external-code-check* which points to a function that takes the error
code as a parameter. This function returns two values: a condition class
to signal or NIL, or a boolean for whether this is an error. If it's an
error than error is used instead of signal. The shell will have its own
external-code-check function and condition classes, but the user could
substitute if they wanted to.
This is all presuming that this Lisp shell winds up being Common Lisp
rather than say... Scheme (which already has a shell program).
From: Ulrich Hobelmann
Subject: Re: Small Lisp to work with small operating system?
Date:
Message-ID: <44e1l3F1mlhrU4@individual.net>
Eli Gottlieb wrote:
> ··············@hotmail.com wrote:
>> I don't want to divert this into a Lisp OS pipe dream discussion, but
>> what you are describing here with numerical error codes (and even shell
>> commands, actually) is very much a UNIX design. Common Lisp has a great
>> condition system, you should consider using it, or, if you want UNIX,
>> run a UNIX-based Lisp.
> The numerical error codes would come from "functions" which were
> actually external programs. Though perhaps creating a condition that
> went off on a non-success error code...
But why wouldn't an external program return something useful, such as an
s-exp, or multiple values?
Even the kernel functions could return multiple values, instead of
setting errno ;)
--
Suffering from Gates-induced brain leakage...
Ulrich Hobelmann wrote:
> Eli Gottlieb wrote:
>
>> ··············@hotmail.com wrote:
>>
>>> I don't want to divert this into a Lisp OS pipe dream discussion, but
>>> what you are describing here with numerical error codes (and even shell
>>> commands, actually) is very much a UNIX design. Common Lisp has a great
>>> condition system, you should consider using it, or, if you want UNIX,
>>> run a UNIX-based Lisp.
>>
>> The numerical error codes would come from "functions" which were
>> actually external programs. Though perhaps creating a condition that
>> went off on a non-success error code...
>
>
> But why wouldn't an external program return something useful, such as an
> s-exp, or multiple values?
>
> Even the kernel functions could return multiple values, instead of
> setting errno ;)
>
PLEASE read the rest of my description. Error codes are secondary
values, the primary return value is the contents of the standard output
stream (which if there is no redirection is printed to the REPL as
normal) as a string. Watch:
LISH-USER>(read (make-string-input-stream (external-program arguments ...)))
And so external programs could return s-expressions if they wanted to
because their standard out would be the primary return value.
Because they were not mentioned yet:
* Eshell: http://www.emacswiki.org/cgi-bin/wiki/CategoryEshell
* Schemix: http://www.abstractnonsense.com/schemix/
From: Ulrich Hobelmann
Subject: Re: Small Lisp to work with small operating system?
Date:
Message-ID: <44eftrF1p8vnU1@individual.net>
Emilio Lopes wrote:
> Because they were not mentioned yet:
>
> * Eshell: http://www.emacswiki.org/cgi-bin/wiki/CategoryEshell
Would you consider Emacs a *small* operating system? ;)
--
Suffering from Gates-induced brain leakage...
Ulrich Hobelmann <···········@web.de> writes:
> Emilio Lopes wrote:
>> Because they were not mentioned yet:
>> * Eshell: http://www.emacswiki.org/cgi-bin/wiki/CategoryEshell
>
> Would you consider Emacs a *small* operating system? ;)
Yes, it only lacks a kernel:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
CAUTION: The mass of this product contains the energy equivalent of
85 million tons of TNT per net ounce of weight.
Emilio Lopes wrote:
> Because they were not mentioned yet:
>
> * Eshell: http://www.emacswiki.org/cgi-bin/wiki/CategoryEshell
> * Schemix: http://www.abstractnonsense.com/schemix/
>
Eshell looks somewhat helpful, but I'm not looking to integrate Lisp
into the OS kernel.
Thanks for the eshell tip!
Eli Gottlieb <···········@gmail.com> writes:
> I'm developing a small operating system and want to do something very
> neat on it with Lisp: I want to have an interpreter/compiler/both for
> a small Lisp dialect that will work with only enough OS support to run
> a text terminal, I want the capability to build it up to a normal
> Common Lisp, Scheme, or other "normal" Lisp, and I want to make the
> interpreter the actual shell for the system.
clisp could fit the bill. It runs or has run on the widest range of
OS. clash is clisp used as a shell. See http://clisp.cons.org
What do you mean by "small"? If you plan to run with little memory,
clisp is also one of the smallest CL implementation. Smaller, you'd
have to try lisp500 or a scheme...
> What I'm wondering is how to go about this. Are there any dialects
> already useful in a situation like this?
I'm not sure you need to consider "dialects", in this epoch of freedom
and opensources, unless you plan to run on a washmachine. Even phones
have a lot of memory and powerful processors.
> The operating system features the interpreter will have access to are
> extensible data segment (sbrk() or the like for a heap); inter-process
> communication; standard input, output and error; multithreading; and
> timers. From these it will be possible to build up things like
> filesystem or networking support, but they shouldn't be required parts
> of the interpreter since someone might want to write the filesystem or
> networking support in Lisp ;-).
What you'd need to run clisp is mostly a POSIX layer and a C
compiler. Of course, some assembly will be needed.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Wanna go outside.
Oh, no! Help! I got outside!
Let me back inside!
To do that you need a strong intraction with your OS kernel and the Lisp
system you choose.
I don't think you can just 'plug' a Lisp and go.
If you do, you just will have a Lisp system for your OS.
IMHO you need a 'customizable' lisp and either hack the Lisp to meet your
needs or thightly work with the Lisp developper team.
I made something similar to integrate my OpenLisp into a CAD system and it
took months before all was smoothly integrated.
Please note that a CAD system is probably more simple than a complete
operating system.
Christian
"Eli Gottlieb" <···········@gmail.com> wrote in message
························@twister.nyroc.rr.com...
> I'm developing a small operating system and want to do something very neat
> on it with Lisp: I want to have an interpreter/compiler/both for a small
> Lisp dialect that will work with only enough OS support to run a text
> terminal, I want the capability to build it up to a normal Common Lisp,
> Scheme, or other "normal" Lisp, and I want to make the interpreter the
> actual shell for the system.
>
> What I'm wondering is how to go about this. Are there any dialects
> already useful in a situation like this? I'd like to reuse as much of my
> own and other people's code as possible here, because progamming an
> entirely new Lisp interpreter from scratch will bore the heck out of me.
>
> The operating system features the interpreter will have access to are
> extensible data segment (sbrk() or the like for a heap); inter-process
> communication; standard input, output and error; multithreading; and
> timers. From these it will be possible to build up things like filesystem
> or networking support, but they shouldn't be required parts of the
> interpreter since someone might want to write the filesystem or networking
> support in Lisp ;-).
>
> For the shell feature, I'm looking at how Scsh handles this. I was
> thinking about shells to port and thought "all a shell does is take it's
> first token off the command line, treat it as a program and run that
> program with the other tokens as arguments, printing the output." Then it
> hit me that by making standard output the "primary value" and standard
> error and the numerical error code "secondary values" shell commands could
> be treated like Lisp functions. From there the idea of using a Lisp
> interpreter as a shell, with programs treated as functions, was obvious.
>
> Appreciating the knowledge and flamewars that shall engulf this thread,
> Eli Gottlieb
Christian Jullien wrote:
> To do that you need a strong intraction with your OS kernel and the Lisp
> system you choose.
> I don't think you can just 'plug' a Lisp and go.
> If you do, you just will have a Lisp system for your OS.
> IMHO you need a 'customizable' lisp and either hack the Lisp to meet your
> needs or thightly work with the Lisp developper team.
>
> I made something similar to integrate my OpenLisp into a CAD system and it
> took months before all was smoothly integrated.
> Please note that a CAD system is probably more simple than a complete
> operating system.
>
> Christian
The Lisp-shell won't be built into the kernel, it will just have FFI
access to system calls. What I need is just a customizable Lisp system
for my OS that doesn't require operating system features above a bare
minimum, or better yet, can turn off its bindings to certain operating
system features if they aren't available.
Good to see this thread is getting off the ground,
Eli
Eli Gottlieb wrote:
> Good to see this thread is getting off the ground,
> Eli
Eli--
Be very careful to keep in mind the significant difference between a
bunch of folks chatting around the cracker barrel with real work being
accomplished.
··············@hotmail.com wrote:
> Eli Gottlieb wrote:
>
>
>>Good to see this thread is getting off the ground,
>>Eli
>
>
> Eli--
>
> Be very careful to keep in mind the significant difference between a
> bunch of folks chatting around the cracker barrel with real work being
> accomplished.
>
Joseph--
Infinite Smarter-Than-Monkey-Primate Theorem: Give a number of people
a topic and large enough amount of time, and they'll find something
helpful or useful to say. A bunch of what's already been said has been
both helpful and useful.
No need to be so cynical.
Eli Gottlieb schrieb:
> The Lisp-shell won't be built into the kernel, it will just have FFI
> access to system calls. What I need is just a customizable Lisp system
> for my OS that doesn't require operating system features above a bare
> minimum, or better yet, can turn off its bindings to certain operating
> system features if they aren't available.
ECL is rather minimal and, being designed to be embedded in other
applications, is easier to understand and to customize. You might want
to have a look at it: http://ecls.sourceforge.net
As for requirements, it comes with the Boehm-Weiser garbage collector
and also a conservative garbage collector that only requires either
sbrk() or mmap(). It should be easy to tweak. The operating system is
expected to be POSIX like, in that it provides streams (FILE), usual
file access (stat, unlink, etc) and optionally you can compile in
support for sockets.
Juanjo
Juanjo wrote:
> Eli Gottlieb schrieb:
>
>>The Lisp-shell won't be built into the kernel, it will just have FFI
>>access to system calls. What I need is just a customizable Lisp system
>>for my OS that doesn't require operating system features above a bare
>>minimum, or better yet, can turn off its bindings to certain operating
>>system features if they aren't available.
>
>
> ECL is rather minimal and, being designed to be embedded in other
> applications, is easier to understand and to customize. You might want
> to have a look at it: http://ecls.sourceforge.net
>
> As for requirements, it comes with the Boehm-Weiser garbage collector
> and also a conservative garbage collector that only requires either
> sbrk() or mmap(). It should be easy to tweak. The operating system is
> expected to be POSIX like, in that it provides streams (FILE), usual
> file access (stat, unlink, etc) and optionally you can compile in
> support for sockets.
>
> Juanjo
>
Thanks!
Juanjo wrote:
> Eli Gottlieb schrieb:
>
>>The Lisp-shell won't be built into the kernel, it will just have FFI
>>access to system calls. What I need is just a customizable Lisp system
>>for my OS that doesn't require operating system features above a bare
>>minimum, or better yet, can turn off its bindings to certain operating
>>system features if they aren't available.
>
>
> ECL is rather minimal and, being designed to be embedded in other
> applications, is easier to understand and to customize. You might want
> to have a look at it: http://ecls.sourceforge.net
>
> As for requirements, it comes with the Boehm-Weiser garbage collector
> and also a conservative garbage collector that only requires either
> sbrk() or mmap(). It should be easy to tweak. The operating system is
> expected to be POSIX like, in that it provides streams (FILE), usual
> file access (stat, unlink, etc) and optionally you can compile in
> support for sockets.
>
> Juanjo
>
Seriously, THANKS! I think I can pretty much port this and use it!
Hedgehogh (http://hedgehog.oliotalo.fi/) is a small and open-source
(therefore hackable)
"Hedgehog is a very concise implementation of a Lisp-like language for
low-end and embedded devices." (from their webpage)
··········@gmail.com wrote:
> Hedgehogh (http://hedgehog.oliotalo.fi/) is a small and open-source
> (therefore hackable)
>
> "Hedgehog is a very concise implementation of a Lisp-like language for
> low-end and embedded devices." (from their webpage)
>
There's more than Hedgehog linked from there, thanks a lot!
Debian User wrote:
> There was (is) a reflisp port in the linux kernel called VXE or VXED.
> Have a look in google.
1. What is reflisp? Will Google.
2. Why should I be interested in an embedded Lisp for the Linux kernel?
On Fri, 03 Feb 2006 16:41:36 GMT, Eli Gottlieb <···········@gmail.com> wrote:
> Debian User wrote:
>> There was (is) a reflisp port in the linux kernel called VXE or VXED.
>> Have a look in google.
> 1. What is reflisp? Will Google.
reflisp is a small lisp implementation , I think by B. Birch from
Australia.
> 2. Why should I be interested in an embedded Lisp for the Linux kernel?
I thought it could be an example of how to couple lisp to an OS.
For another small lisp you could have a look at xlisp. It is quite
CL'ish, but can be build very small. Als it is written in a relativly
simple style in C.
Debian User wrote:
> On Fri, 03 Feb 2006 16:41:36 GMT, Eli Gottlieb <···········@gmail.com> wrote:
>
>>Debian User wrote:
>>
>>>There was (is) a reflisp port in the linux kernel called VXE or VXED.
>>>Have a look in google.
>>
>>1. What is reflisp? Will Google.
>
>
> reflisp is a small lisp implementation , I think by B. Birch from
> Australia.
>
>
>>2. Why should I be interested in an embedded Lisp for the Linux kernel?
>
>
> I thought it could be an example of how to couple lisp to an OS.
>
> For another small lisp you could have a look at xlisp. It is quite
> CL'ish, but can be build very small. Als it is written in a relativly
> simple style in C.
>
>
>
I'm not trying to couple Lisp to the operating system, just couple it
via FFI to the system call interface.
Thanks, by the way.
Eli Gottlieb <···········@gmail.com> wrote in
························@twister.nyroc.rr.com:
> Debian User wrote:
>> On Fri, 03 Feb 2006 16:41:36 GMT, Eli Gottlieb
>> <···········@gmail.com> wrote:
>>
>>>Debian User wrote:
>>>
>>>>There was (is) a reflisp port in the linux kernel called VXE or
>>>>VXED. Have a look in google.
>>>
>>>1. What is reflisp? Will Google.
>>
>>
>> reflisp is a small lisp implementation , I think by B. Birch from
>> Australia.
>>
>>
>>>2. Why should I be interested in an embedded Lisp for the Linux
>>>kernel?
>>
>>
>> I thought it could be an example of how to couple lisp to an OS.
>>
>> For another small lisp you could have a look at xlisp. It is quite
>> CL'ish, but can be build very small. Als it is written in a
>> relativly simple style in C.
>>
>>
>>
> I'm not trying to couple Lisp to the operating system, just couple it
> via FFI to the system call interface.
>
> Thanks, by the way.
>
Have you seen LispMe : http://www.lispme.de/index.html#lispme/index.html
Source code is there - it is Scheme under PalmOS.
There was a lot of helpful information in responses, so please put up
with this one last question: I've Googled for material on how exactly to
go about implementing Common Lisp (I want the semantics of it at the
very least) and found none. There were a couple of pre-CL books on
implementing Lisp (I'm using one of those from the other thread), but
very little to nothing for CL itself.
Other than the Hyperspec, which prescribes the behavior of anything
without giving any hint to where one actually begins or ends in
implementation (chapter 2 references several variables, functions and
other parts of the spec before you even know how to evalute variables or
apply functions!) are there any works out there on how to go about
implementing Common Lisp?
From: Pascal Bourguignon
Subject: Re: One last question, was Re: Small Lisp to work with small operating system?
Date:
Message-ID: <87slqz7kra.fsf@thalassa.informatimago.com>
Eli Gottlieb <···········@gmail.com> writes:
> There was a lot of helpful information in responses, so please put up
> with this one last question: I've Googled for material on how exactly
> to go about implementing Common Lisp (I want the semantics of it at
> the very least) and found none. There were a couple of pre-CL books
> on implementing Lisp (I'm using one of those from the other thread),
> but very little to nothing for CL itself.
Ask yourself: what do you want really?
I guess you'd be able to sort out library functions and macros from
core functions and special opeators easily enough.
Now, CLHS, the ANSI Specifications should be clear enough describing
the behavior of CL. There are a few points that might not be so clear
or plainly ambiguous, but there's a lot of material, if only on
comp.lang.lisp, which clarify and explain the consensus on everything.
If you want it more formal, and gathered in one place, you've got the
choice between the various open source implementations.
So, we don't have a formal specification that could be turned into a
program automatically. You have to choose between an informal but
quite precise specification, or a number of formal program sources.
> Other than the Hyperspec, which prescribes the behavior of anything
> without giving any hint to where one actually begins or ends in
> implementation (chapter 2 references several variables, functions and
> other parts of the spec before you even know how to evalute variables
> or apply functions!) are there any works out there on how to go about
> implementing Common Lisp?
You should read SICP, in particular Chapter 4. You cannot start from
one point and develop a lisp interpreter upward. It's an eval/apply
yin-yang, recursive procedures calling one the other.
If you didn't keep your eyese shut on comp.lang.lisp only last month,
you'd seen at least once all the references you need. No memory?
Does "Lisp in small pieces" ring a bell?
But anyways, I'd jump head first in one implementation.
I'd read OpenMCL sources.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Pascal Bourguignon wrote:
> Ask yourself: what do you want really?
>
> I guess you'd be able to sort out library functions and macros from
> core functions and special opeators easily enough.
What do I really want? A subset of Common Lisp which includes only the
primitive functions for the types and the core special operators. And
CLOS can be built as a macro system, so I don't have to include that, right?
>
> Now, CLHS, the ANSI Specifications should be clear enough describing
> the behavior of CL. There are a few points that might not be so clear
> or plainly ambiguous, but there's a lot of material, if only on
> comp.lang.lisp, which clarify and explain the consensus on everything.
>
> If you want it more formal, and gathered in one place, you've got the
> choice between the various open source implementations.
>
> So, we don't have a formal specification that could be turned into a
> program automatically. You have to choose between an informal but
> quite precise specification, or a number of formal program sources.
Start from no place at all? Sounds somewhat like kernel coding. I
suppose in this case it must be OK to write in calls to functions that
don't exist yet?
> You should read SICP, in particular Chapter 4. You cannot start from
> one point and develop a lisp interpreter upward. It's an eval/apply
> yin-yang, recursive procedures calling one the other.
I'll see if I can find a copy of SICP. And I'll watch the lectures for
this semester.
>
> If you didn't keep your eyese shut on comp.lang.lisp only last month,
> you'd seen at least once all the references you need. No memory?
> Does "Lisp in small pieces" ring a bell?
I keep my eyes open, but this newsgroup generates thousands of messages
a month. I read the ones I'm interested in, which may mean I don't read
some of the finer points people talk about in sub-threads 5 replies deep.
>
> But anyways, I'd jump head first in one implementation.
> I'd read OpenMCL sources.
>
OpenMCL? Googling...
Thanks, and maybe now I can shut up and code:
Eli
From: Pascal Bourguignon
Subject: Re: One last question, was Re: Small Lisp to work with small operating system?
Date:
Message-ID: <87hd7f7io0.fsf@thalassa.informatimago.com>
Eli Gottlieb <···········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> Ask yourself: what do you want really?
>> I guess you'd be able to sort out library functions and macros from
>> core functions and special opeators easily enough.
>
> What do I really want? A subset of Common Lisp which includes only
> the primitive functions for the types and the core special operators.
> And CLOS can be built as a macro system, so I don't have to include
> that, right?
The problem is that it all started theorically from only one
construct: lambda.
You can build the whole Common Lisp with only lambda. (Well, if you
want to start with a lisp-2 notation, you'll need also funcall, but
you can as well start with a lisp-1, and grow the lisp-2 from it).
Of course, it won't be pretty, and you may have some difficulties to
interface with the hardware (but you could design a device that does
the I/O encoding the data with lambda functions instead of with bytes.
For example here is how you'd write (car (cons t nil)):
(((lambda (car cdr)
(lambda (bool) (bool car cdr)))
(lambda (then else) then)
(lambda (then else) else))
(lambda (then else) then))
Even in this case you have some fundamental lisp stuff to develop:
lambda introduces bindings for the arguments, and a closure.
You want to start from a less minimal minimal set? Try AIM-8 LISP,
have a look at the bottom of:
http://www.informatimago.com/develop/lisp/small-cl-pgms/index.html
You can also have a look at lisp500.c a minimal CL in 500 lines of C.
But the sources of OpenMCL will be more instructive IMO.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Pascal Bourguignon wrote:
> Eli Gottlieb <···········@gmail.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Ask yourself: what do you want really?
>>>I guess you'd be able to sort out library functions and macros from
>>>core functions and special opeators easily enough.
>>
>>What do I really want? A subset of Common Lisp which includes only
>>the primitive functions for the types and the core special operators.
>>And CLOS can be built as a macro system, so I don't have to include
>>that, right?
>
>
> The problem is that it all started theorically from only one
> construct: lambda.
>
> You can build the whole Common Lisp with only lambda. (Well, if you
> want to start with a lisp-2 notation, you'll need also funcall, but
> you can as well start with a lisp-1, and grow the lisp-2 from it).
I think /some/ primitive functions are needed. You can't define car or
cdr with just lambda.
>
> Of course, it won't be pretty, and you may have some difficulties to
> interface with the hardware (but you could design a device that does
> the I/O encoding the data with lambda functions instead of with bytes.
>
>
> For example here is how you'd write (car (cons t nil)):
>
> (((lambda (car cdr)
> (lambda (bool) (bool car cdr)))
> (lambda (then else) then)
> (lambda (then else) else))
> (lambda (then else) then))
>
> Even in this case you have some fundamental lisp stuff to develop:
> lambda introduces bindings for the arguments, and a closure.
>
>
> You want to start from a less minimal minimal set? Try AIM-8 LISP,
> have a look at the bottom of:
> http://www.informatimago.com/develop/lisp/small-cl-pgms/index.html
An interesting read.
The real set I want to start from is "Common Lisp without any operating
system support". This does not mean "kernel Common Lisp" or
"freestanding, bare-metal Common Lisp", it means "Common Lisp that only
knows about the monitor, keyboard, CPU and memory". Hopefully this set
is of a decent size for implementing without going mad.
>
> You can also have a look at lisp500.c a minimal CL in 500 lines of C.
> But the sources of OpenMCL will be more instructive IMO.
>
OpenMCL is <b><i><u>WAY FREAKING MORE</u></i></b> helpful than that
vomity-looking lisp500.c. I don't doubt that the latter works, but I
think it's completely worthless for learning anything from.
From: Karl A. Krueger
Subject: Re: One last question, was Re: Small Lisp to work with small operating system?
Date:
Message-ID: <ds1qab$43f$1@baldur.whoi.edu>
Eli Gottlieb <···········@gmail.com> wrote:
> Pascal Bourguignon wrote:
>> You can build the whole Common Lisp with only lambda. (Well, if you
>> want to start with a lisp-2 notation, you'll need also funcall, but
>> you can as well start with a lisp-1, and grow the lisp-2 from it).
>
> I think /some/ primitive functions are needed. You can't define car or
> cdr with just lambda.
Assuming Lisp-1 evaluation, you sure can.
Let TRUE be (lambda (x y) x) and FALSE be (lambda (x y) y).
CONS follows: (lambda (x y) (lambda (z) (z x y)))
Then CAR and CDR are (lambda (x) (x TRUE)), and (lambda (x) (x FALSE)).
--
Karl A. Krueger <········@example.edu> { s/example/whoi/ }
From: Pascal Bourguignon
Subject: Re: One last question, was Re: Small Lisp to work with small operating system?
Date:
Message-ID: <87r76j5okb.fsf@thalassa.informatimago.com>
Eli Gottlieb <···········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> Eli Gottlieb <···········@gmail.com> writes:
>>
>>>Pascal Bourguignon wrote:
>>>
>>>>Ask yourself: what do you want really?
>>>>I guess you'd be able to sort out library functions and macros from
>>>>core functions and special opeators easily enough.
>>>
>>>What do I really want? A subset of Common Lisp which includes only
>>>the primitive functions for the types and the core special operators.
>>>And CLOS can be built as a macro system, so I don't have to include
>>>that, right?
>> The problem is that it all started theorically from only one
>> construct: lambda.
>> You can build the whole Common Lisp with only lambda. (Well, if you
>> want to start with a lisp-2 notation, you'll need also funcall, but
>> you can as well start with a lisp-1, and grow the lisp-2 from it).
>
> I think /some/ primitive functions are needed. You can't define car
> or cdr with just lambda.
Read 4 lines below!
>> Of course, it won't be pretty, and you may have some difficulties to
>> interface with the hardware (but you could design a device that does
>> the I/O encoding the data with lambda functions instead of with bytes.
>> For example here is how you'd write (car (cons t nil)):
>> (((lambda (car cdr)
>> (lambda (bool) (bool car cdr))) (lambda (then else) then)
>> (lambda (then else) else))
>> (lambda (then else) then))
>> Even in this case you have some fundamental lisp stuff to develop:
>> lambda introduces bindings for the arguments, and a closure.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Pascal Bourguignon wrote:
> Eli Gottlieb <···········@gmail.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Eli Gottlieb <···········@gmail.com> writes:
>>>
>>>
>>>>Pascal Bourguignon wrote:
>>>>
>>>>
>>>>>Ask yourself: what do you want really?
>>>>>I guess you'd be able to sort out library functions and macros from
>>>>>core functions and special opeators easily enough.
>>>>
>>>>What do I really want? A subset of Common Lisp which includes only
>>>>the primitive functions for the types and the core special operators.
>>>>And CLOS can be built as a macro system, so I don't have to include
>>>>that, right?
>>>
>>>The problem is that it all started theorically from only one
>>>construct: lambda.
>>>You can build the whole Common Lisp with only lambda. (Well, if you
>>>want to start with a lisp-2 notation, you'll need also funcall, but
>>>you can as well start with a lisp-1, and grow the lisp-2 from it).
>>
>>I think /some/ primitive functions are needed. You can't define car
>>or cdr with just lambda.
>
>
> Read 4 lines below!
>
>
>>>Of course, it won't be pretty, and you may have some difficulties to
>>>interface with the hardware (but you could design a device that does
>>>the I/O encoding the data with lambda functions instead of with bytes.
>>>For example here is how you'd write (car (cons t nil)):
>>>(((lambda (car cdr)
>>> (lambda (bool) (bool car cdr))) (lambda (then else) then)
>>> (lambda (then else) else))
>>> (lambda (then else) then))
>>>Even in this case you have some fundamental lisp stuff to develop:
>>>lambda introduces bindings for the arguments, and a closure.
>
>
So how exactly does this work on a modern CL interpreter rather than in
Lisp-1?
From: Pascal Bourguignon
Subject: Re: One last question, was Re: Small Lisp to work with small operating system?
Date:
Message-ID: <87y80r7y34.fsf@thalassa.informatimago.com>
Eli Gottlieb <···········@gmail.com> writes:
> Pascal Bourguignon wrote:
>> Eli Gottlieb <···········@gmail.com> writes:
>>
>>>Pascal Bourguignon wrote:
>>>
>>>>Eli Gottlieb <···········@gmail.com> writes:
>>>>
>>>>
>>>>>Pascal Bourguignon wrote:
>>>>>
>>>>>
>>>>>>Ask yourself: what do you want really?
>>>>>>I guess you'd be able to sort out library functions and macros from
>>>>>>core functions and special opeators easily enough.
>>>>>
>>>>>What do I really want? A subset of Common Lisp which includes only
>>>>>the primitive functions for the types and the core special operators.
>>>>>And CLOS can be built as a macro system, so I don't have to include
>>>>>that, right?
>>>>
>>>>The problem is that it all started theorically from only one
>>>>construct: lambda.
>>>>You can build the whole Common Lisp with only lambda. (Well, if you
>>>>want to start with a lisp-2 notation, you'll need also funcall, but
>>>>you can as well start with a lisp-1, and grow the lisp-2 from it).
>>>
>>>I think /some/ primitive functions are needed. You can't define car
>>>or cdr with just lambda.
>> Read 4 lines below!
>>
>>>>Of course, it won't be pretty, and you may have some difficulties to
>>>>interface with the hardware (but you could design a device that does
>>>>the I/O encoding the data with lambda functions instead of with bytes.
>>>>For example here is how you'd write (car (cons t nil)):
>>>>(((lambda (car cdr)
>>>> (lambda (bool) (bool car cdr))) (lambda (then else) then)
>>>> (lambda (then else) else))
>>>> (lambda (then else) then))
>>>>Even in this case you have some fundamental lisp stuff to develop:
>>>>lambda introduces bindings for the arguments, and a closure.
>>
> So how exactly does this work on a modern CL interpreter rather than
> in Lisp-1?
You need to add two FUNCALL:
[3]> (funcall ((lambda (car cdr)
(lambda (bool) (funcall bool car cdr))) (lambda (then else) then)
(lambda (then else) else))
(lambda (then else) then))
#<FUNCTION :LAMBDA (THEN ELSE) THEN> ; this is "T"
[4]>
If you prefer to use names for cons car cdr t nil:
(shadow '(t nil))
((lambda (t nil)
((lambda (cons car cdr)
(funcall car (funcall cons t nil))
;; these car, cons, t and nil are lambdas, not your implementation's.
)
(lambda (car cdr) (lambda (bool) (funcall bool car cdr)))
(lambda (cons) (funcall cons t))
(lambda (cons) (funcall cons nil))))
(lambda (then else) then)
(lambda (then else) else))
--> #<FUNCTION :LAMBDA (THEN ELSE) THEN>
If you add STEP, you can verify that only LAMBDA and FUNCALL are used:
((lambda (t nil)
((lambda (cons car cdr)
(step
(funcall car (funcall cons t nil))
))
(lambda (car cdr) (lambda (bool) (funcall bool car cdr)))
(lambda (cons) (funcall cons t))
(lambda (cons) (funcall cons nil))))
(lambda (then else) then)
(lambda (then else) else))
step 1 --> (FUNCALL CAR (FUNCALL CONS T NIL))
Step 1 [10]> step
step 2 --> CAR
Step 2 [11]> step
step 2 ==> value: #<FUNCTION :LAMBDA (CONS) (FUNCALL CONS T)>
step 2 --> (FUNCALL CONS T NIL)
Step 2 [12]> step
step 3 --> CONS
Step 3 [13]> step
step 3 ==> value: #<FUNCTION :LAMBDA (CAR CDR) (LAMBDA (BOOL) (FUNCALL BOOL CAR CDR))>
step 3 --> T
Step 3 [14]> step
step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 3 --> NIL
Step 3 [15]> step
step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) ELSE>
step 3 --> #'(LAMBDA (BOOL) (DECLARE (SYSTEM::SOURCE #)) (FUNCALL BOOL CAR CDR))
Step 3 [16]> step
step 3 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
step 2 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
step 2 --> (FUNCALL CONS T)
Step 2 [17]> step
step 3 --> CONS
Step 3 [18]> step
step 3 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
step 3 --> T
Step 3 [19]> step
step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 3 --> (FUNCALL BOOL CAR CDR)
Step 3 [20]> step
step 4 --> BOOL
Step 4 [21]> step
step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 4 --> CAR
Step 4 [22]> step
step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 4 --> CDR
Step 4 [23]> step
step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) ELSE>
step 4 --> THEN
Step 4 [24]> step
step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 2 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
step 1 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
#<FUNCTION :LAMBDA (THEN ELSE) THEN>
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Pascal Bourguignon wrote:
> Eli Gottlieb <···········@gmail.com> writes:
>
>
>>Pascal Bourguignon wrote:
>>
>>>Eli Gottlieb <···········@gmail.com> writes:
>>>
>>>
>>>>Pascal Bourguignon wrote:
>>>>
>>>>
>>>>>Eli Gottlieb <···········@gmail.com> writes:
>>>>>
>>>>>
>>>>>
>>>>>>Pascal Bourguignon wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Ask yourself: what do you want really?
>>>>>>>I guess you'd be able to sort out library functions and macros from
>>>>>>>core functions and special opeators easily enough.
>>>>>>
>>>>>>What do I really want? A subset of Common Lisp which includes only
>>>>>>the primitive functions for the types and the core special operators.
>>>>>>And CLOS can be built as a macro system, so I don't have to include
>>>>>>that, right?
>>>>>
>>>>>The problem is that it all started theorically from only one
>>>>>construct: lambda.
>>>>>You can build the whole Common Lisp with only lambda. (Well, if you
>>>>>want to start with a lisp-2 notation, you'll need also funcall, but
>>>>>you can as well start with a lisp-1, and grow the lisp-2 from it).
>>>>
>>>>I think /some/ primitive functions are needed. You can't define car
>>>>or cdr with just lambda.
>>>
>>>Read 4 lines below!
>>>
>>>
>>>>>Of course, it won't be pretty, and you may have some difficulties to
>>>>>interface with the hardware (but you could design a device that does
>>>>>the I/O encoding the data with lambda functions instead of with bytes.
>>>>>For example here is how you'd write (car (cons t nil)):
>>>>>(((lambda (car cdr)
>>>>> (lambda (bool) (bool car cdr))) (lambda (then else) then)
>>>>> (lambda (then else) else))
>>>>>(lambda (then else) then))
>>>>>Even in this case you have some fundamental lisp stuff to develop:
>>>>>lambda introduces bindings for the arguments, and a closure.
>>>
>>So how exactly does this work on a modern CL interpreter rather than
>>in Lisp-1?
>
>
> You need to add two FUNCALL:
>
> [3]> (funcall ((lambda (car cdr)
> (lambda (bool) (funcall bool car cdr))) (lambda (then else) then)
> (lambda (then else) else))
> (lambda (then else) then))
> #<FUNCTION :LAMBDA (THEN ELSE) THEN> ; this is "T"
> [4]>
>
>
> If you prefer to use names for cons car cdr t nil:
>
> (shadow '(t nil))
> ((lambda (t nil)
> ((lambda (cons car cdr)
>
> (funcall car (funcall cons t nil))
> ;; these car, cons, t and nil are lambdas, not your implementation's.
>
> )
> (lambda (car cdr) (lambda (bool) (funcall bool car cdr)))
> (lambda (cons) (funcall cons t))
> (lambda (cons) (funcall cons nil))))
> (lambda (then else) then)
> (lambda (then else) else))
> --> #<FUNCTION :LAMBDA (THEN ELSE) THEN>
>
>
> If you add STEP, you can verify that only LAMBDA and FUNCALL are used:
>
> ((lambda (t nil)
> ((lambda (cons car cdr)
> (step
> (funcall car (funcall cons t nil))
> ))
> (lambda (car cdr) (lambda (bool) (funcall bool car cdr)))
> (lambda (cons) (funcall cons t))
> (lambda (cons) (funcall cons nil))))
> (lambda (then else) then)
> (lambda (then else) else))
>
>
> step 1 --> (FUNCALL CAR (FUNCALL CONS T NIL))
> Step 1 [10]> step
> step 2 --> CAR
> Step 2 [11]> step
> step 2 ==> value: #<FUNCTION :LAMBDA (CONS) (FUNCALL CONS T)>
> step 2 --> (FUNCALL CONS T NIL)
> Step 2 [12]> step
> step 3 --> CONS
> Step 3 [13]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (CAR CDR) (LAMBDA (BOOL) (FUNCALL BOOL CAR CDR))>
> step 3 --> T
> Step 3 [14]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 3 --> NIL
> Step 3 [15]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) ELSE>
> step 3 --> #'(LAMBDA (BOOL) (DECLARE (SYSTEM::SOURCE #)) (FUNCALL BOOL CAR CDR))
> Step 3 [16]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
> step 2 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
> step 2 --> (FUNCALL CONS T)
> Step 2 [17]> step
> step 3 --> CONS
> Step 3 [18]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (BOOL) (FUNCALL BOOL CAR CDR)>
> step 3 --> T
> Step 3 [19]> step
> step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 3 --> (FUNCALL BOOL CAR CDR)
> Step 3 [20]> step
> step 4 --> BOOL
> Step 4 [21]> step
> step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 4 --> CAR
> Step 4 [22]> step
> step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 4 --> CDR
> Step 4 [23]> step
> step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) ELSE>
> step 4 --> THEN
> Step 4 [24]> step
> step 4 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 3 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 2 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> step 1 ==> value: #<FUNCTION :LAMBDA (THEN ELSE) THEN>
> #<FUNCTION :LAMBDA (THEN ELSE) THEN>
>
OK, without returning a closure can you define car, cdr?
Eli Gottlieb <···········@gmail.com> writes:
> There was a lot of helpful information in responses, so please put up
> with this one last question: I've Googled for material on how exactly
> to go about implementing Common Lisp (I want the semantics of it at
> the very least) and found none. There were a couple of pre-CL books
> on implementing Lisp (I'm using one of those from the other thread),
> but very little to nothing for CL itself.
I'm not sure if it helps for what you want to do, but there's an
excellent talk online: "The 90 Minute Scheme to C compiler" by Marc
Feeley (the author of Gambit Scheme, a highly optimizing compiler).
It uses continuation passing style to transfer a subset of scheme to
C. There's even some source code on the website.
The link is: http://tinyurl.com/dnkb4