Lisp is an old language, and so is CL. So why don't use all the
hindsight and start making a new language(not necessaryly from
scratch)?
Haven't the problems and drawbacks been recognized and discussed?
What do we do with this knowledge now besides debating it over and
over again?
Why not make a new language?
Don't we have enough people with a lot of knowledge in this newsgroup?
I understand that this is what Paul Graham is doing with ARC. What if
the Lisp community starts a free software project with the same goal?
Of course I think that everyone would welcome Paul Graham if he wants
to contribute to this project.
PS: If you think that CL(or any other) is already the perfect language
please ignore this thread, don't reply to it!
From: Christopher C. Stacy
Subject: Re: Designing the next Lisp
Date:
Message-ID: <uad9pw12y.fsf@dtpq.com>
>>>>> On 31 Aug 2003 21:29:07 -0700, thelifter ("thelifter") writes:
thelifter> Haven't the problems and drawbacks been recognized and discussed?
thelifter> What do we do with this knowledge now besides debating it
thelifter> over and over again?
Probably most people are interested in getting things accomplished
with the existing language, and do not see major problems or drawbacks
that necessitate inventing a new language.
thelifter> Why not make a new language?
thelifter> Don't we have enough people with a lot of knowledge in this newsgroup?
In reverse order: Yes; and, Because they have better things to do.
·········@gmx.net (thelifter) writes:
> Lisp is an old language, and so is CL. So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
Why do think there is a need for a new language? Common Lisp is old,
I agree, but it doesn't means it's obsolete. All lot of concepts in
this language are really advanced are doesn't exists in other so
called /modern/ languages. If you look closer, you'll find that C#
is older in term of concepts than Common Lisp. So, think about it,
which language needs a rework?
Moreover, designing a language is a complex, long and hard task. A
new language takes years to mature. I don't want to wait 10 years
for the next mature and modern language because I need it
today. It's Common Lisp.
--
Frederic Brunel
thelifter wrote:
> Lisp is an old language, and so is CL. So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
>
> Haven't the problems and drawbacks been recognized and discussed?
>
> What do we do with this knowledge now besides debating it over and
> over again?
>
> Why not make a new language?
Why not work on improving the current one?
> Don't we have enough people with a lot of knowledge in this newsgroup?
>
> I understand that this is what Paul Graham is doing with ARC. What if
> the Lisp community starts a free software project with the same goal?
> Of course I think that everyone would welcome Paul Graham if he wants
> to contribute to this project.
>
> PS: If you think that CL(or any other) is already the perfect language
> please ignore this thread, don't reply to it!
I do not think it is the perfect language. I think that it is an
immense and stupid waste of resources to "start from scratch", when
contribution could (and should) be made to improve the current language.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
> Why not work on improving the current one?
Maybe because there are inherent problems that cannot be solved
without breaking backward compatibility?
> > PS: If you think that CL(or any other) is already the perfect language
> > please ignore this thread, don't reply to it!
>
> I do not think it is the perfect language. I think that it is an
> immense and stupid waste of resources to "start from scratch", when
> contribution could (and should) be made to improve the current language.
>
How much of a waste of resources do you consider answering to a post
without reading it carefully? I will quote myself:
> > hindsight and start making a new language(not necessaryly from
> > scratch)?
Let me add something. Consider that a language as big as CL is very
hard to port/implement(I think this is one of its main flaws).
How hard would it be to port CMUCL to Windows?
How many versions of Lisp do you know that can generate Java byte
code? AFAIK none and why? Because it's hard to port Lisp.
Why are there at least 3 Scheme implementations that can generate
Java BC? Because Sheme is very easy to implement(I'm not saying that
Sheme is a better language).
Consider SBCL(sbcl.sourceforge.net) which is a fork off from CMUCL.
How many time did they spend on it to make a more maintainable system
than CMUCL? Maybe the time would be better spend trying to make a new
and simpler implementation of a new Lisp like language?
Why do I think that simpler is better? Well this would be one of the
points to be discussed when starting to design the new language. At
least Guy Steele seems to have the same opinion. Read his "growing a
language" get it from:
http://www.research.avayalabs.com/user/wadler/
Enough for now...
"thelifter" <·········@gmx.net> wrote in message
·································@posting.google.com...
> Let me add something. Consider that a language as big as CL is very
> hard to port/implement(I think this is one of its main flaws).
>
> How hard would it be to port CMUCL to Windows?
>
> How many versions of Lisp do you know that can generate Java byte
> code? AFAIK none and why? Because it's hard to port Lisp.
>
> Why are there at least 3 Scheme implementations that can generate
> Java BC? Because Sheme is very easy to implement(I'm not saying that
> Sheme is a better language).
>
> Consider SBCL(sbcl.sourceforge.net) which is a fork off from CMUCL.
> How many time did they spend on it to make a more maintainable system
> than CMUCL? Maybe the time would be better spend trying to make a new
> and simpler implementation of a new Lisp like language?
In the design of Common Lisp, the priority was given to programmer (language
user) efficiency, rather than ease of implementation. I don't think most
programmers care about how hard it was to code the programming environment
they use, what they really appreciate is the power of the language.
--
Matthieu Villeneuve
> In the design of Common Lisp, the priority was given to programmer (language
> user) efficiency, rather than ease of implementation. I don't think most
> programmers care about how hard it was to code the programming environment
> they use, what they really appreciate is the power of the language.
As in all things, the importance of ease of implementation is not an
all-or-nothing deal, but a gradual tradeoff. While the ease of
implementing a language might not affect users directly, it affects
users indirectly, by affecting the quality of their development tools.
Consider, how many production-quality free C++ compilers are there vs
free C compilers? The difficulty of implementing C++ has greatly
reduced the number of viable implementations on the market. Similarly,
there is only one free production-quality CL implementation on the
market (CMUCL --- SBCL is just a fork of the same codebase) while
there are several similarly powerful Scheme compilers (Bigloo, Stalin,
MzScheme, etc).
I think that the layered approach of somthing like EuLisp would be a
better idea, though, I don't know the details of CMUCL's codebase and
can't really say where the complexity really lies.
·······@mindspring.com (Rayiner Hashem) writes:
>> In the design of Common Lisp, the priority was given to programmer (language
>> user) efficiency, rather than ease of implementation. I don't think most
>> programmers care about how hard it was to code the programming environment
>> they use, what they really appreciate is the power of the language.
>
> As in all things, the importance of ease of implementation is not an
> all-or-nothing deal, but a gradual tradeoff.
I (mostly) agree with this.
> While the ease of
> implementing a language might not affect users directly, it affects
> users indirectly, by affecting the quality of their development tools.
> Consider, how many production-quality free C++ compilers are there vs
> free C compilers?
I dunno... "production quality"... 1 C++ compiler (being generous to
gcc), and 1 C compiler? FORTRAN is even simpler to implement, but how
many production quality free compilers are there for that? What was
your point, anyway?
> The difficulty of implementing C++ has greatly
> reduced the number of viable implementations on the market. Similarly,
> there is only one free production-quality CL implementation on the
> market (CMUCL --- SBCL is just a fork of the same codebase)
Possibly the best-known commercial success story for free Lisps
involved the use of CLISP in ViaWeb/Yahoo Store. Rumour has it that
serious chip designers are using ACL2 under GCL. OpenMCL[1] has been
in _space_, for goodness' sake. I'm not even going to address your
"just a fork" comment, since you yourself admit your complete
ignorance; I'm simply going to point out that this sentence is vying
for the top spot for "least accurate comment ever".
Christophe
[1] well, technically not. But it was "the same codebase".
--
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)
In article <··············@lambda.jcn.srcf.net>, Christophe Rhodes
<·····@cam.ac.uk> wrote:
> OpenMCL[1] has been in _space_, for goodness' sake.
Minor correction: it was (a custom port of) Harlequin Lisp that flew in
space. OpenMCL was a spin-off of that effort, but it never flew.
(Actually, I should say it hasn't flown yet. :-)
CLisp was also under serious consideration for flight at one time.
The next Lispy language to fly in space will almost certainly be Python,
which is scheduled to go up on an experiment to the ISS some time in the
next few years. I don't remember the details, but if anyone's interested
let me know and I'll find out.
E.
In article <····················@k-137-79-50-101.jpl.nasa.gov>,
···@jpl.nasa.gov (Erann Gat) wrote:
> In article <··············@lambda.jcn.srcf.net>, Christophe Rhodes
> <·····@cam.ac.uk> wrote:
>
> > OpenMCL[1] has been in _space_, for goodness' sake.
>
> Minor correction: it was (a custom port of) Harlequin Lisp that flew in
> space. OpenMCL was a spin-off of that effort, but it never flew.
> (Actually, I should say it hasn't flown yet. :-)
>
> CLisp was also under serious consideration for flight at one time.
>
> The next Lispy language to fly in space will almost certainly be Python,
> which is scheduled to go up on an experiment to the ISS some time in the
> next few years. I don't remember the details, but if anyone's interested
> let me know and I'll find out.
OK, due to popular demand (one person asked for it :-)
The mission is called Low Temperature Microgravity Physics Facility
(LTMPF). Google for more info.
E.
>>>>> "E" == Erann Gat <···@jpl.nasa.gov> writes:
>> The next Lispy language to fly in space will almost certainly
>> be Python, which is scheduled to go up on an experiment to the
>> ISS some time in the next few years. I don't remember the
>> details, but if anyone's interested let me know and I'll find
>> out.
E> OK, due to popular demand (one person asked for it :-)
E> The mission is called Low Temperature Microgravity Physics
E> Facility (LTMPF). Google for more info.
Heh. Thanks.
--
Things will get better despite our efforts to improve them.
-- Will Rogers
>>>>> "rh" == Rayiner Hashem <·······@mindspring.com> writes:
rh> Similarly, there is only one free production-quality CL
rh> implementation on the market (CMUCL --- SBCL is just a fork of
rh> the same codebase)
admire his way of magestically sweeping aside 4 years of development
on SBCL, by some very talented programmers.
rh> while there are several similarly powerful Scheme compilers
rh> (Bigloo, Stalin, MzScheme, etc).
MzScheme does not include a compiler that's comparable to the other
implementations, so I don't know why you're including it in the list.
Bigloo is a nice implementation, particularly if you're linking with C
modules. However, the dialect of Scheme that it implements is
considerably less powerful than Common Lisp: its object system is much
less powerful than CLOS, its condition system is primitive compared
with CL's, it has no extensible streams, no bignums, no complex
numbers, no rational numbers. Most importantly, like Stalin, it's a
batch implementation: you don't benefit from the interactive,
incremental development style which is IMO one of the nicest aspects
of lisp-like languages.
Furthermore, both of these systems implement different subsets of the
Scheme programming language (as standardized by IEEE or R5RS), which
makes it difficult to use the same code for any serious problem on
both implementations. Contrast this with Common Lisp, where (unless
you're using the network or some other non-standarized aspect) it's
not a problem to write non-trivial programs that are portable between
compliant implementations.
rh> I think that the layered approach of somthing like EuLisp would
rh> be a better idea, though, I don't know the details of CMUCL's
rh> codebase and can't really say where the complexity really lies.
thank you for sharing your uninformed speculation with USENET.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
> admire his way of magestically sweeping aside 4 years of development
> on SBCL, by some very talented programmers.
Excuse me on that one, I meant no offense. I am not that familier with
SBCL myself, but whenver I
>
>
> rh> while there are several similarly powerful Scheme compilers
> rh> (Bigloo, Stalin, MzScheme, etc).
>
> MzScheme does not include a compiler that's comparable to the other
> implementations, so I don't know why you're including it in the list.
Mzc is a very good compiler, though its not quite as powerful as
Bigloo or Stalin.
>
> Bigloo is a nice implementation, particularly if you're linking with C
> modules. However, the dialect of Scheme that it implements is
> considerably less powerful than Common Lisp...
Agreed, but who's comparing? We're talking about the compilers, not
the overall environment. To me, that means code generation, type
inference, tail call optimization, etc.
> thank you for sharing your uninformed speculation with USENET.
That was entirely uncalled for. Its not my speculation at all. Several
very smart people behind EuLisp considered the layred approach a good
one, and its one that makes sense given traditional CS theory. Either
politely disagree, or keep your nasty comments to yourself.
·······@mindspring.com (Rayiner Hashem) writes:
[Eric Marsden]
>> thank you for sharing your uninformed speculation with USENET.
> That was entirely uncalled for. Its not my speculation at all. Several
Your exact words, which you have conveniently trimmed from the quoted
text, were
I think that the layered approach of somthing like EuLisp would be a
better idea, though, I don't know the details of CMUCL's codebase and
can't really say where the complexity really lies.
In the self-admitted absence of any knowledge of CMUCL, "uninformed
speculation" is one of the kinder ways to describe the value of your
opinion about ideal implementation strategies for it.
> very smart people behind EuLisp considered the layred approach a good
> one, and its one that makes sense given traditional CS theory. Either
In fact, you don't even know how much of CMUCL is or isn't layered
already. Given that SBCL developers have managed to reduce the
codebase to around 60% of its former size (involving some code
cleanup, removal of a couple of stagnated backends, and the loss of
several extensions[*]) and yet /still/ have a full CL that purports to
confirm to ANSI, I think that's a pretty good indication that there
was some kind of layering already.
The figures, as computed by wc -l
22281 lines of .c and .h files in SBCL CVS src/ directory
214871 lines of Lisp ditto (i.e. excluding contrib/ and tests/)
42245 lines of .c and .h files in CMUCL CVS 2003-07-03 src/ directory
388092 lines of Lisp ditto
[*] Most of the interesting ones are now being maintained in the
contrib/ tree or separately. Apart from the byte compiler, which
would be nice to have back if it can be done cleanly, the only missing
thing that people express any real interest in is Hemlock, and that's
being worked on too.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
We're talking about the layering of the language spec, not layering of
the implementation. I thought the reference to EuLisp (which had a
layered language spec) made that clear. I said that I thought that a
layered language spec would be easier for implementers to work with,
not that layering the implementation would make it easier.
I thought we were talking about the usefulness of "yet another lisp
language which (layered or not) will have to include all of Common Lisp
anyway". The argument being that it is better to contribute to one of
the Common Lisp projects instead of pouring resources in the
specification of YALLW(LON)WHTIAOCLA :)
Meaning. There has been talk here (Dan Barlow talked about it) about a
low level OS interface. That is a "layered" spec that can be worked
out. Why not devote time to that? Or why not perfect UFFI? These seem
better and more self contained tasks than going ahead to work on a new
language.
Rayiner Hashem wrote:
> We're talking about the layering of the language spec, not layering of
> the implementation. I thought the reference to EuLisp (which had a
> layered language spec) made that clear. I said that I thought that a
> layered language spec would be easier for implementers to work with,
> not that layering the implementation would make it easier.
Cheers
--
Marco
thelifter wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
>
>
>>Why not work on improving the current one?
>
>
> Maybe because there are inherent problems that cannot be solved
> without breaking backward compatibility?
Like?
>
>
>>>PS: If you think that CL(or any other) is already the perfect language
>>>please ignore this thread, don't reply to it!
>>
>>I do not think it is the perfect language. I think that it is an
>>immense and stupid waste of resources to "start from scratch", when
>>contribution could (and should) be made to improve the current language.
>>
>
>
> How much of a waste of resources do you consider answering to a post
> without reading it carefully?
I read it and reread it carefully. You got me in a bad day :)
> I will quote myself:
>
>
>>>hindsight and start making a new language(not necessaryly from
>>>scratch)?
>>
>
> Let me add something. Consider that a language as big as CL is very
> hard to port/implement(I think this is one of its main flaws).
Why do you need another implementation of Common Lisp?
>
> How hard would it be to port CMUCL to Windows?
I do not know. I let these questions to people who are have the time to
work on this. The folks working on SBCL are getting there AFAIU.
>
> How many versions of Lisp do you know that can generate Java byte
> code? AFAIK none and why? Because it's hard to port Lisp.
Maybe because the JVM does not have nice support for some of the key
features you *do not want to leave out* from Common Lisp?
But let's ask a better question. Why do you need to compile to the JVM?
>
> Why are there at least 3 Scheme implementations that can generate
> Java BC? Because Sheme is very easy to implement(I'm not saying that
> Sheme is a better language).
Yes. Scheme is so easy to implement (you can write a Scheme interpreter
in CL) that there are a godzillion different (all slightly incompatible)
implementation of it.
> Consider SBCL(sbcl.sourceforge.net) which is a fork off from CMUCL.
> How many time did they spend on it to make a more maintainable system
> than CMUCL? Maybe the time would be better spend trying to make a new
> and simpler implementation of a new Lisp like language?
Beacause another Lisp like language will have to include all the key
features of Common Lisp (multidimensional arrays with displacing,
multiple dispatching, the arithmetic tower etc etc) to make it palatable
to me. So the SBCL folks decided (rightly so) to isolate a problem in
the CMUCL implementation and to fix it. This has led to a very
interesting set of solutions and very valuable code being produced.
Yet, you are still begging the real question. Why do you need a
different language? Because you cannot implement a Common Lisp on a
weekend?
> Why do I think that simpler is better? Well this would be one of the
> points to be discussed when starting to design the new language. At
> least Guy Steele seems to have the same opinion. Read his "growing a
> language" get it from:
> http://www.research.avayalabs.com/user/wadler/
>
> Enough for now...
I read the Steele's paper (as well as the "Lambda the Ultimate...."
series of papers). The arguments he makes about "Growing a Language"
are very good, but ultimately the issue is that they all have the power
of hindsight. Common Lisp is what we have. The language is not perfect
and it needs some fixing. Now: UFFI is a very good fix. Why can't you
devote your resources to something like this? The truth is that working
in Common Lisp is harder because you need to achieve consensus.
Not that I will ever forbid you from go ahead and design a new language.
You will just to bear with my criticism for your wasteful position.
Make it simple. Not simpler.
Cheers
--
Marco
Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
> Why do you need another implementation of Common Lisp?
Perhaps you need one that can generate Java byte code? The correct
answer is: you never know until you need it. Btw, why do you need
another language besides assembler or C or Fortran? Three is enough
isn't it?
>
> >
> > How hard would it be to port CMUCL to Windows?
>
> I do not know. I let these questions to people who are have the time to
> work on this. The folks working on SBCL are getting there AFAIU.
Another poster in this thread said there are working 4 years on it. 4
years!!! This seems enough time to implement a new language.
> >
> > How many versions of Lisp do you know that can generate Java byte
> > code? AFAIK none and why? Because it's hard to port Lisp.
>
> Maybe because the JVM does not have nice support for some of the key
> features you *do not want to leave out* from Common Lisp?
>
> But let's ask a better question. Why do you need to compile to the JVM?
This question is totaly irrelevant. Someone might need it some day
maybe because he has to use a lot of Java legacy code. There could be
lots of reasons ... we can't predict them all.
Why do you need another language besides C ... ?
·········@gmx.net (thelifter) writes:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
> > Why do you need another implementation of Common Lisp?
>
> Perhaps you need one that can generate Java byte code? The correct
> answer is: you never know until you need it. Btw, why do you need
> another language besides assembler or C or Fortran? Three is enough
> isn't it?
>
> >
> > >
> > > How hard would it be to port CMUCL to Windows?
> >
> > I do not know. I let these questions to people who are have the time to
> > work on this. The folks working on SBCL are getting there AFAIU.
>
> Another poster in this thread said there are working 4 years on it. 4
> years!!! This seems enough time to implement a new language.
That's four years of "free time" coding, for most of the part. By a
communication, but (at least in parts) not "close-knit" group. On the
whole, I'd say it's now passed beyond its initial statement ("let's
make the compiler and environment compilable by another lisp
compiler") and has some ratehr interesting stuff happening in it. Some
of it even spin-offs of stuff I did for the code-base (it was,
however (and rightly) not included as-was, because it was ugly,
brute-force code that is now *much* neater).
As for getting Java bytecode out of it... I don't know. A start would
be to write VOPs and assembler templates for Java bytecode and go from
there, but I'm not sure it's trivial.
//Ingvar
--
Self-referencing
Five, seven, five syllables
This haiku contains
Ingvar Mattsson <······@cathouse.bofh.se> writes:
> ·········@gmx.net (thelifter) writes:
>
>> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
>> > > How hard would it be to port CMUCL to Windows?
>> >
>> > I do not know. I let these questions to people who are have the time to
>> > work on this. The folks working on SBCL are getting there AFAIU.
>>
>> Another poster in this thread said there are working 4 years on it. 4
>> years!!! This seems enough time to implement a new language.
>
> That's four years of "free time" coding, for most of the part.
Lest anyone be confused by this thread, those four years of free time
coding by SBCL maintainers has included to my knowledge a sum total of
zero man-hours work on any putative port to Windows.
Some "non-official" people have fiddled with the task, and have
achieved partial results; no-one has yet provided a patch. :-)
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)
thelifter wrote:
> Marco Antoniotti <·······@cs.nyu.edu> wrote in message news:<················@cs.nyu.edu>...
>
>>Why do you need another implementation of Common Lisp?
>
>
> Perhaps you need one that can generate Java byte code? The correct
> answer is: you never know until you need it. Btw, why do you need
> another language besides assembler or C or Fortran? Three is enough
> isn't it?
If you need to generate Java byte codes go ahead and write the backend
for CMUCL. With ECL you could conceivably write a Java backend. Why
don't you just do that?
As per C, FORTRAN and Assembly, you will concede that CL kind of has
features that these languages do not have, won't you?
>
>
>>>How hard would it be to port CMUCL to Windows?
>>
>>I do not know. I let these questions to people who are have the time to
>>work on this. The folks working on SBCL are getting there AFAIU.
>
>
> Another poster in this thread said there are working 4 years on it. 4
> years!!! This seems enough time to implement a new language.
I follow the SBCL developer list regularly. I do not recall seeing much
(or any) traffic pertaining a port to Windows.
>
>
>>>How many versions of Lisp do you know that can generate Java byte
>>>code? AFAIK none and why? Because it's hard to port Lisp.
>>
>>Maybe because the JVM does not have nice support for some of the key
>>features you *do not want to leave out* from Common Lisp?
>>
>>But let's ask a better question. Why do you need to compile to the JVM?
>
>
> This question is totaly irrelevant. Someone might need it some day
> maybe because he has to use a lot of Java legacy code. There could be
> lots of reasons ... we can't predict them all.
> Why do you need another language besides C ... ?
These are rethorical questions. I posed the problem of resources and of
the overall features that the future language should have. I am
questioning your planning, not the hypothetical possibilities of the
human mind :)
If you want to specify a new Lisp language, go ahead and do it. I just
thinkl your time would be better spent producing a UFFI interface to the
JNI.
Cheers
--
Marco
·········@gmx.net (thelifter) writes:
> Let me add something. Consider that a language as big as CL is very
> hard to port/implement(I think this is one of its main flaws).
>
> How hard would it be to port CMUCL to Windows?
Ok. Let's get rid of garbage collector (btw, isn't it easier to just
call free instead of meditating over generational GC?), make pathnames
be just strings, remove lambda list keywords, multiple value
functions, make type declarations be necessary, remove hierarchy of
types, so that FFI would be trivial, and I'd also remove native code
compiler (no other LISP implementation has it, isn't it? Hmm, well, at
least no one allows to call the compiler at runtime -- that's
absolutely sure) -- will you be happy?
> Why do I think that simpler is better?
According to Gabriel, there are simplicity to use and simplicity to
implement, and they conflict. Which one do you prefer?
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
Alexey Dejneka <········@comail.ru> wrote in message news:<··············@comail.ru>...
> According to Gabriel, there are simplicity to use and simplicity to
> implement, and they conflict. Which one do you prefer?
Do these goals necessaryly conflict? Think of Java: small core,
everything else in Class libraries. If you port the small core to any
system you can use all the classes(at least if they are pure Java).
Wouldn't a similar approach be possible with a Lisp like language? The
secret is to keep the core small and powerful.
thelifter wrote:
> Alexey Dejneka <········@comail.ru> wrote in message news:<··············@comail.ru>...
>
>>According to Gabriel, there are simplicity to use and simplicity to
>>implement, and they conflict. Which one do you prefer?
>
>
> Do these goals necessaryly conflict? Think of Java: small core,
> everything else in Class libraries. If you port the small core to any
> system you can use all the classes(at least if they are pure Java).
>
> Wouldn't a similar approach be possible with a Lisp like language? The
> secret is to keep the core small and powerful.
Note that a considerably large part of the Java core API is
platform-dependent and some of it even interacts in "dirty" ways with
what you call the core. (For example, Java's serialization is able
create instances of classes with no public constructors. Scary, eh? ;)
In order to get a useful Java runtime environment up and running from
scratch you would have to implement a lot more than, say, the ANSI CL
standard requires for Common Lisp.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> The secret is to keep the core small and powerful.
Hmm. Someone who hasn't done anything like this is telling folks who have
the "secret", and berating them for not spending their time doing his project
his way.
For some reason, the words "insightful" and "productive" don't come to mind.
·········@gmx.net (thelifter) writes:
> Alexey Dejneka <········@comail.ru> wrote in message news:<··············@comail.ru>...
>> According to Gabriel, there are simplicity to use and simplicity to
>> implement, and they conflict. Which one do you prefer?
>
> Do these goals necessaryly conflict? Think of Java: small core,
> everything else in Class libraries. If you port the small core to any
> system you can use all the classes(at least if they are pure Java).
Java... Small core... Ever built a JDK?
Regards,
Julian
--
*NOW* is a point in time that is already gone.
From: Nils M Holm
Subject: Re: Designing the next Lisp
Date:
Message-ID: <bj47r2$3ei$1@online.de>
thelifter <·········@gmx.net> wrote:
> Wouldn't a similar approach be possible with a Lisp like language? The
> secret is to keep the core small and powerful.
ArrowLISP is a dialect of LISP that takes this appraoch quite to the
extreme. The interpreter is purely symbolic, it just knows pairs,
lists, and symbols, and that's it. Its code has a size of less than
2000 lines in a rather low-level language. There are 17 primitive
functions, the rest is implemented in LISP.
Even functions performing integer arithmetics are implemented in LISP.
Numbers are represented by lists of digits with an alternative syntax
allowing you to write (PLUS '#123 '#456) rather than (PLUS '(1 2 3)
'(4 5 6)).
The whole thing works pretty well, I have written a lot of useful
programs in it. No need to say, though, that its programs run at a
rather slow pace.
If you are interested, visit http://www.t3x.org/LISP/ALISP/
There's an online version of the interpreter, too. Example
programs can be found at http://www.t3x.org/LISP/CL/
(CL meaning 'code library', not 'Common LISP').
Nils.
--
Nils M Holm <···@t3x.org> -- http://www.t3x.org/~nmh
Alexey Dejneka schrieb:
> ... Hmm, well, at
> least no one allows to call the compiler at runtime -- that's
> absolutely sure) -- will you be happy?
Hm. You write a very tricky piece of Java-Code (maybe you need some days
for this). You give this tricky code to the Java Compiler and this
software hacks your tricky code following older rules made by the sun
people. Now you run that hacked tricky code and the virtual machine
comes along meaning 'bah, I know a quicker way to calculate that (hacked
tricky code)'. At least you see a screen filled with things which you
can easily have without any tricks (in case thats not enough, there is a
seperat runtime engine with more goodies). This is Java like I know it.
Yes, I'm happy to see the results of my work by simply pressing return.
stefan
> So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
IMHO the reason this hasn't been happening is because lisp has no
"benevolent dictator" ala linux, python, perl et al. There are, of
course, pros and cons to this.
I think the "not from scratch" part is important- If there was a BD
he/she could add improvement and remove rough edges, as in the
proverbial "pebble in a river" metaphor. I think this could really
benefit LISP.
PG is basically attempting this, but is using an unusual approach that
(again IMHO) is turning many people off because they feel his style is
(for lack of a better description) anti-modularity and
anti-consistency, with its strong emphasis on macros and limited
type/object system. Personally, I find much appeal to his approach and
hope people give it a chance.
> PS: If you think that CL(or any other) is already the perfect language
> please ignore this thread, don't reply to it!
What, you think asking nicely will help? ;)
...but I definitely think it is a great compliment to CL that
intelligent people can claim that it is nigh perfect and do so with a
straight face.
In article <····························@posting.google.com>,
·········@gmx.net (thelifter) wrote:
> Lisp is an old language, and so is CL. So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
>
> Haven't the problems and drawbacks been recognized and discussed?
A group of Lisp gurus did this about ten years ago. As I understand it,
their new language (Dylan) got a lot of support and interest from
typical members of this group, right up to the point where they decided
to go with a non S-expr syntax.
-- Bruce
> A group of Lisp gurus did this about ten years ago. As I understand it,
> their new language (Dylan) got a lot of support and interest from
> typical members of this group, right up to the point where they decided
> to go with a non S-expr syntax.
>
> -- Bruce
Whoa. I can already see this thread spinning out of control :) I'm
curious, though. How does the Dylan community react to something like
Goo, which is a lot like Dylan only in prefix form. Would any Lispers
be more interested in Dylan if a prefix version was available?
·······@mindspring.com (Rayiner Hashem) writes:
> > As I understand it, their new language (Dylan) got a lot of
> > support and interest from typical members of this group, right up
> > to the point where they decided to go with a non S-expr syntax.
> How does the Dylan community react to something like Goo, which is a
> lot like Dylan only in prefix form.
However,
"Lisp lists will most likely be deprecated and program fragments
will be represented by a richer data structure which can capture
source locations and hygiene information."
http://www.ai.mit.edu/~jrb/goo/manual.44/goomanual_51.html
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
In article <····························@posting.google.com>,
·······@mindspring.com (Rayiner Hashem) wrote:
> > A group of Lisp gurus did this about ten years ago. As I understand it,
> > their new language (Dylan) got a lot of support and interest from
> > typical members of this group, right up to the point where they decided
> > to go with a non S-expr syntax.
> >
> > -- Bruce
>
> Whoa. I can already see this thread spinning out of control :) I'm
> curious, though. How does the Dylan community react to something like
> Goo, which is a lot like Dylan only in prefix form.
For myself, I became interested in Dylan when it had only a prefix
syntax, and remained so when it went infix. It happens that I like the
present syntax better than the original one, but I'd prefer either to CL.
Goo is being done by Dylan people and it's interesting to seem them do a
lightweight prototype of the sort of thing I'd like to add to Gwydion
Dylan.
-- Bruce
In article <···························@copper.ipg.tsnz.net>, Bruce
Hoult <·····@hoult.org> wrote:
> In article <····························@posting.google.com>,
> ·······@mindspring.com (Rayiner Hashem) wrote:
>
> > > A group of Lisp gurus did this about ten years ago. As I understand it,
> > > their new language (Dylan) got a lot of support and interest from
> > > typical members of this group, right up to the point where they decided
> > > to go with a non S-expr syntax.
> > >
> > > -- Bruce
> >
> > Whoa. I can already see this thread spinning out of control :) I'm
> > curious, though. How does the Dylan community react to something like
> > Goo, which is a lot like Dylan only in prefix form.
>
> For myself, I became interested in Dylan when it had only a prefix
> syntax, and remained so when it went infix. It happens that I like the
> present syntax better than the original one, but I'd prefer either to CL.
>
> Goo is being done by Dylan people and it's interesting to seem them do a
> lightweight prototype of the sort of thing I'd like to add to Gwydion
> Dylan.
Interestingly, I sat in on some of the design meetings where the
syntax issue was discussed. Seems like most of the Lisp types were
indifferent about syntax, but the non-Lisp folks were adamant about
having non-sexpr syntax. I was one of the Lisp folks, and like a
typical Lisper, was receptive to non-sexpr syntax. In fact, I argued in
favor of it. To my surprise, I found that I didn't care for it; I much
preferred the version of Dylan we were using in the Newton group that
had a Lisp syntax. It was basically Scheme+clos+a few new things.
thelifter schrieb:
Hallo, here are some comments.
> Lisp is an old language, and so is CL. So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
There are so many new languages, see what happens to them.
Why put one on top of these?
> Haven't the problems and drawbacks been recognized and discussed?
More important is: have that change anything? (If no, what are we doing
here?)
> What do we do with this knowledge now besides debating it over and
> over again?
For example, Kent Pittman writes articles (and books). I can leran from
this. That is only one aspect.
> Why not make a new language?
I think there are some points you do not like very much (not only, that
all is old). So instead of creating all new, it would be easier to
create parts new and put that in a wellknown form: a package.
Sure, this is nothing complete new, but it is a small step in this
direction. (I leave Java, because I start with Java 1.0 and rewrite my
applets 3 times before I say No). Lisp offers you the package concept,
it is a good way to bring in something new.
> I understand that this is what Paul Graham is doing with ARC. What if
> the Lisp community starts a free software project with the same goal?
> Of course I think that everyone would welcome Paul Graham if he wants
> to contribute to this project.
Well, this is real world. You can try it. I can't help you for this.
But take a look at the ARC (I do not know that enough) and compare it
with the old stuff. You may think about the hard work and is it all done
there?. You may ask P.G. what he missed there, what he want to add and
you may imagine the manpower this needs.
In most cases there is one or two idea to do something in a different
way (meaning also modern way), and maybe this needs to adjust the
environment in parts. This is nothing complete new but with lisp, this
should be realizable in a relative amount of time.
> PS: If you think that CL(or any other) is already the perfect language
> please ignore this thread, don't reply to it!
Perfect? Oh. Big aim. Easier in understandable, I would say. Think of
all those who look at Lisp the first time (some are complete confused).
Last Yoda ask: will he finnised what he start? -pause-
stefan
"thelifter" <·········@gmx.net> wrote in message
·································@posting.google.com...
> Lisp is an old language, and so is CL. So why don't use all the
> hindsight and start making a new language(not necessaryly from
> scratch)?
>
> Haven't the problems and drawbacks been recognized and
> discussed?
If _you_ have problems with the language, then those problems
can be of 3 kinds:
1) Missing features. This is not a problem: just implement them,
then eventually make the code available for all.
2) Useless features (or features you consider obsolete). This is
not a problem: don't use them. The fact that they are in the
language shows that other people than you use them, but that's
not a problem to you.
3) Badly designed bits of the language. Do not assume that you have
enough insight to judge that. Ask real experts. As far as I can
remember, there always were good reasons for design decisions
that have been contested in the past.
On the other hand, if you don't personnaly have problems with the
language, then this discussion is pointless.
--
Matthieu Villeneuve