Common LISP: The Next Generation
P. Srinivas
The fall and Rise of LISP (or Lisp in 21st Century)
===================================================
Why are they so many splinter groups in LISP community? The strength
of LISP as an experimental vehicle contributed to its own misery. So
many dialects so few users!!
It took almost two decades to the world to realise the strengths of
LISP. Everybody is reinventing LISP in some form or other, some call
it Dylan, some other call it Java yet some more call it TCL. Yet some
people still call the good old name Scheme. People do not want to use
the word LISP. That is fine. A rose is in any name is a rose. But why
so many splinter groups? Apple started Dylan and now it is a defunct
language even before it is born. Tom Lord started Guile and now he
quits Cygnus; may be Guile is a dead language again. Whenever somebody
gets a new idea, he starts of a new dialect. I do not think it is
necessary to do that. If we have a common substrate then everybody can
start from there and build an extension package library.
Why not unite many of these "LISP"s under one umbrella? It is
perfectly feasible to define a common core and various extensions to
suite various needs. LISP as a hierarchy with the core functionality
as its root and various extensions as specialisations of the core
system. If I want to start a new LISP, I do not need to start from
scratch, Just add my extensions to the existing core!
Common LISP was a major step forwards. Thanks to many people. Since we
have ANSI standards, why dump all the success and everybody going in
their own way? Here we have an industrial strength tried and tested
language used in commercial world. Why not try improve the Common
LISP. Yes I am saying that it is time to work on new version of ANSI
Common LISP 2.0 or call it Common LISP 2000 to reflect the language of
the next century.
The following are some of my wish lists for the Common LISP: The
Next Generation.
1. Layered architecture (possibly a hierarchical) + autoloaded
libraries a la EULISP. Small executables are possible.
2. Clean and well integrated object system and MOP a la Dylan
3. Simplified package system
4. Cleaning of many builtins and possibly removing a few redundant
ones
5. A standard network interface
6. A standard interface for persistent object oriented database
7. A standard for multiprocessing with lightweight threads
8. Ability to create applets for Web based systems
9. Multi-media bindings such as JPEG and MPEG etc..
Current Common LISP is inadequate as a future programming language
without new features such as threads etc.
I think a time will come again where an OS will be implemented in LISP
again. LISP machine was not a failure. It was just too early for the world.
All the Lispers of the world unite! we have nothing to loose but a few
dialects! :-)
Srini
--
URL http://www.cs.usask.ca/homepages/grads/srini/
--------------------
Srinivas Palthepu Email: sr...@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
John Brewer
In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
Srinivas) wrote:
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
>
> 2. Clean and well integrated object system and MOP a la Dylan
>
> 3. Simplified package system
>
> 4. Cleaning of many builtins and possibly removing a few redundant
> ones
>
> 5. A standard network interface
>
> 6. A standard interface for persistent object oriented database
>
> 7. A standard for multiprocessing with lightweight threads
>
> 8. Ability to create applets for Web based systems
>
> 9. Multi-media bindings such as JPEG and MPEG etc..
It's been done. It's called Java. You might want to look into it sometime.
John Brewer Senior Software Engineer Spyglass, Inc.
Opinions expressed do not necessarily reflect those of my employer.
Heck, I'm old enough to remember the _first_ time Apple was "doomed".
Carl L. Gay
From: jbr...@spyglass.com (John Brewer)
Date: Fri, 23 Aug 1996 17:54:43 -0500
In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
Srinivas) wrote:
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
>
> 2. Clean and well integrated object system and MOP a la Dylan
>
> 3. Simplified package system
>
> 4. Cleaning of many builtins and possibly removing a few redundant
> ones
>
> 5. A standard network interface
>
> 6. A standard interface for persistent object oriented database
>
> 7. A standard for multiprocessing with lightweight threads
>
> 8. Ability to create applets for Web based systems
>
> 9. Multi-media bindings such as JPEG and MPEG etc..
It's been done. It's called Java. You might want to look into it sometime.
Don't know if that was supposed to be flame bait or not, but...
Yes, Java has many of the things on the above list, but what the
original poster was asking for was to add them to Common Lisp. That
request probably wasn't just accidental but rather a reflection of the
fact that Common Lisp is in many ways a more complete *language* than
Java, even though it lacks *standard* versions of most of the above.
He might just as well have proposed the following:
The following are some of my wishes for Java: The Next Generation.
A. Higher order functions
B. Multiple inheritance
C. Multimethods
D. Macros
To which someone would reply "It's been done. It's called Common
Lisp. You might want to look into it sometime."
Dylan, on the other hand not only has A - B, but also has 1, 2, 3, and
4. Personally, I hold out more hope that Dylan will add threads and a few
standard libraries than that Java will add A - D, which are
indispensable for large system development. Java's great for what it
does, but it's not a replacement for Common Lisp in many ways.
[comp.lang.tcl removed]
Philippe Troin
>>>>> "John" == John Brewer <jbr...@spyglass.com> writes:
John> It's been done. It's called Java. You might want to look
John> into it sometime.
Java is not LISP. Java is a C++ bastard.
Tcl is not LISP neither. Though Tcl has the idea of list, processing
lists in Tcl is painfully slow.
Phil.
Rainer Joswig
> so many splinter groups? Apple started Dylan and now it is a defunct
> language even before it is born.
They still have NewtonScript. People programming the Newton
are using a language with Lisp semantics. Don't tell them. ;-)
> Common LISP was a major step forwards. Thanks to many people. Since we
> have ANSI standards, why dump all the success and everybody going in
> their own way? Here we have an industrial strength tried and tested
> language used in commercial world. Why not try improve the Common
> LISP.
This is exactly my position, too. Some people might consider
Common Lisp unfixable. ;-)
> The following are some of my wish lists for the Common LISP: The
> Next Generation.
>
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
Seems difficult.
> 2. Clean and well integrated object system and MOP a la Dylan
We already have CLOS, which I think is quite nice. Let all
vendors implement the MOP. Many stuff in commercial CLs is
based on CLOS (pathnames, streams, conditions, ...). Make
it standard.
> 3. Simplified package system
Hmm.
> 5. A standard network interface
Yes, we need a common interface to TCP/IP services.
> 6. A standard interface for persistent object oriented database
Yes, we all would like that.
> 7. A standard for multiprocessing with lightweight threads
Some people think we should use the stuff CLIM. Why not? Should
be extended to handle multiple processors.
> 8. Ability to create applets for Web based systems
I would like to see the following:
- a mechanism to generate multiple secure packages at runtime
- the package gives you access to secure versions of
CL functionality
- code can be loaded (and compiled is necessary) into that package
- code can be safely executed in this package
- after execution finishes, remove the packages and clear all waste
- have a monitoring mechanism, which ensures the proper
behaviour of the code
> 9. Multi-media bindings such as JPEG and MPEG etc..
gzip and some graphics stuff in Lisp would be fine.
> Current Common LISP is inadequate as a future programming language
> without new features such as threads etc.
Commercial CLs have had threads for quite a while.
> I think a time will come again where an OS will be implemented in LISP
> again. LISP machine was not a failure. It was just too early for the world.
With current processors this thing would fly.
Additionally we need:
- a common FFI
- a common interface to SOM, CORBA, ...
- a common GUI (free CLIM !)
- mechanism for compile time type checking
But most of all we need a fair amount of people willing to work
on that stuff. I'm not optimistic. But still there are some
Lisp hackers out there who are developing useful code
(example: see the CL-HTTP stuff). I'm not interested in
developing technology just because it is fun. Lisp still
is being used in the high-end areas. Bring
it to the masses.
It has to have real value for users:
- speed up our development
- increase code quality
- increase reuse
- and most important it should lead to usable, fast, stable and
portable software that solves real problems
Stop wasting your time reinventing *nix for nth time.
Rainer Joswig
Ashley Branchfeather
In article <CGAY.96Au...@plastix.cs.uoregon.edu>,
cg...@plastix.cs.uoregon.edu (Carl L. Gay) wrote:
>A. Higher order functions
>B. Multiple inheritance
>C. Multimethods
>D. Macros
...
>Dylan, on the other hand not only has A - B, but also has 1, 2, 3, and
>4.
You meant A - D here, right? Dylan has macros and multimethods.
--
Ashley Branchfeather
Ashley Branchfeather
In article <joswig-2408...@news.lavielle.com>,
jos...@lavielle.com (Rainer Joswig) wrote:
>In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
>Srinivas) wrote:
>
>> so many splinter groups? Apple started Dylan and now it is a defunct
>> language even before it is born.
>
>They still have NewtonScript. People programming the Newton
>are using a language with Lisp semantics. Don't tell them. ;-)
I hear Apple originally acquired Dylan for the purpose of using it for the
Newton.
--
Ashley Branchfeather
Paul R. Potts
In article <AshleyB-2508...@news.halcyon.com>,
Ash...@halcyon.com (Ashley Branchfeather) wrote:
> I hear Apple originally acquired Dylan for the purpose of using it for the
> Newton.
In prototype, unreleased versions of the Newton project, Dylan or a
precursor to it (infix syntax, legend has it called Ralph?) was used.
The NewtonScript language, used for most Newton application development,
is actually very cool and I recommend that anyone interested in language
design take a look at it. While it isn't as featured as something like
Dylan, you get:
- very simple syntax, very small language, uncluttered design
- dynamic
- introspection features
- Compile ()
- every expression returns a value - uniform syntax
- closures
- a built-in mechanism for dual inheritance
- designed for very small RAM footprint
- built in data types for dynamic arrays, associative arrays (frames),
Unicode strings
Unfortunately, there is no stand-alone implementation. I think it would
make a good teaching language, introducing concepts of procedural
programming, recursion, object-oriented programming, inheritance, and
many of the things that are now taught using Lisp.
In fact, using Newt or some yet-to-be-written
development environment that would let you write NewtonScript on the
Newton, you could have a $700 student development workstation, with
keyboard; a faster Newton with more memory and a larger screen that
can fit in a student's backpack and support a development environment
as well as provide e-mail and web surfing would be quite cool.
-Paul-
Paul R. Potts - Project Engineering Lead - Health Media Research Lab
Comprehensive Cancer Center, University of Michigan - po...@umich.edu
Kenneth R. Knight
Ashley Branchfeather (Ash...@halcyon.com) wrote:
: In article <joswig-2408...@news.lavielle.com>,
: jos...@lavielle.com (Rainer Joswig) wrote:
: >In article <sjpw4hb...@alfresco.usask.ca>, sr...@alfresco.usask.ca (P.
: >Srinivas) wrote:
: >
: >> so many splinter groups? Apple started Dylan and now it is a defunct
: >> language even before it is born.
: >
: >They still have NewtonScript. People programming the Newton
: >are using a language with Lisp semantics. Don't tell them. ;-)
: I hear Apple originally acquired Dylan for the purpose of using it for the
: Newton.
Apple didn't acquire Dylan. They created it. Sadly they also are letting
it die as far as the Mac is concerned (laid off the entire Cambridge Lab
where Dylan was created). Dylan was considered for the resident language
on the Newton, but it was deemed to large. NewtonScript was developed by
Wlater Smith and owes a lot to langauges like Self (I guess I see some
LISP semantics in it too and that is fine - I really like NewtonScript
alot more than Java certainly, but that is another boat Apple could've
filled and didn't).
** Ken **
--
**** Kenneth Knight IA, Inc. Software Engineer ****
**** voice: (313)-995-9338 fax: (313)-995-9338 ****
**** email: kni...@sphinx.biosci.wayne.edu ****
Rainer Joswig
In article <potts-26089...@host-239.subnet-134.med.umich.edu>,
po...@cancer.med.umich.edu (Paul R. Potts) wrote:
> The NewtonScript language, used for most Newton application development,
> is actually very cool and I recommend that anyone interested in language
> design take a look at it.
It is an ugly (but brilliant) hack. ;-)
> While it isn't as featured as something like
> Dylan, you get:
You don't get:
- packages or modules
This is actually a big disadvantage!
- threads in NewtonScript
- functions and objects are not that well integrated
Rainer Joswig
Harley Davis
sr...@alfresco.usask.ca (P. Srinivas) writes:
> 1. Layered architecture (possibly a hierarchical) + autoloaded
> libraries a la EULISP. Small executables are possible.
Actually, EuLisp does not have autoloaded libraries. It has a module
system which requires you to explicitly import other modules you want
to use. We did try to make it possible to write automatic tools which
determine module imports; Ilog Talk does that in its development
environment.
-- Harley Davis
-------------------------------------------------------------------
Harley Davis net: da...@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
Phil Perucci
On 24 Aug 1996 04:12:44 -0700, Philippe Troin <ph...@tantale.fifi.org>
wrote:
>Java is not LISP. Java is a C++ bastard.
Definately a son-of-a-bitc? sometimes :-) Still, I think it will be
enough to cause Micro$loth's growth to plateau.
Anyway, can anyone shed any light on the ability of Java to perform
LISPs (eval) function? It would be very nice to generate Java code,
and pass it back to Java for compilation/execution, which is one of
the main things LISP was famous for (that and lists...).
Eugene O'Neil
In article <503ff7$5...@rigel.tm.informatik.uni-frankfurt.de>, Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> wrote:
>In article <32242ff6...@news.alt.net>,
>Phil Perucci <pper...@idsonline.com> wrote:
>
>> Anyway, can anyone shed any light on the ability of Java to perform
>> LISPs (eval) function? It would be very nice to generate Java code,
>> and pass it back to Java for compilation/execution, which is one of
>> the main things LISP was famous for (that and lists...).
>
>is well-nigh impossible in C++, only more so because of the so-called
>`security features'.
It is only impossible to do this in applets loaded off the network.
Applications, and other code loaded from the local file system, have no such
security restrictions. Some day, when authenticated applets show up,
it may even be possible for trusted applets to have less restrictions.
Not only is it possible to dynamically create java code in applications, it is
relatively easy. What you do is create a subclass of "classloader", which
is part of the core java distribution. Classloaders can convert an array
of bytes into a java class. Look up classloaders in a good book on Java
for more information: You will find it does most of the work for you. It's a
cakewalk compared to trying to do the same thing in C++.
-Eugene
Anselm Lingnau
> Anyway, can anyone shed any light on the ability of Java to perform
> LISPs (eval) function? It would be very nice to generate Java code,
> and pass it back to Java for compilation/execution, which is one of
> the main things LISP was famous for (that and lists...).
This is going to be well-nigh impossible for the same reasons why it
is well-nigh impossible in C++, only more so because of the so-called
`security features'.
Anselm
--
Anselm Lingnau ......................... lin...@tm.informatik.uni-frankfurt.de
Life is ours to be spent, not to be saved. --- D. H. Lawrence
Thomas Kwong
After playing with so many different programming languages for
a couple years, I finally realized that *language does not matter*.
It's almost a waste of time trying to relearn whatever we already
know. Do everyone in the world speaks the same language? No.
Stick with the language you like the most and be happy.
BTW, Java is the most fun language I have ever known, next to
Scheme.
Tom
P. Srinivas wrote:
>
> The fall and Rise of LISP (or Lisp in 21st Century)
> ===================================================
>
> Why are they so many splinter groups in LISP community? The strength
> of LISP as an experimental vehicle contributed to its own misery. So
> many dialects so few users!!
>
> [etc...]
Kenneth R. Knight
Phil Perucci (pper...@idsonline.com) wrote:
: Anyway, can anyone shed any light on the ability of Java to perform
: LISPs (eval) function? It would be very nice to generate Java code,
: and pass it back to Java for compilation/execution, which is one of
: the main things LISP was famous for (that and lists...).
At least on the Mac-based platforms (and I think it is prohibited period)
there is noe quivilent to LISPs EVAL (or NewtonScripts Compile :) ). We
had to write our own expression evaluator to do this sort of stuff.
However, Java does seem to have some nice tokening classes you can work
with that make the task easier.
Bruce O'Neel
Hi,
Is there documention for NewtonScript somewhere?
thanks.
bruce
Paul R. Potts (po...@cancer.med.umich.edu) wrote:
: In article <AshleyB-2508...@news.halcyon.com>,
: Ash...@halcyon.com (Ashley Branchfeather) wrote:
: > I hear Apple originally acquired Dylan for the purpose of using it for the
: > Newton.
: In prototype, unreleased versions of the Newton project, Dylan or a
: precursor to it (infix syntax, legend has it called Ralph?) was used.
: The NewtonScript language, used for most Newton application development,
: is actually very cool and I recommend that anyone interested in language
: design take a look at it. While it isn't as featured as something like
: Dylan, you get:
--
on...@arupa.gsfc.nasa.gov -- Bruce O'Neel HSTX (301) 286-1511 -- So
you get an error in the ninth decimal digit to the right of the
mantissa. I think even if you're an engineer, you're not going to see
this. -- Steve Smith, Intel, from EE Times, 11/7/94
James Thiele
In article <506ne4$s...@post.gsfc.nasa.gov> on...@arupa.gsfc.nasa.gov (Bruce O'Neel) writes:
>Hi,
> Is there documention for NewtonScript somewhere?
>
Newton docs, including NewtonScript, are at:
http://devworld.apple.com/dev/newton/techinfo/docs.pdf.html
or they were at 1:15 PM PST 30 Aug 1996.
Hope this helps,
James Thiele
j...@eskimo.com
Richard A. O'Keefe
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> writes:
[Java generating Java and then running it]
>is going to be well-nigh impossible for the same reasons why it
>is well-nigh impossible in C++, only more so because of the so-called
>`security features'.
A Java program can write text to a file.
This text may be source text.
A Java program can load new object code at run time
(combining this with the "security features" is what
the bytecode verifier is all about).
If this were not so, down-loaded applets would not be possible.
All that's needed is a way to call the compiler in between.
I had a notion this was possible...
--
Australian citizen since 14 August 1996. *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
John C. Wang
Thomas Kwong <tomk...@wilshire.com> wrote in article
<322614...@wilshire.com>...
> After playing with so many different programming languages for
> a couple years, I finally realized that *language does not matter*.
> It's almost a waste of time trying to relearn whatever we already
> know. Do everyone in the world speaks the same language? No.
> Stick with the language you like the most and be happy.
>
> BTW, Java is the most fun language I have ever known, next to
> Scheme.
>
> Tom
I think for a programming language is a different thing. It's bears more
resemblance to an
electrical specification than it does to one's mother tongue. A "good"
programming
language can be efficient, portable, readable, provable, ... among other
nice things.
No matter how good you are at writing assembly code, you still can't cut
your
maintenance cost below that for code written by a fairly experienced C++
programmer.
John.
Mark Tillotson
Anselm Lingnau <lin...@tm.informatik.uni-frankfurt.de> wrote:
> In article <32242ff6...@news.alt.net>,
>
> > Anyway, can anyone shed any light on the ability of Java to perform
> > LISPs (eval) function? It would be very nice to generate Java code,
> > and pass it back to Java for compilation/execution, which is one of
> > the main things LISP was famous for (that and lists...).
>
> is well-nigh impossible in C++, only more so because of the so-called
> `security features'.
>
security checking can check it. You unfortunately have to generate a
vector of bytes to represent the new class definition, and present it
to a suitable class-loader, but thereafter you simply instantiate an
instance and do what you want. To do anything useful you tend to use
interface types.
Note that the Java compiler is written totally in Java, and apart from
redirection of its reads and writes to in-core class byte-vectors, all the
machinery is there to do this. It seems a bit of a shame you are
currently forced to use the file-system though.
(In common lisp this would be sort of like
(defun eval (form) (funcall (compile `(defun temp () ,form))))
except having to synthesize compile from compile-file)
__Mark
[ ma...@harlequin.co.uk | http://www.harlequin.co.uk/ | +44 1954 785433 ]
[ personal homepage http://www.juggling.org/~ma...@harlequin.co.uk/ ]
[Is this another instance of confusion caused by myth that Java and C++
are languages with similar semantics I wonder?]