Pick up a good book for learning. Here they use Paul Graham's ANSI common
lisp.

Finally, visit http://www.elwoodcorp.com/alu/

Marcel K Haesok <Hae...@earthlink.net> writes:

 (1)  All forms in Lisp return a value.  That means that the language
      doesn't draw a distinction between expressions and statements.
      Effectively it means that all forms are expressions.

      This simple difference actually has a profound effect on the style
      of programming, since it means that there is a lot more nested
      structure to Lisp programs and fewer variables.

      One other consequence is that Lisp on needs a single conditional
      form IF rather than having both statement "if ... then ... else"
      and expression  "... ? ... : ..." forms.

 (2)  The object model in CLOS is very much different from many other OO
      languages.  In CLOS, objects encapsulate data only, not data and
      behavior.

      Generic functions are used to organize behavior.  Methods do not
      belong to classes, but rather to generic functions.

      What this means is that all methods with the same name should do
      roughly the same operation, but on arguments of different types.
      It would be bad style to have radically different methods share
      the same name (and coincidentally the same argument list).

Finally, I would suggest that you read your book next to the computer,
so you can try things out as you go along.  The interpreter in Lisp
systems makes this very easy and should speed up the learning process.

        (setf x (with-open-file (in "myfile" ...)
                   (read in)))

where WITH-OPEN-FILE is something that expands to a `block' which
establishes a local variable IN, which in CL might be (this is
oversimplified):

        (setf x (let ((in (open "myfile" ...)))
                  (prog1 (read in)
                         (close in))))

Whereas in C I would find this extraordinarily hard:

        x = WITH_OPEN_FILE(in, ..., read_file(in));

translates as:

        x = { FILE *in = fopen(...);
              read_file(in);
            };

But this is not legal, because blocks are not expressions in C, and it
*cannot be made legal* without converting it to something where the
`in' variable is pushed up to a higher scope, so you lose.

