I'm a newbie to LISP and all the languages I've at least been exposed to in
the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
the order they are presented, without second thought. Not so with LISP, as
I painfully discovered!
For example, here's a snippet of code (unfortunately, I'm doing this for a
school assignment and must not post the whole thing):
(defvar a (car input2))
(defvar b (cdr input2))
(defvar c a)
(if (not (eq input1 b))
... blah blah ....
)
Here, it complains that "b" is unbounded at the if-statement. Had LISP
executed these statements in order, "b" would already be defined once the
if-statement is reached, but this doesn't seem to be the case.
Does anyone know of some sort of a guide that specifically addresses this
problem? All the books and newbie tutorials I've encountered made no
mention of it. Perhaps it's an inherent flaw in my C and Java style of
thinking and trying to apply it to LISP.
"Fringe" <·········@fdaddsfdsa-HotMail-dfsad.com> writes:
> [...]
> (defvar a (car input2))
> (defvar b (cdr input2))
> (defvar c a)
> (if (not (eq input1 b))
> ... blah blah ....
> )
>
> Here, it complains that "b" is unbounded at the if-statement. [...]
By the way, is this at the top level, or inside some form (e.g. a
function definition)? DEFVAR should be used at the top level [1].
A LET or LET* form is used for local variables, e.g. for the above:
(let ((a (car input2))
(b (cdr input2))
(c a))
(if (not (eq input1 b)) ...) ...)
and in the above, INPUT1 or INPUT1 might be unbound, but certainly
not A, B, or C.
Even if you cannot post the whole code, you should post the exact
error message you received (and whether it occurred during
compilation or execution), and, as others have asked, which kind of
Lisp, implementation and version you are using.
[1] Using DEFVAR not at the top level is not illegal, but there are
a number of differences from top-level use (that are out of scope
for this thread) and non-top-level use is rarely appropriate. In
any case, DEFVAR is _not_ for introducing local variables. (While
in C, Java, and many other languages a local variable declaration
may be syntactically the same as a global variable declaration,
taken out of context.)
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Matthew Danish
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <87isasheac.fsf@mapcar.org>
Matthew Danish <··········@cmu.edu> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>> (let ((a (car input2))
>> (b (cdr input2))
>> (c a))
>> (if (not (eq input1 b)) ...) ...)
>
> (LET* ((a (car input2))
> (b (cdr input2))
> (c a))
> (if (not (eq input1 b)) ...) ...)
>
> Otherwise binding C to A won't work.
Thanks for the correction, and sorry about the typo. (I did mean to
write LET*, otherwise I wouldn't have mentioned it on the line
before...)
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Pascal Costanza
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <chekr3$t64$1@newsreader2.netcologne.de>
Fringe wrote:
> I'm a newbie to LISP and all the languages I've at least been exposed to in
> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> the order they are presented, without second thought. Not so with LISP, as
> I painfully discovered!
No, there seems to be something else going wrong. At least in Common
Lisp, evaluation order is always from top to bottom and from left to
right, at least in the general case. (This may be different for macros,
but that's a different issue.)
> For example, here's a snippet of code (unfortunately, I'm doing this for a
> school assignment and must not post the whole thing):
>
> (defvar a (car input2))
> (defvar b (cdr input2))
> (defvar c a)
> (if (not (eq input1 b))
> ... blah blah ....
> )
>
> Here, it complains that "b" is unbounded at the if-statement. Had LISP
> executed these statements in order, "b" would already be defined once the
> if-statement is reached, but this doesn't seem to be the case.
You seem to have found a way to evaluate / execute one expression at a
time, and you seem to try to evaluate the if expression without having
executed the rest of the source code above first. Check out whether
there is an "evaluate buffer" command that you can use instead. Or else,
copy and paste all the expressions into the listener one by one from top
to bottom. "Evaluate buffer" is the better idea, however.
If this doesn't help, please let us know what Lisp dialect you use, what
Lisp implementation and what development environment. If you use Emacs,
let us also know what mode you use. Then it's easier to help you.
BTW, the LISP spelling (all upper case letters) is pretty old fashioned.
Pascal
--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."
Pascal Costanza <········@web.de> writes:
> Fringe wrote:
>
> > I'm a newbie to LISP and all the languages I've at least been exposed to in
> > the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> > the order they are presented, without second thought. Not so with LISP, as
> > I painfully discovered!
>
> If this doesn't help, please let us know what Lisp dialect you use,
> what Lisp implementation and what development environment. If you use
> Emacs, let us also know what mode you use. Then it's easier to help
> you.
When you cut-and-paste several sexps in ilisp REPL, only the sexps
starting on the first line are taken into account. Use slime,
evaluate the sexps one at a time, or encapsulate them in a PROGN:
[25]> (print :a) (print :b)
(print :c)
:A
:A
[26]>
:B
:B
[27]> (progn
(print :a) (print :b)
(print :c))
:A
:B
:C
:C
[29]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
From: Joel Ray Holveck
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <y7cn002aeq9.fsf@sindri.juniper.net>
> When you cut-and-paste several sexps in ilisp REPL, only the sexps
> starting on the first line are taken into account. Use slime,
> evaluate the sexps one at a time, or encapsulate them in a PROGN:
I don't have that problem. I regularly paste several sexps at a
time. Here, I pasted two sexps with C-y and then pressed RET.
Clearly, the repl read both:
* (+ 1 1)
(+ 2 2)
2
*
4
*
This is using CMUCL 18d, GNU Emacs 21.3, ilisp 5.11.1.
Am I missing something you said?
Cheers,
joelh
Joel Ray Holveck <·····@juniper.net> writes:
> > When you cut-and-paste several sexps in ilisp REPL, only the sexps
> > starting on the first line are taken into account. Use slime,
> > evaluate the sexps one at a time, or encapsulate them in a PROGN:
>
> I don't have that problem. I regularly paste several sexps at a
> time. Here, I pasted two sexps with C-y and then pressed RET.
> Clearly, the repl read both:
>
> * (+ 1 1)
> (+ 2 2)
> 2
> *
> 4
> *
>
> This is using CMUCL 18d, GNU Emacs 21.3, ilisp 5.11.1.
>
> Am I missing something you said?
>
> Cheers,
> joelh
I definitely get (and always have got) the behavior I described (and
copy-pasted) with clisp-2.33.2 (and olders), emacs 21.3.1, and
ilisp-20021222.
[40]> (print :a) (print :b)
(print :c)
(print :d)
:A
:A
[41]>
:B
:B
[42]>
But I confirm that with cmucl, it works as for you. The problem is the
interaction between ilisp and clisp (slime does it right with clisp).
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we.
From: Marco Baringer
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <m2zn45c8c5.fsf@bese.it>
"Fringe" <·········@fdaddsfdsa-HotMail-dfsad.com> writes:
> I'm a newbie to LISP and all the languages I've at least been exposed to in
> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> the order they are presented, without second thought. Not so with LISP, as
> I painfully discovered!
from section 3.1.2.1.2.3 of the hyperspec, assuming you're talking
about function evaluation:
--------------------
The subforms in the cdr of the original form are evaluated in
left-to-right order in the current lexical and dynamic
environments. The primary value of each such evaluation becomes an
argument to the named function; any additional values returned by the
subforms are discarded.
--------------------
all of section 3.1.2.1 would make for an interesting read.
of course the order in which forms are presented may not be the same
as the compiler sees them. read time conditionalization, eval-when,
macros, special operators and just opening a file in emacs and
randomly using C-M-x may change this.
> Here, it complains that "b" is unbounded at the if-statement. Had LISP
> executed these statements in order, "b" would already be defined once the
> if-statement is reached, but this doesn't seem to be the case.
the problem is elswhere.
CL-USER> (defvar input1 1)
INPUT1
CL-USER> (defvar input2 '(1 2))
INPUT2
CL-USER> (defvar a (car input2))
A
CL-USER> (defvar b (cdr input2))
B
CL-USER> (defvar c a)
C
CL-USER> (if (not (eq input1 b)) t nil)
T
CL-USER>
what implementation are you using?
--
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
-Leonard Cohen
"Fringe" <·········@fdaddsfdsa-HotMail-dfsad.com> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
> I'm a newbie to LISP and all the languages I've at least been exposed to in
> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> the order they are presented, without second thought.
That is not true of these languages. For example, in C, the full
expressions A, B, C, and D in the following statement are evaluted in
the order A, B, D, C:
for (A; B; C) { D }
Moreover, within a full expression, C has undefined and unspecified
evaluation orders. The following is quite nonportable:
int i = 0;
printf("%d %d %d %d", i++, i++, i++, i++);
Assembly languages are not sequenced either. It depends on the
processor. Instructions can be issued and completed out of order, and
it may be up to the programmer to resolve any conflicts that may
occur! Some processors may also execute a few instructions that follow
a branch, even if the branch is taken!
Sorry, I can't take you seriously enough to address the rest of your
posting.
In article <····························@posting.google.com>,
···@ashi.footprints.net (Kaz Kylheku) wrote:
> "Fringe" <·········@fdaddsfdsa-HotMail-dfsad.com> wrote in message
> news:<·····················@newssvr29.news.prodigy.com>...
> > I'm a newbie to LISP and all the languages I've at least been exposed to in
> > the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> > the order they are presented, without second thought.
>
> That is not true of these languages. For example, in C, the full
> expressions A, B, C, and D in the following statement are evaluted in
> the order A, B, D, C:
>
> for (A; B; C) { D }
The OP said "statements", not "expressions". A, B, and C are
expressions, not statements (actually, I think A might be something
else, because it can also contain a variable declaration with its
initializer).
>
> Moreover, within a full expression, C has undefined and unspecified
> evaluation orders. The following is quite nonportable:
>
> int i = 0;
>
> printf("%d %d %d %d", i++, i++, i++, i++);
Again, these are expressions, not statements.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
On 6 Sep 2004 13:12:46 -0700, ···@ashi.footprints.net (Kaz Kylheku)
wrote:
>That is not true of these languages. For example, in C, the full
>expressions A, B, C, and D in the following statement are evaluted in
>the order A, B, D, C:
>
> for (A; B; C) { D }
Only "B" is an expression - "A", "C" and "D" are, in fact,
statements.
"for ( A; B; C ) { D }" is notational shorthand for
A;
while ( B )
{
D;
C;
}
"for" was just a preprocessor macro in early "C" compilers.
>Moreover, within a full expression, C has undefined and unspecified
>evaluation orders.
>
> The following is quite nonportable:
>
> int i = 0;
> printf("%d %d %d %d", i++, i++, i++, i++);
You are confusing "expression" evaluation with "argument" evaluation.
Argument evaluation order is left unspecified, however expression
evalution order is completely specified.
If an expression consists of multiple subexpressions separated by
commas, the subexpressions are evaluated in order, left to right, and
the result of the last subexpression becomes the result of the
expression.
Each argument to a function is, itself, a complete expression. A
function call is an expression but the arguments are *not*
subexpressions.
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> [...]
> expression evalution order is completely specified
This needs to be qualified, because otherwise it at least appears to
include the evaluation order of f(x) and g(y) in (f(x) + g(y)),
which is unspecified, unlike the evaluation order of (F X) and (G Y)
in (+ (F X) (G Y)), where (F X) is evaluated before (G Y).
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
On Wed, 08 Sep 2004 22:03:08 -0400, Vassil Nikolov
<········@poboxes.com> wrote:
>George Neuner <·········@comcast.net> writes:
>
>> [...]
>> expression evalution order is completely specified
>
>
> This needs to be qualified, because otherwise it at least appears to
> include the evaluation order of f(x) and g(y) in (f(x) + g(y)),
> which is unspecified, unlike the evaluation order of (F X) and (G Y)
> in (+ (F X) (G Y)), where (F X) is evaluated before (G Y).
>
Reading it again, I realize I did word that more strongly than I
probably should have. OTOH, one could argue that when the language
standard deliberately says something is unspecified, that itself *is*
a specification 8-)
The langauge semantics are important: (f(x) + g(y)) is merely an
expression in "C" whereas (+ (F X) (GY)) is a composition of functions
in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
specified - you can't depend on (F X) happening before (G Y) unless
you sequence with let. [ anyway what you wrote looks like Lisp ...
if it's some other language which does specify argument order then you
can ignore the comments about Lisp ]
Anyway, with respect to comma separation - in "C" the comma performs
two different functions depending on context:
1) within an expression, the comma sequences evaluation of
subexpressions, and
2) within a function call, the comma separates the argument
expressions.
In "C" you can write something like:
int f( int x )
{
printf( "F " );
return x + 1;
}
int g( int y )
{
printf( "G "
return y + 2;
}
void main ( void )
{
int q, r;
q = (r = f(1),g(2));
printf( "r=%d q=%d\n", r, q );
q = (g(2),r = f(1));
printf( "r=%d q=%d\n", r, q );
}
which when executed prints "F G r=2 q=4" and "G F r=2 q=2".
With respect to expressions in general: a "C" compiler may evaluate
subexpressions in any order unless the intended order of evaluation is
specified by parenthesation or sequenced by the comma operator which
forces left to right evaluation. The compiler may evaluate arguments
to a function in any order.
George
--
for email reply remove "/" from address
On Thu, 09 Sep 2004 13:06:56 -0400, George Neuner
<·········@comcast.net> wrote:
>The langauge semantics are important: (f(x) + g(y)) is merely an
>expression in "C" whereas (+ (F X) (GY)) is a composition of functions
>in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
>specified - you can't depend on (F X) happening before (G Y) unless
>you sequence with let. [ anyway what you wrote looks like Lisp ...
>if it's some other language which does specify argument order then you
>can ignore the comments about Lisp ]
Forgot where I was reading this 8-)
George
--
for email reply remove "/" from address
George Neuner <·········@comcast.net> writes:
> On Thu, 09 Sep 2004 13:06:56 -0400, George Neuner
> <·········@comcast.net> wrote:
>
>>The langauge semantics are important: (f(x) + g(y)) is merely an
>>expression in "C" whereas (+ (F X) (GY)) is a composition of functions
>>in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
>>specified - you can't depend on (F X) happening before (G Y) unless
>>you sequence with let. [ anyway what you wrote looks like Lisp ...
>>if it's some other language which does specify argument order then you
>>can ignore the comments about Lisp ]
Well, in CL (+ (f x) (g y)) actually evaluates (f x) before (g
y). Guaranteed. And that's a feature.
George Neuner <·········@comcast.net> writes:
> [...]
> The langauge semantics are important: (f(x) + g(y)) is merely an
> expression in "C" whereas (+ (F X) (GY)) is a composition of functions
> in Lisp.
On a tangent, I suppose you mean that in C, + is a built-in
operator, while in (Common) Lisp, it is "just" a function? I am not
sure that the difference in practice is really that big, since the
compiler of any reasonable Common Lisp implementation is going to
treat most calls to + specially. (Well, yes, this is rather fuzzy:
how big is "that big", which implementations are "unreasonable", and
how many are "most calls", but I believe there is a way to make a
more precise (and much longer) statement in support of the analogy
between (f(x) + g(y)) and (+ (F X) (G Y))).
Besides, and perhaps more importantly, the evaluation order is
completely specified for all of Common Lisp's standard special
forms and macros, not just for the function calls.
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
On Thu, 09 Sep 2004 20:46:57 -0400, Vassil Nikolov
<········@poboxes.com> wrote:
>George Neuner <·········@comcast.net> writes:
>> [...]
>> The langauge semantics are important: (f(x) + g(y)) is merely an
>> expression in "C" whereas (+ (F X) (GY)) is a composition of functions
>> in Lisp.
>
> On a tangent, I suppose you mean that in C, + is a built-in
> operator, while in (Common) Lisp, it is "just" a function? I am not
> sure that the difference in practice is really that big, since the
> compiler of any reasonable Common Lisp implementation is going to
> treat most calls to + specially. (Well, yes, this is rather fuzzy:
> how big is "that big", which implementations are "unreasonable", and
> how many are "most calls", but I believe there is a way to make a
> more precise (and much longer) statement in support of the analogy
> between (f(x) + g(y)) and (+ (F X) (G Y))).
I was actually thinking more about the first class nature of functions
in Lisp. Lisp's built-in functions, from the programmer's
perspective, are no different than user written functions. "C"
doesn't allow references to it's built-in operators, therefore there
is no way to describe their function prototypes, and hence no way to
pass them as arguments or to reference them in data structures. It
may be trivial to wrap them in a user function, but it lacks the
roundness of APPLY.
> Besides, and perhaps more importantly, the evaluation order is
> completely specified for all of Common Lisp's standard special
> forms and macros, not just for the function calls.
Yes. Another message provided the hyperspec cite. Thanks for the
correction.
George
--
for email reply remove "/" from address
> > Besides, and perhaps more importantly, the evaluation order is
> > completely specified for all of Common Lisp's standard special
> > forms and macros, not just for the function calls.
>
> Yes. Another message provided the hyperspec cite. Thanks for the
> correction.
Note, however, that "completely specified" doesn't mean the
evaluation order is completely specified. See for example
http://www.lisp.org/HyperSpec/Issues/iss171-writeup.html
Will
··········@verizon.net (William D Clinger) writes:
>> [Vassil Nikolov wrote:]
>> > Besides, and perhaps more importantly, the evaluation order is
>> > completely specified for all of Common Lisp's standard special
>> > forms and macros, not just for the function calls.
>> [...]
> Note, however, that "completely specified" doesn't mean the
> evaluation order is completely specified. See for example
> http://www.lisp.org/HyperSpec/Issues/iss171-writeup.html
I stand corrected, thanks. Only a weaker statement applies, that
Common Lisp leaves considerably fewer cases than C in which the
evaluation order is not specified...
---Vassil.
--
Vassil Nikolov <········@poboxes.com>
Hollerith's Law of Docstrings: Everything can be summarized in 72 bytes.
From: Reini Urban
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <4153307a@e-post.inode.at>
William D Clinger schrieb:
>>> Besides, and perhaps more importantly, the evaluation order is
>>> completely specified for all of Common Lisp's standard special
>>> forms and macros, not just for the function calls.
>>
>>Yes. Another message provided the hyperspec cite. Thanks for the
>>correction.
>
> Note, however, that "completely specified" doesn't mean the
> evaluation order is completely specified. See for example
> http://www.lisp.org/HyperSpec/Issues/iss171-writeup.html
i.e: funcall as arg0: (arg0 arg1 arg2...) or ((arg0) arg1 arg2)
True. That really hit me once when changing my lisp.
Any one (beta-version) lisp also treated it differently
between compiled and interpreted code.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/
From: Alexey Dejneka
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <m3zn3zmjhc.fsf@comail.ru>
Hello,
George Neuner <·········@comcast.net> writes:
> (+ (F X) (GY)) is a composition of functions
> in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
> specified - you can't depend on (F X) happening before (G Y) unless
> you sequence with let.
In ANSI Common Lisp you can.
CLHS 3.1.2.1.2.3 "Function Forms" says:
> The subforms in the cdr of the original form are evaluated in
> left-to-right order
--
Regards,
Alexey Dejneka
"Alas, the spheres of truth are less transparent than those of
illusion." -- L.E.J. Brouwer
From: Paul Dietz
Subject: Re: How does LISP decide the order to evaluate consecutivestatements?
Date:
Message-ID: <4140A3D5.E84E7BB8@motorola.com>
Alexey Dejneka wrote:
> George Neuner <·········@comcast.net> writes:
>
> > (+ (F X) (GY)) is a composition of functions
> > in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
> > specified - you can't depend on (F X) happening before (G Y) unless
> > you sequence with let.
>
> In ANSI Common Lisp you can.
>
> CLHS 3.1.2.1.2.3 "Function Forms" says:
>
> > The subforms in the cdr of the original form are evaluated in
> > left-to-right order
This determinism is a *really good thing* in a language design, IMO.
It makes porting software between different implementations easier.
It also simplifies random testing of the language implementations.
Paul
On 09 Sep 2004 21:37:35 +0400, Alexey Dejneka <········@comail.ru>
wrote:
>Hello,
>
>George Neuner <·········@comcast.net> writes:
>
>> (+ (F X) (GY)) is a composition of functions
>> in Lisp. Also, IIRC, in Lisp, the order of argument evaluation is not
>> specified - you can't depend on (F X) happening before (G Y) unless
>> you sequence with let.
>
>In ANSI Common Lisp you can.
>
>CLHS 3.1.2.1.2.3 "Function Forms" says:
>
>> The subforms in the cdr of the original form are evaluated in
>> left-to-right order
Thanks for the correction. My Lisp is somewhat outdated as I like
Scheme better.
George
--
for email reply remove "/" from address
"Fringe" <·········@fdaddsfdsa-HotMail-dfsad.com> wrote in message news:<·····················@newssvr29.news.prodigy.com>...
> I'm a newbie to LISP and all the languages I've at least been exposed to in
> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> the order they are presented, without second thought. Not so with LISP, as
> I painfully discovered!
A few people have pointed out that CL also executes statements in the
order they are presented, and pointed out that you have probably
accidentally evaluated a form without having already evaluated forms
that appear above this form in the buffer you're working in.
I remember that this sort of thing was a real problem for me when I
first learned CL- I was using Poplog, which is in some ways a kind of
difficult development environment, at least compared to modern CL
systems, but these kinds of problems can happen in any CL environment-
in practice they don't, much, once you are used to programming in a
highly interactive language.
The thing to remember is that CL isn't as file oriented as C (given
the normal C compile-run model)- it is instead oriented toward the
state of the running system. This is actually one of the real
strengths of CL- you can redefine things on the fly while your system
is running- but it takes some adjusting to, and requires some
discipline.
If you find some of the responses to your post intemperate... well,
you should understand that a lot of people have very strange ideas
about Lisp, and frequently pull them out (from whence is left as an
exercise) as criticisms of the language, and Clers are thus pretty
sensitive on this subject. These ideas, I think, mostly arise because
people make snap judgements, based on previous experience with
languages that are very unlike CL- when you say "Not so with LISP, as
I painfully discovered!" you are guaranteed to raise some hackles. You
might do better to phrase that as a question.
I have a theory about the weird prejudice that exists toward Lisp, and
it is even structurally similar to your question :). The order in
which people learn programming languages is really important to their
preferences in programming languages. Most programmers learn C-like
languages as their first "serious" languages. This entails a great
deal of pain (along with a great deal of satisfaction, once they have
learned well enough to accomplish things). They then tend to forget
how painful the initial learning process was (forgetfulness of pain
seems like a necessary trait for living in the world- otherwise we'd
just huddle in our houses in fear, and of course the childbirth rate
would drop well below replacement rate).
So when people are forced to learn a new language that is really
different from C, they react very badly to having to reexperience the
pain of being novices. Having experienced that pain once (and having
largely forgotten how painful it actually was the first time) they are
very resentful of having to experience it again, particularly since
they are already capable of writing working programs in another
language, without having to experience the pain of adapting to
something new.
As evidence for the above I'll note the amount of complaining that
there is about the CL package system, and existing system definition
facilities. I remember having to figure out Imake at one point-
there's a joke that goes "There's actually only one Imake file in
existence, which has been copied and modified by everyone who needs to
use IMake"- well, it's not a very funny joke, but that was my
experience with Imake- and make is not much better.
I think you'll find, once you have adjusted to it, that CL is
remarkable for its expressive power, and is remarkably sensible and
well specified. When you see something that makes no sense (like
statements being evaluated in an order other than that in which they
are presented), assume, at least until you have some experience with
the language, that the problem probably lies with some assumption that
you have made about the language (likely based on your experiences
with other languages) that does not hold.
Marvin Minsky said: "anyone could learn Lisp in 1 day, except that if
they already knew Fortran, it would take 3 days."
--
Tagore Smith
On 2004-09-05 04:35:01 -0400, "Fringe"
<·········@fdaddsfdsa-HotMail-dfsad.com> said:
> I'm a newbie to LISP and all the languages I've at least been exposed to in
> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
> the order they are presented, without second thought. Not so with LISP, as
> I painfully discovered!
>
> For example, here's a snippet of code (unfortunately, I'm doing this for a
> school assignment and must not post the whole thing):
>
> (defvar a (car input2))
> (defvar b (cdr input2))
> (defvar c a)
> (if (not (eq input1 b))
> ... blah blah ....
> )
>
> Here, it complains that "b" is unbounded at the if-statement. Had LISP
> executed these statements in order, "b" would already be defined once the
> if-statement is reached, but this doesn't seem to be the case.
>
> Does anyone know of some sort of a guide that specifically addresses this
> problem? All the books and newbie tutorials I've encountered made no
> mention of it. Perhaps it's an inherent flaw in my C and Java style of
> thinking and trying to apply it to LISP.
I suspect you really wanted to write something like:
(let* ((a (car input2))
(b (cdr input2))
(c a))
(if (not (eq input1 b)) ... ))
LET and LET* are probably the most common ways of declaring a variable.
DEFVAR creates a 'special' variable, and you *probably* wanted garden
variety variables.
From: Reini Urban
Subject: Re: How does LISP decide the order to evaluate consecutive statements?
Date:
Message-ID: <41488b87$1@e-post.inode.at>
Will Fitzgerald schrieb:
> On 2004-09-05 04:35:01 -0400, "Fringe"
> <·········@fdaddsfdsa-HotMail-dfsad.com> said:
>
>> I'm a newbie to LISP and all the languages I've at least been exposed
>> to in
>> the past (C, Java, Assembly, BASIC, Perl, etc.) all execute statements in
>> the order they are presented, without second thought. Not so with
>> LISP, as
>> I painfully discovered!
>>
>> For example, here's a snippet of code (unfortunately, I'm doing this
>> for a
>> school assignment and must not post the whole thing):
>>
>> (defvar a (car input2))
>> (defvar b (cdr input2))
>> (defvar c a)
>> (if (not (eq input1 b))
>> ... blah blah ....
>> )
>>
>> Here, it complains that "b" is unbounded at the if-statement. Had LISP
>> executed these statements in order, "b" would already be defined once the
>> if-statement is reached, but this doesn't seem to be the case.
>>
>> Does anyone know of some sort of a guide that specifically addresses this
>> problem? All the books and newbie tutorials I've encountered made no
>> mention of it. Perhaps it's an inherent flaw in my C and Java style of
>> thinking and trying to apply it to LISP.
>
>
> I suspect you really wanted to write something like:
>
> (let* ((a (car input2))
> (b (cdr input2))
> (c a))
> (if (not (eq input1 b)) ... ))
>
> LET and LET* are probably the most common ways of declaring a variable.
> DEFVAR creates a 'special' variable, and you *probably* wanted garden
> variety variables.
And when we are already, here we have to explain to him, that
LET assigns its variables not in the natural order, instead it assigns
its variables in parallel.
LET* is the sequential counterpart (which is a just a nested orgy of LET)
So
(let ((a (car input2))
(b (cdr input2))
(c a))
...)
will require a global a,
and a, b, and c are assigned in parallel (on an ideal machine at least).
There are a couple of other special forms and macros which evaluate
their args in different order. left-to-right most of the time, but some
don't evaluate their args, and some stop in the middle, dependent on an
arg value. for example IF, COND, OR or AND.
And some parallel extensions to lisp evaluate all their args in parallel.
But I never heard of right-to-left evaluation as a stack based
calculator can be interpreted.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/