Difference between LISP and C++
arien
wondering if someone can explain to me (in fairly simple terms), why
(and how) lisp differs from standard programming languages such as C++.
I think I sort of get the idea. Lisp is an AI language for starters, and
it is based on logic, but after that I'm lost. I just need a bit more of
an in depth (not TOO deep) explaination as to why this is so.
TIA
--
Mel
Please post reply to newsgroup. Reply address isn't valid.
JB
> I've only just started studying lisp this semester at uni,
> and I'm wondering if someone can explain to me (in fairly
> simple terms), why (and how) lisp differs from standard
> programming languages such as C++. I think I sort of get
> the idea. Lisp is an AI language for starters, and it is
> based on logic, but after that I'm lost. I just need a bit
> more of an in depth (not TOO deep) explaination as to why
> this is so.
This is a strange question! If you do not know C++, there is
no sense in asking this question.
If you know C++ and played a bit with Common Lisp then you
must have reckognized that memory is allocated
automatically, that is you do not have to deal with memory
allocation. Also, you can write functions that take many
different types of arguments whereas in C++ you must
specify in advance the type of the argument. If you want to
have functions with different argument types, you must
overload the function. But you must have reckognized this.
Statements like "Lisp is based on logic" are so general that
they have no sense. Every programming language is based on
logic.
--
J.... B....
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Pascal Costanza
> I've only just started studying lisp this semester at uni, and I'm
> wondering if someone can explain to me (in fairly simple terms), why
> (and how) lisp differs from standard programming languages such as C++.
> I think I sort of get the idea. Lisp is an AI language for starters, and
> it is based on logic, but after that I'm lost. I just need a bit more of
> an in depth (not TOO deep) explaination as to why this is so.
Hi Arien,
It's a good idea to compare a language to other languages in order to
quickly get an impression of the main concepts and features. It is
folklore that Lisp is an AI language, but it's not true. It is in fact a
general purpose language - it does have some nice features that make it
suitable for AI, but it's not at all focused only on this domain.
You might want to take a look at http://www.lisp.org/table/compare.htm
for some language comparisons that involve Lisp. I have also found
http://www.lisp.org/table/objects.htm to be very helpful in order to get
a quick overview of what Lisp is all about.
I think it's a great opportunity to be able to learn Lisp - that doesn't
happen so often nowadays. Lisp is a very exciting language. Have fun!
Pascal
--
Given any rule, however ‘fundamental’ or ‘necessary’ for science, there
are always circumstances when it is advisable not only to ignore the
rule, but to adopt its opposite. - Paul Feyerabend
Fred Gilham
> I've only just started studying lisp this semester at uni, and I'm
> wondering if someone can explain to me (in fairly simple terms), why
> (and how) lisp differs from standard programming languages such as
> C++.
Given that Lisp predates C++ by a couple decades, and is the first
object oriented programming language to have an ANSI standard, the
term `standard' as used in the above sentence is perhaps of
questionable semantic content... :-)
Anyway I'd say the primary difference is that C++, C, even Java are
`batch programming languages', while Lisp is designed for interactive
use. This is not, by the way, the same thing as the difference
between `compiled' and `interpreted'. You might even say that Lisp is
an `on-line' programming language --- all the features of the language
environment are always there. When you run a C++ program it's like
pushing a bird out of the nest --- it either flies or falls on its
own, and if it falls you have to scrape the results off the ground
with a post-mortem debugger. With Lisp, your program has all of Lisp
there with it; if you have a bug, the vast majority of the time you
will be able to view the state of your program in mid execution, fix
the bug, and sometimes even pick up where you left off.
I had an example of this at a demo I gave once; my user interface
program crashed with a segmentation violation (!) and landed in the
debugger because it didn't properly check its input. I restarted the
offending routine, properly typed my input, and was back up in less
than ten seconds. No core dumps, no restarting the system from
scratch, no unhappy demo viewer.
In typical use one writes code, watches it run, and if it is not
running the way one likes, one modifies the code and forces the
(compiled) modifications into the running program. This allows you to
see the effects of your changes immediately. Imagine a program
running under Emacs with the Ilisp IDE. You see that it's giving the
wrong output. You look at your code, see the bug, fix it, hit ^c^c,
and suddenly your program starts giving the right output (without
having to restart it). I've done this often. You can see how this
would speed up the development process. The only thing you have to do
is remember to save your files from time to time. :-)
This compares to `edit, compile, link, run, debug, edit....' where the
`compile, link, run' steps can sometimes be quite time consuming.
The interactive aspect of Lisp is not only useful for debugging; it
allows a more dynamic approach to program construction. Your program
can compile pieces of itself while it is running. It can even write
pieces of itself while running. This can give a whole different view
to what a program is and what it does.
--
Fred Gilham gil...@csl.sri.com
Jordan Hubbard: We have a crash bug. It needs to be fixed. We DO NOT
need to know how to print 3000 spaces in 11 different languages! :-)
Daniel Sobral: I concur. But if anyone wants to do it with loader,
: 3kbl 3000 0 do bl emit loop ; 3kbl will do the trick.
Matthew Danish
> I've only just started studying lisp this semester at uni, and I'm
> wondering if someone can explain to me (in fairly simple terms), why
> (and how) lisp differs from standard programming languages such as C++.
> I think I sort of get the idea. Lisp is an AI language for starters, and
> it is based on logic, but after that I'm lost. I just need a bit more of
> an in depth (not TOO deep) explaination as to why this is so.
I think a good way to approach this would be first to excise the concept
that there is some "standard" for programming languages which C++ obeys
and Lisp does not (and I don't mean ANSI standards), and the concept
that Lisp is an AI language. And also, there isn't such a thing as a
programming language not based in logic (as JB has mentioned) ;) It
wouldn't be for any computers I know of, anyway.
Perhaps you mean to say that C++ is what you are accustomed to; in which
case I advise approaching Lisp with a fresh viewpoint. And Lisp is not
an "AI language", it just happens to be popular with people working in
the AI problem domain due to flexibility.
The best way for you to understand the differences would be to know
both, but I'll list a few key points to get you started:
* There is no such thing as a "statement" in Lisp syntax, even though
there may be constructs which act similarly. Every form is an
expression which evaluates to a value.
* Functions, for the most part, are the unit of "thought" within the
language. I couldn't think of a better word, so here's a description:
You will organize your thoughts/programs around writing functions,
using functions, generating functions (and methods, macros, etc... as
well). They also are the primary unit of compilation.
* Lisp code IS Lisp data. Most other languages hide the abstract syntax
tree of the language behind a veneer of sugary syntax. Lisp
programmers have chosen to work with the tree almost directly, which
makes writing operations on the tree (macros) simple. It also
provides an obvious choice for data-representation. And if you use an
editor which understands Lisp (ie. Emacs), you get the benefit of
structure-editing commands.
* Lispers work in a dynamic language and a dynamic environment. Change
and redefinition are normal parts of the language, not something that
one pretends not to exist. You modify a program while it continues
to run and maintain state, rather than restarting it all the time like
with C++.
URLs to start at:
http://ww.telent.net/cliki/index
http://www.lisp.org/
http://www.psg.com/~dlamkins/sl/cover.html
--
; Matthew Danish <mda...@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
news:MPG.181043893...@news.adl.ihug.com.au...
> I've only just started studying lisp this semester at uni, and I'm
> wondering if someone can explain to me (in fairly simple terms), why
> (and how) lisp differs from standard programming languages such as C++.
why...
Lisp was initially created 40+ years ago when computing was fresh and
new ideas were not constrained by what went before. There was no
C++ syntax back then, it is only a modern phenomena that current languages
like C++/Java have strained to retain some C like syntax. Lisp is the way
it is because of a number of factors; its syntax; the computing theory behind
it; and its evolution by people who (over decades) programmed hard and difficult
problems like AI. Many of what are now considered everyday computing
applications and techniques were first done in Lisp.
how..
See above, plus, it is much more complete as a programming environment.
Lisp is simply a better programming language and environment than C++.
Wade
Erik Naggum
| I've only just started studying lisp this semester at uni, and I'm
| wondering if someone can explain to me (in fairly simple terms), why
| (and how) lisp differs from standard programming languages such as C++.
FYI: Common Lisp is a standard programming language.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
arien
> arien wrote:
>
> > I've only just started studying lisp this semester at uni,
> > and I'm wondering if someone can explain to me (in fairly
> > simple terms), why (and how) lisp differs from standard
> > programming languages such as C++. I think I sort of get
> > the idea. Lisp is an AI language for starters, and it is
> > based on logic, but after that I'm lost. I just need a bit
> > more of an in depth (not TOO deep) explaination as to why
> > this is so.
>
> This is a strange question! If you do not know C++, there is
> no sense in asking this question.
I know Java, and I have started to look at C++ (don't really understand
it though).
> If you know C++ and played a bit with Common Lisp then you
> must have reckognized that memory is allocated
> automatically, that is you do not have to deal with memory
> allocation. Also, you can write functions that take many
> different types of arguments whereas in C++ you must
> specify in advance the type of the argument. If you want to
> have functions with different argument types, you must
> overload the function. But you must have reckognized this.
This is not really what I'm asking about. I'm not talking about the
specific syntax etc, I'm referring to what the language acheives. For
starters, Lisp is not compiled into an executable. In Lisp is it
possible to create a UI?
>
> Statements like "Lisp is based on logic" are so general that
> they have no sense. Every programming language is based on
> logic.
>
That is why I am asking this question, I don't understand. All I can see
is that Lisp is very different from Java or C++ and I'm not sure why.
arien
>
> See above, plus, it is much more complete as a programming environment.
> Lisp is simply a better programming language and environment than C++.
>
I wonder what the C++ programmers would say if I asked this :-)
arien
> * arien <spamme...@getlost.invalid>
> | I've only just started studying lisp this semester at uni, and I'm
> | wondering if someone can explain to me (in fairly simple terms), why
> | (and how) lisp differs from standard programming languages such as C++.
>
> FYI: Common Lisp is a standard programming language.
>
>
Ah, you see this I didn't know. Since the only languages I know are Java
(and I've seen a little C++), I can't get my head around the difference.
I'm starting to get an idea, and thanks for everyone's input. What I
still find hard to grasp, is normally when you distribute a program, you
distribute the executables. So how would you distribute a program
created in Lisp?
Also, as I asked in another post above, can lisp create a UI? Or would
you use something like C++ for the UI, and then that runs the lisp code?
Lastly, I show some sample lisp code, that I had written, to a friend
and he responded that it looked like a Low Level Lanuage. Could someone
tell me 1) if this is true, and 2) The difference between High Level and
Low Level languages?
Edi Weitz
> This is not really what I'm asking about. I'm not talking about the
> specific syntax etc, I'm referring to what the language
> acheives. For starters, Lisp is not compiled into an executable.
Says who? Several commercial Lisp implementation can create
stand-alone executables if that's what you're asking for.
> In Lisp is it possible to create a UI?
Yes.
Edi.
Coby Beck
"arien" <spamme...@getlost.invalid> wrote in message
> In article <32432735...@naggum.no>, er...@naggum.no says...
> > * arien <spamme...@getlost.invalid>
> > | I've only just started studying lisp this semester at uni, and I'm
> > | wondering if someone can explain to me (in fairly simple terms), why
> > | (and how) lisp differs from standard programming languages such as
C++.
> >
> > FYI: Common Lisp is a standard programming language.
>
> Ah, you see this I didn't know. Since the only languages I know are Java
> (and I've seen a little C++), I can't get my head around the difference.
> I'm starting to get an idea, and thanks for everyone's input. What I
> still find hard to grasp, is normally when you distribute a program, you
> distribute the executables. So how would you distribute a program
> created in Lisp?
Most implementations can compile to an executable.
> Also, as I asked in another post above, can lisp create a UI? Or would
> you use something like C++ for the UI, and then that runs the lisp code?
Lisp can create GUI's (I think you mean GUI - note that the listener *is* a
UI) though it is common to use Java or C++ to construct the GUI and have
the application logic run in Lisp.
> Lastly, I show some sample lisp code, that I had written, to a friend
> and he responded that it looked like a Low Level Lanuage. Could someone
> tell me 1) if this is true, and 2) The difference between High Level and
> Low Level languages?
Lisp is a High Level Language, more so than C++. It separates the
programmer much more from the nuts and bolts of pointers and memory
management for example. I don't think that is disputable by anyone with
knowledge of languages and no personal agenda. Low level languages like C
force you to think on the computer's terms, memory addresses, data
representations etc.
As for your initial question about Lisp and AI, I think Lisp is well suited
for AI for a number of reasons:
- symbols as a data type
- code can be recompiled incrementally for rapid development
- general flexibility as mention in other posts
- interactive environment for easy testing and prototyping
- dynamic typing
- optional and keyword arguments to functions
- macros
It seems that you have a number of all-to-common misconceptions about lisp
and would benefit greatly from a trip to www.lisp.org You will find there a
lot of basic info including tutorials and references.
Enjoy!
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Erik Naggum
| What I still find hard to grasp, is normally when you distribute a
| program, you distribute the executables.
But executables do not live in a void. You cannot get an executable that
runs under Windows and Linux despite running on the same hardware once
booted with the appropriate system, or on the Wintendo platform and on
the Solaris platform despite being written in languages available on
both. There is a persistent myth about "standalone" executables that is
fairly strongly counter-indicated by incompatible operating systems, and
in the C++ world, you even need the exact same compiler to make things
work with distributed shared libraries. (One version of the semipopular
DeadRat Linux distribution actually used a very particular version of gcc
that did funny things so that you could not compile C++ programs on other
Linux systems and have them run on DeadRat systems.) So you cannot just
distribute executables. It is a myth. Better shed it now or hurt later.
| So how would you distribute a program created in Lisp?
You distribute something that will run in the environment your users have
already installed, possibly mere minutes prior to installing your program
in whatever form they may take. This is really a non-issue. If you ask
whether a Common Lisp program can run on the bare metal, the answer is
No. If you ask whether it can run with only "standard" libraries, you
have to compare that with other languages, and you will find that Common
Lisp is no different from any other language in this regard: No. To be
able to run with only operating-system-supplied shared libraries, your
program really has to be part of that operating system. Some Unix and
Windows programs have that function. It is not common to write "hello,
world" programs in Common Lisp like it is in C/C++ and Common Lisp
environments are therefore not optimized very heavily for this task.
| Also, as I asked in another post above, can lisp create a UI?
Well, we have not quite developed our artificial intelligence systems
that far, yet. You still need a programmer to create a user interface.
If the Common Lisp programmer is well versed in user interfaces, then he
would use Common Lisp to create the user interface, too. Please note
that several of the Common Lisp environments include interface builders
that alleviate some of the tedium of writing user interfaces. Those who
like that kind of thing will find them the kind of thing they like.
| Or would you use something like C++ for the UI, and then that runs the
| lisp code?
Java has positioned itself as very useful tool in this regard. People
have also found HTML and web pages to be a convenient vehicle.
| Lastly, I show some sample lisp code, that I had written, to a friend and
| he responded that it looked like a Low Level Lanuage. Could someone tell
| me 1) if this is true, and 2) The difference between High Level and Low
| Level languages?
I think you should ask yourself why you trust your friend's opinion and
ask him what he means by it. You could, for instance, have written very
low-level code and your friend may have been polite about who is to blame
for that. Some people here think that being polite is all the rage, but
I am not generally of that opinion as it tends to make people believe
they have not made serious mistakes even when the intended message is
that they have.
Pascal Costanza
> What I
> still find hard to grasp, is normally when you distribute a program, you
> distribute the executables. So how would you distribute a program
> created in Lisp?
This depends on the Lisp environment you use. You can expect most
commercial implementations to be able to create distributable
executables (but watch out for licensing issues), and I guess also some
of the free implementations.
If you develop open source software, it seems to be quite usual to just
make the sources available.
> Also, as I asked in another post above, can lisp create a UI? Or would
> you use something like C++ for the UI, and then that runs the lisp code?
Again, some of the Lisp implementations provide libraries that allow you
to access the GUI of your operating system. There's also a platform
independent GUI library called CLIM that is supported by some Lisps.
Note that it's hard in these regards to compare Lisp to Java. Java is a
language + environment that is controlled by Sun - so actually you have
mainly one reference implementation of Java that is ported to several
operating systems, and all other implementation try to stay as close as
possible to the Java implementation provided by Sun.
Common Lisp has an exceptionally precise specification that is respected
by all conforming implementations, but things like GUI and deployment,
among other things, are largely left to the implementors. Since Common
Lisp is not controlled by a single company, there is much more diversity
in Common Lisp implementations than is the case for Java. Some people
consider this as an advantage.
> Lastly, I show some sample lisp code, that I had written, to a friend
> and he responded that it looked like a Low Level Lanuage. Could someone
> tell me 1) if this is true, and 2) The difference between High Level and
> Low Level languages?
I don't think these terms have precise definitions, but I think that
most people have the following notion: A low level language stays close
to the computer operational model, whereas a high level language is
closer to the mental model(s) of people.
All programming language look kind of low level when you use them for
simple toy examples. The low level / high level distinction becomes more
important when you start to write sufficiently large programs, and is
therefore hard to recognize for a beginner.
According to this notion, for example C is a very low level language.
C++ is a hybrid of very low level elements (the C heritage) and very
high level elements (for example templates). Java is a strange creature
that is somewhere in between - it has some low level elements in that it
stays close to the data types as provided by the hardware, but is also
kind of high level in that it encourages object-oriented programming
(but with some limitations). And then, Java incorporates also some
elements of Lisp, like garbage collection.
C++ is a language for experts who want to stay close to the machine
level by default, but it allows high level abstractions if they are
wanted. So for example, C++ doesn't provide garbage collection, and the
type system has many opportunities to shoot yourself in the foot
accidentally. Common Lisp is a language for experts who want to stay
close to their own mental model by default, but it allows low level
manipulations if they are needed.
I hope this helps.
Petr Swedock
> In article <32432735...@naggum.no>, er...@naggum.no says...
> > * arien <spamme...@getlost.invalid>
> > | I've only just started studying lisp this semester at uni, and I'm
> > | wondering if someone can explain to me (in fairly simple terms), why
> > | (and how) lisp differs from standard programming languages such as C++.
> >
> > FYI: Common Lisp is a standard programming language.
> >
> >
>
> Ah, you see this I didn't know. Since the only languages I know are Java
> (and I've seen a little C++), I can't get my head around the difference.
> I'm starting to get an idea, and thanks for everyone's input. What I
> still find hard to grasp, is normally when you distribute a program, you
> distribute the executables. So how would you distribute a program
> created in Lisp?
As source. As an executable.
distributing the executables is done, but is not the only, or even
the most popular, method. This is more often a 'supply-side' issue
as the code writer often will establish the efficacy of the binary
on his/her favorite platform only and then release the src to the
wild for others to compile on their favorite platforms.
> Also, as I asked in another post above, can lisp create a UI? Or would
> you use something like C++ for the UI, and then that runs the lisp code?
You can do anything in Lisp you can do in Java or C/C++, or what have
you. It's a full language.
> Lastly, I show some sample lisp code, that I had written, to a friend
> and he responded that it looked like a Low Level Lanuage. Could someone
> tell me 1) if this is true, and 2) The difference between High Level and
> Low Level languages?
In my experience (admittedly grossly underwhelming when compared to
others here... =-) Lisp doesn't fit into those categories: older
Lisps, for example, were made to manipulate everything from
'lower-level' assembler instructions to very abstract 'higher-level'
stuff. I don't think that practice is as prevelant today because,
back then, the Lisps were implemented only on specific hardware with-
out a view to portability.
Peace,
Petr
Martti Halminen
> Since the only languages I know are Java
> (and I've seen a little C++), I can't get my head around the difference.
> I'm starting to get an idea, and thanks for everyone's input. What I
> still find hard to grasp, is normally when you distribute a program, you
> distribute the executables. So how would you distribute a program
> created in Lisp?
While some implementations have ways to produce C -style stand-alone
executables, or .dll files, the "native" style in Lisp would be to
install the Lisp runtime system, and then load the compiled files into
it; if you have a single application, that may be delivered as already
loaded into the runtime system (i.e. load the application into a clean
Lisp, and dump the memory image). This is actually rather close to the
way Java does it, except that there is no virtual machine between the
program and the hardware.
- At least, what Java stuff I've done, we always delivered the Java
runtime environment (JRE) with the application, to make sure the
customer ran a compatible version.
> Also, as I asked in another post above, can lisp create a UI? Or would
> you use something like C++ for the UI, and then that runs the lisp code?
Presumably you are talking about a GUI, here. The Common Lisp standard
doesn't define a GUI system, so most commercial CL implementations have
their proprietary GUI tools. Additionally there are some non-proprietary
GUI systems of varying applicability. Another way would be to do the GUI
in another language, and communicate with the Lisp side some way
(sockets, CORBA, through a foreign function call mechanism etc).
--
Thomas F. Burdick
> > See above, plus, it is much more complete as a programming environment.
> > Lisp is simply a better programming language and environment than C++.
>
> I wonder what the C++ programmers would say if I asked this :-)
Well, it depends. Do those C++ programmers also know ANSI Common Lisp
well? I'm competent in both, and I find CMUCL+Hemlock+Garnet+Solaris
the nicest, most productive environment I've found yet. I use other
things, and I can appreciate some of the niceties in the Forte IDE or
MSVC++, but I'm just so much more productive in Lisp.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Larry Clapp
> In article <32432735...@naggum.no>, er...@naggum.no says...
>> * arien <spamme...@getlost.invalid>
>> | I've only just started studying lisp this semester at uni,
>> | and I'm wondering if someone can explain to me (in fairly
>> | simple terms), why (and how) lisp differs from standard
>> | programming languages such as C++.
>>
>> FYI: Common Lisp is a standard programming language.
>
> Also, as I asked in another post above, can lisp create a UI?
> Or would you use something like C++ for the UI, and then that
> runs the lisp code?
Yes, Lisp can create a UI. More concretely, many Common Lisp
implementations have functions to talk to X servers and other
graphics engines. For example, in a recent (possibly still
active) thread in this newsgroup, they discussed a web browser
written in Lisp.
> Lastly, I show some sample lisp code, that I had written, to a
> friend and he responded that it looked like a Low Level
> Lanuage. Could someone tell me 1) if this is true,
Yes, you friend did indeed respond that it looked, to him, like a
low level language. ;)
More seriously: You can interpret "low level language" in more
than one way.
From the "target applications" point of view: Common Lisp, like
C, Java, and other languages, can do bit twiddling, interact
directly with hardware, and do other "system" or "O/S" level
operations. It can also, like those other languages, do
large-scale application-level (or larger :) tasks. One often
finds, however, when *not* using Lisp, that one ends up
re-inventing bits and pieces of it, often badly.[1] In this
respect, I consider Lisp at least a little higher level than C,
C++, or Java, and probably more than a little.
From the "amount of code to perform a specific task" point of
view: You *can* do lots of intricate list processing to, say,
create a list, and (sadly) many instructors will have you do just
that in the name of getting a feel for the language. You *can*
do that, but you don't *have* to. Lisp provides many tools to
build the language up to your task, so that eventually, if you've
designed well and don't fear a little refactoring, you find
yourself writing your application in a custom-built, Lisp-like
language. In this respect, I consider Common Lisp a *much*
higher level language than C, C++, or Java.
Other interpretations probably exist.
By the way, why would you ask someone that doesn't know Lisp
their opinion of it?
> and 2) The difference between High Level and Low Level
> languages?
See above.
-- Larry Clapp
[1] The Lisp community even has a name for this phenomenon:
Greenspun's Tenth Rule of Programming
(http://philip.greenspun.com/research/): Any sufficiently
complicated C or Fortran program contains an ad-hoc, informally-
specified bug-ridden slow implementation of half of Common Lisp.
arien
> It seems that you have a number of all-to-common misconceptions about lisp
> and would benefit greatly from a trip to www.lisp.org You will find there a
> lot of basic info including tutorials and references.
This is why I'm here. I don't understand and I'm looking for more
information :-)
arien
runner.mit.edu says...
hmmmm, I can see I still have a lot to learn.
Petr Swedock
> > Peace,
> >
> > Petr
> >
> >
>
> hmmmm, I can see I still have a lot to learn.
As do we all.
Peace,
Petr
Jacek Podkanski
>
>> It seems that you have a number of all-to-common misconceptions about
>> lisp and would benefit greatly from a trip to www.lisp.org You will find
>> there a lot of basic info including tutorials and references.
>
> This is why I'm here. I don't understand and I'm looking for more
> information :-)
>
Please have a look at:
http://www.cs.uni-bonn.de/~costanza/lisp/guide.html
http://www.apl.jhu.edu/~hall/lisp.html
I think they are good places to start. I hope this helps.
--
Jacek Podkanski
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
>
> >
> > See above, plus, it is much more complete as a programming environment.
> > Lisp is simply a better programming language and environment than C++.
> >
>
> I wonder what the C++ programmers would say if I asked this :-)
90% probability that they would say, "What's Lisp?"
5% probablility that they would way, "Lots of silly parentheses"
3% probability that they would say, "I hated that Scheme course"
2% probability that they would say, "Damn, I wish I could get a job programnming in Lisp"
Wade
arien
wa...@nospam.nowhere says...
Hey, I agree with them on the silly parentheses! I haven't had a single
error yet that wasn't caused by parentheses being in the wrong spot!
Damn things ((((((((((((((((())))))))))))))))))))))
arien
says...
No one has yet explained what the difference is between a High or Low
level language? This is why I'm confused!
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
You are using the wrong editor.
Wade
Larry Clapp
> In article <0e65oa...@rabbit.ddts.net>, la...@rabbit.ddts.net says...
>> More seriously: You can interpret "low level language" in more
>> than one way.
>>
>>
>> > and 2) The difference between High Level and Low Level
>> > languages?
>>
>> See above.
>
> No one has yet explained what the difference is between a High
> or Low level language? This is why I'm confused!
Because no hard-and-fast definition of either exists.
You must grasp the central concept of levels and layers of
abstraction before any of the rest of it makes sense. What
central concepts does the language allow/force you to think
about?
You could call assembly language "low level" because it takes
many lines of code to do anything significant. Or because one
usually uses assembler to manipulate hardware directly.
You could call Lisp "high level" because it often takes very few
lines of code to do some pretty amazing things, or because people
often use Lisp in ways that don't deal directly with integers and
characters and so forth.
So-called "low level" languages often deal with entities (bits,
bytes, characters) and data structures (pointers, arrays) that
have very close similarities to objects the cpu can deal with
directly. They do not provide much in the way of layers of
abstraction, and force the programmer to think like a computer.
So-called "high level" languages often deal with entities
(symbols, properties, classes) and data structures (knowledge
representation maps, neural networks) that, while created from
and built upon the "lower level" entities, abstract away those
details and let the programmer focus on manipulating the
knowledge or training the neurons, rather than twiddling specific
bits here and there. They *do* provide a great deal in the way
of layers of abstraction, and allow the programmer to think in a
way appropriate to the problem domain.
Once you get some more experience with Java and, say, assembler
or C, you'll have a more personal understanding of "high level"
vs. "low level", and if you stick with Lisp (for example), you'll
see that one "high level" language can be higher level than
another.
Put it another way: If I told you that my house took this many
nails, this many pieces of wood, so many pounds of concrete, etc,
you might call that a very low level description. If I told you
my house had two bedrooms, a den, two bathrooms, a living room,
and a kitchen, you might call that a very high level description.
On the other hand, if you had to actually *build* the house,
knowing how many nails wouldn't cut it -- not by a long shot.
You'd need to know exactly what kinds of nails, and where they
went, and what inspections they had to pass. You'd need to know
exactly what kind of concrete to buy, how to mix it, and what
inspections *it* had to pass. And so forth.
Or, I might just say I have a two-bedroom in Florida.
The judgement of the "level" of anything matters only in relation
to the desired task, and what you compare it to.
-- Larry
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
>
> No one has yet explained what the difference is between a High or Low
> level language? This is why I'm confused!
See link, its the best explanation (that can fit within a decent time frame)
http://whatis.techtarget.com/definition/0,,sid9_gci211502,00.html
Lisp is generally 3GL, but with its higher capabilities it can be used
to create 4GL languages that fit within the s-exp syntax. I do not
think the definition of 5GL is accurate in the link (I do not think anyone
knows what a 5GL actually should be).
Sorry, nothing of any consequence can be explained before its time.
Wade
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
> Hey, I agree with them on the silly parentheses! I haven't had a single
> error yet that wasn't caused by parentheses being in the wrong spot!
>
> Damn things ((((((((((((((((())))))))))))))))))))))
>
Oh I also forgot to mention, your brain has not adapted yet, give it some
time and you will not even see them after awhile. You will also discover
of amazingly markers they are for organizing your code.
Wade
Kaz Kylheku
> >
> > See above, plus, it is much more complete as a programming environment.
> > Lisp is simply a better programming language and environment than C++.
> >
>
> I wonder what the C++ programmers would say if I asked this :-)
Unless those C++ programmers know a lot about Lisp, why would you care
what they say? If you pay attention in this newsgroup for a while, you
will discover that the Lisp programmers here are also practitioners of
languages other than Lisp, reluctantly so or otherwise. I can confess,
for instance, that I currently make my living by developing in C++.
The typical C++ programmer thinks that Lisp is some 1960's thing
involving slow interpretation, lots of parentheses and list
processing. Or that it's the same thing as Scheme. You can't even
begin to explain to some average programmer using a dumbed-down
programming language like Java what the advantages in Lisp are;
because you have to translate everything into the inadequate concepts
that he already understands. This thing is kind of like that thing in
C++, except, well, not really. Do you know what I mean? No? Ah well.
C++ owes big time to Common Lisp. Consider the idea behind C++
exception handling, that errors can be represented as classes, and
that inheritance can play a role in matching an exception to a
handler. That was in Lisp long before Koenig and Stroustrup wrote that
paper back in 1990 about how to hack exception handling into C++. They
did a poor, sloppy job. They missed one important idea from from the
condition handling system of Lisp; namely that you find the error
handler first, call it and give *it* the opportunity to trigger
unwinding. The poor choice to unwind while searching for a handler
leads to an idiotic exception handling system which conflates
non-local control transfers with error recovery. So at best, C++
exception handling can only contain errors, rather than provide a
substrate for error recovery protocols. By the time a matching catch
clause receives an exception, nearly all useful information about the
problem has been erased. Moreover, there is absolutely no way to fix
the problem and continue running near the point where it happened.
That's because the non-local exit is the *last* resort, the *last*
step in handling an error, after considering all options and all
advice. Lisp has throw and catch, but they are a mere control
mechanism for non-local exits; the language has a separate,
intelligently designed condition handling system. The result is that
Lisp programers can write programs that work right in every situation,
rather than contain and sweep problems under the rug, or give up and
terminate.
If you look at the C++ template library and things under #include
<functional> and #include <algorithm>, not only do the ideas come
straight from Lisp, but so do the names! Where you do you think count,
count_if, find, find_if, remove, remove_if and set_difference come
from? Lisp's sequences library has count, count-if, find, find-if,
remove, remove-if and set-difference, and it was here first, long
before C++ had these things. Coincidence, or plagiarism? String
streams? Lisp again.
The programming language designers of the world should hold a big
conference in which they all one by one confess where they obtained
their ideas, and how they compromised those ideas to fit into their
narrow-minded visions of computing.
Paul Wallich
wrote:
In fact, many/most of the UI features common today -- windows, mice with
multiple buttons, clickable text and graphics, popup menus etc were
common in lisp systems going on 20 years ago. (Where's the new stuff,
folks?)
paul
Bruce Hoult
k...@ashi.footprints.net (Kaz Kylheku) wrote:
> C++ owes big time to Common Lisp. Consider the idea behind C++
> exception handling, that errors can be represented as classes, and
> that inheritance can play a role in matching an exception to a
> handler. That was in Lisp long before Koenig and Stroustrup wrote that
> paper back in 1990 about how to hack exception handling into C++. They
> did a poor, sloppy job. They missed one important idea from from the
> condition handling system of Lisp; namely that you find the error
> handler first, call it and give *it* the opportunity to trigger
> unwinding. The poor choice to unwind while searching for a handler
> leads to an idiotic exception handling system which conflates
> non-local control transfers with error recovery.
While I agree with you that unwinding the stack before selecting the
handler is inferior, you are quite incorrect in saying that Stroustrup
et al "missed" the alternative. I was using C++ at the time, and there
were extensive discussions in places such as comp.lang.c++ and the C++
group on BIX (a small, high quality discussion group that included
Stroustrup, Mike Vilot, Greg Comeau, Walter Bright, Grady Booch and
others). Stroustrup debated for quite a while on whether to support
"termination" or "resumption" semantics for C++ exceptions. I think he
made the wrong choice, but it was certainly a conscious *choice* and not
done out of ignorance of thealternatives.
You can find a brief (3.5 pages) discussion of this in section 16.6 of
_The Design and Evolution of C++_. Among other things, the argument is
made that "resumption requires the key mechanisms for continuations and
nested functions without providing the benefits of those mechanisms".
I can certainly see the argument about nested functions, but then being
a Pascal and PL/I guy from way back I think you want those in a language
*anyway*. Continuations I'm not so sure about -- certainly the CL and
Dylan implementations of exceptions use "exit functions", which are
effectively single-use continuations that are valid for the dynamic
extent of the block that created them. Schemelike call/cc is *not*
required.
Gwydion Dylan manages to compile resumption exceptions into pretty
efficient (and not all that obscure) ANSI C code, so I can't see why
CFront couldn't also do it.
The _Design and Evolution_ discussion also recounts practical experience
of resumption semantics (p392):
"Then, at the Palo Alto meeting in November 1991, we heard a brilliant
summary of the arguments for termination semantics backed with both
personal experience and data from Jim Mitchell (from Sun, formerly from
Xerox PARC). Jim had used exception handling in half a dozen languages
over a period of 20 years and was an early proponent of resumption
semantics as one of the main designers and implementers of Xerox's
Cedar/Mesa system. His message was 'termination is preferred over
resumption; this is not a matter of opinion but a matter of years of
experience. Resumption is seductive, but not valid.'"
"He backed his statement with experience from several operating systems.
The key example was Cedar/Mesa: It was written by people who liked and
used resumption, but after ten years of use, there was only one use of
resumption left in the half million line system -- and that was a
context enquiry. Because resumption wasn't actually necessary for such
a context enquiry, they removed it and found a significant speed
increase in that part of the system. In each and every case where
resumption had been used it had -- over the ten years -- become a
problem and a more appropriate design had replaced it. BASICALLY, EVERY
USE OF RESUMPTION HAD REPRESENTED A FAILURE TO KEEP SEPARATE LEVELS OF
ABSTRACTION DISJOINT." (emphasis mine)
*Well*.
I'd be really interested to hear from people who know more about
Cedar/Mesa and can comment on the above.
-- Bruce
Bruce Hoult
"Wade Humeniuk" <wa...@nospam.nowhere> wrote:
> > Hey, I agree with them on the silly parentheses! I haven't had a single
> > error yet that wasn't caused by parentheses being in the wrong spot!
> >
> > Damn things ((((((((((((((((())))))))))))))))))))))
>
> You are using the wrong editor.
Or maybe he just didn't notice that all the *other* sources of errors in
C++&Java have quietly disappeared.
-- Bruce
JB
> This is not really what I'm asking about. I'm not talking
> about the specific syntax etc, I'm referring to what the
> language acheives. For starters, Lisp is not compiled into
> an executable. In Lisp is it possible to create a UI?
What I told you was not a matter of syntax.
You can create user interfaces with Lisp, but is is not
quite simple. This is a long story.
For C++, on the other hand, there are a lot of nice GUI
libraries, like C++, wxWindows, Fulltick, Fox, etc.
If you look only at the language, Lisp is suprior to C++ as
far as creating UIs are concerned but Lisp lacks the
infrastructure.
> That is why I am asking this question, I don't understand.
> All I can see is that Lisp is very different from Java or
> C++ and I'm not sure why.
I must confess that I have never used Java. The abstraction
level of Lisp is much higher as the abstraction level of
C++.
--
J.... B....
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
Espen Vestre
> Linux systems and have them run on DeadRat systems.) So you cannot just
> distribute executables. It is a myth. Better shed it now or hurt later.
I guess the closest the world has been to really "selfcontained
executables" were DOS games a few years ago. Probably MS won a lot
of market share because DOS was so bad (that game developers had to
and could create their own runtime environments running on the "bare
metal")...
> No. If you ask whether it can run with only "standard" libraries, you
> have to compare that with other languages, and you will find that Common
> Lisp is no different from any other language in this regard: No.
I'm not quite sure what you mean here.. When I produce executables for
Win* with lisp they are "standalone" modulo a standard Windows
install. No libraries needed except for those that come with Windows
(versions 98 to XP) out of the box. (The linux version of the same
program is a little more demanding, it requires a minimum libc version
and that Motif must be present. But that's about all, I think).
--
(espen)
Tim Bradshaw
>
> Ah, you see this I didn't know. Since the only languages I know are Java
> (and I've seen a little C++), I can't get my head around the difference.
> I'm starting to get an idea, and thanks for everyone's input. What I
> still find hard to grasp, is normally when you distribute a program, you
> distribute the executables. So how would you distribute a program
> created in Lisp?
>
> Also, as I asked in another post above, can lisp create a UI? Or would
> you use something like C++ for the UI, and then that runs the lisp code?
We ship executables. Actually, what we now ship is an executable and
a number of module files which (may) get loaded when the executable
starts - we do this so that the system can be customized by the user
(users can (or could, if there was enough documentation) write their
own modules based on the core weld system).
We have a (rudimentary) GUI. It's rudimentary because we haven't got
around to making it not so yet, not because of limitations in the
system. It runs on Windows and Linux/Unix from identical code (I
think there is a couple of lines of hackery with choosing fonts, but
that's it).
The system runs mostly on Linux. Originally we thought it would run
mostly on Windows, and a very substantial amount of code was written
on Windows, at which time we didn't even have a Linux box (we had
Solaris boxes but no testing was done on them as we didn't have the
development environment). When things changed, we got a Linux box,
and moved it there. It compiled and ran on Linux first time, with
*no* changes to the source (we did later find a couple of small bugs I
think). I now develop about 50/50 on the two platforms - Windows
because it runs on my laptop, Linux because the machine has a big
screen.
Things like making executables and GUIS are not defined by the
standard, but decent implementations do a good job of it. In fact, of
course, the rather few language standards define most of this stuff -
I'm fairly sure that C++/C doesn't for instance. Java probably does
though. Many single-implementation languages like Perl probably do too
but this is not different than a single Lisp implementation doing so
except that there is more than one Lisp implementation.
--tim
Christopher C. Stacy
Paul> In article <87k7kp2...@bird.agharta.de>, Edi Weitz <e...@agharta.de>
Paul> wrote:
>> arien <spamme...@getlost.invalid> writes:
>>
>>> This is not really what I'm asking about. I'm not talking about the
>>> specific syntax etc, I'm referring to what the language
>>> acheives. For starters, Lisp is not compiled into an executable.
>>
>> Says who? Several commercial Lisp implementation can create
>> stand-alone executables if that's what you're asking for.
>>
>>> In Lisp is it possible to create a UI?
>>
>> Yes.
Paul> In fact, many/most of the UI features common today -- windows, mice with
Paul> multiple buttons, clickable text and graphics, popup menus etc were
Paul> common in lisp systems going on 20 years ago. (Where's the new stuff,
Paul> folks?)
More like 29 years ago, but who's counting?
Pascal Costanza
> "arien" <spamme...@getlost.invalid> wrote in message
> news:MPG.1810e231b...@news.adl.ihug.com.au...
>
>>Hey, I agree with them on the silly parentheses! I haven't had a single
>>error yet that wasn't caused by parentheses being in the wrong spot!
>>
>>Damn things ((((((((((((((((())))))))))))))))))))))
>
> You are using the wrong editor.
Arien,
Most Lisp development environments come with their own editors that
support you in "coping" with the parentheses. Another choice would be to
use the Lisp mode in Emacs/XEmacs. Whatever editor you have used
previously, you should definitely switch to one of these choices.
Erik Winkels
>
> I guess the closest the world has been to really "selfcontained
> executables" were DOS games a few years ago.
And the products of the demoscene in the late 80s, early 90s. The OS
(at least on the Atari ST) didn't even get a chance to start up once
our demos were finished :-)
But I can hardly image that there weren't any selfcontained
executables before that time, though my memory on the history of
computing is not good enough to recall any, or did this need really
arise because of homecomputers and their shoddy operating systems?
Erik
Andreas Eder
> FYI: Common Lisp is a standard programming language.
Yes, and there is even a Portable Standard Lisp (that is not officialy
standardized) :-)
'Andreas
--
Wherever I lay my .emacs, thereæ„€ my $HOME.
Joe Marshall
> For starters, Lisp is not compiled into an executable.
This isn't directed particularly at arien; about once a month someone
asks about compiling to an `executable' or `standalone executable'.
What is this fascination with `executables'?
Fred Gilham
arien <spamme...@getlost.invalid> writes:
> ...What I still find hard to grasp, is normally when you distribute
> a program, you distribute the executables. So how would you
> distribute a program created in Lisp?
If the program is big enough[1], you dump a Lisp image. You also dump
a Lisp image when you want to add packages to your basic Lisp
environment so that the features in those packages will be available
when you start up. I now have three Lisp images that I run on a
regular basis. One is the `bare' Lisp, containing only the packages
that come with CMU Lisp. It has no GUI. Actually that's a little
misleading, since it has CLX, which is the Lisp version of XLIB.
Another is a Garnet image, which contains the Garnet GUI toolkit, and
another is a CLIM image, which contains FreeCLIM. CLIM is a
more-or-less standardized cross-platform GUI toolkit. FreeCLIM is an
open source version that is not yet complete, but which some people
are working on.
Here are the sizes of the images:
25489408 clim.x86f
19111936 garnet.x86f
14712832 lisp.core
There's also Maxima, a symbolic algebra program, which gets dumped as
a Lisp image. Here is the size of Maxima:
28405760 maxima.core
There's also CL-HTTP, a Lisp-based web server:
25341952 cl-http.core
These are just a few images I happen to have around at the present.
The way all these work under CMU Lisp is that you have a Lisp `image
loader' which maps the image into memory, runs a few initialization
things and then hands control to Lisp. So a Lisp binary distribution
would consist of the image loader, the image or core file, and perhaps
a script to start things up, telling the image loader the name and
location of the image and what function to run to start things going.
This is the size of the image loader (which is the actual `executable'
from the Unix or DOS perspective):
353116 lisp
So to run the Maxima application, I'd have a script that would invoke
it as follows:
/usr/local/lib/cmucl/bin/lisp -eval "(user::run)" -core /usr/local/lib/maxima/5.9.0rc1/binary-cmucl/maxima.core
Maxima 5.9.0rc1 http://maxima.sourceforge.net
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
This is a development version of Maxima. The function bug_report()
provides bug reporting information.
(C1)
Other versions of Lisp will have distribution mechanisms similar to
this, though not exactly the same. Some will merge the image and the
loader into the same file.
-----
[1] `Big enough' has, ironically, taken on smaller values over time as
disk space has increased. That is, it used to be unpleasant to have a
bunch of 20-30 meg images lying around on one's disk, so one would
load the program from fasls (Lisp object code) instead of dumping an
image of that size. Now people think nothing of keeping around
multiple images that size. This is one aspect of the way that
hardware has `caught up' with Lisp, making it much more pleasant to
run Lisp than it was even ten years ago.
--
Fred Gilham gil...@csl.sri.com
The density of a textbook must be inversely proportional to the
density of the students using it. --- Dave Stringer-Calvert
Joe Marshall
> Hey, I agree with them on the silly parentheses! I haven't had a single
> error yet that wasn't caused by parentheses being in the wrong spot!
Of course. It isn't as if you *could* put a curly brace, semicolon, comma,
etc. in the wrong spot.
Espen Vestre
> What is this fascination with `executables'?
I'd say that "all-in-one" executables are usually easier to sell or
give away, because they might be easier to insall than a whole lisp
system and since they sometimes don't require the receiver to buy some
license for the lisp system.
--
(espen)
Joe Marshall
> Lastly, I show some sample lisp code, that I had written, to a friend
> and he responded that it looked like a Low Level Lanuage. Could someone
> tell me 1) if this is true, and 2) The difference between High Level and
> Low Level languages?
I don't know. I have written interrupt handlers, garbage collectors,
and virtual memory systems in Lisp and in general have found it to be
much easier than writing them in C or in assembly.
Joe Marshall
> You could call assembly language "low level" because it takes
> many lines of code to do anything significant. Or because one
> usually uses assembler to manipulate hardware directly.
But if your assembly *is* Lisp, this distinction disappears.
Pascal Costanza
I don't think this "fascination" has anything to do with executables in
a strict sense. I guess they are actually talking about deployment. Take
Arien as an example: He says he comes from the Java world - you also
don't have executables in Java in a strict sense (apart from some
compilers that directly produce native executables, but that's the
exception and also has some limitations). However, the standardization
of class file and jar file formats in the Java world provides a very
simple model of delivering applications, together with the fact that
almost all operating systems provide a Java runtime environment by default.
There's nothing similar like that in the Lisp world, and this can be
confusing for beginners. When you deliver an application to end users,
you have to take into account that they don't care what language an
application is implemented in and that they don't want to install many
different packages just to try out a single application. (Or, to put it
the other way around: You have an advantage if your application can be
installed with as little intervention by end users as possible.)
Other people have already mentioned that many Common Lisp
implementations offer their own deployment models, and some of them,
especially those of commercial vendors, are actually equally simple like
those of other programming languages, including Java. There's just no
standardized model available.
(For example, several years ago I have used SchemaText as a tool for
commercial website development. I wasn't aware until recently that this
application had been developed in Allegro Common Lisp.)
JB
I have had the experience that I do not make syntatic errors
often when I write Lisp. (Emacs takes care for the
parentheses and I very much miss this feature in Maple for
example). Syntatic errors in C++ or in Python occur much
more frequently (I always forget those /wretched/ /colons/
after else for example). (In Perl I tended to forget the
dollar signs.) Additionally in Python, the indentation can
play some nice tricks on you too.
Not that I have written much Lisp code until now.
I think that Lisp forces me to take a closer look at the
true structure of a statement and this is partly the reason
why errors do not happen so often.
JB
On my Linux system, when I type in a cnsole "lisp", cmucl
starts up and if I type "clisp" then I get clisp. Both are
executables. Why?
Wade Humeniuk
"arien" <spamme...@getlost.invalid> wrote in message
> This is not really what I'm asking about. I'm not talking about the
> starters, Lisp is not compiled into an executable. In Lisp is it
> possible to create a UI?
If you want an example of a executable with a GUI. I wrote a Windows
based running log program.
See http://www3.telus.net/public/whumeniu/runnerslog-140.exe
Manual at
http://www3.telus.net/public/whumeniu/Manual.html
It is written with Xanalys's LispWorks for Windows 4.1.20
Delivery level 5
Download and run it, you can check on many things,
the size of the executable, speed, gui capabilities.
Wade
Fred Gilham
arien <spamme...@getlost.invalid> writes:
> Hey, I agree with them on the silly parentheses! I haven't had a single
> error yet that wasn't caused by parentheses being in the wrong spot!
>
> Damn things ((((((((((((((((())))))))))))))))))))))
Reminds me of a joke.
(Start of joke)
I was able to break into the DOD research computers and steal the
source code for the Star Wars project! It's written in Lisp. And to
prove it, here are the last few lines of the code:
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
(End of joke)
I think I understand what you're saying, though. When you first start
with lisp, you tend to do things like
(let (x (+ y 1))
(foo x))
or
(defun (foo x)
(bar x))
or
(cond (= x 3)
(foo x))
and so on. But it goes away after a while.
--
Fred Gilham gil...@csl.sri.com
The amazing thing is, back when I was a C++ programmer, I thought that
[Design Patterns] was SUCH a great book. And I guess it was, in a
way: it made it possible to use C++ and get something done. In the
long run, of course, that may have been a disservice... - Alain Picard
ozan s yigit
> C++ owes big time to Common Lisp. Consider the idea behind C++
> exception handling, that errors can be represented as classes, and
> that inheritance can play a role in matching an exception to a
> handler. That was in Lisp long before Koenig and Stroustrup wrote that
> paper back in 1990 about how to hack exception handling into C++.
i think that this form of exceptions (as opposed to PL/1 design) is due
to clu. [can anyone familiar with liskov's design comment?]
oz
--
needless to say, debating the pope is the ultimate exercise in futility.
-- steven pinker
Erik Winkels
>
> The key example was Cedar/Mesa: It was written by people who liked
> and used resumption, but after ten years of use, there was only one
> use of resumption left in the half million line system -- and that
> was a context enquiry. Because resumption wasn't actually necessary
> for such a context enquiry, they removed it and found a significant
> speed increase in that part of the system. In each and every case
> where resumption had been used it had -- over the ten years --
> become a problem and a more appropriate design had replaced it.
> BASICALLY, EVERY USE OF RESUMPTION HAD REPRESENTED A FAILURE TO KEEP
> SEPARATE LEVELS OF ABSTRACTION DISJOINT." (emphasis mine)
Does this piece not make a great case for resumption? Especially the
sentence you have emphasized.
That, while resumption has no place in an end-product, it is a great
development tool.
Erik
Thomas F. Burdick
> C++ owes big time to Common Lisp. Consider the idea behind C++
> exception handling, that errors can be represented as classes, and
> that inheritance can play a role in matching an exception to a
> handler. That was in Lisp long before Koenig and Stroustrup wrote that
> paper back in 1990 about how to hack exception handling into C++. They
> did a poor, sloppy job. They missed one important idea from from the
> condition handling system of Lisp; namely that you find the error
> handler first, call it and give *it* the opportunity to trigger
> unwinding. The poor choice to unwind while searching for a handler
> leads to an idiotic exception handling system which conflates
> non-local control transfers with error recovery. So at best, C++
> exception handling can only contain errors, rather than provide a
> substrate for error recovery protocols.
Bah, you can too build error recovery protocols on top of it, it's
just really difficult (which maybe means it was the right choice for
C++?). And your system will be incompatible with mine. But if you
pass around enough state, you can wrap up enough information in your
exception object to correct an error and restart the computation.
I've done it, cursing Stroustrup's name the entire time...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick
> arien wrote:
>
> > This is not really what I'm asking about. I'm not talking
> > about the specific syntax etc, I'm referring to what the
> > language acheives. For starters, Lisp is not compiled into
> > an executable. In Lisp is it possible to create a UI?
>
> What I told you was not a matter of syntax.
> You can create user interfaces with Lisp, but is is not
> quite simple. This is a long story.
> For C++, on the other hand, there are a lot of nice GUI
> libraries, like C++, wxWindows, Fulltick, Fox, etc.
> If you look only at the language, Lisp is suprior to C++ as
> far as creating UIs are concerned but Lisp lacks the
> infrastructure.
Uhh ... CL has libraries, too. Garnet, for example. It comes with an
interface builder, and it's much easier to use than wxWindows. If
you're willing to pay money, they commercial vendors have their
systems, too. It's true that CL doesn't have any OS-portable,
vendor-portable, native-look-and-feel GUI libraries ... but I've never
seen one in any language worth using.
Gisle Sælensminde
Because it's considered the way you distribute you software. I my
experience this is not even the most common way of distibute software.
I have distributed software as a zip file of java components
in the form of jar files to be used in other applications, and once
in a previous job, we delivered a computer ready installed with
OS and the software we sold. The customer just wanted the job done, and
that was the most convenient way of doing it.
On Windows applications often comes as executables, but the executables
are not the program, but installers, and is really a substitute for
a missing package system. On Linux, software most frequently comes
as rpm or deb archives, which is not executables either.
In practice you can't just deliver just a standalone executable, since you
need to distribute things like data files, documentation, examples etc in
addition to the executable. If your lisp system can't produce standalone
executable, that would in most cases not be a problem, precisly because
it will not suffice to deliver just a standalone executable.
--
Gisle Sælensminde ( gi...@ii.uib.no )
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going
to land, and it could be dangerous sitting under them as they fly
overhead. (from RFC 1925)
Christopher C. Stacy
Joe> arien <spamme...@getlost.invalid> writes:
>> For starters, Lisp is not compiled into an executable.
Joe> This isn't directed particularly at arien; about once a month someone
Joe> asks about compiling to an `executable' or `standalone executable'.
Joe> What is this fascination with `executables'?
I suspect it's because there is a popular myth that Lisp is an
"interpreted language", and that this would imply that execution
requires an "interpreter", and that this would be slow.
(Of course, about 30 years ago, that was mostly true!)
Charlton Wilbur
EW> But I can hardly image that there weren't any selfcontained
EW> executables before that time, though my memory on the history
EW> of computing is not good enough to recall any, or did this
EW> need really arise because of homecomputers and their shoddy
EW> operating systems?
I recall Bank Street Writer as one example of serious software that
did that. When you wanted to run it, you rebooted your computer, and
when you were done, you turned the computer off.
I think it had more to do with the fact that the operating systems on
the 8-bit micros were almost universally extremely primitive -- but at
the same time, they were small enough that you could grasp the entire
system and understand how it all worked together well enough to
replace it.
Charlton
JB
> Uhh ... CL has libraries, too. Garnet, for example. It
> comes with an
> interface builder, and it's much easier to use than
> wxWindows. If you're willing to pay money, they
> commercial vendors have their
> systems, too. It's true that CL doesn't have any
> OS-portable, vendor-portable, native-look-and-feel GUI
> libraries ... but I've never seen one in any language
> worth using.
I use Qt with Python. It is excellent and I still consider
myself a Lisp programmer.
I tried the Gtk+ bindings for cmucl: I should use Gtk+, but
I was not even able to build it.
I saw an IDE for cmucl and clisp in CLiki: it is programmed
in Java! And I read what Mac Battyany said about using the
native MS-Windows interface with Corman Lisp. Because there
is nothing else.
I think the missing GUI was one of the points being put
forward by Peter Norvig when he talked about the
shortcomings of Lisp.
It is a pity as the language itself is superior to
everything I have ever come across.
Wade Humeniuk
"JB" <j...@yahoo.de> wrote in message news:3da72...@news.newsgroups.com...
> I saw an IDE for cmucl and clisp in CLiki: it is programmed
> in Java! And I read what Mac Battyany said about using the
> native MS-Windows interface with Corman Lisp. Because there
> is nothing else.
The Windows GUI interface is every bit a programming interface as Qt
or Gtk+ is. If you keep your app within the Windows env there is nothing
like using the native toolkit. Using a layered toolkit necessarily limits your ability
to create a GUI on any particular platform.
> I think the missing GUI was one of the points being put
> forward by Peter Norvig when he talked about the
> shortcomings of Lisp.
> It is a pity as the language itself is superior to
> everything I have ever come across.
Hmm, this seems to a common complaint, but nobody seems to wring their
hands about every operating system having its own GUI toolkit. It is just
accepted as the fact it is. There seems to a different GUI for every major OS,
which can be viewed as a good thing. Why limit yourself to Gtk+?
I think every implementation of CL has a GUI toolkit, they are just different,
there is only one implementation of Python, so by trivial definition they
have "standard" GUIs.
I have to pose this as a serious question, do you think there should be only
one implementation of CL?
Wade
Chisheng Huang
> > commercial vendors have their
> > systems, too. It's true that CL doesn't have any
> > OS-portable, vendor-portable, native-look-and-feel GUI
> > libraries ... but I've never seen one in any language
> > worth using.
>
> I use Qt with Python. It is excellent and I still consider
> myself a Lisp programmer.
>
> I tried the Gtk+ bindings for cmucl: I should use Gtk+, but
> I was not even able to build it.
Take a look at http://www.izware.com/mirai/index.html.
Most of the development work was done prior to the end
of 1999. Its heritage can be traced back to Symbolics.
It's written in Allegro CL and run on SGI, Red Hat Linux,
and Micros**t Windows. All its graphical user interface
is done in CL. Based on my miserable experience with
Java, I doubt you can use Java for a system like that.
If you use CMUCL and the old GTK+ 1.2 binding, you still
can get lots of stuff done. The same GTK+ 1.2 binding was
ported to LispWorks to run on Micros**t Windows.
-cph
JB
> Hmm, this seems to a common complaint, but nobody seems to
> wring their hands about every operating system having its
> own GUI toolkit. It is just
> accepted as the fact it is. There seems to a different
> GUI for every major OS, which can be viewed as a good
> thing. Why limit yourself to Gtk+?
I named Gtk because I saw that Gtk+ 2 bindings existed for
cmucl, if I understood this correctly. I could not even
build it.
> I have to pose this as a serious question, do you think
> there should be only one implementation of CL?
Im my opinion this is not an important question.
I must admit that what I wrote to the original poster was
not precise.
I could buy one of the two professional products that
support CLIM and everything would be all right. Maybe I had
not the native look and feel of the OS but I should not
care.
So the correct answer to the original question would have
been /in/ /my/ /opinion/: Yes, it seems to be possible to
creat very nice UIs with CL but only with one of the
commercial products.
(I should remark that when you learn Qt or Gtk then you can
use your knowledge with C++ or other languages as well.
CLIM is limited to Lisp. Even so I used and use CL in my
classes when I do not need a UI.)
Thomas F. Burdick
> So the correct answer to the original question would have
> been /in/ /my/ /opinion/: Yes, it seems to be possible to
> creat very nice UIs with CL but only with one of the
> commercial products.
What's with the Qt/Gtk obsession for free CLs? You can use Garnet
with CMUCL on Unix, and I believe it also works with MCL on the Mac
(OS9/Classic), and the commercial CLs on Unix. There's also CLM, if
you want to use Motif, for a Unix "native"[*] look-and-feel. For
plain-old-X11 stuff, you can use CLX. And there's also CLUE/CLIO,
which may or may not be a good idea, I've never tried them.
On the Mac, it looks like OpenMCL has Cocoa bindings, so if you can't
make nice looking GUIs with it, you're hopeless :). On MS Windows,
Corman Lisp is commercial, but the compiler is freely-available, and
you can make native look-and-feel Windows apps using it.
All in all, if you want the holy grail, something that works on all
platforms, on all implementations, you can't have it. But if you're
willing to pick one or two implementations, and/or one or two
platforms, you're fine, commercial or not.
[*] Scare quotes because while this works on, say, Solaris, Linux
users might not think it looks too native.
quasi
for someone who come from, say, the C world, the only way to get a
"hello world" to display is to compile the source into and executable
and then run it by typing it's name. When I first started programming
(first lang. C), getting the code to compile and getting a running
executable made me more happy than getting it to do what I wanted it
to. But of course this was only in the beginning... '-)
--
Gareth McCaughan
> No one has yet explained what the difference is between a High or Low
> level language? This is why I'm confused!
Alan Perlis, author of many epigrams related to computing,
once said: A language is low-level if it requires attention
to the irrelevant.
*
So, for instance, C++ is low-level because when you're
programming in C++ you need to concern yourself with
memory management; any time you create an object, you
need to know whose responsibility disposing of it is.
Some programming languages, like Common Lisp, provide
automatic memory management: objects get disposed of
once no one is using them any more, and the programmer
doesn't have to think about that.
C++'s memory management, in turn, is more automatic
than C's, because of all the neat things you can do
with constructors and destructors. So, in C++, you
can create objects of class "string" and pass them
around freely without worrying "whose job is it to
destroy this thing?"; and you can make something similar
happen with your own classes. You have more work to do
than in Common Lisp, but considerably less than in C;
C can't do this sort of thing at all.
Another C++/Lisp comparison: in C++ you have to be
aware of the sizes of the integers you're working with,
because integers just silently overflow when they get
too big. In C or C++ on a 32-bit machine,
1000000*1000000 == -727379968
which is, um, wrong. In Common Lisp, integers can get
really big; much larger than your computer's word size.
*
This definition of "low-level" makes low-level-ness
a matter of degree; *all* programming languages require
attention to stuff you'd prefer to think of as irrelevant.
It's also a matter of context. If you're writing a program
whose job is to solve logic problems of the kind they publish
in some magazines ("There are five houses in a row. Each
one is inhabited by a husband and wife, who keep three pets
and have two favourite artists. [...] Which pets are owned
by the couple whose favourite artists are Kandinsky and Tintoretto?")
then Prolog is a high-level language, because you can pretty much
express the problem directly in it, and Common Lisp would be
low-level because it forces you to be explicit about how you
want to search for the solution. But if you're writing a program
to play chess, then Prolog is low-level and Common Lisp is
high-level because Prolog doesn't offer the sort of searching
facilities you need and you have to hack them together from
rather inappropriate raw materials.
In a wide range of contexts, Common Lisp is higher-level
than C++ by this criterion. But surely not all contexts.
(For instance, if the majority of a project is interfacing
to someone else's code that's written in C++ then Common Lisp
will feel low-level because the interfacing is harder there.
In the short term, any language you don't know is low-level
because you have to keep reminding yourself of its syntax,
the contents of its standard library, and so on. That might
be why your friend said a piece of Lisp code looked low-level.
But this sort of low-level-ness goes away once you actually
use the language for a while.
--
Gareth McCaughan Gareth.M...@pobox.com
.sig under construc
Gareth McCaughan
> I have had the experience that I do not make syntatic errors
> often when I write Lisp. (Emacs takes care for the
> parentheses and I very much miss this feature in Maple for
> example). Syntatic errors in C++ or in Python occur much
> more frequently (I always forget those /wretched/ /colons/
> after else for example). (In Perl I tended to forget the
> dollar signs.) Additionally in Python, the indentation can
> play some nice tricks on you too.
> Not that I have written much Lisp code until now.
With experience, the colons and whitespace in Python
disappear just like the parentheses in Lisp :-).
Curiously, most of my syntax errors when writing Python
are ... missing parentheses! :-)
Christopher Browne
This is actually /not/ true.
It is /not/ the only way to get "hello, world!" to display.
There have been numerous C interpreters implemented, including CINT,
CH, and EiC. (EiC is the most ambitious one; it appears to have
recently gone AWOL.)
People don't commonly use them, but it's as true that there "are no C
interpreters" as it is that "Common Lisp is an interpreted language."
(Which is to say that the correct response is: "Nonsense!")
It seems to me that in a lot of cases, people would be better off
using a C interpreter instead of some of the shell scripting
languages; it provides the not inconsiderable merit that they could
readily move to a compiled application should that prove necessary...
[I know the author of a shell language called "BUSH" that's basically
a subset of Ada; part of the express intent of it is to allow users
work in a language that doesn't forcibly need them to do a complete
rewrite when it turns out that a "quick script" has to be turned into
a "real application."]
--
(reverse (concatenate 'string "gro.gultn@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/
A student, in hopes of understanding the Lambda-nature, came to
Greenblatt. As they spoke a Multics system hacker walked by. "Is it
true", asked the student, "that PL-1 has many of the same data types
as Lisp?" Almost before the student had finished his question,
Greenblatt shouted, "FOO!", and hit the student with a stick.
Thomas A. Russ
>
> I've only just started studying lisp this semester at uni, and I'm
> wondering if someone can explain to me (in fairly simple terms), why
> (and how) lisp differs from standard programming languages such as C++.
> I think I sort of get the idea. Lisp is an AI language for starters, and
> it is based on logic, but after that I'm lost. I just need a bit more of
> an in depth (not TOO deep) explaination as to why this is so.
Well, there are lots of answers to this particular question. With no
particular claim to completeness, here are some of my takes on this:
In Lisp, everything is an expression and returns a value. That is why
Lisp only needs one IF form, whereas C++ needs both "if ... then
... else ..." and "... ? ... : ...). That is because in Lisp IF returns
a value and can be used anywhere.
This also leads to a programming style that is more apt to use nested
function calls (since everything is a function, there aren't really
"procedures"), even though you could nest C++ function calls.
Lisp has a much more uniform syntax, represented in a form that is a
native data structure in the language. This allows for easy source code
transformations and allows complicated source code transformations to be
encoded in Lisp macros without the need for additional tools like
parsers, lexers or preprocessors. For a (relatively) simple example,
you could try the exercise of writing a CASE macro that has the same
syntax and behaves like the built-in case statement in Lisp. It isn't
really all that difficult once you know Lisp. It would be rather
daunting to consider writing a control structure like "switch" in C++.
I suspect that you couldn't do it with a C++ macro.
Then there is the Common Lisp Object System (CLOS). It is organized in
a very different way than the C++ object system. In CLOS, classes
encapsulate just the data representation (i.e., the slots or instance
variables). Methods do not belong to classes. Methods belong to
generic functions, which are invoked in exactly the same way as any
other function. This lack of special syntax provides a couple of
benefits, among them the aesthetic one of having all function call look
the same, the practical one of allowing a change from function to
generic function without having to change callers, and MOST CRUCIALLY
the ability to have Multi-methods, namely methods that dynamically
dispatch on the types of any combination of the arguments.
Another benefit of having methods divorced from classes, and in fact, of
the ability to add additional methods to generic functions at all times
is an increased reusability of code. That is because you don't need
access to a class' source code in order to be able to write new methods
for it. If the objects encapsulate code + function theory were
operating in the real world, one would presumably not be able to use a
screwdriver to pry up the lid of a paint can because the "pry" method
was not forseen by the designer of the screwdriver object. Likewise,
one could not use a hammer to hold a towel down on a windy day, since
such a method (use) was not forseen by the designer.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Friedrich Dominicus
> A long time ago, in a galaxy far, far away, quasi <quas...@yahoo.com> wrote:
> > On 11 Oct 2002 10:25:35 -0400, Joe Marshall <j...@ccs.neu.edu> wrote:
> >
> >>arien <spamme...@getlost.invalid> writes:
> >>
> >>> For starters, Lisp is not compiled into an executable.
> >>
> >>This isn't directed particularly at arien; about once a month someone
> >>asks about compiling to an `executable' or `standalone executable'.
> >>
> >>What is this fascination with `executables'?
> >
> > for someone who come from, say, the C world, the only way to get a
> > "hello world" to display is to compile the source into and executable
> > and then run it by typing it's name. When I first started programming
> > (first lang. C), getting the code to compile and getting a running
> > executable made me more happy than getting it to do what I wanted it
> > to. But of course this was only in the beginning... '-)
>
> This is actually /not/ true.
exactly.
It's nonsense as it is to say Lisp is an interpreted language.
You can use e.g Cint as you C/C++ Interpreter, and it works quite
nicely.
Regards
Friedrich
quasi
<spamme...@getlost.invalid> wrote:
>For starters, Lisp is not compiled into an executable.
for some information on this you may want to check out
http://abhijit-rao.tripod.com/digital/compiled-lisp.html
It has some material and examples from a previous thread on cll.
cheers!
--
JB
> Janos Blazi wrote:
>
>> I have had the experience that I do not make syntatic
>> errors often when I write Lisp. (Emacs takes care for
>> the parentheses and I very much miss this feature in
>> Maple for example). Syntatic errors in C++ or in Python
>> occur much more frequently (I always forget those
>> /wretched/ /colons/ after else for example). (In Perl I
>> tended to forget the dollar signs.) Additionally in
>> Python, the indentation can play some nice tricks on you
>> too. Not that I have written much Lisp code until now.
>
> With experience, the colons and whitespace in Python
> disappear just like the parentheses in Lisp :-).
Most unfortunately, this is not the case at least as far as
I am concerned. I have written many thousand of lines o
Python code and still have this problem.
quasi
wrote:
>>
>> for someone who come from, say, the C world, the only way to get a
>> "hello world" to display is to compile the source into and executable
>> and then run it by typing it's name. When I first started programming
>> (first lang. C), getting the code to compile and getting a running
>> executable made me more happy than getting it to do what I wanted it
>> to. But of course this was only in the beginning... '-)
>
>This is actually /not/ true.
>
>It is /not/ the only way to get "hello, world!" to display.
I was inaccurate in my post. I overlooked adding "like me". When I
was first introduced to a PC it was a 386 running MSDOS and Turbo C.
I did not know what Lisp was and I did not know what google was. I
did not have internet access till 2 years later and that too for about
once a week for 15 minutes to check email for the next year.
/No/ one in my personal contact who programmed in C has started with
an interpreter or has used one (I live in Mumbai, India). This does
/not/ say that there are no interpreters. That was not what I wanted
to convey.
*sigh* - All I was saying was that there /are/ people like me. And
those are the reasons for "the facination".
>
>[ some very interesting information ]
regards
--
quasi
<spamme...@getlost.invalid> wrote:
>
>Hey, I agree with them on the silly parentheses! I haven't had a single
>error yet that wasn't caused by parentheses being in the wrong spot!
>
>Damn things ((((((((((((((((())))))))))))))))))))))
emacs should solve the problem. If you are used to vi, vi can show
matching parenthesis too. About 10% of your "parentheses being in
wrong spot" errors can be eleminated by proper indentation. Emacs
will do this automagically. The remaning such errors should dissapear
with the "show matching parenthesis" ability which both emacs and vi
have.
I find the simple Lisp syntax very clarifying.
regards
p.s.
I have done 95% of all my programming to date in C.
--
Kaz Kylheku
> Hey, I agree with them on the silly parentheses! I haven't had a single
> error yet that wasn't caused by parentheses being in the wrong spot!
If that is the case, then there is only one thing that stands between
you and success, and an intelligent text editor can do most of it for
you.
> Damn things ((((((((((((((((())))))))))))))))))))))
Most other programming languages, including C++, have parentheses or
some other kinds of delimiters for indicating the parameter list to a
function call. In C++ you would write f(g(x,y)); whereas in Lisp it
would be (f (g x y)) . Note how there is no comma or semicolon. When
an expression becomes too deeply nested, you have the same kinds of
tools in Lisp as in other languages: namely decomposition into
functions. In addition, Lisp has a very powerful macro system that
lets you write little compilers into your program that translate
simple syntax into complex code. In one freeware program that I wrote
in Lisp, I can traverse a directory tree of files by writing:
(for-each-file-info (info-variable "/dir/to/traverse")
... body ...)
For each object under /dir/to/traverse is visited, the variable
``info-variable'' is bound to a Lisp object which describes that
filesystem object, and the body is executed. There is robust error
handling built in into the above construct. You can add a graphical
user interface that will let a user recover from directory traversal
errors, such as trying to descend into a directory for which the
process has no permissions. And you can add that interface without
touching a line of the above code by writing an error handler
somewhere else which is called when the error occurs, which can
dynamically inquire about the available ways of recovering, and create
a menu for the user. So there are lots of powerful semantics hidden
behind that very simple expression.
You can't get away from syntax; there has to be some way for the
programmer to specify a program, as a complex, nested data structure,
indicating that one element is subordinate to another. Lisp chooses
the most straight forward way of writing nested structures, which
allows programs to be conveniently treated as data structures.
Lastly note that Lisp can be easily taught to understand infix read
syntax. There exists a portable Lisp module that allows you to write
C-like syntax such as f(g(a+3,x++) - b). Lisp does not constrain the
programmer to using only one syntax; the main idea behind Lisp is to
liberate programmers rather than constrain them.
Frank A. Adrian
> What is this fascination with `executables'?
That is a very good question. I was going to say something smarmy like
"When all a man has is a UNIX, everything looks like an executable...", but
I stopped myself when I realized that almost all OS's out there have this
odd fascination with the concept. In the fundamental sense, an executable
is simply a proxy for a stopped process - and not a very good one at that.
There's a huge amount of work in turning the executable back into a running
process, it doesn't save any state, so you have to reload that, too, and in
the end, it's a holdover from when disk sizes were small and whose
usefulness has come to an end. But, then, so are a lot of the dumb things
in computers.
faa
Hannah Schroeter
Pascal Costanza <cost...@web.de> wrote:
>[...]
>Most Lisp development environments come with their own editors that
>support you in "coping" with the parentheses. Another choice would be to
>use the Lisp mode in Emacs/XEmacs. Whatever editor you have used
>previously, you should definitely switch to one of these choices.
In fact I found vim with
:set lisp ai showmatch
to work quite okay, too.
Kind regards,
Hannah.
Marc Battyani
> I saw an IDE for cmucl and clisp in CLiki: it is programmed
> in Java! And I read what Mac Battyany said about using the
> native MS-Windows interface with Corman Lisp. Because there
> is nothing else.
Hum, that's not what I said... In fact I think I said exactly the opposite.
(or is my English so bad ? ;-))
I use directly the Windows API not because there is nothing else but rather
because it's a very powerful way to do a GUI for Windows. Sure you have to
read the docs and it only works on Windows. But it's really easy. For
instance my window.lisp file that encapsulate the base Windows stuff has
only 649 lines, the full windows directory has 1500 lines and the controls
directory (the lisp code to use standard controls like edit, list, etc.)
only 800.
Using this I can do all I want for a GUI. And thanks to the CLOS method
combinations and multiple dispatch I had much fun doing this.
I even made a Lisp shell extension so that the Lisp UI was embedded into the
Explorer as a set of virtual directories.
Here is what I said (spelling errors not removed...):
"I generally use the FLI/FFI to directly call the Win32 API.
That way you can build the win32 application you want with the all the
functionalities you want. (controls, OpenGL, etc.)
I think that Common Lisp + Win32 API is far superior to the MFC or other
Win32 frameworks. The before/around/after method combinaisons are really
useful here.
Now I tend to use IE as an interface rather than Win32 when I don't need
OpenGL."
BTW I use Lispworks though Corman Lisp is probably a very good
implementation too.(I look forward to attend Roger Corman's presentation at
the ILC)
Marc
sv0f
k...@ashi.footprints.net (Kaz Kylheku) wrote:
>If you look at the C++ template library and things under #include
><functional> and #include <algorithm>, not only do the ideas come
>straight from Lisp, but so do the names! Where you do you think count,
>count_if, find, find_if, remove, remove_if and set_difference come
>from? Lisp's sequences library has count, count-if, find, find-if,
>remove, remove-if and set-difference, and it was here first, long
>before C++ had these things. Coincidence, or plagiarism? String
>streams? Lisp again.
Stepanov, the designer of the C++ template system, was heavily
influenced by Scheme. See:
Huw Giddens
> arien <spamme...@getlost.invalid> writes:
>
>> > See above, plus, it is much more complete as a programming environment.
>> > Lisp is simply a better programming language and environment than C++.
>>
>> I wonder what the C++ programmers would say if I asked this :-)
>
> Well, it depends. Do those C++ programmers also know ANSI Common Lisp
> well? I'm competent in both, and I find CMUCL+Hemlock+Garnet+Solaris
> the nicest, most productive environment I've found yet. I use other
> things, and I can appreciate some of the niceties in the Forte IDE or
> MSVC++, but I'm just so much more productive in Lisp.
Heh. After a bit of C++, hemlock doesn't seem like such a bad idea ;)
Huw
--
That's the thing about people who think they hate computers. What they
really hate is lousy programmers.
- Larry Niven and Jerry Pournelle in "Oath of Fealty"
arien
says...
> Arien as an example: He says he comes from the Java world
>
Just wanted to point out - it's "She" :-)
--
Mel
Please post reply to newsgroup. Reply address isn't valid.
arien
I've been told that Lisp IS an interpreted language! Now I'm even more
confused.
arien
> arien <spamme...@getlost.invalid> writes:
>
> > For starters, Lisp is not compiled into an executable.
>
>
>
>
>
I don't have a fascination with executables, I just don't understand any
other way to do it. For example, although I've been learning Java, I
have not understood how the programs could be deployed.
For example, I have never downloaded a program (say, from Tucows), that
wasn't delivered as an executable.
So to add another question, how are programs such as Microsoft Office
deployed? Are these considered executables (even though there is more
than 1 file)? Does anyone know what language the programs in Office are
written in?
(please don't start bashing Microsoft! I will totally and absolutely
agree with any MS bashing. I am just using this as an example)
arien
wa...@nospam.nowhere says...
>
> "arien" <spamme...@getlost.invalid> wrote in message
> news:MPG.1810e231b...@news.adl.ihug.com.au...
> > wa...@nospam.nowhere says...
> > >
> > > "arien" <spamme...@getlost.invalid> wrote in message
> > > >
> > > > >
> > > > > See above, plus, it is much more complete as a programming environment.
> > > > > Lisp is simply a better programming language and environment than C++.
> > > > >
> > > >
> > > > I wonder what the C++ programmers would say if I asked this :-)
> > >
> > > 5% probablility that they would way, "Lots of silly parentheses"
> > > 3% probability that they would say, "I hated that Scheme course"
> > > 2% probability that they would say, "Damn, I wish I could get a job programnming in Lisp"
> > >
> > > Wade
> > >
> > >
> >
> > Hey, I agree with them on the silly parentheses! I haven't had a single
> > error yet that wasn't caused by parentheses being in the wrong spot!
> >
> >
>
> You are using the wrong editor.
>
> Wade
>
>
The editor only makes sure that you have the right number of ()'s. It
doesn't guarentee that you have them in the right spot - which is my
problem!
arien
says...
> Wade Humeniuk wrote:
> > "arien" <spamme...@getlost.invalid> wrote in message
> > news:MPG.1810e231b...@news.adl.ihug.com.au...
> >
>
> >>error yet that wasn't caused by parentheses being in the wrong spot!
> >>
> >>Damn things ((((((((((((((((())))))))))))))))))))))
> >
> > You are using the wrong editor.
>
>
> Most Lisp development environments come with their own editors that
> support you in "coping" with the parentheses. Another choice would be to
> use the Lisp mode in Emacs/XEmacs. Whatever editor you have used
> previously, you should definitely switch to one of these choices.
>
>
>
>
I am using Xanalys Lispworks 4.2
arien
> arien <spamme...@getlost.invalid> writes:
>
> > Hey, I agree with them on the silly parentheses! I haven't had a single
> > error yet that wasn't caused by parentheses being in the wrong spot!
>
> etc. in the wrong spot.
>
At least curly brace, semicolon, comma etc are all different. It becomes
easier to find the error, and the compiler will even tell you which line
has the error.
In lisp, all you have is parentheses, parentheses, and more parentheses.
And if you get it wrong, lisp doesn't tell you. It just gives you a
bizarre error message such as:
"Likes is not a cons type"
(where Likes is the first atom of a list). *That's* why I have more
problems with ()'s than I ever had in Java.
Tim Bradshaw
> I've been told that Lisp IS an interpreted language! Now I'm even more
> confused.
Lisp systems may be interpreted or compiled or both. Almost all
serious modern implementations have a compiler. Common Lisp (which is
the dominant modern dialect, at least as far as this group is
concerned), specifies a compiler and some minimal things that it must
do (which are not very onerous - it could be implemented as an
interpreter more-or-less). All CL implementations that I know of have
a compiler, although one compiles to a virtual machine, and at least
one uses the system's C compiler as the back-end of the compiler.
The myth that Lisp is an interpreted language is just that - a myth:
* (defun foo (x)
(cons (car x) (cadr x)))
foo
* (compile 'foo)
Compiling lambda (x):
Compiling Top-Level Form:
foo
nil
nil
* (disassemble 'foo)
400BA170: .entry foo(x) ; (function (t) cons)
188: add -18, %code
18C: add %cfp, 32, %csp
190: cmp %nargs, 4 ; %nargs = #:g0
194: bpne,pn %icc, L0
198: nop
19C: mov %a0, %a1 ; %a0 = #:g1
1A0: and %a1, 7, %nl0 ; No-arg-parsing entry point
1A4: cmp %nl0, 3
1A8: bpne %icc, L1
1AC: nop
1B0: mov %a1, %a0
1B4: lduw [%a0-3], %a2
1B8: lduw [%a1+1], %a0
1BC: and %a0, 7, %nl0
1C0: cmp %nl0, 3
1C4: bpne %icc, L2
1C8: nop
1CC: lduw [%a0-3], %a3
1D0: add 4, %alloc ; Set pseudo-atomic flag
1D4: andn %alloc, 7, %a0
1D8: or 3, %a0
1DC: add 4, %alloc ; Reset pseudo-atomic, allocated 8 bytes
1E0: andcc %alloc, 3, %zero ; pseudo-atomic interrupted?
1E4: tne %icc, 16
1E8: st %a2, [%a0-3]
1EC: st %a3, [%a0+1]
1F0: mov %cfp, %csp
1F4: mov %ocfp, %cfp
1F8: j %lra+5
1FC: mov %lra, %code
200: L0: illtrap 10 ; Error trap
204: byte #x04
205: byte #x19 ; INVALID-ARGUMENT-COUNT-ERROR
206: byte #xFE, #xED, #x01 ; NARGS
209: .align 4
20C: L1: illtrap 10 ; Error trap
210: byte #x04
211: byte #x02 ; OBJECT-NOT-LIST-ERROR
212: byte #xFE, #x2E, #x02 ; A1
215: .align 4
218: L2: illtrap 10 ; Error trap
21C: byte #x04
21D: byte #x02 ; OBJECT-NOT-LIST-ERROR
21E: byte #xFE, #x0E, #x02 ; A0
221: .align 4
*
arien
> (Start of joke)
>
> I was able to break into the DOD research computers and steal the
> source code for the Star Wars project! It's written in Lisp. And to
> prove it, here are the last few lines of the code:
>
>
> )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
> )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
> )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
> )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
>
> (End of joke)
>
>
hehehehe. I love that one. I'm sending this one on to all my fellow
exasperated students!
Espen Vestre
> In lisp, all you have is parentheses, parentheses, and more parentheses.
> And if you get it wrong, lisp doesn't tell you.
Have patience and learn to use your tool:
In another posting, you said you were using LW 4.2, which has a
sophisticated debugger which e.g. can take you to the source code
where the error happened.
--
(espen)
Martti Halminen
> > I suspect it's because there is a popular myth that Lisp is an
> > "interpreted language", and that this would imply that execution
> > requires an "interpreter", and that this would be slow.
> > (Of course, about 30 years ago, that was mostly true!)
> I've been told that Lisp IS an interpreted language! Now I'm even more
> confused.
Very few languages as such are either interpreted or compiled; their
implementations may be. Major Lisp implementations have had compilers
for a long time (someone mentioned Lisp 1.5 having a compiler; I
wouldn't know: I started with MacLisp, which had one, about 20 years
ago.)
Many people see Lisp's interactive programming environment, and
automatically assume that it needs to be interpreted. While most of
those are, there are some implementations (at least Macintosh Common
Lisp, IIRC) without interpreters: it just compiles any code written by
the user on-the-fly, and executes the compiled code.
Generally, the current style in using CL on those implementations that
have both a compiler and an interpreter is to run mostly compiled code:
interpreted code is mostly only the trivial stuff written on the command
line, or when needing better debugging information that you get from
compiled code.
--
Espen Vestre
> those are, there are some implementations (at least Macintosh Common
> Lisp, IIRC) without interpreters: it just compiles any code written by
> the user on-the-fly, and executes the compiled code.
This is probably only confusing in the current thread, but anyway:
MCL does in fact have an interpreter, but AFAIR you have to set at
least two flags in order to make it crawl out of its hiding place.
With standard MCL environment configuration, your description is
accurate.
--
(espen)
Tim Bradshaw
> In lisp, all you have is parentheses, parentheses, and more parentheses.
No, you have words too. Don't obsess about the parens, read the
words. C (for instance) uses a small number of characters to indicate
different sorts of constructs in the language, while Lisp uses words
to indicate a much larger (indeed, potentially infinite) number of
constructs.
So whereas in C you might have:
{ /* this means `begin a block' */
int a = 3;
...
}
In Lisp you have:
(let ; this means `begin a binding'
((a 3))
...)
or
(progn ; this means `begin a group of expressions'
... )
or
(block foo ; this means `begin a block named FOO from which you
; can return'
...)
(synchronized (x) ; this means `begin a block, synchronizing on X'
; (this is not part of the standard language)
...)
--tim
Joe Marshall
> I've been told that Lisp IS an interpreted language! Now I'm even more
> confused.
Dr. Frankenstein: But they told me it was `ee-gore'.
Igor: Well they were wrong then, weren't they?
Joe Marshall
> In article <u1jtdp...@ccs.neu.edu>, j...@ccs.neu.edu says...
> > arien <spamme...@getlost.invalid> writes:
> >
> > > Hey, I agree with them on the silly parentheses! I haven't had a single
> > > error yet that wasn't caused by parentheses being in the wrong spot!
> >
> > Of course. It isn't as if you *could* put a curly brace, semicolon, comma,
> > etc. in the wrong spot.
> >
>
> At least curly brace, semicolon, comma etc are all different. It becomes
> easier to find the error, and the compiler will even tell you which line
> has the error.
I have always detested compilers that report things like:
``Expected a ; found a }''
If it is smart enough to know what ought to go there, why doesn't it
just fix it?
Erik Naggum
| I've been told that Lisp IS an interpreted language!
| Now I'm even more confused.
This may be a turning point in your life. In some ways you have been
lucky, but you have mostly been unlucky. Your first brush with a lie can
be a riveting experience. When you first notice that somebody was less
than truthful, outright misleading, or even told you something that was
hurtful to you, many questions arise in your mind. Why would anyone lie?
The sad answer is that people have no reason to lie. People get a reason
to tell the truth and to spend time and effort to find things out when
they discover that doing so has even greater benefits in society than to
lie and cheat, but the history of mankind has generally been about not
telling the truth. Why would anyone pass on a myth that they could not
back up by fact? Sadly, again, they have no reason to do this: it is the
prevailing default behavior. People do not generally think unless they
have been shown the great benefits of thinking. It has actually happened
that people have become the president of very large countries without
realizing the benefits of thinking. Thinking is hard work. Sorting true
from false is hard work. If this is your first experience of a lie, of
people who only parrot what they have heard unthinkingly, of people who
have not yet experienced the great benefits of telling the truth and of
thinking about what they say, I almost envy you, but only /after/ I spent
so much time agonizing over /why/ people would lie and only /after/ I saw
that people lie all the time and they do not have any reason to do so.
Lying is the default human action. Telling things how you want them to
be (without being particularly conscious of it) is much /easier/ than
getting up every morning to spend the whole day making enemies with
others because you want to know the truth and they want to tell lies.
So be not confused. Many things you have been told have been lies. In
fact, most of what you have been told should really have turned out to be
wrong if you acted on what you had been told and checked to see if things
developed as they would have if what you were told had been true. This
takes time and effort, but so many more interesting things happen when
you make that effort.
If you want to know what is true about Lisp, just watch this newsgroup.
People who tell lies and spread misinformation are quickly corrected, and
if you hang around long enough, almost all the lies will be debunked and
what you have left is a pretty good approximation to the truth. But just
as in life in general, even most people here will not have thought very
carefully about everything they say and will repeat myths and confusions
in the service of maintaining a consensus of views, which is very useful,
even when the consensus thus built is based on misrepresentations. The
only result of wanting to debunk all the myths is that people think you
are out to start trouble and will invent all sorts of stupid lies to tell
about you, instead, so the price one pays for wanting the most correct
technical environment is one where a lot of people who do not care about
the truth when it does not serve their immediate needs will tell lies
about something non-technical. Note how many discussions in this
newsgroup are all about people telling stories about me. This is a
pretty good indication that I have exposed them as liars and frauds and
careless people who tell stories instead of thinking and caring about the
truth. But at the very least they won't be telling lies about Lisp while
they tell lies about me. This means that the remainder of this newsgroup
is mostly true, and if it is technical, very likely the best answers you
can get. Still, do not /believe/ what you are told, think about it and
spend the time and effort to sort out the true from the false. We'll be
here to help debunk myth after myth and falsehood after falsehood.
So in a way, you are very lucky to have found us and it is good of you to
notice that what you have been told is wrong. Welcome to Common Lisp.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Erik Winkels
>
> I have always detested compilers that report things like:
> ``Expected a ; found a }''
>
> If it is smart enough to know what ought to go there, why doesn't it
> just fix it?
Wouldn't things get ugly very quickly? Should the compiler:
1) Fix the source file?
2) Just fix it for the current compilation and give a warning?
I think the current situation is the least bad of all. Case 1 seems
an absolute no-no to me and case 2 just leads to people leaving a ';'
where there should be a '}' because the compiler'll fix it anyway.
Nevertheless, I do find such messages pretty annoying and they give me
a good opportunity to start swearing at the computer (actually, at my
own stupidity) :-)
Erik
--
"However, anybody who would have designed Perl has an aesthetic sense
sufficiently different from mine that it simply does not apply to me.
Sort of like anybody who thought E.T. was a profound and moving movie,
only more so." -- David Thornley in comp.lang.lisp
Christopher Browne
Then you have been told wrongly.
Try to find an "interpreted" implementation of Common Lisp.
You won't, because there /isn't one./
/All/ Common Lisp implementations compile their code. Some (CLISP
being most notable) compile to bytecode, not native code.
But they /all/ compile the code.
Whomever told you that "Lisp is an interpreted language" is either
talking about facts a dozen years obsolete, thus indicating that they
are woefully ignorant, or they are outright lying. Neither option is
terribly flattering.
--
(concatenate 'string "cbbrowne" "@acm.org")
http://cbbrowne.com/info/finances.html
"If a word in the dictionary were misspelled, how would we know?"
-- Steven Wright
Tim Bradshaw
> I have always detested compilers that report things like:
> ``Expected a ; found a }''
> If it is smart enough to know what ought to go there, why doesn't it
> just fix it?
I remember a (pascal?) compiler which did fix this kind of thing (not
in the source file, but on the fly, so it would mutter each time you
ran it).
--tim
Kenny Tilton
arien wrote in message ...
>In article <u1jtdp...@ccs.neu.edu>, j...@ccs.neu.edu says...
>> arien <spamme...@getlost.invalid> writes:
>>
>> > Hey, I agree with them on the silly parentheses! I haven't had a single
>> > error yet that wasn't caused by parentheses being in the wrong spot!
>>
>> Of course. It isn't as if you *could* put a curly brace, semicolon,
comma,
>> etc. in the wrong spot.
>>
>
>At least curly brace, semicolon, comma etc are all different. It becomes
>easier to find the error, and the compiler will even tell you which line
>has the error.
>
>In lisp, all you have is parentheses, parentheses, and more parentheses.
>And if you get it wrong, lisp doesn't tell you.
Welllllll, I hope your Lisp editor also supports automatic indentation. If
not, change editors. If so, I think you will agree that that puts you
leagues ahead of editing other languages. Using
matching-parens-highlighting, the /editor/ will tell you /as you type/
whether or not to hit the ")" key and when you have hit it too often. The
auto-indent will tell you when you put the parens inthe wrong place.
The only problem is that the auto-indent is a clear guide only after you
have done sufficient (not much) CL coding to know where you are expecting
the next line to start. When it starts somewhere else, you got a parens in
the wrong place. So you have to bootstrap a little. And you do have to be
generous with the line-breaks so you get the feedback.
And /do/ break up big functions into smaller ones if only to divide and
conquer the visual mass.
Finally, end this thread and write some code. Then the parentheses will
simply disappear.
kenny
clinisys
Michael Sullivan
There's no such thing as an interpreted language. If a language can be
interpreted, it can be compiled.
Interpretation vs. compilation is an implementation issue. I suppose if
you have a proprietary language where the only implementation is a
purely interpreted one, you could call it an "interpreted language".
Applescript would be a good example. But there's nothing keeping it
from being compiled, except the fact that no one has written a compiler.
Lisp is generally written with an interpreter, but you can direct every
modern Lisp implementation (that I'm aware of) to compile specific
functions, or even all your code.
Since writing code in an interpreter is *much* easier than doing
edit/compile/link/debug cycles, this seems like an intelligent way to
work. If something is too slow when interpreted (and it's not a poor
algorithm problem), compile it.
It's so obviously a good idea, I have a hard time understanding why
things are not done this way in some IDE of every popular language.
Probably because only people who've been exposed to working this way for
long enough to get it, understand what's so wonderful about it.
Michael
--
Michael Sullivan
Business Card Express of CT Thermographers to the Trade
Cheshire, CT mic...@bcect.com
Michael Sullivan
> In article <CQrp9.3810$Sk6.2...@news1.telusplanet.net>,
> wa...@nospam.nowhere says...
> > "arien" <spamme...@getlost.invalid> wrote in message
> > news:MPG.1810e231b...@news.adl.ihug.com.au...
> > > Damn things ((((((((((((((((())))))))))))))))))))))
> > You are using the wrong editor.
> The editor only makes sure that you have the right number of ()'s. It
> doesn't guarentee that you have them in the right spot - which is my
> problem!
That's a brain problem, not a parentheses problem. I don't mean that
you're stupid. What I mean is that if you're getting the parentheses
wrong, it's because you don't understand the structure of your code
correctly.
You would have this same problem with the syntax in any other language.
When I first learned pascal and C, around 15 years ago, I was driven
absolutely insane by the syntax requirements. It took me 18 hours
(about 15 of them spent in cursing) to get my first college CS
assignment to compile in MacPascal, though I'd written provably correct
pseudocode in about 5 minutes. I had been writing in nothing but basic
and assembler (Z80 and 6502) before that. I could have coded the
project in either Assembler in 1/10th the time it took for me to get my
code past that ridiculous pascal compiler.
While I've had some parenthesis slippage in Lisp, I haven't ever felt
myself fighting the syntax in the way I had to when I first learned C
and Pascal. Not even close. And I'd gotten quite used to infix and the
idiosyncrasies of C by the time I seriously looked at Lisp.