The ability to have code which reasons about code -- `macros' in
Lisp-speak -- is one of the defining charactersitics of Lisp, and, for
me, makes Lisp-family languages an extraordinarily good environment
for thinking about computational problems.

        (DISPLAY thing medium)

needs to depend both on the sort of thing (a postscript drawing or
something), and the medium (paper, screen).

But multiple-dispatch makes it very hard to see behaviour as
`attached' to an object, or to regard methods as responses to
`messages' sent to objects.  So CLOS doesn't do that. Some previous
Lisp Object systems (old flavors) did.

One of the problems with CLOS is that many of the cultures that have
grown up around OO programming are based in a less rich model (single
dispatch, often single-inheritance, and simpler in other ways too),
and then *fail to distinguish* between tricks required because their
model is too poor, and fundamental issues.  A good example of this are
some design patterns (not all), which are really irrelevant in CLOS.

  even (VALUES)?  sorry, I had to.

(foo) => no values

The original context was refering to the use of a "result" in some
context.
Every Lisp expression returns a result that can be used, and the rules
are always the same:

  If the thing which receives the result is not doing anything with it,
the result
     is ignored.
  If the thing which receives the result is passing the result on, then
it is
     passed on without further manipulation.
  If the thing which receives the result is doing a variable or
parameter
     assignment, then the first value is used.  If there are no values,
the
     "result" used instead is NIL.
  If the thing which receives the result is manipulating multiple values
somehown,
     then it does what it does.

But in the spirit of bit twiddling, I will claim that the (VALUES) form
must in some sense have a value if needed by the caller, since otherwise
it should be an error to write:

   (if (values) 'true 'false)

and the result of

   (list (values) 1 (values) 2)

should not be

   (NIL 1 NIL 2)

  well, I think high-level overviews that contradict detailed technical
  specs are destructive and that if we cannot express ourselves save by
  contradicting the specifics, we do not have a consistent language to
  begin with, and high-level overviews should not be attempted.  the task
  must be to find the appropriate way to express language characteristics
  that hold true no matter how deep we dig into the specifics.

  a new-comer needs to understand that there is no syntactic concept of a
  "statement" in the Algol sense in Lisp.  while it is true that Lisp forms
  return values, I think the important difference between Algol and Lisp in
  this regard is that there is no restriction on where a form can be used,
  syntactically.  (there are a number of semantic restrictions, of course.)
  this lack of restriction leads to the _conclusion_ that Lisp has been
  designed with a concern that forms should return useful values, even if
  they are intended for side effects, and that not using such values is not
  an error -- the form will still be fully evaluated.

  the important distinction is between languages that drive an artificial
  wedge between "statements" and "expressions" and languages that do not:
  the Algol family (including Scheme) does feature this artificial wedge,
  while the Lisp family (excluding Scheme) does not.

1. Remember that BLISS, definitely a member of the Algol family (IMHO),
   was also quite explicitly an "expression language". Every control form
   in BLISS (including loops) could deliver a value that could be used
   in any value-requiring place -- *including* the "left-hand side" of
   an assignment operator (which requires a pointer object value).
   Example legal (to the extent that I remember it correctly) BLISS:

        // for brevity, assume w.l.g. that a match will always be found
        search: begin
                local table_structure p = table_head;
                while .p[NEXT] neq EOL_MARKER
                do if some_predicate(.p[ELEMENT])
                   then leave search with p
                   else p = .p[NEXT]
                   fi
                elihw
                end [ELEMENT] = .foo; // foo contains new value for the table

   (By the way, the value of a BLISS loop that terminates "normally"
   [without a "return" or "exit" or "leave"] was explicitly defined to
   be "-1". Often not terribly useful, but *defined*, so you could
   depend on it for a post-loop test.)

2. I strongly disagree with your assessment of Scheme in this respect.
   To me, it quite clearly falls on the "everything has a value" side
   of the line, at least as much as CL. True, for some forms the standard
   says the values are "not specified" (e.g., "set!"), but *some* value
   is required to be delivered. E.g., the following is quite legal Scheme:

        > (define foo 1)
        > (define bar 2)
        > (set! foo (set! bar 3))

   Now, exactly *what* the value of "foo" is at this point is quite
   implementation-dependent (as it is allowed to be by R5RS), but it
   definitely *has* a value. [In Elk, it's "2", the previous value of
   "bar"; in MzScheme, it's the "#<void>" object; in SCM, it's the
   "#<unspecified>" object (hah! talk about an oxymoron!).]

   I'd be interested to hear what in Scheme causes you to toss it
   so cavalierly into the non-expression-language camp.

-Rob

  the stuff you just mentioned about the value of side-effecting forms, and
  SET!, in particular.  saying that it returns a value is like saying that
  an unbound slot in a class instance has a value.  clearly, these forms
  are not intended to be used for their value, and the language is quite
  explicit in that respect.  had the language defined SET! to return the
  new value of the object that got it, and DEFINE to return either the
  symbol or the object, I would have had a much weaker case.  as it stands,
  however, Scheme does proper homage to the Algol tradition, to which it
  was dedicated, at least as of R4Rs.  (I personally think it's a serious
  mistake to try to marry Algol to Lisp, and Scheme is the bastard that
  came out of it, but this is not something I thought before I studied
  Scheme, it's a conclusion after watching the horrible messes people who
  like Scheme willingly get themselves into.)

  BTW, if Scheme had had a _value_ that could be compared with the result
  of SET!, things would also look very different.

In my education, I was routinely taught lies or simplifications
(depending on how charitable you are toward the teacher).  When I
learned math as a child in school, I was taught a number was
1,2,3,...,9.  Later I was taught about 2-digit numbers.  Later I was
taught about 0.  And later about negative numbers.  Always these were
"whole world" views, but they omitted stuff.  At some point I even
asked if the set they were teaching was complete, and probably someone
told me it was or that there was "only this one more thing".  Like
reals in place of rationals (failing to mention complexes), and so on.

Would I have learned math better if someone had started with a full
theory of complexes, or with the right terms but just lots of missing
elements conspicuously waiting for years to be filled in?  Maybe.
Maybe not.  Were my teachers incompetent or liars for deciding to omit
information?  I don't really think so.  Most of my classmates, I'm
pretty sure, would have done even worth with a tell-all approach,
honest though it might have been.

I think it's great to create a theory of teaching that is monotonic and
to push it as far as you can with whomever you can get it to resonate
with.  But I'm quite sure from my experience with students that it is
not for everyone, and so I repeat myself for the n-thousandth time in
saying that there is no "good" or "bad" absent a context.  Teaching
is always done in a context, and often in a context particular to the
student or the instructor's estimation of a student.  Probably it would
be good if we all knew when someone asked a question whether they were
of the Erik school or the Russ school ... but often we don't know.
So we make guesses about what people will like, and as often as not we're
wrong.

It's probably why half the time people say you, Erik, are a very
interesting guy to listen to and the other half of the time people get
all up in arms about how the perceive some problem with you.  It's not
as simple as either group just being just right or just wrong--we're a
pluralistic group with different preferences not only technically but
in how we receive technical information.  When that aligns, we are happy;
when it doesn't, we are sad.  Or so, at least, I perceive... FWIW.

That's easy, (length (list (set! x 1))) ==> 1

Minor quibble: The value in (most) Scheme(s) of set!/define/(if #f #f) is
*not* the same as an "unbound slot", or at least, *not* the same as an
unbound variable in Scheme. The "unspecified value" is (must be?) a real
first-class value that can be stored in an object, passed as a parameter,
tested against, and (very unlike an "unbound variable") does *not* cause
a error when referenced. [Whether that behavior is *useful* or not is a
different issue.] It's just that the type and semantics of that value
aren't defined by the standard, nor is every legal "statement-like" form
or sub-form required to produce the *same* value (that why it's called
"unspecified"). Some implementations do; some don't.

+---------------
|   BTW, if Scheme had had a _value_ that could be compared with the result
|   of SET!, things would also look very different.
+---------------

As I said, most implementations do have such a value[*], but it's not
usefully standard or portable [although I have occasionally used it to
pretty-up my own specialized REPLs, usually just to suppress the printing
of that value], so your point is well taken.

+---------------
| had the language defined ... DEFINE to return either the symbol or the
| object, I would have had a much weaker case.
+---------------

Actually, for DEFINE your case for "statement"-ness is extremely *strong*,
since according to my reading of the standard, there's no syntactic way
to place a top-level Scheme "define" in a place where its value (if it
had one) could be captured without turning it into an "internal define",
which is syntactic sugar for a completely different construct (a "letrec").

[That said, all of MzScheme/SCM/Elk *do* allow (define foo (define bar 1)),
which actually seems a bit weird even to me!]

-Rob

[*] Most readers will probably want to ignore this...

For MzScheme, the built-in procedures "void" and "void?" give you
access to the "magic value" returned by "define", "set!", "display",
and the one-legged "if", that is, (if #f #f), and so on:

        (void) ==> #<void>
        (void? (void)) ==> #t
        (eq? (void) (set! foo 'whatever)) ==> #t
        (void? (if #f #f)) ==> #t
and:
        (define foo (define bar 1))
        bar ==> 1
        foo ==> #<void>

but:    (void? (define foo (define bar 1))) ==>
        define-values: illegal use (not at top-level)
        in: (#%define-values (foo) (define bar 1))

For SCM, the following definitions can be used to get similar behavior
(it prints as "#<unspecified>" instead of "#<void>"):

        (define (void) (if #f #f))
        (define (void? x) (eq? x (void)))

but this works:

        (void? (define foo (define bar 1))) ==> #t
        bar ==> 1
        foo ==> #<unspecified>

For Elk, the value of "set!" is the previous value of the variable being
set, but even though that's "well-defined" (for Elk), it's *not* a constant
(it sounded like that might matter to you). Worse, the other usual suspects
all return *different* magic values:

        (display 'whatever) ==> [the symbol (string->symbol "")]
        (void? (string->symbol "")) ==> #t
        (if #f #f) ==> ()    ; so (void? (if #f #f)) ==> #f

  Kent, I think you're overreacting.  my issue is only with having a
  one-shot high-level overview of something finite and fully knowable that
  is _contradicted_ by fact, not about how successive approximations to a
  complete understanding of something would work, especially not as used in
  a situation where the teacher can control the real or apparent confusions
  when moving from one approximation to the next.

  I'm concerned that you appear to think that explaining a simple principle
  in the design of Common Lisp (no statement/expression dichotomy) cannot
  be done simply _and_ correctly, however.  yet I'm not sure that's really
  what you wanted to say.

  when I study something, I want to know what motivated those who figured
  it out, not only whatever somebody thinks would motivate me to use it.
  if I understand the former, I can perhaps find a better way, combining
  what I know from other motivations, and do something fun and cool.  if I
  only learn the latter, the best I can hope for is using existing tools,
  and how fun is that?

 (1) Use an ambiguous expression and hope the person doesn't know
     you're being vague until you have a chance to explain.  (This is
     what I'm trying to do, btw.)
 (2) Use a truthful expression that forces you to indulge a presentation
     order that might not be of your choosing.
 (3) Lie, and fix the lie later.  (A modified version of this is to "color"
     the lie in a way that explains you are doing it, and then repair the
     lie later; I've experimented with this "explicit lying", too.)

It is frustrating how dependent teaching is on "order" because it seems
like it should be enough to concentrate on a compositional set of concepts.
It's hard enough to get a good set of concepts, which I think is why you're
frustrated--if you are not minding the order, and willing to hold it all
in your head until the "why" makes sense, then any additional info just
makes it more painful.  This is why a programming language that has explicit
"forward referencing" notations is more painful than one that does not.
We'd like to believe that the compiler would just wait and figure things
out at the right time, but presentation order affects the amount of
intermediate storage required.  If you're willing to allocate more
intermediate storage, you can do a more intelligent/brief presentation.

I hate to keep referring to personality but I do believe that
personality is often a hint of something computational, just as a
program can often be debugged by its output, and I have to believe
that your personality (both your temper and your apparent quick mastry
of large issues like SGML and CL) suggest that you are either willing
or able to hold more in your head at once than some other people are.
This, I think, explains (at least partially) your difference in taste
for presentation order/style.

I'm only trying to open conversational space enough to admit that you
are not necessarily right, but I'm not saying you are definitely wrong
in this case.  I really do think there are two points of view active
here, and that you are correctly identifying an issue that might have
been neglected, but I also think your statement of that fact doesn't
necessarily (within context of the particular student) mean that a bad
choice was made--only that a bad choice might have been made.

I've actually appreciated the opportunity to think through the issues
in this explicit way because it gives me some concrete food for
thought in how to present my book and to better inform the reader to
take the information more smoothly.

I am with Rob et al that Scheme doesn't syntactically
distinguish between expressions and statements, but
rather underspecifies what some expressions ought to
return.  For better or worse, the Scheme standard (at
least some of whose authors seem to have trafficked
heavily in "bottom" values) considers
underspecification to be quite all right.  (Another
famous example of Scheme's willing underspecification
is the order of evaluation of procedure arguments.)
Sure, this drives some people nuts, but it shouldn't be
miscategorized as something else.

What I ended up doing is lying but saying right up front that some
things would not be quite strictly true, and often saying `that was a
lie' when I said something.

The real problem with (2) with the `all forms return a value' and
order is that not only can forms return no or many values, they can
fail to return, and not just in cases where an error has happened:

        (block foo
          (setf y (return-from foo 3)))

Obviously that is a trivial case, but there are plenty of cases like
that that are *not* trivial.  For instance I often use a trick of
passing and then calling a (downward) closure around that effectively
does a (return-from myblock ...) as a way of doing what CATCH and
THROW do except knowing exactly which block I am returning from.