·······@atl.mindspring.com wrote in message
<················@nntp6.mindspring.com>...
>I started my study of Lisp because I was told that it is a functional
>progrmming language that supports recursion well and avoids things
>like iterative loops. I then examine the documentation that comes
>with XLisp and see that I have all the global variables, Do loops,
>functions for jumping out of code blocks and loops, records, and all
>the other imperative programming constructs I'm familiar with. Given
>all this, is Lisp any "better"? Or, should I stick with C++ or Pascal
>and practice recursion techniques?
Let me start out by saying that Lisp (or Scheme) is my favorite language by
far and that it is not so simply as a matter of preference (IMO).
While lisp supports (promotes?) functional programming and recursion, as
you've
noted, it's really no more "functional" or "recursive" than most any
language. C
supports "functional" programming as well as recursion just as well as lisp
and
typically runs 5 to 100 _times_ faster (please no flames, I did say
"typically").
So if this is true why would I prefer (for real technical reasons) lisp?
A programming language is a tool for solving problems. Factors such as a
language's
restrictions or limitations, and the complexity of the language have nothing
to do
with the problem or solution and just act to further separate the problem
from the solution
(i.e. make it harder to solve the problem at hand). Except for forth, lisp
(or scheme) has
the simplest syntax of any (well known) language. You can learn the syntax
of lisp in
less than a minute and know that it is used throughout the entire language.
Unlike
most languages (including C, Pascal, Fortran, Cobol, ADA, etc.) lisp has one
syntax
for executing statements, the same syntax for declaring variables or
structures, the
same syntax for defining functions, etc. All the other languages have a
different
syntax for each of these, lisp as one and the same. Therefore with lisp
syntax is
not an impediment to solving the problem, not just an unnecessarily added
element.
Now, I'm sure that there are those of you who might say "but who besides a
lisp interpreter
can understand all those parenthesis". First of all those parenthesis are
no stranger to
view that any other new language is to a programmer. And I submit that the
simple
syntax of lisp makes getting over all the parenthesis much easier than
understanding
all the syntactical elements of another language. Secondly, using a common,
very
powerful, and free editor such as GNU Emacs makes programming in lisp
trivial
since it automatically and intelligently indents the code such that the
parenthesis are
not an issue at all. Additionally, there are some very, very important
reasons to
retain lisp's parenthesis syntax as I'll talk about below.
Lisp is a weakly typed (or dynamically typed) language. Most other compiled
languages
are strongly types (or statically typed) languages. This is a debate which
has gone on
for a long time and I don't think I can settle the matter except for this.
Strongly typed
languages are clearly more difficult to work with for two reasons. First
they require
a lot of detailed declarations which add a lot of language elements
separating the
problem from the solution in the name of program correctness and runtime
efficiency.
While it is true that detailed declarations do allow compilers to detect
certain classes
of bugs at compile time there are still many other types of problems which
it can't
detect (such as logic errors). Why add all those complicated language
elements
(declarations) just to find one type of problem? Just because a program
compiles
(all the types agree) surely doesn't mean it is correct or will run.
It can be argued that adding language elements (such as declarations)
decreases
static type errors at the expense of logic errors since the declarations
make the logic
harder to decipher.
The second reason for adding static typing is runtime efficiency. Since the
types are
statically known the language can dispense with the runtime costs associated
with
doing the right thing with the right type. This argument has been mitigated
by two
factors. First modern lisp compilers have become so intelligent and
efficient that
programs written lisp can often approach that of statically typed languages
making the
difference irrelevant. Secondly, the speed of modern CPU's renders many
get-it-
down-to-the-last-microsecond issues irrelevant. As long as the computer
responds
before the user notices any delay what's the difference? If everyone was as
fanatical
about efficiency as the appear why don't they all code in assembler? Hand
written
assembler most often runs a lot faster than C! The bottom line is that it
is a trade
off. Given the modern CPU speeds and the sophisticated lisp compilers the
scale is often tipping in favor of lisp.
Besides the very significant clutter that declarations introduce they also
make a program
less flexible. This is a very significant issue and I could write a great
deal about it.
The more general solution one can find to a problem the greater use it can
be. Instead
of solving a specific problem and only being able to be used in one case the
solution
can be written in general terms and have wide applicability. Let me give a
trivial
example in C and Scheme:
void twice(int x)
{
once(x);
once(x);
}
(define (twice x)
(once x)
(once x))
In this example C's twice only works for integers. You'd have to write one
for double, long,
string, or any other type you wanted to use it for. Basically, every time
you added a type
you'd have to write another twice! On the other hand, the scheme version
works for any
type! A general solution!
(Note also that the lisp syntax is just as easy to read and much simpler!!)
IMO, the advantages of a weakly typed language far out weigh the advantages
of a strongly
typed language.
When writing real life programs one most often has to allocate memory. Most
of the
popular languages make it cumbersome and unnatural to allocate memory and
then
require you to manually dispose of it when you are done thus, again,
introducing
elements unrelated to the solution of the problem. Lisp allocates naturally
(without any
special function calls and typecasting) and has an automatic garbage
collector thus
eliminating the need to manually track and free memory. This feature can
eliminate
many bugs associated with applications written in other languages.
Now for one of the biggest reasons to use lisp and its parenthetical syntax,
IMO. Given
lisp's primitive data type (the CONS cell or list structure) and its ability
to read in and
manipulate lisp programs as data, lisp is uniquely able to parse, modify,
and create
other lisp programs! In C is it easy to read (parse) C programs? Is it
easy to write
C programs to evaluate other C programs? Is it easy to write C programs
which can modify
themselves or create other C programs? I didn't think so. Lisp can do all
these things
absolutely trivially. So why, you might ask, is this important? Let's see
if I can explain.
In any language one can write a program (solution to a problem). But lisp
is
uniquely qualified to write programs which can themselves write programs.
It's
kind of like meta-programming. Why would anyone want to do this? Let me
give
a trivial example from mathematics.
In math it is convenient to add. With addition one can do quite a lot. But
at some
point of complexity it becomes more convenient to use multiplication. In a
sense
multiplication is like meta-addition since it's just a bunch of addition.
And then
as things get more complicated powers become useful. Powers are kind of
like meta-multiplication since it's just a short hand for a bunch of
multiplications.
The point to this simple minded example is that as the problem becomes more
complex increasingly abstract tools are needed thus the ability of lisp to
parse,
modify, and create it's own programs put lisp in a unique position to solve
the
most complex problems!
Another thing which makes lisp and even more so scheme powerful is their
ability to
treat functions as first class data types. This means that functions can be
passed
like other data as function arguments or assigned to like variables. Most
languages
treat functions very statically and restricted (as compared to other
elements like
variables). While it's true that languages such as C allow pointers to
functions to
be passed like variables, few languages match schemes first class treatment
of functions.
The final comment I wish to make relates to elegance. I've heard elegance
defined
as a simple solution to a complex problem. In this case I find lisp (or
scheme) to
be the most elegant (beautiful) solution to the problem of programming.
Finally, if you take into account all of lisp/scheme's features of simple
syntax,
weak typing, garbage collection, meta-programming, and elegance you find
lisp in a very unique position as the best language choice for many types of
problems.
--blake
--
Download source code to my Dynace Object Oriented
Extension to C and Windows Development System from:
http://www.edge.net/algorithms
Blake McBride (·····@edge.net)
Algorithms Corporation - 615-791-1636 - USA
In article <············@usenet42.supernews.com>, "Blake McBride"
<·····@edge.net> wrote:
> ... lisp has one syntax
> for executing statements, the same syntax for declaring variables or
> structures, the same syntax for defining functions, etc.
How about (from the HyperSpec):
defparameter name initial-value [documentation] => name
defun function-name lambda-list [[declaration* | documentation]] form*
=> function-name
Is this different syntax or not? I'm puzzled.
> Besides the very significant clutter that declarations introduce
Some may even call it "documentation". ;-)
From: Klaus Schilling
Subject: Re: How is Lisp "better"?
Date:
Message-ID: <8790lddd4k.fsf@ivm.de>
······@lavielle.com (Rainer Joswig) writes:
> In article <············@usenet42.supernews.com>, "Blake McBride"
> <·····@edge.net> wrote:
>
> > ... lisp has one syntax
> > for executing statements, the same syntax for declaring variables or
> > structures, the same syntax for defining functions, etc.
>
> How about (from the HyperSpec):
>
> defparameter name initial-value [documentation] => name
>
> defun function-name lambda-list [[declaration* | documentation]] form*
> => function-name
>
> Is this different syntax or not? I'm puzzled.
>
>
> > Besides the very significant clutter that declarations introduce
>
> Some may even call it "documentation". ;-)
Scheme can have as many user-defined syntaxes as you want, until the hardware
bursts.
Klaus Schilling
* Jacques Duthen <··············@sncf.fr>
| I think the lisp syntax Blake refers to is:
|
| left parenthesis
| function name
| arguments
| right parenthesis
|
| which applies to any instruction, whether it's a variable declaration, a
| function definition, an addition, etc. and the same syntax also applies
| recursively to the arguments.
but this is _obviously_ false. why do people believe such nonsense?
#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
From: Jacques Duthen
Subject: Re: How is Lisp "better"?
Date:
Message-ID: <35D45BE6.41F8@sncf.fr>
Excuse me as I was not clear enough. I wrote:
> > I think the lisp syntax Blake refers to is:
[snip]
Maybe, to make things clearer, I should have said:
"Perhaps the kind of lisp syntax Blake has in mind is:" etc.
Apart this, I totally agree with Rainer and Erik.
Jacques Duthen <··············@sncf.fr> writes:
> > In article <············@usenet42.supernews.com>, "Blake McBride"
> > <·····@edge.net> wrote:
> > > ... lisp has one syntax
> > > for executing statements, the same syntax for declaring variables or
> > > structures, the same syntax for defining functions, etc.
> I think the lisp syntax Blake refers to is:
>
> left parenthesis
> function name
> arguments
> right parenthesis
>
> which applies to any instruction, whether it's a variable
> declaration, a function definition, an addition, etc.
> and the same syntax also applies recursively to the arguments.
>
> Note that this is _syntax_. The semantics may impose
> restrictions: the first argument of `defun' _must_ be a symbol
> otherwise you get a runtime error (wrong type argument), just
> like the args of the standard `+' function have to be numbers,
> not strings, nor symbols, nor lists, or the arg of `sqrt' has
> to be a positive number, etc.
> This is imposed by the semantics of the function, not the
> syntax of the language.
I agree with you about what syntax Blake (probably) had in mind.
But the line between syntax and semantics can be moved around.
For instance, in a language where there are procedures with a
fixed number of arguments, this rule is not normally given in
the syntax, because the syntax is usually given in BNF or some
other notation for context-free grammars. But the Algol 68
definition handles this in the formal syntax.
Now, in Lisp one often sees formal syntax for more than the
basic "data syntax". This goes back possibly even to Lisp 1.5
(I don't have a copy of the book handy right now), but certainly
both the Common Lisp and Scheme language definitions have
formal syntax definitions for cond, if, defun/define, let, etc.
Saying that these specifications, in BNF or some similar notation,
are part of the *semantics* might make a certain amount of sense,
but it's surely not the only way to look at it. It seems fairly
natural, at least, to say that this is *syntax* and that some of
the syntax rules are implemented by the macros and special forms
rather than the reader.
-- jd
Jeff Dalton a �crit:
>
> Jacques Duthen <··············@sncf.fr> writes:
>
> > > In article <············@usenet42.supernews.com>, "Blake McBride"
> > > <·····@edge.net> wrote:
>
> > > > ... lisp has one syntax
> > > > for executing statements, the same syntax for declaring variables or
> > > > structures, the same syntax for defining functions, etc.
>
> > I think the lisp syntax Blake refers to is:
> >
> > left parenthesis
> > function name
> > arguments
> > right parenthesis
> >
> > which applies to any instruction, whether it's a variable
> > declaration, a function definition, an addition, etc.
> > and the same syntax also applies recursively to the arguments.
> >
> > Note that this is _syntax_. The semantics may impose
> > restrictions: the first argument of `defun' _must_ be a symbol
> > otherwise you get a runtime error (wrong type argument), just
> > like the args of the standard `+' function have to be numbers,
> > not strings, nor symbols, nor lists, or the arg of `sqrt' has
> > to be a positive number, etc.
> > This is imposed by the semantics of the function, not the
> > syntax of the language.
>
> I agree with you about what syntax Blake (probably) had in mind.
>
> But the line between syntax and semantics can be moved around.
> For instance, in a language where there are procedures with a
> fixed number of arguments, this rule is not normally given in
> the syntax, because the syntax is usually given in BNF or some
> other notation for context-free grammars.
I agree too.
What I had in mind (for the syntax/semantics part) is that a
C program like the following is syntactically correct:
foo () {
float x;
char *y;
*x = y + z;
}
It probably won't compile because of undefined variable,
mismatch type...
But this code will pass the lexical analysis and the syntactical
analysis. Thus, this program is an element of the language
defined by the C grammar, but not a valid C program, because
of semantical errors.
While the distinction syntax/semantics seem (at least for me) to
be quite clear for a C program, I agree that it's not so obvious
for lisp programs.
> But the Algol 68 definition handles this in the formal syntax.
>
> Now, in Lisp one often sees formal syntax for more than the
> basic "data syntax". This goes back possibly even to Lisp 1.5
> (I don't have a copy of the book handy right now), but certainly
> both the Common Lisp and Scheme language definitions have
> formal syntax definitions for cond, if, defun/define, let, etc.
If you define (a part of) the grammar with something like this:
function-call ::= '(' lambda-or-symbol arg* ')'
etc.
then (car a b c) will be syntactically correct,
but if you put in the grammar things like:
function-call ::= car-call | cdr-call | ...
car-call ::= '(' 'car' arg ')'
then (car a b c) will NOT be syntactically correct.
I think the reasonable conclusion is that the limit between
syntax and semantics in lisp is just arbitrary!
> Saying that these specifications, in BNF or some similar notation,
> are part of the *semantics* might make a certain amount of sense,
> but it's surely not the only way to look at it. It seems fairly
> natural, at least, to say that this is *syntax* and that some of
> the syntax rules are implemented by the macros and special forms
> rather than the reader.
I still agree, and think it's more "natural" (if that can make
sense in such a context!) to consider as syntax standard special
forms like cond, let, defun, do... but, then, what is the status
of user-defined macros or special forms (if this is possible in
some lisp)?
> -- jd
-- another jd [jack]
--
| # # | # # # | # # | # # # | # # | # # # | Jacques Duthen [jack] |
| # # | # # # | # # | # # # | # # | # # # | ······@club-internet.fr |
|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|_|
In article <·················@club-internet.fr>, ······@club-internet.fr wrote:
> I still agree, and think it's more "natural" (if that can make
> sense in such a context!) to consider as syntax standard special
> forms like cond, let, defun, do... but, then, what is the status
> of user-defined macros or special forms (if this is possible in
In a compiled Lisp, user defined macros usually will
be expanded a macro expansion
time, before the code will be compiled. They clearly
introduce syntax.
* Jacques Duthen <······@club-internet.fr>
| While the distinction syntax/semantics seem (at least for me) to be quite
| clear for a C program, I agree that it's not so obvious for lisp
| programs.
it might help to understand where the line is drawn to remember that Lisp
source code is lists in memory, not character strings in files, such as C
code is. the processing and interpretation of character strings into
in-memory representation of the various types of objects in Lisp is
performed by the READ function. since this function has completed it
task before any of the (other?) language-analysis functions get to work
on the code, I'd say the syntactic properties of the character string
representation (which is normally what syntax is understood to be) are
taken care of by READ.
in non-Lisp languages, READ rarely exists, even in the compiler. C, for
instance, has several _processes_ that go into the syntactical parsing,
like preprocessing, and then there's the unenviable `typedef' which
affects the table of keywords (another "syntax" concept Lisp does not
have to deal with), and it is fairly hard to represent C code in memory
at any stage of this process in such a way that it can be written out and
still look like it did to begin with. I'd say that the line is very
fuzzy in C, whereas at least one line can be drawn very clearly in Lisp.
#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
>>>>> "Erik" == Erik Naggum <······@naggum.no> writes:
Erik> it might help to understand where the line is drawn to remember that Lisp
Erik> source code is lists in memory, not character strings in files, such as C
Erik> code is. the processing and interpretation of character strings into
Erik> in-memory representation of the various types of objects in Lisp is
Erik> performed by the READ function.
This is a gross oversimplification, and nonsense for Scheme. Using
READ for pre-parsing Scheme source code may be convenient, but it
prevents a Scheme system from catching a number of syntax errors, and
reporting errors accurately. A prominent example (taught to me by
Richard Kelsey) is:
(+ . (21 21))
which, when read by READ yields
(+ 21 21)
which is correct Scheme, whereas (+ . (21 21)) isn't.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
* ·······@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor])
| ... and nonsense for Scheme.
Scheme is not a Lisp in this regard (as in several others). if you
insist on calling Scheme a Lisp, confusions like this will crop up.
#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
·······@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
< which is correct Scheme, whereas (+ . (21 21)) isn't.
Why isn't (+ . (21 21)) correct? Shouldn't it be the same as
(+ . (21 . (21 . ())))?
Or maybe
(+ . (21 . (21 . '()))).
Is this the reason for it's illegality (having to quote nil)? Just
curious.
* Steve Gonedes <········@worldnet.att.net>
| Why isn't (+ . (21 21)) correct?
because Scheme's syntax, like Algol's, is defined as character strings.
thus, you need a different reader for Scheme source than for Scheme data.
a crucial element of the Lisp heritage is thus lost on Scheme.
#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
In article <···············@brabantio.informatik.uni-tuebingen.de>,
Michael Sperber [Mr. Preprocessor] <·······@informatik.uni-tuebingen.de> wrote:
>>>>>> "Erik" =3D=3D Erik Naggum <······@naggum.no> writes:
>
>Erik> it might help to understand where the line is drawn to remember tha=
>t Lisp
>Erik> source code is lists in memory, not character strings in files, suc=
>h as C
>Erik> code is. the processing and interpretation of character strings in=
>to
>Erik> in-memory representation of the various types of objects in Lisp is=
>
>Erik> performed by the READ function.
>
>This is a gross oversimplification, and nonsense for Scheme. Using
>READ for pre-parsing Scheme source code may be convenient, but it
>prevents a Scheme system from catching a number of syntax errors, and
>reporting errors accurately. A prominent example (taught to me by
>Richard Kelsey) is:
>
>(+ . (21 21))
>
>which, when read by READ yields
>
>(+ 21 21)
>
>which is correct Scheme, whereas (+ . (21 21)) isn't.
It is -- and evaluates to the same result as (+ 21 21).
(Just as in Common Lisp.) Does Scheme 48 do something
different here?
--d
Dorai Sitaram writes, quoting Michael Sperber:
> >(+ . (21 21))
> >
> >which, when read by READ yields
> >
> >(+ 21 21)
> >
> >which is correct Scheme, whereas (+ . (21 21)) isn't.
>
> It is -- and evaluates to the same result as (+ 21 21).
I recall nothing in Scheme's syntax that allows or requires this.
DrScheme's reader used to disallow this, but stopped doing so for two
reasons: (1) compatibility with other Scheme's, and (2) to make life
easier for metaprogrammers -- they could thus generate bodies of the
form (x . y) and have it be a proper list if y was a proper list. It
actually takes more work for DrScheme to allow the above expression
than to disallow it.
'shriram
Shriram Krishnamurthi <·······@cs.rice.edu> writes:
stuff about (+ . (21 21)) and (+ 21 21)
> I recall nothing in Scheme's syntax that allows or requires this.
> DrScheme's reader used to disallow this, but stopped doing so for two
> reasons: (1) compatibility with other Scheme's, and (2) to make life
> easier for metaprogrammers. (omissis) It
> actually takes more work for DrScheme to allow the above expression
> than to disallow it.
>
What kind of of "Scheme" is DrScheme? Is it a Scheme or is it not?
What level of compliance with Scheme standards does it provide?
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 80 79 23, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
[Note follow-ups.]
Marco Antoniotti <·······@galvani.parades.rm.cnr.it> writes:
> What kind of of "Scheme" is DrScheme?
Tell me how you categorize your "Scheme"s, and I'll tell you what
kind of "Scheme" it is.
> Is it a Scheme or is it not?
It is very much a Scheme in any conventional sense of the word.
> What level of compliance with Scheme standards does it provide?
It's compatible with R4RS, and offers many, many extensions as well.
If your question is serious rather than frivolous, visit the Web page
http://www.cs.rice.edu/CS/PLT/packages/drscheme/ ,
read the technical papers mentioned (and available) there, and review
the extensive documentation. If you still have questions, mail me.
'shriram
>>>>> "Shriram" == Shriram Krishnamurthi <·······@cs.rice.edu> writes:
Shriram> Dorai Sitaram writes, quoting Michael Sperber:
>> >(+ . (21 21))
>> >
>> >which, when read by READ yields
>> >
>> >(+ 21 21)
>> >
>> >which is correct Scheme, whereas (+ . (21 21)) isn't.
>>
>> It is -- and evaluates to the same result as (+ 21 21).
Shriram> I recall nothing in Scheme's syntax that allows or requires
Shriram> this.
Well, if you don't recall, look it up.
R5RS:
<expression> -> <procedure call>
<procedure call> -> (<operator> <operand>*)
<operator> -> <expression>
<operand> -> <expression>
There's no expression starting with ". ".
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
> >(+ . (21 21))
> >
> >which, when read by READ yields
> >
> >(+ 21 21)
> >
> >which is correct Scheme, whereas (+ . (21 21)) isn't.
>
> It is -- and evaluates to the same result as (+ 21 21).
> (Just as in Common Lisp.) Does Scheme 48 do something
> different here?
Gambit-C 3.0 does detect this error:
% gsi
Gambit Version 3.0
> (+ . (21 21))
*** ERROR IN (stdin)@1.1 -- Ill-formed procedure call
> (+ 21 21)
42
In article <··············@raptor.IRO.UMontreal.CA>, Marc Feeley
<······@raptor.IRO.UMontreal.CA> wrote:
> > >(+ . (21 21))
> > >
> > >which, when read by READ yields
> > >
> > >(+ 21 21)
> > >
> > >which is correct Scheme, whereas (+ . (21 21)) isn't.
> >
> > It is -- and evaluates to the same result as (+ 21 21).
> > (Just as in Common Lisp.) Does Scheme 48 do something
> > different here?
>
> Gambit-C 3.0 does detect this error:
>
> % gsi
> Gambit Version 3.0
>
> > (+ . (21 21))
> *** ERROR IN (stdin)@1.1 -- Ill-formed procedure call
> > (+ 21 21)
> 42
Is an implementation required to detect this?
So READ can't be used? Really? Why?
Is there a reason why the usual list/dot notation has not
been used?
In MCL:
? (trace (read))
NIL
?
;Compiling "Macintosh HD:Desktop Folder:test.lisp"...
Calling (READ #<INPUT CCL::INPUT-FILE-STREAM to "Macintosh HD:Desktop
Folder:test.lisp"> NIL (NIL))
READ returned (PRINT (+ 1 2))
Calling (READ #<INPUT CCL::INPUT-FILE-STREAM to "Macintosh HD:Desktop
Folder:test.lisp"> NIL (NIL))
READ returned (PRINT (+ 2 2))
Calling (READ #<INPUT CCL::INPUT-FILE-STREAM to "Macintosh HD:Desktop
Folder:test.lisp"> NIL (NIL))
READ returned (NIL)
Erik Naggum <······@naggum.no> wrote:
>* Jacques Duthen <······@club-internet.fr>
>| While the distinction syntax/semantics seem (at least for me) to be quite
>| clear for a C program, I agree that it's not so obvious for lisp
>| programs.
>
> it might help to understand where the line is drawn to remember that Lisp
> source code is lists in memory, not character strings in files, such as C
> code is. the processing and interpretation of character strings into
> in-memory representation of the various types of objects in Lisp is
> performed by the READ function. since this function has completed it
> task before any of the (other?) language-analysis functions get to work
> on the code, I'd say the syntactic properties of the character string
> representation (which is normally what syntax is understood to be) are
> taken care of by READ.
>
> in non-Lisp languages, READ rarely exists, even in the compiler. C, for
> instance, has several _processes_ that go into the syntactical parsing,
> like preprocessing, and then there's the unenviable `typedef' which
> affects the table of keywords (another "syntax" concept Lisp does not
> have to deal with), and it is fairly hard to represent C code in memory
> at any stage of this process in such a way that it can be written out and
> still look like it did to begin with. I'd say that the line is very
> fuzzy in C, whereas at least one line can be drawn very clearly in Lisp.
I seem to remember richard stallman explaining how he tried to implement
the optimizing gcc: he used techniques he learned from lisp compilers
and uses internally a node structure similar to those found in lisp
compilers (the ADT probably), just to be able to do some high-level
abstraction and optimization.
This is from the gcc man page:
"RTL Representation
Most of the work of the compiler is done on an intermediate
representation called register transfer language. In this language, the
instructions to be output are described, pretty much one by one, in an
algebraic form that describes what the instruction does.
RTL is inspired by Lisp lists. It has both an internal form, made up of
structures that point at other structures, and a textual form that is
used in the machine description and in printed debugging dumps. The
textual form uses nested parentheses to indicate the pointers in the
internal form."
This is from his stockholm speech were he talked about the gnu history
and such
http://www.fsf.org/philosophy/stallman-kth.html
about gcc:
"but it was clear to me I had to rewrite it entirely to get the speed I
wanted, so I have rewritten it to use list
structure representations for all these expressions. Things like this:
(set (reg 2)
(+ (reg 2)
(int 4)))
This looks like Lisp, but the semantics of these are not quite LISP,
because each symbol here is one recognized specially. There's a
particular fixed set of these symbols that is defined, all the ones you
need. And each one has a particular pattern of types of arguments, for
example: ``reg''
always has an integer, because registers are numbered, but ``+'' takes
two subexpressions, and so on. And with each of these expressions is
also a data type which says essentially whether it's fixed or floating
and how many bytes long it is. It could be extended to handle other
things too if you needed to.
---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Jacques Duthen <··············@sncf.fr> writes:
> I think the lisp syntax Blake refers to is:
>
> left parenthesis
> function name
> arguments
> right parenthesis
>
> which applies to any instruction, whether it's a variable
> declaration, a function definition, an addition, etc.
> and the same syntax also applies recursively to the arguments.
This isn't exactly true (even in the syntactically-simpler scheme): a
more accurate description would be:
Lists are formed as:
open paren
element
element
...
and optionally: . tail-of-list
close paren
Then lists are interpreted by evaluating the first element; if you get
a syntax object, feed it the list; otherwise evaluate the rest of the
list elements, then pass them as arguments to the funciton.
This covers everything, including lets, defines, and functions
returning functions. It leaves out special reader gizmos to allow
(eg) infix syntax.
> Note that this is _syntax_. The semantics may impose
> restrictions: the first argument of `defun' _must_ be a symbol
> otherwise you get a runtime error (wrong type argument), just
> like the args of the standard `+' function have to be numbers,
> not strings, nor symbols, nor lists, or the arg of `sqrt' has
> to be a positive number, etc.
> This is imposed by the semantics of the function, not the
> syntax of the language.
The list notation (and its universality) make things like code
generation much easier. Some humans have trouble getting used to it,
but at least it's uniform...
Andrew
········@csclub.uwaterloo.ca
While I agree with most of Blake's conclusions, there were some details
which I do feel could give someone the wrong idea.
Some of these issues are introduced briefly by subject under the "What
is Lisp?" section of the ALU web-site. See
http://www.elwood.com/alu/table/lisp.htm
In particular, there is a page of references to some "classic" language
comparisons which are worth looking at by anyone trying to summarize
what they like or don't like about Lisp vs. some other language. See
http://www.elwood.com/alu/table/compare.htm
(If the ALU had its PC working, and a volunteer to do the work, we could
have coordinated CL-HTTP discussion threads on these issues....)