Hello,
I will try to give an example of how I think a possible improvement to
CL could be made:
- Choose the smallest orthogonal subset of CL so that the whole of CL
can be expressed in terms of this subset. Call this subset
Ortho-Lisp(OL).
- Everything else is expressed as libraries, in terms of OL. I will
call it Rest-Lisp(RL).
Of course there is a danger here: if OL is very small RL might be very
inefficient to program. So there has to be some trade-off here. OL
should be reasonably powerful to enable a satisfactory efficient
implementation of RL.
Once this has been done we have the following advantages:
- Since OL hopefully will be rather small, all that is needed to port
CL to another system, is to port OL. RL just has to be recompiled
after OL has been ported.
- Since RL is expressed in terms of OL, optimizations in OL will
reflect in the whole system. Since OL will be small it should be much
easier to optimize and maintain.
- modularity: You just use the parts of RL that you need. Ideal for
small systems, micro devices...
Disadvantages: Comparing to the traditional way, where we have a big
OL, this approach might be less efficient because everything in RL has
to be expressed in terms of OL. This will make it impossible to use
low-level tricks as is possible if everything is part of OL. But there
is a solution to this:
The system should be implemented in such a way as to permit RL to be
programmed in C/Assembler(possibly other languages). Of couse from
outside they should behave exactly like they where programmed in terms
of OL, that is, in Lisp. In this manner it would be possible to
optimize those libraries where speed is essential.
These are just some ideas...I'm interested in your feedback...
In article <····························@posting.google.com>,
·········@gmx.net (thelifter) wrote:
> Hello,
>
> I will try to give an example of how I think a possible improvement to
> CL could be made:
>
> - Choose the smallest orthogonal subset of CL so that the whole of CL
> can be expressed in terms of this subset. Call this subset
> Ortho-Lisp(OL).
The smallest possible subset capable of describing everything else is {lambda}.
I doubt that's really what you want.
E.
Have you actually read the entire posting? Read the relevant part here:
Of course there is a danger here: if OL is very small RL might be very
inefficient to program. So there has to be some trade-off here. OL
should be reasonably powerful to enable a satisfactory efficient
implementation of RL.
···@jpl.nasa.gov (Erann Gat) wrote in message news:<····················@192.168.1.52>...
> In article <····························@posting.google.com>,
> ·········@gmx.net (thelifter) wrote:
>
> > Hello,
> >
> > I will try to give an example of how I think a possible improvement to
> > CL could be made:
> >
> > - Choose the smallest orthogonal subset of CL so that the whole of CL
> > can be expressed in terms of this subset. Call this subset
> > Ortho-Lisp(OL).
>
> The smallest possible subset capable of describing everything else is {lambda}.
>
> I doubt that's really what you want.
>
> E.
Yes, that's not what he really wants and one paragraph later
he makes that clear.
>>Of course there is a danger here: if OL is very small RL might be very
>>inefficient to program. So there has to be some trade-off here. OL
>>should be reasonably powerful to enable a satisfactory efficient
>>>implementation of RL.
Do you just read a post up to the point where you can find something
to sneer at?
·········@gmx.net (thelifter) writes:
> - Choose the smallest orthogonal subset of CL so that the whole of CL
> can be expressed in terms of this subset. Call this subset
> Ortho-Lisp(OL).
>
> - Everything else is expressed as libraries, in terms of OL. I will
> call it Rest-Lisp(RL).
What are you talking about? That's the way it already basically _is_.
(basically any "lisp" is like this)
> - Since OL hopefully will be rather small, all that is needed to port
> CL to another system, is to port OL. RL just has to be recompiled
> after OL has been ported.
What makes you think that anything in ANSI CL makes it hard to port in
the first place? An _implementation_ may be easy or hard to port as
the case may be, but there really isn't anything much in the language
that tosses a monkey wrench into such an effort. Why in the world do
you think otherwise?
Or are you _really_ saying, "gee implementing a CL from scratch is
hard, boo hoo hoo"? At this point, who cares, there are plenty of
implementations available on all sorts of hw/os configurations.
> These are just some ideas...I'm interested in your feedback...
see above...
/Jon
·········@gmx.net (thelifter) writes:
> I will try to give an example of how I think a possible improvement to
> CL could be made:
I will try to give an example of how I think a new computer systems
can be designed.
> - Choose the smallest orthogonal subset of CL so that the whole of CL
> can be expressed in terms of this subset. Call this subset
> Ortho-Lisp(OL).
Choose the smallest orthogonal subset of the operations that the
computer is required to do such that the whole system can be implemented
using only this subset. Call this subset Hardware.
> - Everything else is expressed as libraries, in terms of OL. I will
> call it Rest-Lisp(RL).
Everything else is implemented as software, to run on Hardware. I
will call this Software.
> Of course there is a danger here: if OL is very small RL might be very
> inefficient to program. So there has to be some trade-off here. OL
> should be reasonably powerful to enable a satisfactory efficient
> implementation of RL.
Of course there is a MASSIVE HONKING GREAT LACK OF ANY USEFUL CONTENT
in this article, because the concept that some parts of the system
will be dependent on the others is so bleeding obvious that even a 6
year old could easily grasp it, but yet I've chosen to point it out as
if it were a completely new insight whose brilliance should excuse me
from having to do any of the /actual/ work: the engineering decisions
and appropriate tradeoffs necessary to make a system which is actually
useful.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> wrote in message news:<··············@noetbook.telent.net>...
> Of course there is a MASSIVE HONKING GREAT LACK OF ANY USEFUL CONTENT
> in this article, because the concept that some parts of the system
> will be dependent on the others is so bleeding obvious that even a 6
> year old could easily grasp it, but yet I've chosen to point it out as
> if it were a completely new insight whose brilliance should excuse me
> from having to do any of the /actual/ work: the engineering decisions
> and appropriate tradeoffs necessary to make a system which is actually
> useful.
Hahahahaha, you gave me a good laugh. Thanks for it!
Of course the basic concept is obvious, but be careful, most ingenious
ideas are simple to understand but difficult to conceive.
The point is, that AFAIK CMUCL doesn't follow this rule of simplicity,
therefore the SBCL project is doing just that: simplifying CMUCL.
To be honest I don't know to what extent the different Lisp
implementations follow this modular design, maybe somone with more
knowledge could give us more useful info.
I just was wondering: why are there so much more Sheme implementations
than CL implementations? Maybe that CL is really BIG? Could we make
anything to make it easier to port? I didn't say to make it smaller,
but easier to port. This could be achieved if we follow the outlined
strategy.
To be honest, I don't believe that much implementations cared much
about portability in the first place. So it would be really
interesting to check how modular they really are.
More food for thought...
·········@gmx.net (thelifter) writes:
> The point is, that AFAIK CMUCL doesn't follow this rule of simplicity,
> therefore the SBCL project is doing just that: simplifying CMUCL.
Might I suggest that, in future, when you don't actually have a clue
about things, you ask, rather than assert? It makes for more
reasonable discussions.
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)
·········@gmx.net (thelifter) writes:
> I just was wondering: why are there so much more Sheme implementations
> than CL implementations? Maybe that CL is really BIG?
Yes, probably. The size of CL surely makes it difficult to create a brand
new implementation from scratch. But so what?
> Could we make anything to make it easier to port? I didn't say to make it
> smaller, but easier to port.
You're very, very confused about the difference between "easy to port" and
"easy to implement".
SBCL is already "easy to port". Likely, just as easy as it would be to get
Java or any other major language on some brand new architecture.
> This could be achieved if we follow the outlined strategy.
The "brilliant idea" you came up with is numbingly obvious to anyone who
actually works on (multi-platform) implementations. So they all _already_ do
it, and you've added no value by suggesting it.
> To be honest, I don't believe that much implementations cared much
> about portability in the first place.
Do you have _any_ evidence for your wild claims? Do you even know how many
platforms some of the major implementations (e.g. Franz's Allegro Common Lisp)
are available for?
Common Lisp is already available on a huge number of platforms, so it has
been ported to many architectures. This porting, however, was done with a
relatively small number of implementations. That is because Common Lisp is
large enough that making a new implementation is a significant amount of
work.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Lazlo's Chinese Relativity Axiom: No matter how great your triumphs or how
tragic your defeats---approximately one billion Chinese couldn't care less.
·········@gmx.net (thelifter) writes:
> To be honest, I don't believe that much implementations cared much
> about portability in the first place. So it would be really
> interesting to check how modular they really are.
If it's that interesting, why don't you actually do it instead of just
rambling about it on usenet? There are plenty of implementations out
there for which sources are available, so don't give me any crap about
cost or licensing.
Or is it, perhaps, that you meant to say "it would be very interesting
if someone else did the work for me and summarised their findings in a
form I can regurgitate later"?
> More food for thought...
I would have characterized it as some significant portion of the way
further through the digestive process than "food" usually is.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> I will try to give an example of how I think a possible improvement to
> CL could be made:
Go for it.
What? You're not interested? You're just trying to tell someone else
how to do it? Why should they listen to you? (Many of them actually
have relevant experience.) Failing that, how much are you offering to
pay? (FWIW, "they" actually never laughed at Einstein, but they did
laugh at Bozo the Clown.)
Or, if you prefer a more indirect lesson, consider why experienced
folk often say "everything is easy for someone who isn't doing the
work".
-andy
·········@gmx.net (thelifter) writes:
> I will try to give an example of how I think a possible improvement
> to CL could be made:
>
> - Choose the smallest orthogonal subset of CL so that the whole of
> CL can be expressed in terms of this subset. Call this subset
> Ortho-Lisp(OL).
>
> - Everything else is expressed as libraries, in terms of OL. I will
> call it Rest-Lisp(RL).
But why on earth do you think this has anything to do with making an
"improvment to Common Lisp"?
Let's assume you have designed your Ortho-Lisp. Now, one of two things
will happen:
1. It turns out that it is indeed possible to implement Common Lisp
atop of Ortho-Lisp with only negligible (or at least tolerable)
drawbacks compared to traditional, "monolithic" implementations, on
some or most platforms. This would be an excellent service to the
CL community (in terms of CL implementation technology), assuming
the hypothetical Ortho-Lisp is substantially easier to implement
and/or port than typical CL implementations are. Also, this
situation might very well inspire some effort to divide the Common
Lisp (and more) library into layers or modules, if there really is
sufficient interest in some "CL--".
2. You're not really able to implement Common Lisp over Ortho-Lisp, at
least not without accepting substantial problems. But Ortho-Lisp
might still be useful in its own right. Congratulations, you have
designed a new programming language, and good luck with attracting
a user community and an O'Reilly publishing contract.
Personally I think it would be very, very difficult to achieve
alternative 1. Also, I am personally not very interested in any
"CL--". But of course, having more Common Lisp implementations
available and more easily portable would be nice, although this is not
really a great concern of mine. So all in all I have doubts with
regards to both feasibility and motivation.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@cs.uit.no> writes:
> Let's assume you have designed your Ortho-Lisp. Now, one of two things
> will happen:
>
> 1. It turns out that it is indeed possible to implement Common Lisp
> atop of Ortho-Lisp with only negligible (or at least tolerable)
> drawbacks compared to traditional, "monolithic" implementations,
By the way, the word "monolithic" brings to mind the well known "Linux
is obsolete" Torvalds vs Tanenbaum thread.
Paolo
--
Paolo Amoroso <·······@mclink.it>
> By the way, the word "monolithic" brings to mind the well known "Linux
> is obsolete" Torvalds vs Tanenbaum thread.
That is a very bad analogy. Most of traditional problems with the
monolithic approach have been remedied by making Linux modular. I
believe this is precisely what the grand-parent poster intended to do
with his Lisp.
·······@mindspring.com (Rayiner Hashem) writes:
> Most of traditional problems with the monolithic approach have been
> remedied by making Linux modular. I believe this is precisely what
> the grand-parent poster intended to do with his Lisp.
And my point I suppose was that you don't need to "improve"
POSIX/Unix/the Linux ABI or somesuch to do this.
--
Frode Vatvedt Fjeld
> And my point I suppose was that you don't need to "improve"
> POSIX/Unix/the Linux ABI or somesuch to do this.
Its a matter of how you want to approach the problem. You could start
with CL and try to factor out the elementary core of CL, or build a CL
on top of an elementary core. Its the same as the Linux approach, say,
vs the BeOS approach. Linux was POSIX first then modularized
afterwards, while BeOS was modular first, and POSIX was built on top.
·········@gmx.net (thelifter) wrote in message news:<····························@posting.google.com>...
> I will try to give an example of how I think a possible improvement to
> CL could be made:
The problem is that a programming language
takes many years, or even decades, to mature
enough to become stable. And only then does
it start to realize its full power. Common
Lisp is only old in the same sense that
silicon is old. Silicon is one of the
foundations of modern technology. Common
Lisp can be one of the foundations of future
technology. Being almost as old and stable
as silicon is a big advantage for it, not a
liability.
The power of a programming language such as
Common Lisp comes in large part from how well
it's implemented. Solid implementations are
a key factor. But implementations of any
kind of sophisticated software become solid
gradually, over a period of many years. So
being stable gives it that advantage too.
Those who fear obsolescence are conflating the
evolution of computer hardware with software.
Good software adapts, and grows more powerful
with more powerful hardware. Common Lisp can
keep improving rapidly forever with no changes
at all in the language standard.
thelifter schrieb:
> I will try to give an example of how I think a possible improvement to
> CL could be made:
Just some thoughts:
; comments
' do nothing -second' is missing
"string"
(command data) ;classic way
[command body] ;new macro notation
{command extern} ;extern datas, packages or ffi stuff
/free for use\ ;what ever -*variable* -general exclude
\free for use/ ;what ever -structur-body -general include
Did I forget a combination?
You can change the :option to Linux like -option
You can set a general /? syntax-help
... see NCL2 :)
stefan