What kind of Lisp should I learn if I want to start programing with Lisp?
Water Lin
using Emacs.
Now I want to learn Lisp to understand it better.
But there are also a lot of Lisp, for example, scheme, Common Lisp,
elisp, etc.
I am really confused which kind of Lisp I should focus on......
Any suggestions?
jos...@corporate-world.lisp.de
Water Lin schrieb:
Common Lisp is fine. Get a copy of the book Practical Common Lisp
(also online http://www.gigamonkeys.com/book/ ).
For beginners I would also recommend to use the LispWorks Personal
Edition ( http://www.lispworks.com ).
Alternatively many people start with Emacs + SLIME + SBCL , which is a
bit too complex for my taste.
Nevertheless lots of people use it.
Emacs is a simple Lisp dialect for Emacs scripting. It is behind the
times in many ways.
Scheme: Typically one can start with DrScheme and one of the Scheme
books.
But I would prefer Common Lisp .
kod...@eurogaran.com
> I am really confused which kind of Lisp I should focus on......
>
> Any suggestions?
Short answer = Common Lisp.
Xah Lee
• Common Lisp is mostly used in the it industry.
• Scheme lisp is mostly academia.
• Emacs lisp is right on your desktop, mostly used just for text
processing.
Personally, i recommend emacs lisp, because it is most practical.
you can try my tutorial here:
• Xah's Emacs Lisp Tutorial
http://xahlee.org/emacs/elisp.html
Xah
∑ http://xahlee.org/
☄
Xah Lee
> I am really confused which kind of Lisp I should focus on......
Rainer Joswig wrote:
> Common Lisp is fine. Get a copy of the book Practical Common Lisp ...
> Emacs is a simple Lisp dialect for Emacs scripting. It is behind the
> times in many ways.
> Scheme: Typically one can start with DrScheme and one of the Scheme
> books.
>
> But I would prefer Common Lisp .
Note that Rainer is a Common Lisp fanatic. He's been posting regularly
in comp.lang.lisp since at least 1999, and it seems to me he does not
know any other functional lang other than common lisp, but always
trumpet Common Lisp in every aspect, and is often aggressive in his
online behavior that you can often see he fight with other lispers
too. I think he's retired in his 50s or older. Much regular posters in
comp.lang.lisp are old. (majority would be above 40 i think. (I'm 40
myself.))
If emacs lisp is behind the times in many ways, which is true, Common
Lisp is also behind the times in many ways.
If you really want to compare lisps in the context of computer langs,
lisps in my opinion is pretty much obsolete. I'd recommend JavaScript,
Ruby, Ocaml, Mathematica, over any lisp. I think that each of the lang
above are superior with respect to the tech aspect. Also, each of the
lang mentioned above has perhaps 10 times more programers than all
lisps combined. (In the case of javascript, it's few thousand or
million times)
You can start with some basic tutorial here:
• Emacs Lisp Basics
http://xahlee.org/emacs/elisp_basics.html
• OCaml Basics
http://xahlee.org/ocaml/ocaml_basics.html
• JavaScript Basics
http://xahlee.org/js/javascript_basics.html
See also:
• Will Lisp Ever Be Popular?
http://xahlee.org/UnixResource_dir/writ/lisp_be_popular.html
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
Xah
∑ http://xahlee.org/
☄
jos...@corporate-world.lisp.de
> On Feb 6, 1:22 am, Water Lin <water...@ymail.com> wrote:
>
> > I am also a newbie in Lisp. I have learned some part of elisp when I am
> > using Emacs.
>
> > Now I want to learn Lisp to understand it better.
>
> > But there are also a lot of Lisp, for example, scheme, Common Lisp,
> > elisp, etc.
>
> > I am really confused which kind of Lisp I should focus on......
>
> > Any suggestions?
>
> • Common Lisp is mostly used in the it industry.
> • Scheme lisp is mostly academia.
> • Emacs lisp is right on your desktop, mostly used just for text
> processing.
>
> Personally, i recommend emacs lisp, because it is most practical.
Note that you can ignore Mr. Lee's opinion. He has scripted
a little Emacs, but never wrote a single Scheme or Lisp program.
jos...@corporate-world.lisp.de
> Water Lin wrote:
> > I am really confused which kind of Lisp I should focus on......
> Rainer Joswig wrote:
> > Common Lisp is fine. Get a copy of the book Practical Common Lisp ...
> > Emacs is a simple Lisp dialect for Emacs scripting. It is behind the
> > times in many ways.
> > Scheme: Typically one can start with DrScheme and one of the Scheme
> > books.
>
> > But I would prefer Common Lisp .
>
> Note that Rainer is a Common Lisp fanatic. He's been posting regularly
> in comp.lang.lisp since at least 1999,
At least since 1992.
> and it seems to me he does not
> know any other functional lang other than common lisp, but always
> trumpet Common Lisp in every aspect,
Different from you I really learned functional programming many years
ago starting with Scheme, ML, Miranda, etc. I've used Haskell, Gofer,
etc. when they appeared.
> and is often aggressive in his
> online behavior that you can often see he fight with other lispers
> too. I think he's retired in his 50s or older. Much regular posters in
> comp.lang.lisp are old. (majority would be above 40 i think. (I'm 40
> myself.))
Let's just note that your Emacs Lisp is at beginners level
and you have never managed to write a single line of Scheme,
Common Lisp or, say, Clojure. Lots of people on comp.lang.lisp can
write
in various Lisp dialects. Not you.
Yeah, and spare me with your drivel. No need to answer.
Alex Mizrahi
Note that Xah Lee is a troll and an idiot.
XL> and is often aggressive in his online behavior
Yep.
jos...@corporate-world.lisp.de
...
> If emacs lisp is behind the times in many ways, which is true, Common
> Lisp is also behind the times in many ways.
>
How would you know? You never have read a book or manual about Common
Lisp
or one of its implementations.
Emacs Lisp
+ dynamic scope
+ eval
+ simple compiler
+ simple data structures
- no objects
- no lexical binding
- primitive compiler
- mostly only available with Emacs
- no threading
- never modernized
- no continuations
Common Lisp
+ dynamic scope
+ lexical scope
+ eval
+ compile
+ objects (Common Lisp Object System)
+ sophisticated compilers available
+ threading with multicore-support available
+ can be used for scripting (CLISP)
+ can be used to write applications
+ several independent implementations
- oldish standard
- continuations only partially via libaries
If you look around all educational resources (books, implementations)
are around Scheme and Common Lisp. Emacs Lisp is mostly NOT
used in schools or universities. The universities and schools
that teach introductions to programming or computer science using some
Lisp dialect are using mostly Scheme (some are using Logo).
Universities are
sometimes offering Common Lisp courses.
Xah Lee
world.lisp.de> wrote:
I fully agree with what you wrote above.
however, to put things in proper context, if the question we are
asking is which lang to choose among lisp for a imperative programer,
i think emacs lisp can easily be the right choice, for one simple
reason: pracitcal utility.
You see, to a professional programer, who is studying lisp to learn
some new language concept and aspects, elisp is of the most ulility
because:
A: it has immediate practical utility. Most lispers use emacs and
swear by emacs for its multitude of uses and extensibility, even if
they program only in Common Lisp or Scheme Lisp.
B: emacs lisp, although technically is useful just within emacs and
text processing, however, contain almost all the essential features
and qualities of lisp that are not in imperative langs. Namely, nested
paren syntax, symbols, lisp macros, functional programing.
Put in other words: if a industrial programer coming from C, Java,
Perl, etc imperative or static langs want to learn lisp's concepts, he
can learn basically all of it with the very simple and useful emacs
lisp. If he is so hooked, he can then trivially extend his knowledge
and start to learn one of Scheme lisp or Common lisp and start to
write whatever real software he had in mind in these langs.
This is why, in recommend emacs lisp, among the 3 major lisps, for
imperative programers who wants to venture in lisp.
(for those unaware, there are also NewLisp, Clojure, Arc. Their number
of users, and age of the lang, are roughly in that order given too.)
Now, if a imperative coder is wondering which lang he should learn
outside of his meager C, C++, Java, Perl, type of imperative langs,
for the purpose of enriching his knowledge in comp langs in some
academic sense, then, i do not even recommend lisp. I recommend:
OCaml, Mathematica, for examples.
Xah
∑ http://xahlee.org/
☄
Slobodan Blazeski
Well it depends on you but I would recommend common lisp, since it has
a best ecosystem (literature, libraries, community,
implementations ..).
As a runner up scheme is a good option, since it leanes more toward
functional style and has continuations something that's lacking in
common lisp.
The other lisps should be considered only if you are interested in
their specific niches.
cheers
bobi
Kojak
jos...@corporate-world.lisp.de a écrit :
> [...]
> + can be used for scripting (CLISP)
> [...]
Just for information, since version 1.0.22, SBCL can be use
for scripting too (without need of extra tweak in rc file).
--
Jacques.
Phil Armitage
> Note that Rainer is a Common Lisp fanatic. He's been posting regularly
> in comp.lang.lisp since at least 1999, and it seems to me he does not
> know any other functional lang other than common lisp, but always
> trumpet Common Lisp in every aspect, and is often aggressive in his
> online behavior that you can often see he fight with other lispers
> too. I think he's retired in his 50s or older.
To the OP: if you look back at Rainer's posts you'll find a wealth of
informative, well explained and friendly help. He is one of a number
of people who regularly provide good advice on this group and as such,
his posts are well worth reading.
--
Phil
http://phil.nullable.eu/
Xah Lee
2009-02-06
Addendum:
the gist of my previous message, in recommending emacs lisp over
common lisp and scheme lisp, among lisps, is this:
all of us are busy, and all of us geeks always have aspiration to
learn new langs, but not always follow thru. If a imperative programer
tried to learn lisp for half a year in his spare time, then, whatever
he has learned with emacs lisp remains quite useful in his programing
career. But whatever he learned in Common or Scheme lisp would be
rather find no where to go and be forgotten.
Xah
∑ http://xahlee.org/
☄
Slobodan Blazeski
bobi
>
> --
> Philhttp://phil.nullable.eu/
jos...@corporate-world.lisp.de
> B: emacs lisp, although technically is useful just within emacs and
> text processing, however, contain almost all the essential features
> and qualities of lisp that are not in imperative langs. Namely, nested
> paren syntax, symbols, lisp macros, functional programing.
Functional programming is relatively weak in Emacs Lisp.
Of the Lisp dialects, Scheme is MUCH better at it.
> Put in other words: if a industrial programer coming from C, Java,
> Perl,
These are very different languages.
C
* imperative, low-level, used for systems programming, static
Java
* imperative object-oriented, large object-oriented eco system, static
Perl
* mix of paradigms, scripting and text processing, interactive/dynamic
If one wants to look beyond those, there are languages like (just to
name a few):
Haskell: statically typed, lazy, pure functional
Ocaml: statically typed, added OO, strict, non-pure
Apl: array language
Diverse Assembly languages
Forth: Stack language
Smalltalk: mostly pure object-oriented language, interactive
environment
Erlang: concurrent functional language
Emacs Lisp: simple symbolic programming, editor scripting
Now, where is Scheme?
Scheme provides us:
* powerful, clean, functional semantics in a tiny package with little
baggage
* functional and imperative
* 'easily' implementable
* code as data, eval, macros, compile, ...
To learn some core concepts of functional programming Scheme is a MUCH
better choice than
Emacs Lisp (which does not even have lexical binding, which is a basic
requirement
for anything functional nowadays).
What does Common Lisp offer:
* standardized multi-paradigm language
* interactive programming (error handling, REPL, ...)
* dynamic object system
* flexibility (macros, read macros, MOP, ...)
What makes Common Lisp unique is that it allows you to develop
seamlessly
in multiple paradigms inside a single interactive environment using
explorative and incremental development techniques.
Emacs Lisp is simply not nearly as powerful as Common Lisp in that
area. Take as an example the Common Lisp Object System. It really
is at the heart of Common Lisp and you will find lots of user
software using and/or extending it. Parts of CLOS have been
implemented in several programming languages (even Emacs Lisp),
but nowhere it is as powerful as in Common Lisp. There is
simply not an 'Art of the MetaObject Protocol' in Emacs Lisp.
Since Common Lisp offers all of Emacs Lisp and much more,
Emacs Lisp can simply be skipped and one can start with
Common Lisp. But then you can learn CLOS, rule languages,
etc. inside one powerful interactive language.
Note, what Common Lisp does not offer directly:
* small easily implementable language
* static typing
* pure functional programming
* lazy functional programming
* full continuations
But unlike Emacs Lisp, Common Lisp is not limited to be an
extension language. With Common Lisp you can write applications
and even learn systems programming in a higher-level language.
Common Lisp has been used to write CAD systems, text editors,
operating systems, GUI toolkits, interface builders, web servers,
email servers, ...
Emacs Lisp has not been used there. It gives the person wanting
to learn Lisp the illusion that all you can do with Lisp
is write inside one editor toolkit. Common Lisp frees
you from that view. You can write much more.
The basic harm that recommending Emacs Lisp as a beginners
Lisp does, is that it gives the impression that Lisp
somehow can't be used to write 'real' software.
All the beginner sees is some Emacs extensions
or simple algorithmic/symbolic code on the Lisp level.
A similar harm is done by using Lisp (often Scheme)
in computer science introduction. The student learns
concepts like recursion, church numerals, etc.
and gets to know Lisp as vehicle to learn those concepts -
but not as a language to write software.
What WE as a Lisp community want, is that the person who
learns the language also learns to understand the
full capability of the language. The main application
area of Lisp is the interactive, incremental development of software,
where flexibility and meta-level programming (code as data, meta-
objects,
symbolic programming, declarative programming, ...)
are key elements. Common Lisp is still hard to beat in that
area, given the many years of work that have been invested
into implementations and tools.
juergen....@googlemail.com
Hi,
I am a beginner, too! Although I have already programming experience
in C, the functional programming paradigm is totally new to me.
I have chosen Common Lisp because it's not just a functional language,
but also a language (system) for developing "real" applications.
there's also a large number of good books out there and some of them
are free. I would suggest you to start with "COMMON LISP: A Gentle
Introduction to Symbolic Computation" by David Touretzky. It's a fine
starting point if your totally new to programming. Another one is
"Practical Common Lisp" by Peter Seibel, which is a little bit more
advanced than Touretzky's. And both are freely available online. I can
recommend the LispWorks Personal Edition as your IDE, because it's
really easy to set it up, it is free, and provides a nice user
interface, which is even more important as you are a beginner. It has
lots of other advanced features, too.
Pascal J. Bourguignon
> Note, what Common Lisp does not offer directly:
>
> * small easily implementable language
CL allows to define Subsets of Common Lisp, so you could define
a small and easily implementable subset of CL.
For example, we could take the intersection of Scheme features and CL
features, and define a subset of CL that would be as simple as Scheme
to implement (simplier since you wouldn't have continuations).
--
__Pascal Bourguignon__
namekuseijin
Indeed. I think it's called maturity. Even if Xah's 40 as he says,
he certainly doesn't behave accordingly.
Javier
> XL> Note that Rainer is a Common Lisp fanatic.
>
> Note that Xah Lee is a troll and an idiot.
Which is better, a troll or a fanatic?
jos...@corporate-world.lisp.de
wrote:
Right. But there is no (see below) useful such subset defined. Just to
take things out
of Common Lisp takes time. It would make sense to have
such a thing, IMHO. Even as a kernel language as part of a standard.
Well, almost. There are some languages that can be seen as subsets.
It is just that there either unused or single purpose.:
* CL0 ( http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/impl/clicc/doc/cl0.pgz
)
* SubL ( http://www.cyc.com/cycdoc/ref/subl-reference.html )
Probably there are others.
a slightly different language:
* Stella ( http://www.isi.edu/isd/LOOM/Stella/)
Xah Lee
world.lisp.de> wrote:
> If one wants to look beyond those, there are languages like (just to
> name a few):
No need to “just to name a few”. I already listed about 50 in my last
message with a summary, here again:
• Proliferation of Computing Languages
http://xahlee.org/UnixResource_dir/writ/new_langs.html
each also linked to Wikipedia for those who wants to read more.
If you can list more than me, then lets see.
Here's the plain text version for those interested.
--------------------------------
Proliferation of Computing Languages
Xah Lee, 2008-07, 2008-11
There is a proliferation of computer languages today like never
before. In this page, i list some of them.
In the following, i try to list some of the langs that are created
after 2000, or become very active after 2000.
Lisp family or similar:
* Mathematica. Computer algebra system background. Used mostly for
math and research.
* NewLisp. Lisp scripting style.
* Arc. Paul Graham squeezing juice out of his celebrity status.
* Qi. Common Lisp added with modern functional lang features.
* Clojure. A new lisp dialect on Java platform.
* Scheme, notably PLT Scheme. Used mostly for teaching.
* (Dead. Dylan. Apple's re-invention of lisp for industrial
programers, active in the 1990s.)
ML Family:
* OCaml
* Alice. Concurrent, ML derivative. Saarland University, Germany.
* F#. Microsoft's functional lang, somewhat compatible with OCaml.
ML/OCaml derived Proof systems:
* HOL theorem prover family
* HOL Light
* Isabelle (theorem prover)
* Coq. For formal proofs.
Modern Functional langs:
* Erlang. Functional, concurrent. Mostly used in a
telecomunication industry for concurrency and continuous up-time
features.
* Haskell Oldish, classic functional lang.
* Mercury. Logic, functional.
* Q. Functional lang, based on term rewriting. To be replaced by
Pure.
* Oz. Concurrent. Multiparadigm.
Perl Family or derivative:
* PHP. Perl derivative for server side web apps. One of the top 10
pop lang.
* Ruby. Perl with rectified syntax and semantics.
* Perl6. Next gen of perl.
* Sleep. A scripting lang, perl syntax. On Java platform.
On Java Virtual Machine:
* Scala. A FP+OOP lang on Java platform as a Java alternative.
* Groovy. Scritping lang on Java platform.
C derivatives:
* ObjectiveC. Strict superset of C. Used as the primary language
by Apple for Mac OS X.
* C#. Microsoft's answer to Java. Quickly becoming top 10 lang
with Microsoft's “.NET” architecture.
* D. Clean up of C++.
2D graphics related.
* Scratch. Derived from SmallTalk + Logo.
* Adobe Flash's ActionScript. 2D graphics. Quickly becomes top 10
lang due to popularity of Flash.
* Processing. 2D graphics on Java platform. Primarily used for art
and teaching.
Misc:
* Linden_Scripting_Language. Used in virtual world Second Life.
* Lua. Scripting.
* Tcl. Scripting, esp GUI.
* JavaScript. Mostly for web browser scripting, but quickly
becoming the standard lang for general purpose scripting. (used by
Adobe Flash, Dashboard Widgets, scripting Adobe PDF files, scripting
Microsoft Windows, scripting Java)
Some Random Thoughts
Following are some random comments on comp langs.
Listing Criterion and Popularity
In the above, i tried to not list implementations. (e.g. huge number
of Scheme implemented in JVM with fluffs here and there; also e.g.
JPython, JRuby, and quite a lot more.) Also, i tried to avoid minor
derivatives or variations. Also, i tried to avoid langs that's one-
man's fancy with little followings.
In the above, i tried to list only “new” langs that are born or seen
with high activity or awareness after 2000. But without this
criterion, there are quite a few staples that still have some user
base. e.g. APL, Fortran, Cobol, Forth, Logo (many variants), Pascal
(Ada, Modula, Delphi). And others that are today top 10 most popular
langs: C++, ObjectiveC, Visual Basic.
The user base of the langs differ by some magnitude. Some, such as for
example PHP, C#, are within the top 10 most popular lang with active
users (which is perhaps in order of hundreds of millions). Some
others, are niche but still with huge users (order of tens or hundreds
of thousands), such as LSL, Erlang, Mathematica. Others are niche but
robust and industrial (counting academic use), such as Coq (a proof
system), Processing, PLT Scheme, AutoLisp. Few are mostly academic
followed with handful of experimenters, Qi, Arc, Mercury, Q,
Concurrent Clean are probably examples.
For those of you developers of Java, Perl, Python for example, it
would be fruitful to spend a hour or 2 to look at the Wikipedia
articles about these, or their home pages. Wikipedia has several pages
that is a listing of comp langs, of which you can read about perhaps
over 2 hundreds of langs.
Why The List
I was prompted to have a scan at these new lang because recently i
wrote a article titled Fundamental Problems of Lisp, which mentioned
my impression of a proliferation of languages (and all sorts of
computing tools and applications). Quote:
10 years ago, in the dot com days (~1998), where Java, Javascript,
Perl are screaming the rounds. It was my opinion, that lisp will
inevitably become popular in the future, simply due to its inherent
superior design, simplicity, flexibility, power, whatever its existing
problems may be. Now i don't think that'll ever happen as is. Because,
due to the tremendous technological advances, in particular in
communication (i.e. the internet and its consequences, e.g. Wikipedia,
youtube, youporn, social networks sites, blogs, Instant chat, etc)
computer languages are proliferating like never before. (e.g. erlang,
OCaml, Haskell, PHP, Ruby, c#, f#, perl6, arc, NewLisp, Scala, Groovy,
Goo, Nice, E, Q, Qz, Mercury, Scratch, Flash, Processing, ..., helped
by the abundance of tools, libraries, parsers, existence of
infrastructures) New langs, basically will have all the advantages of
lisps or lisp's fundamental concepts or principles. I see that,
perhaps in the next decade, as communication technologies further hurl
us forward, the proliferation of langs will reduce to a trend of
consolidation (e.g. fueled by virtual machines such as
Microsoft's .NET.).
Creating A Lang Is Easy
In general, creating a lang is relatively easy to do in comparison to
equivalent-sized programing tasks in the industry (such as, for
example, writing robust signal processing lib, a web server (e.g.
video web server), a web app framework, a game engine ...etc.).
Computing tasks typically have a goal, where all sorts of complexities
and nit-gritty detail arise in the coding process. Creating a lang
often is simply based on a individual's creativity that doesn't have
much fixed constraints, much as in painting or sculpting. Many langs
that have become popular, in fact arose this way. Popularly known
examples includes Perl, Python Ruby, Perl6, Arc. Creating a lang
requires the skill of writing a compiler though, which isn't trivial,
but today with mega proliferation of tools, even the need for compiler
writing skill is reduced. (e.g. Arc, various langs on JVM. (10 years
ago, writing a parser is mostly not required due to existing tools
such as lex/yacc))
Some lang are created to solve a immediate problem or need.
Mathematica, Adobe Flash's ActionScript, Emacs Lisp, LSL would be good
examples. Some are created as computer science research byproducts,
usually using or resulting a new computing model. Lisp, Prolog,
SmallTalk, Haskell, Qi, Concurrent Clean, are of this type.
Some are created by corporations from scratch for one reasons or
another. e.g. Java, Javascript, AppleScript, Dylan, C#. The reason is
mostly to make money by creating a lang that solves perceived problems
or need, as innovation. The problem may or may not actually exist. (C#
is a lang created primarily to overrun Java. Java was created first as
a lang for embedded devices, then Sun Microsystems pushed it to ride
the internet wave to envision “write once run everywhere” and
interactivity in web browser. In hindsight, Java's contribution to the
science of computer languages is probably just a social one, mainly in
popularizing the concept of a virtual machine, and further
popularizing OOP after C++.)
Infinite Number Of Syntaxes And Semantics
Looking at some tens of langs, one might think that there might be
some unifying factor, some unifying theory or model, that limits the
potential creation to a small set of types, classes, models. With
influence from Stephen Wolfram book “A New Kind of Science” (see:
Notes on A New Kind of Science) , i'd think this is not so. That is to
say, different languages are potentially endless, and each can become
quite useful or important or with sizable user base. In other words, i
think there's no theoretical basis that would govern what languages
will be popular due to its technical/mathematical properties. Perhaps
another way to phrase this imprecise thought is that, languages will
keep proliferating, and even if we don't count langs that created by
one-man's fancy, there will still probably be forever birth of
languages, and they will all be useful or solve some niche problem,
because there is no theoretical or technical reason that sometimes in
the future there would be one lang that can be fittingly used to solve
all computing problems.
Also, the possibilities of lang's syntax are basically unlimited, even
considering the constraint that they be practical and human readable.
So, any joe, can potentially create a new syntax. The syntaxes of
existing langs, when compared to the number of all potentially
possible (human readable) syntaxes, are probably a very small
fraction. That is to say, even with so many existing langs today with
their wildly differing syntax, we probably are just seeing a few
pixels in a computer screen.
Also note here all langs mentioned here are all plain-text linear
ones. Spread sheet and visual programing langs would be example of 2D
syntax... but i haven't thought about how they can be classified as
syntax. (nor do i fully understand the ontology of syntax )
Just some extempore thoughts.
Xah
∑ http://xahlee.org/
☄
Majorinc Kazimir
Depends of your intentions. From the most popular
Common Lisp - tried and tested, mature, lot of features
and relatively lot of libraries, lot of compatible
implementations. Designed to be efficiently compiled,
and because of that (and some other reasons) it is harder
to learn and use than other dialects. But if someone asks
for "industrial strength" it would be dishonest not to
point on certain CL implementations.
Scheme - designed to be simple and good for education,
but we must say that it drifted away from that goal. It
is still less complicated than CL, but it is not really
simple. Check PLT Scheme because its free, excellent
free graphical IDE, lots of libraries, lot of people
doing funny things, great community. I've spent few
years there, thank you guys. Some features you'll not
find in other dialects like continuations and tail
recursion, to lesser extent.
Clojure - new, made to work on JVM. Designer made some brave
generalization compared with older Lisp, some in the
spirit of "pure functional programming." Some very nice
and very powerful features are demonstrated here recently.
Personally, I like imperative programming (assignement,
loops, mutability) and I think that functional is OK as
extension, but not as a replacement for imperative, so
I dislike immutable features. But some people think it is
the way to go.
Newlisp - that is what I use and recommend. It is designed to be
interpreted, "scripting", "dynamic". Because of that
it is very simple, easy to learn, but also very powerful:
almost everything is "first class" and mutable, including
macros - during runtime. The price is that it is slower
in simple situations than compiled Lisps, if you want to
"crunch numbers" it will never be that fast. But, for
many uses it is fast enough, and if you want or dream about
"programs that write programs that write programs.."
it is the way to go. Pico Lisp is similar and you can consider
it as well.
I do not know enough about Islisp, Nu Lisp, Emacs Lisp
and other Lisps.
cartercc
Like others, I am a Lisp newbie. I can share my experiences and
suggestions for whatever good it will do.
I use Perl heavily in my day job. I've also written in Java, C/C++,
and Python. I got interested in Lisp by reading Paul Graham's essays,
and wanted to find out if what he said was true.
I've acquired Graham's 'ANSI Lisp',' Seibel's 'Practical CL', Lamkin's
'Successful CL',' Wilensky's 'Common LISPcraft', 'Little Lisper',
Touretzky's 'Gentle Introduction', and a couple of others. For me, the
best of the lot is Wilensky because it is clear, structured, and every
chapter has exercises. You can also purchase the solutions manual for
when you get stuck, and I would recommend getting the solutions manual
as well.
My problem with Graham is that it's too dense. My problem with Seibel
is that he doesn't provide exercises for each chapter. I would
recommend Wilensky, Seibel, and Graham in that order, but I would
definitely read all three. Of the three, I think Graham is the best,
but only for those who already know Lisp.
I am fortunate that I have a job that requires me to use scripting
solutions for problems and the freedom to use whatever technology I
want. The only way to learn a language is to use it on a daily basis,
so I can take advantage of my job to use Lisp. That said, I haven't
figured out what Lisp is good for IN MY PERSONAL SITUATION. Eric
Raymond has been quoted as saying that you should learn Lisp because
it will make you a better programmer, and I can be a witness to the
truth of this.
Lastly, learning Lisp isn't easy, and you need to be prepared to
devote a lot of time and effort to learning Lisp. As one who has just
dipped his big toe into the water, I can see how powerful the language
is, and I am prepared make the effort with the understanding that, the
more powerful a technology is, the harder it is to learn.
CC
Alex Mizrahi
??>> Note that Xah Lee is a troll and an idiot.
J> Which is better, a troll or a fanatic?
there are different sorts of trolls. Richard Gabriel [1], for example, often
wrote
very controversial things, so he is sort of troll, but he is very
intelligent troll.
on the other hand, Xah Lee often writes very stupid things.
it does not matter if you're troll or fanatic if you're an intelligent
person
and write sane things.
[1]: http://en.wikipedia.org/wiki/Richard_Gabriel
w_a_...@yahoo.com
elisp is a Lisp.
Do Commune Lispers always lie?
Javier
Ummm I won't call him a troll, nor that intelligent, but a fanatical,
with a big ego. He has just mastered the science of confusing people.
I would include Paul Graham in the same category.
Raffael Cavallaro
> I would include Paul Graham in the same category.
well Paul Graham has "mastered the science" of making millions by
writing software. maybe that's why people are more inclined to listen
to what he has to say than what you're spouting.
--
Raffael Cavallaro, Ph.D.
Xah Lee
wrote:
Note that it is I, Xah Lee, who started the article on Richard
Gabriel. You can check and trace the history there.
Let me talk a bit about the history of that article.
I won't be giving exact, accurate details, but rather just write from
the top of my brain in a free flow fashion, but from what i wrote
here, you can easily verify, correct the details, from the info i
gave, with my main contention intact.
I started the article in 2005. I don't recall what impetus made me...
i think at the time i was fighting with some motherfucking unix
geeking opensource software-stealing youngster Wikipedia fuckheads on
some articles about unix, such as X-windows, unix hater's handbook, or
the so fucking called “unix philosophy” or was it the article on
“worse in better”.
So, just to give a show of these fuckheads what i know (but hiddenly,
instill the concept of lisp and a lisp dignitary Richard G), so i
started the article. One of the method i use, is to add “Inception!”
as the edit comment, and typically the article will be laden with
grammatical or morphological errors and only a few sentences.
Immediately, it had effects. The guy Marudubshinki there you see who
editted after me, is at the time doing some fighting with me on some
articles. Apparently, he didn't know who the fuck Richard G is, and of
course i knew he is all aware that i suddenly created a article. (most
of them being some type of watchdog, and most editor warriors is in
high vigil on what their enemy is creating).
i don't remember if i communicated with the Mar guy some what, but he
immediately grabbed the free downloadable book on Richard (his book on
patterns (half of the book is his his personal history)), and “copied”
it (with re-wording) and put it on Wikipedia.
I commented to him how good a job he did, and he was happy. (He
actually did a good job. From someone who doesn't know the guy, to
scanning large part of the book, and copy-edited pertinent info into
Wikipedia. It was done in a few hours.)
That's how that article on Richard G started. The bulk of info in the
current version is still from that Mar guy. Thanks to, umm, Xah Lee.
References:
• Book Review: Patterns of Software
http://xahlee.org/PageTwo_dir/Personal_dir/bookReviewRichardGabriel.html
• The Nature of the “Unix Philosophy”
http://xahlee.org/UnixResource_dir/writ/unix_phil.html
• Wikipedia Morons
http://xahlee.org/Periodic_dosage_dir/t2/wikimorons.html
• The Engine of Wikipedia
http://xahlee.org/Periodic_dosage_dir/t2/wikipedia_engine.html
• Encyclopedia, My Experiences
http://xahlee.org/Periodic_dosage_dir/encyclopedia.html
• Lispers and Wikipedia
http://xahlee.org/emacs/lispers_n_wikipedia.html
• Links To Wikipedia from XahLee.org
http://xahlee.org/wikipedia_links.html
Xah
∑ http://xahlee.org/
☄
Raymond Wiker
Which puts Rainer on the exact opposite end of the scale from Xah
Lee, who is one of a (luckily, small) number of people who persist on
posting bad advice and off-topic garbage on this newsgroup as well as a
few others.
jos...@corporate-world.lisp.de
Are you always so stupid?
Can you understand the difference between
an Emacs Lisp script and a Lisp PROGRAM? All he
posted here were a few lines of Emacs Lisp.
André Thieme
> I am also a newbie in Lisp. I have learned some part of elisp when I am
> using Emacs.
>
> Now I want to learn Lisp to understand it better.
>
> But there are also a lot of Lisp, for example, scheme, Common Lisp,
> elisp, etc.
>
> I am really confused which kind of Lisp I should focus on......
>
> Any suggestions?
A fantastic choice would be Clojure: http://clojure.org/
It is the most practical Lisp. Without needing to invest money you can
have a nice development environment: http://enclojure.org/
It has one of the (if not *the*) most powerful GUI-Builders.
Clojure programs run on the JVM, and are able to use all Java libs easily.
Your programs would run on all major plattforms, and you can also
write applications for your Android mobile phone :)
Clojure also makes it trivial to write programs that make use of all
cores in your CPU. Only few other Lisps can do this. And those are not
in all cases functional dialects, which means even if they can target
native OS threads, it will be difficult to write the code.
Also nice is that it is a very modern version of Lisps, which allows
to have much more concise code.
André
--
Lisp is not dead. It’s just the URL that has changed:
http://clojure.org/
Alex Mizrahi
J> with a big ego.
J> He has just mastered the science of confusing people.
emm, are you speaking about RPG or about Xah Lee? it makes
no sense in any case, or you're having very weird definitions.
what is he (RPG i guess?) fanatical about?
J> I would include Paul Graham in the same category.
well, Paul Graham fits into "fanatical with a big ego" category
much better, as he often states his own thoughts as an absolute truth.
but i can't say that "fanatical" is the right word to describe Paul -- he
seems
to be pretty open to new stuff, and he is successful in his business.
can one be "fanatical" on truth and sucess? if so, i'd be glad to be a
"fanatic of truth",
as i can't stand bullshit
anders
I am also strugling to learn som Lisp, i found a MIT video that was
about LISP, it seems old, but for me it was good anyway,
there is also a book online as a companien to the video lecture.
Link: http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-lectures/
I have also found a lot of versions/flavor of lisp, my choice is
Clojure
why
1. Runs on JVM eg if you have java installed it run there
2. It have connection to java, witch meens i can use Java's GUI for me
GUI is importen and Javas GUI look's nice
a lot of other Lisp can do GUI with diffrent system, but i like
Clojure way
3. I can compile it and run on machine that have JVM (alot of LISP can
do runtimes stuff but for me Clojure was nice
4. There is a some IDE that i like
- Clojuredev this is for developing under Eclipse
- enclojure for netbeans (my chice)
5. There is always Emacs and SLIME, if you like Emacs.
Good luck
Anders
Thomas Munro
> I am also a newbie in Lisp. I have learned some part of elisp when I am
> using Emacs.
>
> Now I want to learn Lisp to understand it better.
>
> But there are also a lot of Lisp, for example, scheme, Common Lisp,
> elisp, etc.
>
> I am really confused which kind of Lisp I should focus on......
>
> Any suggestions?
If you get hooked on Lisp you'll finish up learning all three dialects
you mentioned anyway, so I'm interpreting your question as 'where to
start?'
I would suggest starting with Scheme. It's small and elegant, and
there are loads of books focusing on functional programming (even
though imperative programming style is also supported). After some
time, depending on your needs, you might want to move over to Common
Lisp as your primary dialect because it has the trappings of critical
mass: heavy duty implementations, support and a lot of libraries which
are portable -- at that later stage, the practical advantages might be
worth dealing with the baggage and complexity.
Javier
relative to his point of view. But you are fanatical of him, so you are
not goint to understand.
"Fanatical of success" is what I call codiciuos people, and for sure
they are not that happy as you think.
But these are "high order" (or whatever) themes. Better stop here and
going to another newsgroup.
Michael Ekstrand
> I would suggest starting with Scheme. It's small and elegant, and
> there are loads of books focusing on functional programming (even
> though imperative programming style is also supported). After some
> time, depending on your needs, you might want to move over to Common
> Lisp as your primary dialect because it has the trappings of critical
> mass: heavy duty implementations, support and a lot of libraries which
> are portable -- at that later stage, the practical advantages might be
> worth dealing with the baggage and complexity.
I would second that suggestion.
I poked at Common Lisp a bit in high school but didn't get very far with
it at the time. After I spent a semester in Scheme in college, the
basic code structure (e.g. all the parentheses) made sense, and CL (with
the aid of Practical Common Lisp) was far less daunting. It also put my
CL style on a firm functional basis.
Now, there are probably many factors at work in this path, but Scheme
did prove a nice, gentle introduction which smoothed my real entry to
Common Lisp (and Emacs Lisp).
- Michael
--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.
Jason
wrote:
Coming from the newbiest of all in this discussion, I really enjoy
learning Scheme. I love all the documentation and the simplicity of
the syntax. It is an enjoyable experience.
Rob Warnock
+---------------
| p...@informatimago.com (Pascal J. Bourguignon) wrote:
| > For example, we could take the intersection of Scheme features and CL
| > features, and define a subset of CL that would be as simple as Scheme
| > to implement (simplier since you wouldn't have continuations).
|
While you are correct that there is no *standard* subset defined,
the CLHS 1.7 definition of "subset" is so broad that many, many
useful (to someone or other) subsets can easily be defined.
+---------------
| Just to take things out of Common Lisp takes time.
+---------------
IMHO, it's a lot faster to come at it from the other direction
and only put *in* what you really want/need! ;-}
As I have mentioned here before, I've been dabbling around with a
tiny subset of CL that I call QDL ("Quick & Dirty Lisp"), currently
just a pure sexp interpreter written in C. Including a precise GC,
the latest version is ~4 KLOC [would be somewhat less, if you took
out some huge chunks of debugging code], with only 40 symbols in
the oblist at startup [omitting debugging extensions]:
QUOTE LAMBDA PROGN FUNCALL APPLY EVAL
IF SETQ DEFUN LET LET*
PRINT PRINC TERPRI
SYMBOL-VALUE SYMBOL-FUNCTION
LENGTH
CAR CDR CONS LIST ASSOC REVERSE NREVERSE
VECTOR
1+ 1- + - * / = /= < > <= >=
GC ROOM OBLIST
[O.k., so OBLIST isn't standard; (defun oblist () (apropos-list "")).]
Still, QDL's big enough to run (ACKERMANN 3 10) [takes ~6 minutes
on my laptop]; it has proper lexical closures [including DEFUNs
that can share non-null lexical environments]; but only fixnum
arithmetic so far. As Pascal_B suggests, not having to guarantee
"safe-for-space tail-call chains" makes it a *lot* easier to throw
soemthing like this together in C.
+---------------
| It would make sense to have such a thing, IMHO.
+---------------
If only as a tool for bootstrapping a full CL [which is one of
the intended future uses of QDL, but that's another story].
+---------------
| Even as a kernel language as part of a standard.
+---------------
Well, the ANSI committee quite deliberately chose to *not* bless any
particular subset(s). From CLHS "Issue SUBSETTING-POSITION:NONE":
We have no well-defined proposals for subset definitions, and didn't
have the time or energy to pursue their definition, or confidence
that we could reach convergence on a reasonable definition.
After investigating this area a bit myself, I think that they were
quite right to take that position. CL has *so* many *nearly*-orthogonal
dimensions that while it may appear easy on the surface to "subset"
things, it's very difficult in practice to construct a sane transitive
closure of features that doesn't drag in the whole language!! ;-}
[The one exception is CLOS, as several implementations have shown.
It's possible to define a reasonably-full CL subset less CLOS, then
bootstrap CLOS on top of that later.]
Anyway, that's one of the things I'm trying to answer, for myself at
least, with QDL. Here's one (of several!) ways to phrase the question:
"By the the time you've grown a CL subset from 'nothing' to the point
that you might actually want to use it for real work (e.g., ship it in
a product, or at least use it locally in scripts that you run every day),
will it necessarily be so large that you might as well have simply picked
some other already-existing full CL instead?" I consider this question
to be currently unanswered, but indications so far are that the answer
is likely to be "just use an existing full CL".
Note: This is *different* from the question of whether there is a viable
business model for creating an new full CL. I don't think so, but what
do I know about the Lisp business? This is *also* different from the
question of whether some good could come from yet-another-fork of one
of the existing full CLs. I'm more optimistic about that one, since
there have been some successes there in the past.
Yet *another* question is whether a very small CL subset can be a
useful teaching or tutorial or learning vehicle, as an alternative
to Scheme [which already has a plethora of small implementations!].
The answer there, I think, is already a resounding "Yes!". If what you
want is a CL subset about the size of R4RS Scheme, that can easily be
implemented from scratch, in C, in as little as a few days' time for
an experienced programmer interested in self-tutorial, or could be
stretched to a full term paper project in a Computer Science course.
Finally, there's the question of whether a CL subset can be useful
when researching possible modifications/alternatives to/in an existing
full CL. I *think* so, but I'm still working on that one... ;-}
+---------------
| Well, almost. There are some languages that can be seen as subsets.
| It is just that there either unused or single purpose:
| * CL0 ( http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/
| lisp/impl/clicc/doc/cl0.pgz )
+---------------
Thanks for the reference. Do you have any idea how CL0 compares
with, say, ThinLisp <http://www.thinlisp.org/>?
+---------------
| * SubL ( http://www.cyc.com/cycdoc/ref/subl-reference.html )
+---------------
Thanks, but insufficiently Lispy for me. They lost me here: ;-}
SubL does not support these Common Lisp datatypes:
Multi-dimensional arrays
Packages
Pathnames
Random-states
Lambda-Expressions or Closures
Also, the weird separation of many common features into "procedural"
(imperative, with no value) and "functional" versions -- e.g., IF is
split into PIF & FIF -- is just "wrong" for a Lisp.
+---------------
| a slightly different language:
| * Stella ( http://www.isi.edu/isd/LOOM/Stella/)
+---------------
Again, insufficiently Lispy, for similar reasons:
...most STELLA conditionals are statements and therefore
do not return a value.
Ouch!
+---------------
| Probably there are others.
+---------------
Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>. ;-}
88 initial defined symbols, float-only arithmetic, 500 LOC of *very* dense C!
Then loading "init500.lisp" adds another 761 symbols, fleshing out the CL
compatibility a *lot*.
-Rob
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock
+---------------
| Le Fri, 6 Feb 2009 05:55:38 -0800 (PST),
| jos...@corporate-world.lisp.de a écrit :
| > + can be used for scripting (CLISP)
|
| Just for information, since version 1.0.22, SBCL can be use
| for scripting too (without need of extra tweak in rc file).
+---------------
And <http://rpw3.org/hacks/lisp/site-switch-script.lisp> adds
easy "#!" scripting of both source and FASL files to CMUCL.
[I do *lots* of scripting with CMUCL... ;-} ]
Kojak
Rob Warnock a écrit :
> Kojak <nnt...@janville.Borg.invalid> wrote:
> > Just for information, since version 1.0.22, SBCL can be use
> > for scripting too (without need of extra tweak in rc file).
>
> And <http://rpw3.org/hacks/lisp/site-switch-script.lisp> adds
> easy "#!" scripting of both source and FASL files to CMUCL.
> [I do *lots* of scripting with CMUCL... ;-} ]
Cheater! I've said "without need of extra tweak in rc file". :-)
--
Jacques.
Helmut Eller
> Can you understand the difference between
> an Emacs Lisp script and a Lisp PROGRAM? All he
> posted here were a few lines of Emacs Lisp.
I also have trouble to understand the difference between a script and a
program. Would you mind to explain it?
jos...@corporate-world.lisp.de
Really?
A script is a piece of code that controls the behavior of one or more
programs.
Alex Mizrahi
J> relative to his point of view.
everybody says his own opinion. of course, some stuff he writes is wrong.
but probably he is less wrong than a random blogger out there, because
PG have proven he can be right.
J> But you are fanatical of him, so you are not goint to understand.
definitely you're fanatical of saying word fanatical.
i read PGs essays only occasionally and i never said everything
he writes is true. how i can be fanatical of PG???
Helmut Eller
In other words, a script is a program that controls programs?
Or is a script not a program?
If not, what is a program?
Pascal Costanza
> jos...@corporate-world.lisp.de <jos...@corporate-world.lisp.de> wrote:
> +---------------
> | p...@informatimago.com (Pascal J. Bourguignon) wrote:
> | > For example, we could take the intersection of Scheme features and CL
> | > features, and define a subset of CL that would be as simple as Scheme
> | > to implement (simplier since you wouldn't have continuations).
> |
> | Right. But there is no (see below) useful such subset defined.
> +---------------
>
> While you are correct that there is no *standard* subset defined,
> the CLHS 1.7 definition of "subset" is so broad that many, many
> useful (to someone or other) subsets can easily be defined.
I find ISLISP very useful.
See http://www.islisp.info/specification.html
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
jos...@corporate-world.lisp.de
A program is an independent executable piece of
code. For example /bin/sh is usually a program.
You can start /bin/sh and it runs independent of anything,
other than the OS that hands control to the program. (Note
that a script could also be an executable file, but it needs
a program, the script interpreter/runtime to execute).
The shell script then is interpreted by this program. A Lisp program
would be a single executable or a runtime with an image that's
loaded. The program exists and runs on an operating system/hardware
independent from other programs, though it might call
other programs. The script needs a program to execute
and controls its behavior or the behavior of other programs.
For example Autocad provides CAD functionality and AutoLisp scripts
are used
to extend this functionality by calling the built-in functionality and
combine those. Without the Autocad program the AutoLisp
script can't be executed. A scriptable program either includes
an scripting language (in case of Emacs, Autocad, etc.)
or provides interfaces that are called by an external
scripting language (the AppleScript / AppleEvents model).
Some time ago John K. Ousterhout (TCL) promoted the idea that
scripting languages are very important. He wrote the following:
http://home.pacbell.net/ouster/scripting.html
( this piece then was also discussed on comp.lang.lisp )
He describes scripts as the glue between programs.
In Wikipedia you will find the following under scripting language:
'A scripting language, script language or extension language, is a
programming language that allows some control of a single or many
software application(s). "Scripts" are often treated as distinct from
"programs", which execute independently from any other application. At
the same time they are distinct from the core code of the application,
which is usually written in a different language, and by being
accessible to the end-user they enable the behavior of the application
to be adapted to the user's needs. Scripts are often, but not always,
interpreted from the source code or "semi-compiled" to bytecode which
is interpreted, unlike the applications they are associated with,
which are traditionally compiled to native machine code for the system
on which they run. Scripting languages are nearly always embedded in
the application with which they are associated.
The name "script" is derived from the written script of the performing
arts, in which dialogue is set down to be spoken by human actors.
Early script languages were often called batch languages or job
control languages. Such early scripting languages were created to
shorten the traditional edit-compile-link-run process..'
Helmut Eller
>> In other words, a script is a program that controls programs?
>> Or is a script not a program?
>> If not, what is a program?
>
> A program is an independent executable piece of
> code. For example /bin/sh is usually a program.
> You can start /bin/sh and it runs independent of anything,
> other than the OS that hands control to the program. (Note
> that a script could also be an executable file, but it needs
> a program, the script interpreter/runtime to execute).
/bin/sh also needs an interpreter/runtime. Under Linux it's called
/lib/ld-linux.so which loads elf object files into memory, performs
relocation and dynamic linking.
So is this piece of code
emacs -batch -eval '(princ "Hello World!\n")'
a "Hello World"-script or a "Hello World"-program?
Of course, it needs Emacs to do anything useful, and since Emacs is the
archetype of a scriptable application, it must be a script. Right?
But how is that different from:
cmucl -batch -eval '(format t "Hello World!~%") (quit)'
This "script" also needs the "cmucl" application, but so do all other
programs running inside CMUCL.
I can accept that scripts are small, usually stored as source text,
pieces of code, mainly used to glue together external processes or
library functions.
But that scripts are somehow not programs sounds strange to me.
Helmut.
Madhu
* Helmut Eller <m2hc36o...@gmail.com>
Wrote on Sat, 07 Feb 2009 13:02:00 +0100:
| But that scripts are somehow not programs sounds strange to me.
No, obviously they are programs for any pedantic definition of
`program'. But then you are just playing the semantics game.
The difference between scripts and programs is a "fine distinction"
which is worth making (more often than not) when definining or trying to
understand system architecture by decomposing it. AFAICS any real value
of the scripting notion lies here --- so its a valid raison 'd etre.
PS. I'm using `system' as a collection of programs operating together,
where each program individually has well defined behaviour; etc. which
are composed. The sense should be clear from the references Rainer
quoted upthread, and is common in certain communities based around
primarily UNIX programmers (like say git)
PPS. If the program that is constructed in the proof of halting problem
is really a script and not a program, then is the halting problem
suddenly invalid ?
--
Madhu
jos...@corporate-world.lisp.de
Both are similar. The main difference is that Emacs is a text
editor and at its core includes some basic functionality in that
domain. A script usually controls a program that contains
specific implemented functionality for some domain. For example
the program might know how to display characters and how to talk to
the
OS and its libraries. The scripting language then has
an (possibly partly domain independent) implementation
in form of an interpreter (or similar) and
access to the provided functionality of the program. So
with the script you call and combine functionality from
the underlying program. So the typical task of Emacs Lisp
would be to customize and extend the functionality of the
editor. You may be able to call Emacs Lisp in a way that
it does not execute much of the editor functionality, but
that is not the main purpose.
CMUCL as an implementation of the programming language Common
Lisp does not know anything about buffers, keypresses,
frames, menus, etc. But you can write all the functionality
of an editor in CMUCL, including the functionality that
is provided by the Emacs C code. The runtime of CMUCL
is domain independent.
>
> This "script" also needs the "cmucl" application, but so do all other
> programs running inside CMUCL.
>
> I can accept that scripts are small, usually stored as source text,
> pieces of code, mainly used to glue together external processes or
> library functions.
>
> But that scripts are somehow not programs sounds strange to me.
There are different meanings for programs. But when we contrast
'script' with 'program' and 'application', then the difference is
approximately this:
* a program is an independent executable piece of code
(relative to an execution engine like a processor in hardware
or a virtual machine)
* a script is a piece of code that has access to the functionality
of a program (either internal or external). It can call
and combine this functionality.
* an application is the combination of programs, scripts and data
that provides a general functionality. For example the
typical Emacs is an application that combines several
programs ( ctags, emacsclient, etags, emacs, ...),
lots of 'scripts' (typically written in Emacs Lisp)
and data files like dictionary data.
Does that make sense to you?
>
> Helmut.
Helmut Eller
>> I can accept that scripts are small, usually stored as source text,
>> pieces of code, mainly used to glue together external processes or
>> library functions.
>>
>> But that scripts are somehow not programs sounds strange to me.
>
> There are different meanings for programs. But when we contrast
> 'script' with 'program' and 'application', then the difference is
> approximately this:
>
> * a program is an independent executable piece of code
> (relative to an execution engine like a processor in hardware
> or a virtual machine)
>
> * a script is a piece of code that has access to the functionality
> of a program (either internal or external). It can call
> and combine this functionality.
>
> * an application is the combination of programs, scripts and data
> that provides a general functionality. For example the
> typical Emacs is an application that combines several
> programs ( ctags, emacsclient, etags, emacs, ...),
> lots of 'scripts' (typically written in Emacs Lisp)
> and data files like dictionary data.
>
> Does that make sense to you?
With that definition the same piece of text can either be a script or a
program, depending on the execution environment. I can live with that,
but I don't consider it very useful. I would call the Tetris clone that
comes with Emacs a "program" and not a "script".
Helmut.
Pascal J. Bourguignon
No, this is quite silly.
In a program you could implement the interpreter pattern, and most of
that program functionality could be implemented in this interpreter
language. Even if this interpreter language is not accessible by the
user, what difference would there be between this program and a
script? And what if there's a virtual machine somewhere in there?
To take again the Hello World example, compare two implementations
using ecl: in the first you "call" the ecl executable passing the
script as argument. In the other, you write your own main function in
C, link it with libecl, and "call" the ecl eval passing it the same
"script".
In both case, your program needs an external program. In the first
case, arguably the external program can be considered a stand alone
program, in the other case, the external program is libecl, and is not
considered a program but a "library". However, if you type at the shell:
/usr/bin/ecl RET
or
/usr/lib/libecl.so RET
you don't get anything useful in either case.
Consider again your main linked with libecl.so. We could say it's a
script since it relies on external programs. What if we linked it
statically? Would that make it a program?
The boundaries are artificial. For example, there's no fundamental
difference between a syscall and a jsr: the OS can be considered as a
library of subroutines to your program. Wouldn't that mean that your
program is a kernel module? Some system level features (accessed by
programs thru syscalls) are actually implemented in user mode by other
programs.
Also, I don't like the difference that is made in this discussion
between emacs and bash. By your definition of script here, we could
tend to infer that a shell script is more a program, because after
all, bash has not a lot of functionality. By itself, bash hardly
reaches the level of basic, feature wise. Syntactically, it allows to
run external programs more easily. But a bash script, as long as it
doesn't call up on external programs would be nothing more than an
interpreted _program_! (there are also compilers for shells). And
the fact that emacs includes a library to manage text buffers and
display, doesn't make it less an interpreter/virtual machine/compiler
in which you can write normal programs, either as batch programs or
interactive programs.
Your definition of script also is not what is usually called script,
like in bash script, or awk script, etc. You seem to restrict it to
"scriptable applications", where the functionalities provided by the
"script" cannot go much beyond the purpose of the application,
somewhat like what is called "macros" in these applications. On the
contrary, with bash or emacs, we can easily write programs as general
as in any other language. For example, I've written in emacs programs
to generate test cases for a MTA. Far removed from text editing.
So this discussion is quite futile (nothing new), since there's a lot
of overlap between these terms. They don't really design a technical
difference, but more a conotation in the mind of the speaker or writer.
--
__Pascal Bourguignon__
Rob Warnock
+---------------
Then I misunderstood what you meant by "rc file". I assumed
you meant one's own personal "run control" (which is what "rc"
stands for) file in one's home directory, such as "~/.cmucl-init"
is for CMUCL. I can understand not wanting to have to have every user
needing to modify their personal init file just to get scripting.
The "site-switch-script.lisp" file mentioned above, by contrast,
goes in the system library directory, not anyone's home directory,
and thus should be considered an "optional module" installed with
the software. It includes a tweak to the "site-init.lisp" file that
is already there [to grab early control, so that the script's options
(if any) don't get interpreted as CMUCL command-line options]. As such,
it gives the ability to do "#!" scripting to *all* users of CMUCL on
the system, not just one.
If you don't like to do it that way, then just hack the same
thing into the "site-init.lisp" file. Or into the source of CMUCL
itself and recompile. The place to do the latter is in the file
".../src/code/save.lisp", in the function SAVE-LISP, in the LABELS
((%RESTART-LISP ...)), just after the (LOAD SITE-INIT ...) call.
In any case, you need to do it *before* the first call to FIND-SWITCH,
otherwise things can get all messed up if the user types the wrong
thing as command-line args to one of his/her scripts.
Marco Antoniotti
> On Feb 6, 7:20 am, "jos...@corporate-world.lisp.de" <jos...@corporate-
>
>
>
>
>
> world.lisp.de> wrote:
> > On 6 Feb., 14:00, Xah Lee <xah...@gmail.com> wrote:
>
>
> > > > I am also a newbie in Lisp. I have learned some part of elisp when I am
> > > > using Emacs.
>
> > > > Now I want to learn Lisp to understand it better.
>
> > > > But there are also a lot of Lisp, for example, scheme, Common Lisp,
> > > > elisp, etc.
>
> > > > I am really confused which kind of Lisp I should focus on......
>
> > > > Any suggestions?
>
> > > • Scheme lisp is mostly academia.
> > > • Emacs lisp is right on your desktop, mostly used just for text
> > > processing.
>
> > > Personally, i recommend emacs lisp, because it is most practical.
>
> > Note that you can ignore Mr. Lee's opinion. He has scripted
> > a little Emacs, but never wrote a single Scheme or Lisp program.
>
> elisp is a Lisp.
>
Where does the term "Commune" Lisp come from? It looks like you use
it in a derogatory term, but I fail to see the pun in it. "Cobol
Lisp" is much more sarcastic and comic after all.
Cheers
--
Marco
Rainer Joswig
rp...@rpw3.org (Rob Warnock) wrote:
... QDL ... interesting ...
> Well, the ANSI committee quite deliberately chose to *not* bless any
> particular subset(s). From CLHS "Issue SUBSETTING-POSITION:NONE":
>
> We have no well-defined proposals for subset definitions, and didn't
> have the time or energy to pursue their definition, or confidence
> that we could reach convergence on a reasonable definition.
>
> After investigating this area a bit myself, I think that they were
> quite right to take that position. CL has *so* many *nearly*-orthogonal
> dimensions that while it may appear easy on the surface to "subset"
> things, it's very difficult in practice to construct a sane transitive
> closure of features that doesn't drag in the whole language!! ;-}
You could see DIN Kernel Lisp, EuLisp level 0, ISLisp, Prefix
Dylan, etc. as attempts in that direction.
...
>
> Yet *another* question is whether a very small CL subset can be a
> useful teaching or tutorial or learning vehicle, as an alternative
> to Scheme [which already has a plethora of small implementations!].
That's an area, as well as a smaller extension language.
In the past there was demand for a delivery system.
Often the delivery system lacked some features
that seemed to be complicated to implement, seemed
to be to large or seemed to be not usable in a product
(like Lisp implementations without GC).
Sometimes you see books using a 'subset' of Common Lisp,
so that the student can understand the basics of
the algorithms presented without being shown
the complexity of more complete implementations
(with full error handling or more extensive
optimizations). For example 'artificial intelligence
programming, 2nd edition' (charniak/riesbeck/mcdermott/meehan)
uses a CL subset (described in a glossary in the book).
> The answer there, I think, is already a resounding "Yes!". If what you
> want is a CL subset about the size of R4RS Scheme, that can easily be
> implemented from scratch, in C, in as little as a few days' time for
> an experienced programmer interested in self-tutorial, or could be
> stretched to a full term paper project in a Computer Science course.
It would make sense if such a subset is described in
some way that can be reused by teachers.
> Finally, there's the question of whether a CL subset can be useful
> when researching possible modifications/alternatives to/in an existing
> full CL. I *think* so, but I'm still working on that one... ;-}
Sure, for example like the 'toy' implementation of CLOS ('Closette')
in AMOP.
Personally I think it would make sense to have a subset
of CL that is MOSTLY based on CLOS - similar in spirit
to Prefix Dylan, but compatible with CL. DEFSTRUCT
gone. LOOP gone. None CLOS printing/reading gone.
Pathnames as classes, hashtables as classes, streams
as classes, conditions as classes. User definable
method combinations gone. DEFUN gone. SETQ gone.
EQUAL a gf. complex numbers gone. lists/conses/sequences
boiled down to a core. single function to access
contents of a vector, bit vector, array, vector, ...
Just remove all the type specific functions and
replace them with generic functions and corresponding
methods.
>
> +---------------
> | Well, almost. There are some languages that can be seen as subsets.
> | It is just that there either unused or single purpose:
> | * CL0 ( http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/
> | lisp/impl/clicc/doc/cl0.pgz )
> +---------------
>
> Thanks for the reference. Do you have any idea how CL0 compares
> with, say, ThinLisp <http://www.thinlisp.org/>?
I haven't looked to closely to say anything useful.
...
> Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>. ;-}
> 88 initial defined symbols, float-only arithmetic, 500 LOC of *very* dense C!
> Then loading "init500.lisp" adds another 761 symbols, fleshing out the CL
> compatibility a *lot*.
I think it would be more useful to have a small, but readable
implementation, than having a very small but difficult to read
implementation. How readable is the C part of Lisp500?
>
>
> -Rob
>
> -----
> Rob Warnock <rp...@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
Pascal J. Bourguignon
> It would make sense if such a subset is described in
> some way that can be reused by teachers.
>
>> Finally, there's the question of whether a CL subset can be useful
>> when researching possible modifications/alternatives to/in an existing
>> full CL. I *think* so, but I'm still working on that one... ;-}
>
> Sure, for example like the 'toy' implementation of CLOS ('Closette')
> in AMOP.
>
> Personally I think it would make sense to have a subset
> of CL that is MOSTLY based on CLOS - similar in spirit
> to Prefix Dylan, but compatible with CL. DEFSTRUCT
> gone. LOOP gone. None CLOS printing/reading gone.
> Pathnames as classes, hashtables as classes, streams
> as classes, conditions as classes. User definable
> method combinations gone. DEFUN gone. SETQ gone.
So far so good.
> EQUAL a gf.
This cannot be, in a subset of CL.
The criteria is that a program written in the subset must execute the
same in CL.
(defclass my-obj ()
((x :accessor my-obj-x :initform 1)
(y :accessor my-obj-y :initform 2)))
(defmethod EQUAL ((a my-obj) (b my-obj))
(and (equal (my-obj-x a) (my-obj-x b))
(equal (my-obj-y a) (my-obj-y b))))
is not a valid CL program, therefore CL:EQUAL being a generic function
cannot be in a subset of CL.
> lists/conses/sequences
> boiled down to a core. single function to access
> contents of a vector, bit vector, array, vector, ...
I don't think this can be either.
> Just remove all the type specific functions and
> replace them with generic functions and corresponding
> methods.
Well, I assume we could remove CL:EQUAL, and have instead a gf
SYSTEM:EQUAL, or MY-SMALL-LANGUAGE:EQUAL.
> I think it would be more useful to have a small, but readable
> implementation, than having a very small but difficult to read
> implementation.
Definitely.
> How readable is the C part of Lisp500?
Not much.
--
__Pascal Bourguignon__
Kaz Kylheku
> Rob Warnock wrote:
>> jos...@corporate-world.lisp.de <jos...@corporate-world.lisp.de> wrote:
>> +---------------
>> | p...@informatimago.com (Pascal J. Bourguignon) wrote:
>> | > For example, we could take the intersection of Scheme features and CL
>> | > features, and define a subset of CL that would be as simple as Scheme
>> | > to implement (simplier since you wouldn't have continuations).
>> |
>> | Right. But there is no (see below) useful such subset defined.
>> +---------------
>>
>> While you are correct that there is no *standard* subset defined,
>> the CLHS 1.7 definition of "subset" is so broad that many, many
>> useful (to someone or other) subsets can easily be defined.
>
> I find ISLISP very useful.
>
> See http://www.islisp.info/specification.html
``The function car returns the left component of the cons. An error shall be
signaled if cons is not a cons (error-id. domain-error ).''
[ISLISP Working Draft 23.0, sec. 21.1 Cons]
Oops!
jos...@corporate-world.lisp.de
wrote:
Let's put it in a different package let it call CL:EQUAL
if necessary (or whatever low-level, even implementation
specific equal tests). Alternatively one could
implement the functionality in the new package
and provide a CL package (a legacy compatibility package
;-) ) that just calls the new functionality.
So CL:EQUAL is a function that calls GL:EQUAL.
'GL' = Generic Lisp.
> > lists/conses/sequences
> > boiled down to a core. single function to access
> > contents of a vector, bit vector, array, vector, ...
>
> I don't think this can be either.
>
> > Just remove all the type specific functions and
> > replace them with generic functions and corresponding
> > methods.
>
> Well, I assume we could remove CL:EQUAL, and have instead a gf
> SYSTEM:EQUAL, or MY-SMALL-LANGUAGE:EQUAL.
Yes. In Symbolics Genera you can also select a Lisp dialect
and the packages have the same name, but are different.
For example there is a dialect Symbolics Common Lisp
and another one Future Common Lisp. The latter is
similar to ANSI CL. Both have packages CL and CL-USER.
Depending what you select as a dialect the packages
contain different (amount) symbols and the compiler
might generate different code. Historically there
was also a CLtL1 dialect. The purpose was to develop
CLtL1 compatible and portable source code that doesn't
use any Symbolics extensions. There is also the
ZetaLisp dialect. Switching to that makes integers
octal based, etc. So, the dialect also affects
the reader in the REPL and some other stuff.
Pascal Costanza
Yep, there are some minor annoyances in ISLISP. Also: You have to
announce a generic function with defgeneric, a defmethod doesn't just
silently create one; there are no &optional or &key arguments, only
&rest; and there is a gratuitous extension for defining abstract classes.
But there are also some improvements. For example, I think the
separation between lexical and dynamic variables is cleaner; case-using
is neat; assure works a bit better than assert; conditions and classes
are unified; and the condition system has slight improvements.
I have already used ISLISP, as a platform for language experiments, and
it has some advantages there. I also see a potential for ISLISP as an
introductory Lisp language, for a one-semester course, where Common Lisp
is typically too large - but it's better than Scheme when your goal is
to eventually "upgrade" to Common Lisp in the long run. And the ISLISP
specification is smaller than that of Scheme... :-P
Andrew Reilly
> The main difference is that Emacs is a text
> editor and at its core includes some basic functionality in that domain.
> A script usually controls a program that contains specific implemented
> functionality for some domain. For example the program might know how to
> display characters and how to talk to the
> OS and its libraries. The scripting language then has an (possibly
> partly domain independent) implementation in form of an interpreter (or
> similar) and access to the provided functionality of the program. So
> with the script you call and combine functionality from the underlying
> program. So the typical task of Emacs Lisp would be to customize and
> extend the functionality of the editor. You may be able to call Emacs
> Lisp in a way that it does not execute much of the editor functionality,
> but that is not the main purpose.
>
> CMUCL as an implementation of the programming language Common Lisp does
> not know anything about buffers, keypresses, frames, menus, etc. But you
> can write all the functionality of an editor in CMUCL, including the
> functionality that is provided by the Emacs C code. The runtime of CMUCL
> is domain independent.
I really want to like this distinction. It feels kind of right. But I
think that is an illusion, because of the particular limitations of the
set of functions assumed to be part of CMUCL.
What if you had picked some different examples:
mzscheme -e '(display "Hello World\n")'
mred -e '(display "Hello World\n")'
These both do the same thing, but the second one invokes a runtime that
has a vast wodge of GUI and text-editor functionality built in, and the
first doesn't.
The second doesn't leap full-blown into an IDE unless you invoke the
drscheme "script", but the difference clearly can't be just the range of
libraries available or the "general purpose" nature of the base.
> * a program is an independent executable piece of code
> (relative to an execution engine like a processor in hardware or a
> virtual machine)
Not source code, then? Java programs are programs but bourne shell or
clisp or mzscheme programs aren't? Python code runs from source, but is
compiled to python-VM code and executed. Much Javascript code executes
as native processor instructions these days (fancy JITs in Chrome, Fox
and Safari) does that change the program/script nature of the Javascript
code? Is Adobe ActionScript code a program because it's delivered as
independent VM executable, rather than as source code?
> * a script is a piece of code that has access to the functionality
> of a program (either internal or external). It can call and combine
> this functionality.
This feels better, but it is still a bit of an arbitrary distinction,
IMO. A command line for i in *; ... loop in sh is a script, but it is
also a program. Maybe the thing that makes a script a script is that it
is short and that it doesn't take arguments?
> * an application is the combination of programs, scripts and data
> that provides a general functionality. For example the typical Emacs
> is an application that combines several programs ( ctags, emacsclient,
> etags, emacs, ...), lots of 'scripts' (typically written in Emacs
> Lisp) and data files like dictionary data.
But aren't gnus and doctor programs in their own right?
> Does that make sense to you?
Not really, but it's fun nibbling at the edges of the semantics.
Personally, I think that a script is limited to a "transcript" of
something that I could have written at a console during an interactive
session, but have taken a short-cut and saved for later. An application
defines its own purpose and session. Program probably encompasses the
whole spectrum of sequences of instructions (or expressions of functions,
if you prefer)...
--
Andrew
Andrew Reilly
>> See http://www.islisp.info/specification.html
>
> ``The function car returns the left component of the cons. An error
> shall be
> signaled if cons is not a cons (error-id. domain-error ).''
> [ISLISP Working Draft 23.0, sec. 21.1 Cons]
>
> Oops!
I've seen the CL folk (here) make a big deal about this, but it clearly
doesn't stop large lumps of code being written in scheme or (presumably)
islisp. I'm not a fan of exceptions myself: I think that wherever
possible a function should be defined to return a reasonable value for
any input: exception paths complicate program logic and imply hidden
mechanism that I would prefer not to have to analyse. So I can see that
(car '()) could reasonably be defined to return NIL, as it is in CL.
That would fit my preferences. I just don't see where this would be
idiomatically useful: a non-buggy program wouldn't be trying to do that
anyway, so whether it returns a safe NIL or a stupid exception seems moot
to me.
Clearly sometimes exceptions (or crashing into the debugger) are the
right answer, because (car "foo") does that on both CL, scheme and
presumably islisp.
Is the difference that matters the fact that in Common Lisp car operates
on the domain of LIST, which includes NIL, whereas scheme (and islisp)
the domain is pair? OK, maybe that is a fair distinction. I'd still
like to know how that shows up in idiomatic code, though.
Hmm: OK, in CL you can have a list argument and go straight ahead and
destructure it into the car and cdr, and both might be NIL, whereas the
other school of thought requires a test for NIL first. Is that so much
of a win? What if your function is passed (list NIL): shouldn't that
provoke different behaviour?
Cheers,
--
Andrew
Pascal Costanza
Kaz Kylheku
> On Sat, 07 Feb 2009 22:04:45 +0000, Kaz Kylheku wrote:
>>> See http://www.islisp.info/specification.html
>>
>> ``The function car returns the left component of the cons. An error
>> shall be
>> signaled if cons is not a cons (error-id. domain-error ).''
>> [ISLISP Working Draft 23.0, sec. 21.1 Cons]
>>
>> Oops!
>
> I've seen the CL folk (here) make a big deal about this, but it clearly
> doesn't stop large lumps of code being written in scheme or (presumably)
> islisp.
Ah, but so what? Large lumps of code are written in C, and historically even in
assembly language.
The lumps you are writing are larger lumps than what they would be
if car just specializes to the null class.
But it's the lack of compatibility that's the problem: going back into large
lumps of code and sticking in the tests. Or replacing car with my-car which
does the right thing.
> I'm not a fan of exceptions myself: I think that wherever
> possible a function should be defined to return a reasonable value for
> any input:
> exception paths complicate program logic and imply hidden
> mechanism that I would prefer not to have to analyse. So I can see that
> (car '()) could reasonably be defined to return NIL, as it is in CL.
Especially given that ISLISP borrows from CL, and the ISLISP committee people
know very well that (car nil) works in CL perfectly fine.
To me, this is evidence of a little bit of an attitude problem.
``Let's have the language reject things that are accepted in Common Lisp, just
to be rebels against Common Lisp, even though we are taking some of its
features, like a lot of CLOS and namespace separation, etc.''.
That is not how you approach things, if your goal is to bridge gaps between
dialects.
I suspect that things like that may be done to appease users coming to ISLISP
from other than a CL background. Say EuLisp or Scheme users who like some
things in Common Lisp, but due to some attitude problem regard (car nil) as
wrong. ISLISP is then not compatible with their mental illness, or
at least not incompatible on account of this.
> That would fit my preferences. I just don't see where this would be
> idiomatically useful: a non-buggy program wouldn't be trying to do that
> anyway, so whether it returns a safe NIL or a stupid exception seems moot
> to me.
What? It's the definition of car that determines whether the program is buggy
or not, in this regard.
Basically you're revealing your position about this: (car nil) is buggy, so you
don't care. Well, if we define (car nil) in some consistent way then it's not
buggy, is it!
Do you regard (sqrt -1) as buggy? :)
> Clearly sometimes exceptions (or crashing into the debugger) are the
> right answer, because (car "foo") does that on both CL, scheme and
> presumably islisp.
That's right. So if ISLISP is being developed with regard for the cultires of
some existing dialects, like Scheme, Lisp and EuLisp, then (car "foo") being
an error at least isn't inconsistent with compatibility goals.
> Is the difference that matters the fact that in Common Lisp car operates
> on the domain of LIST, which includes NIL, whereas scheme (and islisp)
> the domain is pair? OK, maybe that is a fair distinction. I'd still
> like to know how that shows up in idiomatic code, though.
>
> Hmm: OK, in CL you can have a list argument and go straight ahead and
> destructure it into the car and cdr, and both might be NIL, whereas the
> other school of thought requires a test for NIL first. Is that so much
> of a win?
Regardless of it being a win or not, if I have CL code which depends on this,
maybe I can port it to ISLISP with fewer hassles. I don't have to justify
myself whether that code is ``idiomatic'' or not, only that it's correct CL.
Why have significant CL compatibility in some big things, but neglect the
little things?
> What if your function is passed (list NIL): shouldn't that
> provoke different behaviour?
Sometimes you don't CAR-e. :) Sometimes, for instance, you want to test if the
first item of some list is such and such. If the list is empty, or if it's no
empty with the first item being explicitly NIL, it doesnt' matter:
(when (eq (car list) 'foo)
...)
It's nothing more than academic nitpicking to require this code to be worried
that the list may be empty.
If the list is empty, then it freaking obviously does /not/ have a first item
which is the symbol FOO and so the body of the WHEN should not execute.
Please, dear Programming Language, drop the act like you have Asperger's
syndrome and move on with the processing.
If I asked you, ``Is Joe first in line at the checkout counter?'' would you
tell me ``Sorry, I can't determine who is first in a line that is empty, so I
can't tell you whether that might be Joe''? I'd think you're an autistic geek,
or rather a comedian impersonating one. Since I'm not autistic and can extract
information from bizarre replies, I'd have my answer anyway.
A programming language can achieve precision without exhibiting such a
personality.
Kaz Kylheku
> On Sat, 07 Feb 2009 04:42:12 -0800, jos...@corporate-world.lisp.de wrote:
>
>> The main difference is that Emacs is a text
>> editor and at its core includes some basic functionality in that domain.
>> A script usually controls a program that contains specific implemented
>> functionality for some domain. For example the program might know how to
>> display characters and how to talk to the
>> OS and its libraries. The scripting language then has an (possibly
>> partly domain independent) implementation in form of an interpreter (or
>> similar) and access to the provided functionality of the program. So
>> with the script you call and combine functionality from the underlying
>> program. So the typical task of Emacs Lisp would be to customize and
>> extend the functionality of the editor. You may be able to call Emacs
>> Lisp in a way that it does not execute much of the editor functionality,
>> but that is not the main purpose.
>>
>> CMUCL as an implementation of the programming language Common Lisp does
>> not know anything about buffers, keypresses, frames, menus, etc. But you
>> can write all the functionality of an editor in CMUCL, including the
>> functionality that is provided by the Emacs C code. The runtime of CMUCL
>> is domain independent.
>
> I really want to like this distinction. It feels kind of right. But I
> think that is an illusion, because of the particular limitations of the
> set of functions assumed to be part of CMUCL.
The ``scripting'' versus ``other programming'' distinction isn't one about
programming languages, though programming languages can be designd
to pe particularly suitable for scripting, whatever that may be.
It's not about programming language implementations, though programming
language implementations can be geared toward scripting.
It's a distinction about the programming situation: what is its context,
and what are its goals.
Scripting is a kind of programming activity where the context is automating
some tasks within some application or operating system, using large functional
blocks provided by that host system. The results of that activity are called
scripts, by the people who write them.
Note that you can't easily draw a distinction betweeen scripting and other
programming using large and powerful libraries, except that large and powerful
libraries are not necessarily tied to a particular appliaction or OS, though
they could be.
Suppose that you had a C library which provided a function representing each
Unix utility, like cp, rm, touch, and so on, and all shell builtins, like test.
If you wrote C programs which used nothing but these functions, would that be
scripting?
You could write a program like this:
#include <shell.h>
void rotate_logs(void)
{
rm("-f", "log.2");
mv("log.1", "log.2");
mv("log, "log.1");
}
Is that scripting? There is a lot of irrelevant syntax involved, and you
probably have to compile the program.
There exist interpreted implementations of C, geared toward scripting,
like cint and eic, and they typically allow functions to be called at file
scope. I.e. some simplification is made for the sake of scripting.
But C undeniably has features that get in the way of scripting, like
difficulties with string manipulation and memory management, et cetera.
If the programmer can't put two strings together without worrying about where
the memory comes from for the result, it's probably not scripting.
If there are translation-time versus run-time distinctions in the language
semantics, it's probably not that suitable for scripting in its general form.
In scripting situations, liberties may be taken with dependencies on
interpreted semantics that smear the distinction between translation time and
run time.
>
> What if you had picked some different examples:
> mzscheme -e '(display "Hello World\n")'
> mred -e '(display "Hello World\n")'
>
> These both do the same thing, but the second one invokes a runtime that
> has a vast wodge of GUI and text-editor functionality built in, and the
> first doesn't.
Still, does the display function depend on any of that? The fact is that
you /can/ invoke a light-weight version of the language implementation,
yet that expression still works.
In fact, it will work even in a minimal language implementation, which defines
only a basic library and rudimentary I/O, and can be implemented on a wide
variety of operating systems.
I'd say that both these situations smell like scripting, because the fact is
that what you have is statements in a shell command language, which contain
little logic in themselves, but which move mountains. Beind the "mred" command,
a million things happen: things like forking a process, mapping an executable
and shared libraries into memory and so on. A trivial output appears, and then
all of that is undone.
You would probably not write a large and complicated Scheme program as the
argument of the -e command line option.
Things like that might be done in a shell script or a Makefile, as part of
some packaging steps for a Scheme program and such.
As an example, to install a CLISP program we might do something like
clisp -M memory-image.mem -x '(ext:saveinitmem "name" ...)'
It is legitimate to say that we are in fact scripting an installation step for
a program, contained in the memory image.
Icarus Sparry
> * jos...@corporate-world.lisp.de [2009-02-07 11:53+0100] writes:
>
>>> In other words, a script is a program that controls programs? Or is a
>>> script not a program?
>>> If not, what is a program?
>>
>> A program is an independent executable piece of code. For example
>> /bin/sh is usually a program. You can start /bin/sh and it runs
>> independent of anything, other than the OS that hands control to the
>> program. (Note that a script could also be an executable file, but it
>> needs a program, the script interpreter/runtime to execute).
>
> /bin/sh also needs an interpreter/runtime. Under Linux it's called
> /lib/ld-linux.so which loads elf object files into memory, performs
> relocation and dynamic linking.
>
All the world is not Linux running with ELF! The "a.out" format which was
used by Unix for many years before ELF appeared on the scene does not
have this need for an interpreter.
With ELF you do gain a number of advantages due to its flexability, but
you also pay a cost of slower starting programs and extra complexity that
can cause problems (including security ones).
Even if you stick with ELF, it is not a requirement that an ELF
executable has an interpreter. As a concrete example you can find on your
Linux system, /lib/ld-linux.so (maybe with a version number) is an ELF
executable that does not need an interpreter.
Andrew Reilly
A really good answer. Thanks! I agree completely. Clearly buggyness or
otherwise must depend on the specification of the functions involved:
it's not as though we're dealing with clean-sheet language definitions in
either case here, so it's hard or, indeed, pointless, to consider such
things in the abstract.
Cheers,
--
Andrew
Rob Warnock
+---------------
| rp...@rpw3.org (Rob Warnock) wrote:
| > Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>. ;-}
| > 88 initial defined symbols, float-only arithmetic, 500 LOC of *very*
| > dense C! Then loading "init500.lisp" adds another 761 symbols,
| > fleshing out the CL compatibility a *lot*.
|
+---------------
Almost totally *unreadable*, actually! ;-} It's full of
"obfuscated C"-style compressions to keep the LOC small, e.g.:
...
typedef int lval;
lval *o2c(lval o) { return (lval*)(o - 1); }
...
#define TRUE symi[1].sym
#define T g[-2]
#define U g[-3]
#define V g[-4]
#define W g[-5]
#define NF(n) lval *g; g=f+n+3; f[1]=0; g[-1]=(n<<5)|16; *g=*f;
#define E *f
#define NE *g
lval car(lval c) { return (c & 3) == 1 ? o2c(c)[0] : 0; }
lval cdr(lval c) { return (c & 3) == 1 ? o2c(c)[1] : 0; }
...
lval eval_if(lval *f, lval ex) { return evca(f, evca(f,ex)?cdr(ex):cddr(ex)); }
...
lval eval_unwind_protect(lval *f, lval ex) { NF(1) T=0;
T=ma(g,2,52,E,cdr(ex)); dyns = cons(g, T, dyns); T = evca(g, ex);
T = rvalues(g, T); unwind(g, cdr(dyns)); return mvalues(T); }
lval eval_if(lval *f, lval ex) {
return evca(f, evca(f,ex)?cdr(ex):cddr(ex)); }
lval eval_multiple_value_call(lval *f, lval ex) { lval *g=f+3; lval l;
f[1]=evca(f, ex); for (ex=cdr(ex); ex; ex=cdr(ex)) { *g=*f;
g[-1]=((g-f-3)<<5)|16; for (l = rvalues(g, evca(g, ex)); l; l = cdr(l)) {
g[-1] = car(l); g++; }} xvalues = 8; return call(f, f[1], g-f-3); }
lval eval_multiple_value_prog1(lval *f, lval ex) { NF(1) T=0;
T = evca(g, ex); T = rvalues(g, T); eval_body(g, cdr(ex));
return mvalues(T); }
...
+---------------
| I think it would be more useful to have a small, but readable
| implementation, than having a very small but difficult to read
| implementation.
+---------------
I agree. Which is why even though my QDL is (currently) *much* less
featureful than Lisp500, there might be some point in making it available,
since IMHO it's much more readable. E.g., compare the above "one-liner"
"eval_if()" with the version in QDL-0.4:
lispobj
eval_if(lispobj rest, lispobj env)
{
lispobj bool;
GC_PROTECT_BUF(2);
GC_PROTECT_2(rest, env);
bool = eval(car(rest), env);
GC_UNPROTECT;
if (bool != NIL)
return eval(cadr(rest), env);
else
return eval(caddr(rest), env);
Rob Warnock
+---------------
| p...@informatimago.com (Pascal J. Bourguignon) wrote:
| > Rainer Joswig <jos...@lisp.de> writes:
| > > EQUAL a gf.
| >
| > This cannot be, in a subset of CL.
| >
| > The criteria is that a program written in the subset must
| > execute the same in CL.
| > ...[example]...is not a valid CL program, therefore CL:EQUAL
| > being a generic function cannot be in a subset of CL.
|
| Let's put it in a different package let it call CL:EQUAL
| if necessary (or whatever low-level, even implementation
| specific equal tests). Alternatively one could
| implement the functionality in the new package
| and provide a CL package (a legacy compatibility package ;-) )
| that just calls the new functionality.
| So CL:EQUAL is a function that calls GL:EQUAL.
| 'GL' = Generic Lisp.
That's still not a "subset of Common Lisp", since a subset
must not require any special macros or libraries to be loaded
into the full CL first:
1.7 Language Subsets
...
For a language to be considered a subset, it must have the property
that any valid program in that language has equivalent semantics and
will run directly (with no extralingual pre-processing, and no special
compatibility packages) in any conforming implementation of the full
language.
Of course, you could *define* a subset of your GL, say, "GL-",
that was a proper subset of CL, but it doesn't sound like your
full GL is going to be one.
Your "GL" proposal (and ISLISP, and others mentioned) actually brings up
a basic problem with subsets of CL [that I mentioned before, albeit
indirectly], namely, that CL has so many not-quite-orthogonalities
that one is strongly tempted to "fix" some of them in the process of
defining a smaller language... whereupon one ends up with something
that isn't a proper "subset".
But if one *doesn't* fix them, then the corners that are left sticking
out tend to drag in far too much of full CL, and the "smaller" language
ends up being not that much smaller after all.
It's quite a dilemma, actually...
Rob Warnock
+---------------
| Personally, I think that a script is limited to a "transcript" of
| something that I could have written at a console during an interactive
| session, but have taken a short-cut and saved for later.
Hmmm... That has an approximately-right feel to it, IMHO.
That certainly defines a whole *bunch* of CMUCL-based "scripts"
I have [and use daily]. Although, some of them reflect the
results of fairly *long* interactive sessions... ;-} ;-}
Kaz Kylheku
> On Sat, 07 Feb 2009 13:02:00 +0100, Helmut Eller wrote:
>
>> * jos...@corporate-world.lisp.de [2009-02-07 11:53+0100] writes:
>>
>>>> In other words, a script is a program that controls programs? Or is a
>>>> script not a program?
>>>> If not, what is a program?
>>>
>>> A program is an independent executable piece of code. For example
>>> /bin/sh is usually a program. You can start /bin/sh and it runs
>>> independent of anything, other than the OS that hands control to the
>>> program. (Note that a script could also be an executable file, but it
>>> needs a program, the script interpreter/runtime to execute).
>>
>> /bin/sh also needs an interpreter/runtime. Under Linux it's called
>> /lib/ld-linux.so which loads elf object files into memory, performs
>> relocation and dynamic linking.
>
> All the world is not Linux running with ELF! The "a.out" format which was
> used by Unix for many years before ELF appeared on the scene does not
> have this need for an interpreter.
a.out does not imply that there is no loader. Only, perhaps,
for the situation where the a.out binary is static.
Linux has had an ld.so interpreter, way before the introduction of ELF.
It had one when shared libraries were introduced---a.out ``jump table'' shared
libraries.
It was for shared libraries then, and it's for shared libraries now!
I remember that one of the people that hacked on this early ld.so was Peter
Macdonald, also known for the SLS distribution, which led an early effort
to modularize the kernel.
He might have led the initial development of this dynamic loader. I guess he
was into modularizing everything in his path! Kernel, user space, doesn't
matter.
> Even if you stick with ELF, it is not a requirement that an ELF
> executable has an interpreter. As a concrete example you can find on your
> Linux system, /lib/ld-linux.so (maybe with a version number) is an ELF
> executable that does not need an interpreter.
Well, of course. That would create a chicken-and-egg problem, wouldn't it! If
the program execution handler in the kernel could not load anything at all by
itself, how would the interpreter run? You can't need the interpreter to run
the interpreter.
As a more general concrete example, you can use any other statically linked ELF
executable. There is no ld.so interpreter in those. It's for handling the case
that the program is incomplete---needs shared libs.
Kaz Kylheku
> Rainer Joswig <jos...@lisp.de> wrote:
> +---------------
>| rp...@rpw3.org (Rob Warnock) wrote:
>| > Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>. ;-}
>| > 88 initial defined symbols, float-only arithmetic, 500 LOC of *very*
>| > dense C! Then loading "init500.lisp" adds another 761 symbols,
>| > fleshing out the CL compatibility a *lot*.
>|
>| ... How readable is the C part of Lisp500?
> +---------------
>
> Almost totally *unreadable*, actually! ;-} It's full of
> "obfuscated C"-style compressions to keep the LOC small, e.g.:
[ snip ]
> #define NE *g
^^
[ snip ]
> lval eval_multiple_value_call(lval *f, lval ex) { lval *g=f+3; lval l;
^^
> f[1]=evca(f, ex); for (ex=cdr(ex); ex; ex=cdr(ex)) { *g=*f;
^^
Geez, how confusing! Why is this *g explicitly written, instead of
taking advantage of the abstracting power of the NE macro?
;)
Pascal J. Bourguignon
> You could write a program like this:
>
> #include <shell.h>
>
> void rotate_logs(void)
> {
> rm("-f", "log.2");
> mv("log.1", "log.2");
> mv("log, "log.1");
> }
>
> Is that scripting? There is a lot of irrelevant syntax involved, and you
> probably have to compile the program.
But this one would definitely be a program:
#include <unistd.h>
void rotate_logs(void){
unlink("log.2");
rename("log.1","log.2");
rename("log","log.1");
}
--
__Pascal Bourguignon__
Rainer Joswig
rp...@rpw3.org (Rob Warnock) wrote:
...
>
> I agree. Which is why even though my QDL is (currently) *much* less
> featureful than Lisp500, there might be some point in making it available,
> since IMHO it's much more readable. E.g., compare the above "one-liner"
> "eval_if()" with the version in QDL-0.4:
>
> lispobj
> eval_if(lispobj rest, lispobj env)
> {
> lispobj bool;
> GC_PROTECT_BUF(2);
>
> GC_PROTECT_2(rest, env);
> bool = eval(car(rest), env);
> GC_UNPROTECT;
> if (bool != NIL)
> return eval(cadr(rest), env);
> else
> return eval(caddr(rest), env);
> }
Looks better, IMHO. ;-)
Rainer Joswig
rp...@rpw3.org (Rob Warnock) wrote:
I would not adhere to the standard words where not applicable.
The designers of Common Lisp somehow failed to address
the compatibility problem also. Lots of people used
CLtL1 Common Lisp. Then ANSI CL appeared. Could you
load a non-trivial CLtL1 program into an ANSI CL?
It failed already at IN-PACKAGE. That was a typical
experience - the changes to IN-PACKAGE were trivial,
but you had to change every file (which was using
IN-PACKAGE). For the period of time (many years)
where CLtL1 and CLtL2 (and later) Lisps were used,
one had to put support for both forms of package
functionality into the sources. For some years now,
when I see CLtL1 compatibility code, I take it out,
- it is no longer a problem - because CLtL1 is no
longer relevant. Every time I see a file where
huge feature terms (#+ #- #feature-case ...) is used
around basic Lisp functionality (pathnames, packages, ...)
I can now get rid of almost all of them and have
the code be portable.
So, if we define some derivative of CL, how to deal with that
problem of compatibility with an older standard. Is our
solution constrained by every word of the ANSI CL standard?
> Your "GL" proposal (and ISLISP, and others mentioned) actually brings up
> a basic problem with subsets of CL [that I mentioned before, albeit
> indirectly], namely, that CL has so many not-quite-orthogonalities
> that one is strongly tempted to "fix" some of them in the process of
> defining a smaller language... whereupon one ends up with something
> that isn't a proper "subset".
That's true. I would really look at two different goals.
* a 'real' subset of Common Lisp that still is useful for some
purpose (education, implementation vehicle, ...)
* an intellectual subset of Common Lisp, using reduction
principles.
As an example see aref, bit, char, elt, svref, ...
Just replace all those with a generic function
REF and skip the rest. Then one principle to shrink
the language would be to replace all type specific
functions with methods for fewer generic functions.
> But if one *doesn't* fix them, then the corners that are left sticking
> out tend to drag in far too much of full CL, and the "smaller" language
> ends up being not that much smaller after all.
>
> It's quite a dilemma, actually...
Right. If you look at the simplified Common Lisp named
(prefix) Dylan, the first described version was more
reduced by omitting things (like IO) and a target
domain that had limited requirements (delivery).
Then you start adding those things. Then there
are interactions with the rest of the language. The condition
system for example is the only part of the CL language
that deals with handling conditions and errors - but
it makes absolutely sense to use/integrate it in other
parts (like describing errors in terms of conditions,
having ASSERT using it, etc.). It would be equally
useful to have CLOS classes used for streams.
Unfortunately that's not in the standard. Fortunately
that's still provided by implementations, because it
is useful.
Rainer Joswig
Kojak <nnt...@janville.Borg.invalid> wrote:
> Le Fri, 6 Feb 2009 05:55:38 -0800 (PST),
> jos...@corporate-world.lisp.de a écrit :
>
> > [...]
> > + can be used for scripting (CLISP)
> > [...]
>
> Just for information, since version 1.0.22, SBCL can be use
> for scripting too (without need of extra tweak in rc file).
Thanks! Good to know. Can you post a link to the documentation
where this is described?
Rob Warnock
+---------------
| Rob Warnock <rp...@rpw3.org> wrote:
| > Rainer Joswig <jos...@lisp.de> wrote:
| > +---------------
| >| rp...@rpw3.org (Rob Warnock) wrote:
| >| > Well, there's always Lisp500 <http://www.modeemi.fi/~chery/lisp500/>.
| >| > dense C! Then loading "init500.lisp" adds another 761 symbols,
| >| > fleshing out the CL compatibility a *lot*.
| >|
| >| ... How readable is the C part of Lisp500?
| > +---------------
| >
| > Almost totally *unreadable*, actually! ;-} It's full of
| > "obfuscated C"-style compressions to keep the LOC small, e.g.:
| [ snip ]
| > #define NE *g
| > lval eval_multiple_value_call(lval *f, lval ex) { lval *g=f+3; lval l;
| ^^
| Geez, how confusing! Why is this *g explicitly written, instead of
| taking advantage of the abstracting power of the NE macro? ;)
Heh. Now you see one of the reasons I'm writing my own
"Quick & Dirty Lisp" (QDL) instead of just using Lisp500!! ;-} ;-}
[Well, there were several other reasons, too... ;-} ]
You might be amused to know that even Lisp500's *author*
occasionally has had trouble remembering how it works: ;-} ;-}
http://www.modeemi.fi/~chery/lisp500/
...
2004-05-11 Implemented flet and labels in the compiler. During a
short break in working on lisp500, I apparently managed to forget how
the stack discipline goes. It was somewhat painful to figure out how.
...
That said, I still admire Lisp500 for the huge fraction of CL that
it manages to achieve in only 500 lines of C & 5800 lines of Lisp.
But I wouldn't recommend it for study for someone new to Lisp...
Pascal Costanza
> To me, this is evidence of a little bit of an attitude problem.
>
> ``Let's have the language reject things that are accepted in Common Lisp, just
> to be rebels against Common Lisp, even though we are taking some of its
> features, like a lot of CLOS and namespace separation, etc.''.
>
> That is not how you approach things, if your goal is to bridge gaps between
> dialects.
>
> I suspect that things like that may be done to appease users coming to ISLISP
> from other than a CL background. Say EuLisp or Scheme users who like some
> things in Common Lisp, but due to some attitude problem regard (car nil) as
> wrong. ISLISP is then not compatible with their mental illness, or
> at least not incompatible on account of this.
If I understand the historical background correctly, ISLISP was indeed a
compromise between Lispers and Schemers, so there are some features from
Common Lisp-style languages and some features from Scheme-style
languages. The fact that (car '()) throws an error clearly comes from a
Scheme influence, as does the feature that you can write (lambda ...)
instead of #'(lambda ...) (which then went into ANSI Common Lisp as
well). Kent Pitman probably knows more of the historical details.
The fact that (car '()) throws an error is a nuisance, but nothing I
would judge a language on. Overall, ISLISP looks pretty good.
Pascal
Pascal J. Bourguignon
I think it would be ok for a "Subset of Common Lisp" to _define_
aref, but, char, etc, svref as a common generic function:
(defun cl:aref (a &rest indices) (apply (function gf:ref) a indices))
(defun cl:bit (a &rest indices) (apply (function gf:ref) a indices))
(defun cl:sbit (a &rest indices) (apply (function gf:ref) a indices))
(defun cl:svref (v index) (gf:ref v index))
(defun cl:char (v index) (gf:ref v index))
...
Nothing prevent a full CL implementation to do it that way.
More generally, the subsetting only applies to the CL package. It
would be a valid subset of CL not to define these accessor: valid
conforming programs that don't use them and work in the subset are
still valid and conforming Common Lisp programs. Of course this
would reduce greatly and artificially the number of programs valid in
both the subset and CL.
Any program using directly an extension such as gf:ref wouldn't be
a conforming program in the first place, and wouldn't have to be
considered to determine whether the language is a subset of Common
Lisp. These features would be extensions to the subset as well as
(possible) extensions to Common Lisp.
>> But if one *doesn't* fix them, then the corners that are left sticking
>> out tend to drag in far too much of full CL, and the "smaller" language
>> ends up being not that much smaller after all.
>>
>> It's quite a dilemma, actually...
>
> Right. If you look at the simplified Common Lisp named
> (prefix) Dylan, the first described version was more
> reduced by omitting things (like IO) and a target
> domain that had limited requirements (delivery).
> Then you start adding those things. Then there
> are interactions with the rest of the language. The condition
> system for example is the only part of the CL language
> that deals with handling conditions and errors - but
> it makes absolutely sense to use/integrate it in other
> parts (like describing errors in terms of conditions,
> having ASSERT using it, etc.). It would be equally
> useful to have CLOS classes used for streams.
> Unfortunately that's not in the standard. Fortunately
> that's still provided by implementations, because it
> is useful.
In My Lisp, I could have a specified ML / MY-LISP package containing
all the symbols of My Lisp, such as ML:REF. I could define a package
named COMMON-LISP-SUBSET-1, nicknamed COMMON-LISP and CL, and
exporting a subset of Common Lisp that would intersect with My Lisp or
be trivially implemented in My Lisp.
Programs written using MY-LISP wouldn't be conforming CL programs, too
bad for them. But programs written using the CL package in My Lisp
would be conforming (if restricted), and could be run directly in a
full CL implementation. If I decided to use some features of MY-LISP
in my program using the CL package in My Lisp, I could always define a
MY-LISP package in a CL implementation to port this non conforming
program to CL.
Notice the three classes of programs:
* MY-LISP programs are not CL programs, the cannot be run in a CL
implementation.
* CL-SUBSET conforming programs are CL programs: they can be run
directly in a CL implementation.
* CL-SUBSET non conforming programs are not conforming programs: they
need to be ported to CL, possibly just by writting a portability
layer in form a simple CL package.
One last word: notice that ISLISP CAR is a subset of CL:CAR.
(let ((list '()))
(if (eq list '())
'()
(car list)))
is a valid ISLISP (and also Scheme) program, and is also a conforming
program in Common Lisp. Therefore we could define a subset of CL
containing let, if, eq quote () and car applied on cons cells.
You could also define a subset of Common Lisp where the symbols used
to name functions cannot be used to name variables (including
parameters).
Actually, it looks like the activity of defining a subset of CL
consists more of defining a subset of the other language (the language
in which the subset of CL will run) of CL...
--
__Pascal Bourguignon__
Kaz Kylheku
> Kaz Kylheku wrote:
>
>> To me, this is evidence of a little bit of an attitude problem.
>>
>> ``Let's have the language reject things that are accepted in Common Lisp, just
>> to be rebels against Common Lisp, even though we are taking some of its
>> features, like a lot of CLOS and namespace separation, etc.''.
>>
>> That is not how you approach things, if your goal is to bridge gaps between
>> dialects.
>>
>> I suspect that things like that may be done to appease users coming to ISLISP
>> from other than a CL background. Say EuLisp or Scheme users who like some
>> things in Common Lisp, but due to some attitude problem regard (car nil) as
>> wrong. ISLISP is then not compatible with their mental illness, or
>> at least not incompatible on account of this.
>
> If I understand the historical background correctly, ISLISP was indeed a
> compromise between Lispers and Schemers, so there are some features from
Apparently, a political compromise too, not merely a technical one. Technical
compomises are fine, because they are necessary.
> Common Lisp-style languages and some features from Scheme-style
> languages. The fact that (car '()) throws an error clearly comes from a
> Scheme influence, as does the feature that you can write (lambda ...)
Right, and so the point is to make Schemers /feel/ that their psychosis has
been properly nursed in the design of ISLISP. The idea is that the first thing
a Schemer does at an ISLISP repl is try out an acceptance test: (car '()). He
feels a warm fuzzy feeling of community inclusion when it blows up with a
condition. Is that the idea? Let's make things /not/ work in order to include
people.
Or do you suppose it is the idea that everyone from any dialect background
should be confronted with some nuisances, so that there is equality? If there
are not enough nuisances for this particular camp, that would not be fair, so
we will invent some. I.e. if Schemers ran into nuisances much more frequently
in ISLISP than Common Lisp users, that would be an unacceptable bias. We have
already ``punished'' Schemers by forcing funcall onto them with the dual
namespaces and all, so let's ``give back'' something to them and break (car
nil) for the people coming from a Lisp background. So, programmers are like
kindergarten children. If we take a toy away from Bobby and give it to Mikey,
we have to give Bobby another toy, or a lollipop.
Either way, sounds like a dirty process to me. ISO committee political backroom
garbage, not engineering. They didn't have anyone like me to ``smack them
upside the head'' and set them straight.
See because that is too bad, because ISLISP isn't such a bad idea. Why not
have a smaller common-lisp-like thing for very small systems?
Too bad it has to be screwed up by wanton, pointless incompatibilibites in
addition to the understandable ones.
The feature that we can write (lambda ()) does not hurt the feature
that we can write '(lambda ()) or #'(lambda ()). It's inclusive. We can do
it this way, and the other ways are not banished.
> The fact that (car '()) throws an error is a nuisance, but nothing I
> would judge a language on.
It speaks volumes about the people involved and their approach to the thing,
though, doesn't it!
How about (append 42) not returning 42? It doesn't stop at (car nil).
Sure, let's not judge fifty gallons of milk by one little drop of motor oil.
Tobias C. Rittweiler
> Apparently, a political compromise too, not merely a technical one. Technical
> compomises are fine, because they are necessary.
I think there are more technical arguments in favor of seperating NIL
from boolean false than the other way around.
I like it because I find it too damn convenient most of the time. That's
not really a technical argument, though.
So what are your technical arguments for coalescing them?
-T.
Kaz Kylheku
> Kaz Kylheku <kkyl...@gmail.com> writes:
>
>> Apparently, a political compromise too, not merely a technical one. Technical
>> compomises are fine, because they are necessary.
>
> I think there are more technical arguments in favor of seperating NIL
> from boolean false than the other way around.
Only those technical arguments that occur in a vacuum: designing something from
scratch. Not technical arguments when there is compatibility and existing
practice to consider.
The question of whether or not (car nil) should fail has nothing to do with
separating NIL from false.
Imagine a Lisp dialect in which you have T and FALSE. But the null terminator
is still NIL.
This will work
(if (eq (car list) 'bob) ...)
if (car nil) is allowed, but break if (car nil) isn't allowed.
This of course will break:
(if list ...)
Since NIL isn't false (and perhaps a cons isn't regarded as true, either). But
that's a separate issue from the polymorphism of CAR, isn't it!
> I like it because I find it too damn convenient most of the time. That's
> not really a technical argument, though.
Actually it is a technical argument. Your experience in this regard coincides
with that of nearly that of every other Lisp user. ``Most of the time''
represents the frequent case and ``convenience'' is the result of usability
optimization. So, optimization of the most frequent case. That is engineering.
The way truth and falsehood works, and polymorphism over nil, simplifies the
code. It reduces the special cases that have to be implemented. Fewer special
cases means it's easier to verify the program. Fewer places for bugs to hide.
Special cases require extra coverage testing, or proofs.
Did you forget somewhere that a list may be empty? Are you sure? Here is a
100,000 line program; prove it.
When people implement doubly-linked lists in C, the smart ones use a sentinel
node which makes the list circular, so that they don't have to test the end
cases: insetion and deletion at the head and tail.
That's technically superior, because the code for insertion then just looks
like this:
/* allocate node and insert between predecessor and successor, then: */
node->prev = predecessor;
node->next = successor;
predecessor->next = node;
successor->prev = node;
When inserting at the head, the predecessor is the sentinel node and the
successor is the head node. When inserting at the tail, the predecessor is the
tail node and the successor is the sentinel.
The correctness of the code is painfully easy to see just by inspection. There
are no cases. No if/else. The machine code is slick too, just a
bunch of data movements, no branching.
Deletion is similar.
So what we have taken is eliminated the null pointer and replaced it with an
object that serves in its place, but behaves sanely. It's like a smarter null
pointer on which we have simply made it a correct operation to do
``null_pointer->successor = ...''.
NIL is also like a smart null pointer that behaves as sanely as we want it to.
We can overload it to behave as if it is an instance of whatever type we are
working with, and make it support the methods, so that we don't have to test
for NIL everywhere and avoid doing things that can't be done with NIL.
We can route NIL to a function where the test is done in one place.
That's a technical argument: implementing responsibility in one place, instead
of repeating a endless testing throughout the code.
If you are faced with a CAR that blows up, you must write MYCAR which doesn't
blow up and proceed from there, if you care at all about implementing one
responsibility in one place: modularity, cohesion and all that.
(defun mycar (list)
(if (null list) nil (car cons-or-nil)))
Or even:
(defgeneric mycar (x))
(defmethod mycar ((x cons))
(car x))
;; ``Null Object'' Design Pattern
(defmethod mycar ((x null))
nil)
See, the important responsibility for not trying to extract the CAR field from
something which is not a cons is still being taken care of.
And actually, how about this:
(defmethod mycar ((x null))
(values))
This function returns nothing to express that NIL does not have a car field.
But, a NIL value automatically materializes when we try to use (values) as a
value so code like (if (eq (car list) 'bob) ...) works.
William James
> The fact that (car '()) throws an error is a nuisance, but nothing I
> would judge a language on. Overall, ISLISP looks pretty good.
Ruby:
[].first
==>nil
William James
Ruby:
TOP_LOG = 9
list = (0 .. TOP_LOG).map{|n| "log#{ n>0 and n or '' }" }
File.delete list.last
list.reverse.each_cons(2){|a,b| File.rename b, a }
Tobias C. Rittweiler
Kaz Kylheku <kkyl...@gmail.com> writes:
> On 2009-02-08, Tobias C. Rittweiler <tcr@...> wrote:
>
> > I think there are more technical arguments in favor of seperating NIL
> > from boolean false than the other way around.
>
> ...
>
> The question of whether or not (car nil) should fail has nothing to do with
> separating NIL from false.
Oh, right, of course. Silly me.
> And actually, how about this:
>
> (defmethod mycar ((x null))
> (values))
>
> This function returns nothing to express that NIL does not have a car field.
> But, a NIL value automatically materializes when we try to use (values) as a
> value so code like (if (eq (car list) 'bob) ...) works.
It is, however, not totally semantically equivalent. :-)
Thanks for your answer,
-T.
Pascal Costanza
>> The fact that (car '()) throws an error is a nuisance, but nothing I
>> would judge a language on.
>
> It speaks volumes about the people involved and their approach to the thing,
> though, doesn't it!
No, I don't think so. I cannot get excited about this tidbit. Yep, it's
a nuisance, but, hey, easy to work around: (if (null thing) '() (car
thing)).
Every language design is a compromise, and ISLISP fares pretty well, IMHO.
Kojak
Rob Warnock a écrit :
> Kojak <nnt...@janville.Borg.invalid> wrote:
> > Cheater! I've said "without need of extra tweak in rc file". :-)
>
> Then I misunderstood what you meant by "rc file". I assumed
> [...]
Oops!
Don't worry. It was just a joke, absolutely not a
criticism of your work.
As my english is not as perfect as it should be,
I probably misspoke.
Sorry.
--
Jacques.
Kojak
Rainer Joswig a écrit :
Here are the links for the changelog and the documentation:
<http://sbcl.sourceforge.net/all-news.html#1.0.22>
<http://www.sbcl.org/manual/Shebang-Scripts.html#Shebang-Scripts>
--
Jacques.
Andrew Reilly
Yeah, but in python [][0] gives "IndexError: list index out of range",
and in C ((cons*)0)->car usually gives something like "bus error, dumping
core", so extrapolating from other languages doesn't necessarily help the
argument...
The reason that I asked about idiomatic code before (before Kaz knocked
me upside the head with respect to idiom necessarily being a function of
language definition) is that in these other languages there are perfectly
reasonable idioms for traversing or operating on lists in which the
question of the head of an empty list generally doesn't arise.
Cheers,
--
Andrew
Mirko
world.lisp.de> wrote:
> On 6 Feb., 14:18, Xah Lee <xah...@gmail.com> wrote:
>
> > Water Lin wrote:
> > > I am really confused which kind of Lisp I should focus on......
> > Rainer Joswig wrote:
> > > Common Lisp is fine. Get a copy of the book Practical Common Lisp ...
> > > Emacs is a simple Lisp dialect for Emacs scripting. It is behind the
> > > times in many ways.
> > > Scheme: Typically one can start with DrScheme and one of the Scheme
> > > books.
>
> > > But I would prefer Common Lisp .
>
> > Note that Rainer is a Common Lisp fanatic. He's been posting regularly
> > in comp.lang.lisp since at least 1999,
>
> At least since 1992.
>
> > and it seems to me he does not
> > know any other functional lang other than common lisp, but always
> > trumpet Common Lisp in every aspect,
>
> Different from you I really learned functional programming many years
> ago starting with Scheme, ML, Miranda, etc. I've used Haskell, Gofer,
> etc. when they appeared.
>
> > and is often aggressive in his
> > online behavior that you can often see he fight with other lispers
> > too. I think he's retired in his 50s or older. Much regular posters in
> > comp.lang.lisp are old. (majority would be above 40 i think. (I'm 40
> > myself.))
>
> Let's just note that your Emacs Lisp is at beginners level
> and you have never managed to write a single line of Scheme,
> Common Lisp or, say, Clojure. Lots of people on comp.lang.lisp can
> write
> in various Lisp dialects. Not you.
>
> Yeah, and spare me with your drivel. No need to answer.
On Feb 6, 11:23 am, Javier <javu...@gmail.com> wrote:
> As any duality, there are not trolls when there are not fanaticals, and
> there are not fanaticals when there are not trolls.
> When trolls are not attacking, fanaticals are bored and awaiting for an
> opportunity to express their fanatics, and almost no activity in cll.
> When there are not fanatical fighting against trolls, there is almost no
> activity in cll.
>
> Which brings us the truth: Lisp is almost dead. There is only space for
> controversial and fighting. There is no substance any more. A perfect
> subject for the duality fanatical/troll.
>
> Have a nice day!
When I see these discussions they remind me of the mass fight scenes
amongst the inhabitants of a small Gaul village encircled by Roman
legions of the Julius Caesar era in the comic strip Asterix & Obelix.
The Gauls in the comic strip are kind of nutty, and every once in a
while, a huge brawl will erupt in the village, over items such as
spoiled fish sold on the market, or the quality of the bard's music,
or other trivial issue (who was eying whose pretty partner).
And there are more parallels between them and our little community:
The Gauls have a potent weapon, the `magic potion' that makes them
invincible. We, we have `the macros' and `code is data'
Meanwhile, the Romans have learned that they cannot defeat them, and
they are just content to contain them and ignore them as best they
can, as does the rest of the world vis-a-vis lisp.
Cheers,
Mirko
Marco Antoniotti
I love the analogy. Now who is Panoramix the Druid? (yeah yeah,
names get changed in national versions) And, above all, who is
Cacofonix?
Cheers
--
Marco
Madhu
* (Pascal J. Bourguignon) <87vdrle...@galatea.local> :
Wrote on Sun, 08 Feb 2009 10:06:33 +0100:
| Kaz Kylheku <kkyl...@gmail.com> writes:
|> void rotate_logs(void)
|> {
|> rm("-f", "log.2");
|> mv("log.1", "log.2");
|> mv("log, "log.1");
|> }
|>
|> Is that scripting? There is a lot of irrelevant syntax involved, and you
|> probably have to compile the program.
|
| But this one would definitely be a program:
|
| #include <unistd.h>
|
| void rotate_logs(void){
| unlink("log.2");
| rename("log.1","log.2");
| rename("log","log.1");
| }
This snippet is exactly how all of DJB's installation and configuration
scripts look like.
But you are making the same categorical mistake:
You are not considering the context in which this snippet lives, and
what larger system it forms a part of. The arguments here are that you
cannot answer the question "script or program?" usefully without
considering the context. to quote Kaz upthread,
,----
|It's a distinction about the programming situation: what is its
|context, and what are its goals.
`----
This snippet has code which rotates log files, presumably in an
`application' (in rainer's sense upthread) which does many things
including produce log files. Even the file names in this snippet
hardcoded. A `program' would at least have parametrised these. That
should be clue enough.
--
Madhu
Mirko
I had some ideas about Cacofonix. But I do not want someone whacking
me with an old fish over my face :-)
Mirko
Mirko
The Druid is easy. McCarthy gave us the magic potion :-)
Andy Chambers
Coincidentally, the remaining Asterix author has caused a stir by
selling
he rights to the comic to the French media giant Hachette Livre
http://www.guardian.co.uk/books/booksblog/2009/jan/16/asterix-sylvie-uderzo-le-monde
--
Andy
Mirko
wrote:
>
> --
> Andy
Thanks for the link. I will want to reread the `Obelix & Co'
adventure.
Pascal J. Bourguignon
> Coincidentally, the remaining Asterix author has caused a stir by
> selling
> he rights to the comic to the French media giant Hachette Livre
>
> http://www.guardian.co.uk/books/booksblog/2009/jan/16/asterix-sylvie-uderzo-le-monde
Perhaps he's right, knowing how Hergé's heirs behave...
--
__Pascal Bourguignon__
George Neuner
<kkyl...@gmail.com> wrote:
>
>Imagine a Lisp dialect in which you have T and FALSE. But the null terminator
>is still NIL.
> :
>>This of course will break:
>
> (if list ...)
Not necessarily. It will only break when the test is against T. When
the test is properly against "not FALSE" it works fine.
George
George Neuner
<kkyl...@gmail.com> wrote:
>
>Imagine a Lisp dialect in which you have T and FALSE. But the null terminator
>is still NIL.
> :
>>This of course will break:
>
> (if list ...)
Not necessarily. It will only break when the test is against T. When
Kenneth Tilton
Sounds right. Any sufficiently interesting isolated group will be found
to have divided itself up into cliques engaged continually in mutual
dislike and occasionally outright conflict, united only when threatened
from without. It's a scale thing: folks divide themselves up according
to the biggest differences on the table. When isolated, the remaining
petty differences after the larger common interest are the biggest
differences in play. When the outsider appears, the petty differences
drop below radar.
This is why we hired froggy and bellyflopper: to keep the peace.
kzo
George Neuner
<kkyl...@gmail.com> wrote:
>
>Imagine a Lisp dialect in which you have T and FALSE. But the null terminator
>is still NIL.
> :
>>This of course will break:
>
> (if list ...)
Not necessarily. It will only break when the test is against T. When