From: David Steuber
Subject: Another algorithmic complexity question
Date:
Message-ID: <m2ptfku36e.fsf@verizon.net>
Starting with a basic knowledge of computer programming and having
access to existing public domain source code, how long would it take
a single person to build a fully ANSI compliant Lisp implimentation
as a personal project?
Assume no current knowledge of Lisp. Also assume no other Lisp is
available as a bootstrap. Is any other info required to come up with
a ball park estimate?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> Starting with a basic knowledge of computer programming and having
> access to existing public domain source code, how long would it take
> a single person to build a fully ANSI compliant Lisp implimentation
> as a personal project?
>
> Assume no current knowledge of Lisp. Also assume no other Lisp is
> available as a bootstrap. Is any other info required to come up with
> a ball park estimate?
>
Is an interpreter sufficient or do you need a compiler, as well? If you
want a compiler, is a byte-code to VM compiler sufficient or do you want to
go to machine code? How many targets for machine code? How efficient do
the compilers need to be? How well does the GC have to work? How
defect-free does the system need to be? How efficient does the code for
the built-in functions need to be? How well does the system need to handle
future extensions?
In short, your question is still underspecified. However, I can say without
doubt that the time will be less than for an implementation of C++ with
complete RTL.
faa
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m23ccf5nyj.fsf@verizon.net>
"Frank A. Adrian" <·······@ancar.org> writes:
> David Steuber wrote:
>
> > Starting with a basic knowledge of computer programming and having
> > access to existing public domain source code, how long would it take
> > a single person to build a fully ANSI compliant Lisp implimentation
> > as a personal project?
>
> Is an interpreter sufficient or do you need a compiler, as well? If
> you want a compiler, is a byte-code to VM compiler sufficient or do
> you want to go to machine code?
Machine code would be the preferred target, but an interpreter would
possibly be just fine if it was a correct implementation.
> How many targets for machine code?
The G4 and G5 processors with the Darwin ABI to start. Itanium and
Opteron targets under FreeBSD or Linux are not to be ruled out but are
not required either. It's been a while since I worried about things
like stack frames and calling conventions. And then it was just to
write assembler routines with C calling convention under MS-DOS.
> How efficient do the compilers need to be?
Competitive with GCC would be nice. However no optimization to
start.
> How well does the GC have to work?
I'm not sure how to answer this one (like the above answer is any
good). While performance is always nice to have, the GC should be
correct above all else. I don't know how aggressive GC should be
about returning memory to the system rather than holding onto it for
reuse by the application.
> How defect-free does the system need to be?
As defect-free as possible. If code can't be proved correct, it
should at least be difficult to prove it incorrect.
> How efficient does the code for the built-in functions need to be?
It would be nice for numeric code to be very fast. However, I'm not
concerned with speed at the present. Speed will probably be important
for those built-in functions that are used to implement other built-in
functions.
> How well does the system need to handle future extensions?
The system should be able to link with code that uses C calling
conventions. Objective-C library support would be very nice indeed.
I guess it depends on what the best way to bridge to Cocoa is.
> In short, your question is still underspecified. However, I can say without
> doubt that the time will be less than for an implementation of C++ with
> complete RTL.
Less time than something else that is very hard? ;-)
Would the proliferation of ANSI Lisp systems be helpful to the Lisp
community? Or would it just be a waste of effort, being considered
redundant as another poster mentioned?
I imagine there are also philosophical issues with implementing a
language standard. There are already a number of Lisp implementations
even though everyone seems to want Java developers. I've recently
done some Java coding and was reminded why I hate the language so. I
don't want to hijack my own thread and go into a language debate
though. Suffice it to say I don't like Java and am rather more
interested in Lisp. I am also interested in Lisp being able to
integrate into a Unix style environment. Say what you will about Unix
or Windows, it would be much easier to create a Lisp that works there
than to get everyone to change their OS. Even Java has to pretend to
be native. I don't plan to do Windows though.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: Tim Daly Jr.
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <878ym8r52u.fsf@simple.intern>
David Steuber <·············@verizon.net> writes:
> Starting with a basic knowledge of computer programming and having
> access to existing public domain source code, how long would it take
> a single person to build a fully ANSI compliant Lisp implimentation
> as a personal project?
>
> Assume no current knowledge of Lisp. Also assume no other Lisp is
> available as a bootstrap. Is any other info required to come up with
> a ball park estimate?
>
Two weeks, of course.
-Tim
--
Man must shape his tools lest they shape him. -- Arthur R. Miller
"Tim Daly Jr." <···@tenkan.org> ha scritto nel messaggio
···················@simple.intern...
> David Steuber <·············@verizon.net> writes:
>
> > Starting with a basic knowledge of computer programming and having
> > access to existing public domain source code, how long would it take
> > a single person to build a fully ANSI compliant Lisp implimentation
> > as a personal project?
> >
> > Assume no current knowledge of Lisp. Also assume no other Lisp is
> > available as a bootstrap. Is any other info required to come up
with
> > a ball park estimate?
> >
>
> Two weeks, of course.
>
Two weeks for copying.. ;-)
DaveNlp
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2ekvz5qy3.fsf@verizon.net>
"DaveNlp" <(NOSPAM)·········@iol.it> writes:
> "Tim Daly Jr." <···@tenkan.org> ha scritto nel messaggio
> ···················@simple.intern...
> > David Steuber <·············@verizon.net> writes:
> >
> > > Starting with a basic knowledge of computer programming and having
> > > access to existing public domain source code, how long would it take
> > > a single person to build a fully ANSI compliant Lisp implimentation
> > > as a personal project?
> > >
> > > Assume no current knowledge of Lisp. Also assume no other Lisp is
> > > available as a bootstrap. Is any other info required to come up
> with
> > > a ball park estimate?
> > >
> >
> > Two weeks, of course.
> >
>
> Two weeks for copying.. ;-)
Terrific! How much longer to add multi-threading?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
On Sat, 22 Nov 2003 10:08:38 GMT, David Steuber <·············@verizon.net>
wrote:
>Starting with a basic knowledge of computer programming and having
>access to existing public domain source code, how long would it take
>a single person to build a fully ANSI compliant Lisp implimentation
>as a personal project?
>
>Assume no current knowledge of Lisp. Also assume no other Lisp is
>available as a bootstrap. Is any other info required to come up with
>a ball park estimate?
This is difficult to answer, because I don't think one's ever yet been built.
Roger Corman
Corman Technologies
www.cormanlisp.com
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m28ym75q6i.fsf@verizon.net>
·····@corman.net (Roger Corman) writes:
> On Sat, 22 Nov 2003 10:08:38 GMT, David Steuber <·············@verizon.net>
> wrote:
>
> >Starting with a basic knowledge of computer programming and having
> >access to existing public domain source code, how long would it take
> >a single person to build a fully ANSI compliant Lisp implimentation
> >as a personal project?
>
> This is difficult to answer, because I don't think one's ever yet been built.
> Roger Corman
I find this to be a very interesting response. Your Lisp system is
one that I have heard recomendations for.
Is Corman Lisp a one man project?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> > >Starting with a basic knowledge of computer programming and having
> > >access to existing public domain source code, how long would it take
> > >a single person to build a fully ANSI compliant Lisp implimentation
> > >as a personal project?
> >
> > This is difficult to answer, because I don't think one's ever yet been built.
> > Roger Corman
>
> I find this to be a very interesting response. Your Lisp system is
> one that I have heard recomendations for.
I believe he means no fully ANSI compliant implementation of Lisp has
ever been built (individually or collectively). Some come close, but
perfection is elusive.
Paul
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2he0s3ksi.fsf@verizon.net>
Paul Dietz <············@motorola.com> writes:
> I believe he means no fully ANSI compliant implementation of Lisp has
> ever been built (individually or collectively). Some come close, but
> perfection is elusive.
For some reason I find that rather disturbing. Is it really that
complex? Or are there other reasons?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Paul Dietz <············@motorola.com> writes:
>
> > I believe he means no fully ANSI compliant implementation of Lisp has
> > ever been built (individually or collectively). Some come close, but
> > perfection is elusive.
>
> For some reason I find that rather disturbing.
>
> Is it really that complex?
> Or are there other reasons?
Compliance is often subjective. I recall someone telling me that it is
expected that Ada implementations will fail the existing tests and that
the process of validation is more one of justifying the borderline choices
than one of merely satisfying a set of requirements.
There can be. To be a universal language, you must not presuppose a
particular underlying piece of hardware (or, more generally, virtual
machine). If you rely on the virtual machine for services, you must
either permit it to deviate in this or that way that can be hard to
specify thoroughly, or else you must constrain it to behave in ways
that may make it nearly impossible to conform on some processors.
For example, if you require IEEE arithmetic but the virtual machine
doesn't really do it, then you have to simulate it in software, and
that may be too expensive. But if you don't require it, then you may
get floating point results that deviate from what you expect. If you
require an ASCII-like coding system, you exclude (or make hugely
difficult) correct implementations on EBCDIC and other processors.
If you require 2's complement numeric coding, you exclude 1's complement
and bcd processors. If you require DOS or ISO 9660 or Macintosh or
Unix or whatever file system, then you make it easier to do pathnames
on some computers but harder on others. If you require a certain
amount of memory, you make some computations easier, but you lock out
some microprocessors. If you require a particular representation for
any object, you lock out clever optimizations that might be thought of
later. If you require certain optimizations by the compiler, you
may lock out some simple-minded compilers that are adequate to special
purposes and otherwise functionally equivalent. And on and on...
CL does a relatively good job of papering over these many, many
variances in the underlying system and giving you a base that has a
great deal of predictability. For us to have pushed too hard on that
would have been to limit ourselves in where CL could go. The fringey
edges are messy, but that messiness at the edges is what lets us move
forward into the future.
David Steuber <·············@verizon.net> writes:
> Paul Dietz <············@motorola.com> writes:
>
>> I believe he means no fully ANSI compliant implementation of Lisp has
>> ever been built (individually or collectively). Some come close, but
>> perfection is elusive.
>
> For some reason I find that rather disturbing. Is it really that
> complex? Or are there other reasons?
It seems to be quite tricky. I don't think it's for want of trying
(though it may be for want of market pressure).
As we say these days, "patches welcome" :-)
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Paul Dietz <············@motorola.com> writes:
> >
> >> I believe he means no fully ANSI compliant implementation of Lisp has
> >> ever been built (individually or collectively). Some come close, but
> >> perfection is elusive.
> >
> > For some reason I find that rather disturbing. Is it really that
> > complex? Or are there other reasons?
>
> It seems to be quite tricky. I don't think it's for want of trying
> (though it may be for want of market pressure).
>
> As we say these days, "patches welcome" :-)
Well, "actual" compliance means bug-free. That's hard to assure in a system
of the size of a CL.
This is the reason I created the term "purports to conform", which a lot of
implementations do. In effect, what that means is "willing to receive bug
reports where non-conformance is detected".
I think in practice the notion of purporting to conform is much more
meaningful than the notion of actual conformance. In fact, it's
theoretically possible to actually conform without intending to and
without a commitment to continuing to be that way on an ongoing basis...
or even without detecting the fact. It's the commitment that matters, not
the "incidental" fact.
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m24qwpxw3o.fsf@verizon.net>
Kent M Pitman <······@nhplace.com> writes:
> Well, "actual" compliance means bug-free. That's hard to assure in a system
> of the size of a CL.
>
> This is the reason I created the term "purports to conform", which a lot of
> implementations do. In effect, what that means is "willing to receive bug
> reports where non-conformance is detected".
>
> I think in practice the notion of purporting to conform is much more
> meaningful than the notion of actual conformance. In fact, it's
> theoretically possible to actually conform without intending to and
> without a commitment to continuing to be that way on an ongoing basis...
> or even without detecting the fact. It's the commitment that matters, not
> the "incidental" fact.
This makes sense. It certainly is a lot easier to prove the
existence of bugs than the nonexistence of bugs ;-)
The notion of "purports to conform" that you put forward sounds like
a good one and I hope that it works well in practice.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
On Sun, 23 Nov 2003 10:35:31 GMT, David Steuber <·············@verizon.net>
wrote:
>·····@corman.net (Roger Corman) writes:
>
>> On Sat, 22 Nov 2003 10:08:38 GMT, David Steuber <·············@verizon.net>
>> wrote:
>>
>> >Starting with a basic knowledge of computer programming and having
>> >access to existing public domain source code, how long would it take
>> >a single person to build a fully ANSI compliant Lisp implimentation
>> >as a personal project?
>>
>> This is difficult to answer, because I don't think one's ever yet been built.
>> Roger Corman
>
>I find this to be a very interesting response. Your Lisp system is
>one that I have heard recomendations for.
>
>Is Corman Lisp a one man project?
Corman Lisp is mostly written by me. I have pulled in a number of public domain
modules, such as from CMU Lisp, and over the years users have contributed a fair
number of enhancements and bug fixes (a benefit of distributing the source
code).
Corman Lisp is not "fully ANSI compliant" but I do regard non-compliance areas
as defects and am addressing them. I believe the other common lisp systems are
in the same place, with some being closer to full compliance than others, but
with full compliance being difficult to measure objectively. ANSI compliance for
a language the size of common lisp is indeed a major feat. I believe the spec is
well over a thousand pages, and compared to other types of software, compiler
specifications are quite dense.
A perhaps comparable language spec is the ANSI C++ spec, and Microsoft's
implementation is still not fully ANSI compliant even though at least a decade
has elapsed since the standard was finished. That has had quite a few man years
invested in it.
A common lisp implementation is a big project, and if you decide to take on a
big project and invest the resources necessary, then you also find that you are
building a useless thing unless it also includes lots of modules and properties
not included in the spec. The spec doesn't say anything about performance, but
that's obviously important. You spend a lot of time making performance
reasonable. The spec doesn't say anything about a garbage collector, but of
course you need that, and it better be fast. Then you either have to include
lots of custom modules for non-specified features (sockets, database, etc) or
else you at least need to include an FFI so they can be added on. All the things
not specified are in some ways as important or more important than meeting all
the details of the standard, and so you have to come up with a trade-off. A real
estimate for completion of such a project then necessarily includes the whole
project, not just the time to meet the letter of the standard.
Roger Corman
Corman Technologies
www.cormanlisp.com
From: Joe Marshall
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <oev45aja.fsf@comcast.net>
David Steuber <·············@verizon.net> writes:
> Starting with a basic knowledge of computer programming and having
> access to existing public domain source code, how long would it take
> a single person to build a fully ANSI compliant Lisp implementation
> as a personal project?
Seriously?
I'll make a guess that a good hacker with extensive Lisp knowledge and
experience could do it by themselves in something like 5-6 years.
This is an `order of magnitude' guess, so I'd say there's *no way* to
do it half a year, and that 50 years ought to be ample. (Actually,
I'd be really surprised to see it done in, say, 4 years, and I'd begin
to doubt the person's lisp ability after, say, 12 years.)
I don't think there is much in the way of `public domain' (as in, no
copyright whatsoever) source code that will be of much help.
What do you consider `basic' knowledge of computer programming?
`Teach yourself Java in 21 days'? A bachelor's degree from Berkeley?
> Assume no current knowledge of Lisp.
Add another few years, then.
> Also assume no other Lisp is available as a bootstrap.
The few years you just added is for them to build a bootstrap lisp.
It is likely that they'll get part way into it and decide to start all
over, but they'll have a mini-lisp at that point.
> Is any other info required to come up with a ball park estimate?
Sure. How much are you willing to pay for a better estimate?
--
~jrm
Joe Marshall <·············@comcast.net> writes:
> I don't think there is much in the way of `public domain' (as in, no
> copyright whatsoever) source code that will be of much help.
The library of general Common Lisp functionality that is distributed
with CMUCL should be a significant help. Likewise, PCL, while not in
the public domain, can also provide a boost.
It would be great if somebody was to start a project which would
implement as much of Common Lisp as possible based on a small set of
primitives. Given such a library of code, people could experiment
with compilers and run-times targeting this minimal set of primitives
and hopefully get a complete Common Lisp for free!
From: Christopher C. Stacy
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <uvfpb1th2.fsf@dtpq.com>
>>>>> On 23 Nov 2003 01:11:56 -0500, Carl Shapiro ("Carl") writes:
Carl> Joe Marshall <·············@comcast.net> writes:
>> I don't think there is much in the way of `public domain' (as in, no
>> copyright whatsoever) source code that will be of much help.
Carl> The library of general Common Lisp functionality that is distributed
Carl> with CMUCL should be a significant help. Likewise, PCL, while not in
Carl> the public domain, can also provide a boost.
Carl> It would be great if somebody was to start a project which would
Carl> implement as much of Common Lisp as possible based on a small set of
Carl> primitives. Given such a library of code, people could experiment
Carl> with compilers and run-times targeting this minimal set of primitives
Carl> and hopefully get a complete Common Lisp for free!
But there are already several complete Common Lisp implementations for
free. Is there some target platform that is not adequately supported?
Would someone's small set of primitives really accomodate an efficient
implementation of full Common Lisp? Given that there are no standard
subsets of Common Lisp -- one of the points of the language is that it
contains things that you want --- is there some reason to believe that
the existing implementations are bloated?
I wouldn't say that it would "be great" for someone to spin their
wheels on difficult problems that have already been solved, to no
particularly useful end. Wouldn't it be more worthwhile for someone
to work on improving the existing implementations, or on writing
libraries that everyone can use? Or in writing an application
that will benefit someone? Maybe even make some money by deploying
more Common Lisp applications in industry?
······@dtpq.com (Christopher C. Stacy) writes:
> But there are already several complete Common Lisp implementations for
> free. Is there some target platform that is not adequately supported?
> Would someone's small set of primitives really accomodate an efficient
> implementation of full Common Lisp? Given that there are no standard
> subsets of Common Lisp -- one of the points of the language is that it
> contains things that you want --- is there some reason to believe that
> the existing implementations are bloated?
I do not believe my desire for such a system is a consequence of the
existing free implementations being either bloated or not. I would
like to experiment with changes to the implementation strategy of a
Lisp system without having to worry about undocumented or
under-documented interactions between functionality which is the
logical province of library-level or kernel-level code. Furthermore,
I would want to benchmark my changes on the large Common Lisp systems
I work with on a daily basis.
> I wouldn't say that it would "be great" for someone to spin their
> wheels on difficult problems that have already been solved, to no
> particularly useful end. Wouldn't it be more worthwhile for someone
> to work on improving the existing implementations, or on writing
> libraries that everyone can use? Or in writing an application
> that will benefit someone? Maybe even make some money by deploying
> more Common Lisp applications in industry?
My interest in such a system is derived from my experience delivering
real-world Common Lisp applications. For example, I have been in
situations where the extant Common Lisp environments are not suitable
to deliver in the targeted environment for one reason or another.
People in my position have been driven to such hacks as translating
(by machine or by hand) large tracts of Lisp code to get the desired
interactions with the host system "just right".
I may have my head in the sand, but from my perspective, it is not
practical to specialized an existing Common Lisp to meet unique
performance or structural properties for application. There are scads
of commercial concerns with specialized Lisp implementations, each
implemented to be deployed in a specialized environment. Most of
these systems are described as being "Scheme-like" and I believe that
often the "Scheme-like" attribution is due to the fact it is easier to
engineer a Lisp to be "Scheme-like" than "Common Lisp-like". I do not
harbor a personal disdain for Scheme, but I am of the Common Lisp
persuasion -- if I have to implement a specialized Lisp I would want
to bill it as resembling Common Lisp. Having a large library of
shrink-wrapped and easily retargeted Common Lisp proto-matter would
significantly lower the engineering expense of my endeavor.
From: Christopher C. Stacy
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <u4qwvquee.fsf@dtpq.com>
Well, if you want to start from scratch, I suppose you had better get
going and plan on doing nothing else for 60-80 hours a week, for about
the next 3 years. If you're pretty good, and know what you're doing,
you ought to have a credibly competitve Common Lisp implementation
running by the winter of 2007.
But I see no reason to believe that yours will be better for your
purposes than the existing ones. Quite the contrary, since unless
you have very unique requirements (you didn't actually say what any
of them were), the existing implementations will have been making
progress in those directions outracing your dead start.
But certainly it is entirely your business if it makes you happy to do
that, so don't let people like me nay-say you! I just wonder for your
own good if you're severly underestimating the scope of the project.
······@dtpq.com (Christopher C. Stacy) writes:
> Well, if you want to start from scratch, I suppose you had better get
> going and plan on doing nothing else for 60-80 hours a week, for about
> the next 3 years. If you're pretty good, and know what you're doing,
> you ought to have a credibly competitve Common Lisp implementation
> running by the winter of 2007.
Let's pop the stack a few times and recall the post that you had
originally followed up on: there are already huge tracts of code which
could be incorporated as part of a portable library. Nobody should
have to start from scratch! If somebody refactors this library in
terms of a small set of Lisp primitives, no one else should have to
derive such a subsequent design from first principles ever again.
If I recall correctly, Portable Standard Lisp was organized in such a
fashion (albeit, at a different level of granularity). There was a
set of primitives which embodied machine specific knowledge (such as
the opening of a stack frame) which one had to specify. In theory,
the rest of the system was then gotten for free.
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2r7zz47h0.fsf@verizon.net>
······@dtpq.com (Christopher C. Stacy) writes:
> I wouldn't say that it would "be great" for someone to spin their
> wheels on difficult problems that have already been solved, to no
> particularly useful end. Wouldn't it be more worthwhile for someone
> to work on improving the existing implementations, or on writing
> libraries that everyone can use? Or in writing an application that
> will benefit someone? Maybe even make some money by deploying more
> Common Lisp applications in industry?
Yes to all the above except that improving the best free
implementation might require a rewrite, not that I would know.
As for what Carl Shapiro would wish for, I have some of that wish too.
I might go a step further and wish for a system that could be
manipulated by some genetic algorithm to produce the best possible
machine code for a Lisp system on a target platform. More
realistically, the algorithm should have some escape clause for "this is
good enough".
I honestly don't know what sort of breakthrough it would be to
automate the process of compiler design or if that is even possible.
I don't know all the subtle details of Rice's Theorem. I've only ever
thought of that as the halting problem where the halt was substituted
by some arbitrary function.
There are a lot of things that I want to do with my time and not
enough time to do them all. Lisp is like a strange attractor to me.
I go off in strange orbits but I keep coming back to Lisp. I have
this strange desire to build a Lisp system so that I can fully
understand it and bend it to my will. Being able to take advantage of
existing building blocks should reduce the time and effort to do
that. Maybe.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber writes:
> Yes to all the above except that improving the best free
> implementation might require a rewrite, not that I would know.
Not necessarily. A couple of examples:
- GNU CLISP: one might add the remaining missing ANSI Common Lisp
functionality, and perhaps also make PCL work again so that McCLIM
could be used with CLISP.
- SBCL: just grep for the hundreds of "FIXME" strings in the source
tree. No need for a rewrite.
> There are a lot of things that I want to do with my time and not
> enough time to do them all. Lisp is like a strange attractor to me.
Sounds familiar...
> I go off in strange orbits but I keep coming back to Lisp. I have
> this strange desire to build a Lisp system so that I can fully
> understand it and bend it to my will. Being able to take advantage of
Rewriting a system from scratch is not the only way of understanding
it. But if this is your preferred way of learning, by all means do it.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
From: Joe Marshall
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <1xry631i.fsf@comcast.net>
David Steuber <·············@verizon.net> writes:
> There are a lot of things that I want to do with my time and not
> enough time to do them all. Lisp is like a strange attractor to me.
> I go off in strange orbits but I keep coming back to Lisp. I have
> this strange desire to build a Lisp system so that I can fully
> understand it and bend it to my will.
I know the feeling.
I wouldn't *recommend* writing an ANSI Common Lisp from scratch
because it is a lot of work and there exist other implementations.
However, if you feel compelled to, by all means do it! I think that
writing a lisp system is a great way to learn a lot of rather
interesting things.
Most language implementations out there seem to start with the efforts
of one or two people who aren't satisfied with what they have and feel
compelled to hack languages.
--
~jrm
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2wu9r48qc.fsf@verizon.net>
Joe Marshall <·············@comcast.net> writes:
> What do you consider `basic' knowledge of computer programming?
> `Teach yourself Java in 21 days'? A bachelor's degree from Berkeley?
Somewhere in between I would think. No Java knowledge should be
required. However C would be rather helpful as it is close to the
machine. Assembler would be very helpful indeed.
Knuth's The Art Of Computer Programming series seems to hold the
essentials. Abelson, Sussman & Sussman's Structure and
Interpretation of Computer Programs has some good theory in it
although I don't see how you are supposed to write a Scheme compiler
in Scheme. Chicken and the egg there.
Does that BS from Berkeley go into the gory details of program
loading and execution? Would it help me with the REPL?
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: Joe Marshall
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <ekvxvl8e.fsf@ccs.neu.edu>
David Steuber <·············@verizon.net> writes:
> Does that BS from Berkeley go into the gory details of program
> loading and execution? Would it help me with the REPL?
I don't know, I never went to Berkeley. I hope it doesn't, though.
The gory details of loading and execution (as in getting an ELF or
PECOFF into RAM and fixing up the relocs) are minutae.
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2brr03kmr.fsf@verizon.net>
Joe Marshall <···@ccs.neu.edu> writes:
> David Steuber <·············@verizon.net> writes:
>
> > Does that BS from Berkeley go into the gory details of program
> > loading and execution? Would it help me with the REPL?
>
> I don't know, I never went to Berkeley. I hope it doesn't, though.
> The gory details of loading and execution (as in getting an ELF or
> PECOFF into RAM and fixing up the relocs) are minutae.
True. But the devil is in the details. I never got that deep
myself. But I did have to understand C calling to write assembler
routines to be called by a C program. The assembler and compiler
were both Borland, so I expect that there were some details handled
for me behind the scenes.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
From: Joe Marshall
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <llq4ddr3.fsf@comcast.net>
David Steuber <·············@verizon.net> writes:
> Joe Marshall <···@ccs.neu.edu> writes:
>
>> David Steuber <·············@verizon.net> writes:
>>
>> > Does that BS from Berkeley go into the gory details of program
>> > loading and execution? Would it help me with the REPL?
>>
>> I don't know, I never went to Berkeley. I hope it doesn't, though.
>> The gory details of loading and execution (as in getting an ELF or
>> PECOFF into RAM and fixing up the relocs) are minutae.
>
> True. But the devil is in the details. I never got that deep
> myself. But I did have to understand C calling to write assembler
> routines to be called by a C program. The assembler and compiler
> were both Borland, so I expect that there were some details handled
> for me behind the scenes.
A good comp. sci. education should focus on the broad picture of how
one would go about finding out the details rather than on what the
details are. For something like calling assembly code from C, for
example, given that I don't know what machine (but probably an x86
variant given that it is Borland), I *do* know that I can count on the
PC being at my routine, that there is a return address somewhere (99%
of the time that's on the stack), that there are some arguments
somewhere (90% of the time on the stack, maybe in a register or two),
that someone has to clean up (given that it is C it is most likely,
but not always, the caller), that the return value has to go somewhere
(either an `accumulator' or top of stack), that the linker has to find
my assembly routine (probably have to prefix an underscore and arrange
for the assembler to `export' the name), and that the compiler will
need a declaration for my assembly function. Marshaling arguments
isn't an issue because assembly and C are at roughly the same level.
I can find out those details by (I hope!) reading the docs, or (if
necessary) disassembling real code.
I wouldn't want to take a course that went into the exact mechanisms
used by each of GCC, MSVC, Borland, and Watcom!
--
~jrm
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m2d6bg12z4.fsf@verizon.net>
Joe Marshall <·············@comcast.net> writes:
> I can find out those details by (I hope!) reading the docs, or (if
> necessary) disassembling real code.
>
> I wouldn't want to take a course that went into the exact mechanisms
> used by each of GCC, MSVC, Borland, and Watcom!
True enough. I guess what I should have said and meant was that at
some level you should know that these things go on and you would have
to know that in order to write a device driver or a linker or
whatever.
Concentrating on a specific product (like say Java?) is probably a
good way to guarantee obsolete knowledge by the time you get the
degree.
I guess Knuth knew a thing or two when he used MIX ;-). That
language never gets old.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber wrote:
> although I don't see how you are supposed to write a Scheme compiler
> in Scheme. Chicken and the egg there.
Since implementations of Scheme already exist, you can actually run
a Scheme compiler that you've written in Scheme. The "chicken and
the egg" is no more a problem than it would be for a Scheme compiler
written in Common Lisp, C, Smalltalk-72, Algol 60, or IBM 1620 assembly
language.
Will
David Steuber <·············@verizon.net> wrote in message news:<··············@verizon.net>...
> Starting with a basic knowledge of computer programming and having
> access to existing public domain source code, how long would it take
> a single person to build a fully ANSI compliant Lisp implimentation
> as a personal project?
>
> Assume no current knowledge of Lisp. Also assume no other Lisp is
> available as a bootstrap.
Under these assumptions, it's hard to see where the individual's
*motivation* would come from to get started. Personal projects that
have no motivation behind them tend to never show a line of code.
From: David Steuber
Subject: Re: Another algorithmic complexity question
Date:
Message-ID: <m265h83jzm.fsf@verizon.net>
···@ashi.footprints.net (Kaz Kylheku) writes:
> Under these assumptions, it's hard to see where the individual's
> *motivation* would come from to get started. Personal projects that
> have no motivation behind them tend to never show a line of code.
This is one of my biggest problems. Another one is starting a
project, making some good progress, and then loosing interest in it.
In this case there are two opposing forces. ANSI Lisp is frickin
huge. I am nearly 100% certain I won't do something from scratch.
If I do get moving, I will probably do something with SBCL. Still
hypothetical there. The other force is my desire to play with the
language implementation. The language is already designed and that
is the hard part.
I don't expect to be taken too seriously without showing code. I
know better.
Then there is that annoying reality of having to eat which means
having to work which takes time and energy. This is the downside to
not being independently wealthy.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> Starting with a basic knowledge of computer programming and having
> access to existing public domain source code, how long would it take
> a single person to build a fully ANSI compliant Lisp implimentation
> as a personal project?
I don't know about ANSI, but I believe KCL (basically implementing
CLTL1) was written in about 2 years, mostly by 3 or 4 people.
You have to say how serious an implementation you're talking about.
Do you have to have a real compiler? Generational GC? A good FFI?
Or is it enough to just pass some test suite for the standard?
I actually don't think CL is all that complicated, as opposed to
merely being big. That is, if you can implement some simple subset
(basically Scheme) then what you have left to code up is a big runtime
library. So this is mostly a question of how many keystrokes per day
you can pound into your computer, and also how effective you are at
finding useful existing code (e.g. for math libraries) out on the net.
Of course in the above, I'm reading "basic knowledge of programming"
as having some skill at language implementation including languages
like (say) Javascript or Python.
David Steuber <·············@verizon.net> writes:
> > Starting with a basic knowledge of computer programming and having
> > access to existing public domain source code, how long would it take
> > a single person to build a fully ANSI compliant Lisp implimentation
> > as a personal project?
The trick may be the "access to existing public domain source code" part.
How much do you want to code from scratch (and in what language!), vs. how
much are you willing to borrow?
Because, just so you know, a full ANSI-compliant Common Lisp implementation
is already available with source code (basically) in the public domain:
CMUCL, and/or SBCL.
So if you're willing to start by "borrowing" that public domain code, you
could probably "build" an implementation in a day :-).
If you just want to start with only the tools from a regular programming
language, e.g. C/C++, and write Lisp from scratch, then you're surely talking
man-years of effort. But then I wonder what the "having access to source code"
part was about...
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Don Geddis <···@geddis.org> writes:
> The trick may be the "access to existing public domain source code" part.
> How much do you want to code from scratch (and in what language!), vs. how
> much are you willing to borrow?
>
> Because, just so you know, a full ANSI-compliant Common Lisp implementation
> is already available with source code (basically) in the public domain:
> CMUCL, and/or SBCL.
I think he specifically said you can't use existing lisp
implementations but I gathered you could use anything else you wanted.
I took it to mean you can use other kinds of libraries, for example
bignum and rational arithmetic (maybe GMP), complex math functions,
maybe a Boehm garbage collector, stuff like that. Maybe you could
even take something like the Python bytecode interpreter to bang into
shape for Lisp.
I think if you just want a minimal implementation and aren't trying to
recreate CMUCL, then some people here are overestimating the problem.
CLISP was written by two students if I remember correctly. I don't
know how long it took them, but I don't think they worked on it full
time during that period either.
In article <··············@ruckus.brouhaha.com>,
Paul Rubin <·············@NOSPAM.invalid> wrote:
(personal) Is this the Paul Rubin I know?
If so, what's your actual email-addr these days?
Thanks,
David
·······@panix.com (David Combs) writes:
> Paul Rubin <·············@NOSPAM.invalid> wrote:
>
> (personal) Is this the Paul Rubin I know?
Hey, yep. Wow, small world! What's happening man?
> If so, what's your actual email-addr these days?
I mostly don't use one, due to rampant spam. See http://phr.cx (the
url in my From: line) if you want to drop me a note.
Paul Rubin <·············@nospam.invalid> wrote:
> You have to say how serious an implementation you're talking about.
> Do you have to have a real compiler? Generational GC? A good FFI?
> Or is it enough to just pass some test suite for the standard?
^^^^
I nominate this a "Understatement of the Year 2003".
Cheers,
-- Nikodemus
Nikodemus Siivola <······@random-state.net> writes:
> Paul Rubin <·············@nospam.invalid> wrote:
>
>> You have to say how serious an implementation you're talking about.
>> Do you have to have a real compiler? Generational GC? A good FFI?
>> Or is it enough to just pass some test suite for the standard?
> ^^^^
> I nominate this a "Understatement of the Year 2003".
Seconded.
But remember that not all of us have the privilidge of knowing
intimately how hard that task is. Especially when most people have
probably never even looked at a few chapters of the spec. (I'll spare
Kent the pain of seeing yet another mention of which one I'm thinking of
in particular. :)
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> But remember that not all of us have the privilidge of knowing
> intimately how hard that task is. Especially when most people have
> probably never even looked at a few chapters of the spec. (I'll spare
> Kent the pain of seeing yet another mention of which one I'm thinking of
> in particular. :)
I've never implemented CL so it's quite possible that I'm missing
something. But can you tell me what's so hard about it? Does CLISP
not count as a valid implementation? What about the original KCL?
Paul Rubin <·············@NOSPAM.invalid> writes:
> I've never implemented CL so it's quite possible that I'm missing
> something. But can you tell me what's so hard about it? Does CLISP
> not count as a valid implementation?
Are you trying to kill me by making me laugh my guts out? I'm assuming
you mean "valid" as in "complies to the spec, to the letter".
> What about the original KCL?
Well, other than the fact that it doesn't even purport to comply to the
standard?
But really, let's not beat this dead horse.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
Rahul Jain <·····@nyct.net> writes:
> > I've never implemented CL so it's quite possible that I'm missing
> > something. But can you tell me what's so hard about it? Does CLISP
> > not count as a valid implementation?
>
> Are you trying to kill me by making me laugh my guts out? I'm assuming
> you mean "valid" as in "complies to the spec, to the letter".
Well does it? I'm not a CL wizard.
> > What about the original KCL?
>
> Well, other than the fact that it doesn't even purport to comply to the
> standard?
There wasn't a standard at the time, but it purported to comply to
CLTL1 which was the closest thing available to a standard back then.
A bunch of stuff got added for CLTL2 but it was basically just more of
the same. The ANS standard is presumably similar. Remember that the
whole design of CL was already a standardization process, done by
combining elements of a bunch of existing Lisp systems, not created
out of the blue. I seriously doubt any changes between CLTL1 and the
ANS standard were really complicated rather than just the addition of
further features. CL is still a 1970's language deep down.
Paul Rubin <·············@NOSPAM.invalid> wrote in message news:<··············@ruckus.brouhaha.com>...
> I seriously doubt any changes between CLTL1 and the
> ANS standard were really complicated rather than just the addition of
> further features. CL is still a 1970's language deep down.
Right. CLOS was easy to do. The condition system a mere triviality,
dashed off by some random hacker in 10 minutes I expect.
··········@tfeb.org (Tim Bradshaw) writes:
> > I seriously doubt any changes between CLTL1 and the
> > ANS standard were really complicated rather than just the addition of
> > further features. CL is still a 1970's language deep down.
>
> Right. CLOS was easy to do. The condition system a mere triviality,
> dashed off by some random hacker in 10 minutes I expect.
Those things don't appear especially harder than the stuff that was
already in CLTL1. Nobody dashes them off in 10 minutes but nobody
dashes off a CLTL1 implementation in 10 minutes either.
* Paul Rubin wrote:
> Those things don't appear especially harder than the stuff that was
> already in CLTL1. Nobody dashes them off in 10 minutes but nobody
> dashes off a CLTL1 implementation in 10 minutes either.
I think decent CLOS performance without HW support was more-or-less an
open problem at various points in the late 80s - at least I was told
it was by people who I trust. But actually, yes, CLtL1 was `really
complicated' as well.
--tim
Tim Bradshaw <···@cley.com> writes:
> > Those things don't appear especially harder than the stuff that was
> > already in CLTL1. Nobody dashes them off in 10 minutes but nobody
> > dashes off a CLTL1 implementation in 10 minutes either.
>
> I think decent CLOS performance without HW support was more-or-less an
> open problem at various points in the late 80s - at least I was told
> it was by people who I trust. But actually, yes, CLtL1 was `really
> complicated' as well.
But it's empirically observable that CLTL1 was implemented by small
groups of people (CLISP, KCL) in a reasonable amount of time. The
question is whether anything in ANSI CL is qualitatively harder than
CLTL1, or whether it's just a matter of grinding out more code. CLOS
doesn't seem so complicated if you just implement straightforwardly
and take the performance hit. However, I may still be missing something.
Paul Rubin <·············@NOSPAM.invalid> wrote in message news:<··············@ruckus.brouhaha.com>...
> CLOS
> doesn't seem so complicated if you just implement straightforwardly
> and take the performance hit.
Well, yes, it's easy (or easier) to implement something
catastrophically slow.
> However, I may still be missing something.
Maybe that catastophically slow implementations of languages tend not
to do very well?
··········@tfeb.org (Tim Bradshaw) writes:
> > However, I may still be missing something.
>
> Maybe that catastophically slow implementations of languages tend not
> to do very well?
Python is doing pretty good despite being much slower than any serious
CL implementation.
Paul Rubin <·············@NOSPAM.invalid> writes:
> Tim Bradshaw <···@cley.com> writes:
> > > Those things don't appear especially harder than the stuff that was
> > > already in CLTL1. Nobody dashes them off in 10 minutes but nobody
> > > dashes off a CLTL1 implementation in 10 minutes either.
> >
> > I think decent CLOS performance without HW support was more-or-less an
> > open problem at various points in the late 80s - at least I was told
> > it was by people who I trust. But actually, yes, CLtL1 was `really
> > complicated' as well.
>
> But it's empirically observable that CLTL1 was implemented by small
> groups of people (CLISP, KCL) in a reasonable amount of time. The
> question is whether anything in ANSI CL is qualitatively harder than
> CLTL1, or whether it's just a matter of grinding out more code. CLOS
> doesn't seem so complicated if you just implement straightforwardly
> and take the performance hit.
These are design decisions that must be made. You are welcome to
try rolling your own, and it shouldn't take you very long, since it
should be so easy to do.
CLtL was not a spec. It was only a de-facto spec, and it had a lot
of unclear areas, which left implementations free to do almost whatever
they wanted to do. The Ansi process, among other things, clarified a
lot of the intentions of CLtL, (or established intentions when there
were none apparent), and that is very hard for implementors to do.
For a one-implementation language, intention establishment is trivial;
just look to the implementation, and whatever it does was the
intention...
> However, I may still be missing something.
Two things: CL implementation experience, and customers/users.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig <·····@franz.com> writes:
> CLtL was not a spec. It was only a de-facto spec, and it had a lot
> of unclear areas, which left implementations free to do almost whatever
> they wanted to do. The Ansi process, among other things, clarified a
> lot of the intentions of CLtL, (or established intentions when there
> were none apparent), and that is very hard for implementors to do.
I can't quite parse what you're saying here. ANSI is a specification,
not an implementation. It sounds to me that if CLTL1 left some things
unclear and implementers had to figure out on their own devices what
to do, then it sounds like following ANSI is easier than following
CLTL1, because implementers have to figure out less on their own. If
you mean that the extra clarity meant writing ANSI standard was more
work for the specifiers than writing CLTL1, then sure, however, that
again makes life easier for implementers, not harder. If you mean
CLTL1's unclarity left implementers free to choose easier approaches
to some features where ANSI requires harder approaches, I'd be
interested in examples.
> > However, I may still be missing something.
>
> Two things: CL implementation experience, and customers/users.
Customers/users are irrelevant to the original question, of whether it
was feasible for someone to implement CL as a one-person project
without having done Lisp implementation before. I take that to mean
writing an implementation that follows the spec and passes any test
suites is all that's asked for. Ending up with a product that
attracts customers and users was not part of the question.
Paul Rubin <·············@NOSPAM.invalid> writes:
> I take that to mean writing an implementation that follows the spec
> and passes any test suites is all that's asked for.
You know, I wish people would stop saying "all" or "just" there.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> > I take that to mean writing an implementation that follows the spec
> > and passes any test suites is all that's asked for.
>
> You know, I wish people would stop saying "all" or "just" there.
What's the issue? The guy asked how hard it would be to implement CL
as a personal project. It sounded like the goal was to learn
something about Lisp and Lisp implementation. In particular, code
stability, runtime performance competitive with heavyweight
implementations, support for features that real users of production
implementations might demand but which are not part of the ANSI spec,
portability among different target platforms, etc. etc. etc. are NOT
part of the mission. All that's asked for is being conformant to the
standard, and that should be much easier to accomplish than building
something competitive with CMUCL. There, I said it again ;-).
Paul Rubin wrote:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>>>I take that to mean writing an implementation that follows the spec
>>>and passes any test suites is all that's asked for.
>>
>>You know, I wish people would stop saying "all" or "just" there.
>
>
> What's the issue?
It might help to dig up the release notes of recent versions of mature
implementations of CL and see how many items mention coming into
compliance with the spec. Or Google up articles on this NG in which some
implementation or other is unmasked as having missed this detail or that.
The spec covers a lot of ground in a lot of detail. You see the good
news in that, but not the bad: imagine a Heathkit Space Shuttle.
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Paul Rubin <·············@NOSPAM.invalid> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>> > I take that to mean writing an implementation that follows the spec
>> > and passes any test suites is all that's asked for.
>>
>> You know, I wish people would stop saying "all" or "just" there.
>
> What's the issue? The guy asked how hard it would be to implement
> CL as a personal project. It sounded like the goal was to learn
> something about Lisp and Lisp implementation. [...] All that's
> asked for is being conformant to the standard, and that should be
> much easier to accomplish than building something competitive with
> CMUCL. There, I said it again ;-).
The issue is that it's surprisingly hard to make something that passes
even the half-built[*] test suites, concerns about efficiency or
portability of implementation aside. You might be enlightened by
looking at the ansi-tests subdirectory of the gcl CVS tree.
Christophe
[*] maybe closer to three-quarters.
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Paul Rubin <·············@NOSPAM.invalid> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
> > > I take that to mean writing an implementation that follows the spec
> > > and passes any test suites is all that's asked for.
> >
> > You know, I wish people would stop saying "all" or "just" there.
>
> What's the issue? The guy asked how hard it would be to implement CL
> as a personal project. It sounded like the goal was to learn
> something about Lisp and Lisp implementation. In particular, code
> stability, runtime performance competitive with heavyweight
> implementations, support for features that real users of production
> implementations might demand but which are not part of the ANSI spec,
> portability among different target platforms, etc. etc. etc. are NOT
> part of the mission. All that's asked for is being conformant to the
> standard, and that should be much easier to accomplish than building
> something competitive with CMUCL. There, I said it again ;-).
I'm rather surprised to see this thread pop up again.
I asked my original question from a naive perspective. I thought
that there were a number of compliant implementations and test suites
for compliance. Oops.
I also had in mind that I could borrow the work of others (CMUCL,
SBCL, any other free lisp with appropriate license). Maybe I didn't
make that clear enough in the original question. Although compiling
an existing implementation is not the answer to the question ;-)
Although I didn't express it, there was also an 'eat my own dog food'
motive behind the question. From my perspective, there is no lisp
with features x, y, and z. What to do? Build my own perhaps. Why?
So I could then go on to developing easily distributed software with
my custom Lisp system.
This is only worth doing if the complexity of building the lisp
system is not more than programming a project with an existing system
and finding a way to fit x, y, and z into that.
I actually came away with something useful. One, an ANSI spec lisp
is hard. Two, I'm better off using an existing system. Three, SBCL
looks like the system I want. Four, SBCL does not yet have the
features I think I need (like threading on PPC). I know threading is
not part of ANSI. The reason for ANSI is so that when you write code
that says it is ANSI, it should work without change on a system that
also says that it is ANSI.
ANSI is for portability. If I don't care about porting code to
another architecture, then I don't need ANSI so much. If I don't
care about other people being able to maintain the code at some point
in the future, I don't need ANSI at all. The latter point is
actually more important. Conformance to ANSI enlarges the developer
base that can understand the code and add to it.
I'm leaving a lot of stuff out. I expect people here are more than
intelligent enough to be able to fill in the gaps. This isn't rocket
science. It's harder ;-)
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
David Steuber <·············@verizon.net> writes:
> From my perspective, there is no lisp
> with features x, y, and z. What to do? Build my own perhaps.
Or take an existing Lisp system s, extend it with x, y and z, and send
the result to the developers of s. Why should we have a lot of toys
instead of a small number of powerful implementations?
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
David Steuber <·············@verizon.net> writes:
> I actually came away with something useful. One, an ANSI spec lisp
> is hard. Two, I'm better off using an existing system. Three, SBCL
> looks like the system I want. Four, SBCL does not yet have the
> features I think I need (like threading on PPC).
Can I suggest a solution? I'd love a native threading SBCL on PPC :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> David Steuber <·············@verizon.net> writes:
>
> > I actually came away with something useful. One, an ANSI spec lisp
> > is hard. Two, I'm better off using an existing system. Three, SBCL
> > looks like the system I want. Four, SBCL does not yet have the
> > features I think I need (like threading on PPC).
>
> Can I suggest a solution? I'd love a native threading SBCL on PPC :-)
If I knew how to add native threading for the PPC to SBCL I would be
on it ;-)
I'm getting myself back to basics right now. It seems I can't do
everything at once :-(. I am using Xcode to learn programming for OS
X. Unfortunately, Objective-C is weird. I'm still not clear on who
has responsibility for allocating memory for objects and deallocating
it just as an example. I was surprised when running code in the
debugger to see that objects were having their -init method called
when I didn't put code in to do that :-/.
If that isn't a reason to want to program in Lisp, I don't know what
is.
Everything I want to learn is big. Bigger than my brain it seems.
--
One Emacs to rule them all. One Emacs to find them,
One Emacs to take commands and to the keystrokes bind them,
All other programming languages wish they were Lisp.
* Paul Rubin wrote:
> I can't quite parse what you're saying here. ANSI is a specification,
> not an implementation. It sounds to me that if CLTL1 left some things
> unclear and implementers had to figure out on their own devices what
> to do, then it sounds like following ANSI is easier than following
> CLTL1, because implementers have to figure out less on their own.
Here are two specs for a Lisp dialect:
1.
2. See http://www.lispworks.com/reference/HyperSpec/index.html
Which do *you* think it will be harder to conform to?