But one usually learns quickly to not forget semicolons (whether at
the end of the line or elsewhere).  Then one goes on to make much
more interesting syntax errors.  The example given in another
article in this thread,

  foo("bar);

at least will likely have the number of that same line in the error
message.  I don't have a good example handy, but it is much more
fun when the reported line number is far off the place where the
problem is (and it does happen).

By the way, even in a language with C's syntax, using Emacs can be
very helpful because the moment you notice the current line does
not indent correctly, you know something is wrong, you don't have
to wait for the compiler to tell you.

---Vassil.

So maybe the problem is with you (or your editor)? You totally ignored
what others have pointed out: you are simply stuck on the first syntax
you happened to learn. you should just relax and do your classwork. Get
back to us after a couple of months (with a good editor) and let us know
what you think.

Right now you are just showing us how close-minded you are.

--

For example if an if-then-else doesn't look like this:

(if test (do-something-to a)
  (do-something-to b))

or like this:

(if test
    (do-something-to a)
  (do-something-to b))

Then the code contains a logical error. Let's introduce an incorrect
parenthesis while we type:

(if test (do-something-to a))    <--hit return here
(do-something-to b))

You can see the logical error visually. You don't need to count the
parentheses to see this. And with parenthesis highlighting you would
already have seen that you matched the wrong parenthesis while still in
the top line.

There is one language currently more popular than Lisp that has syntax
where programs cannot even be accurately written on a blank piece of paper
(without drawing a load of vertical lines to make sure all the appropriate
columns match up) Get over the fact that Lisp cannot be written
productively without a suitable editor. I believe you. It can't.

Personally I think Lisp's syntax allows remarkable expressiveness and I
enjoy being able to completely ignore manual indentation.

If a lecturer displays code to the class with mistakes and the
indentation couldn't possibly have been generated by someone typing the
incorrect code within a suitable editor then the examples could give a
false impression about how hard it is to track down errors in Lisp code.

If you are given the source to a broken example try reindenting it and
watch what moves.

Here is a mental model that might help you in the beginning: Think about
natural languages like Japanese, Chinese, Russian or even sign language.
These languages are totally different from English, especially with
regard to "syntax". Yet, they are at least equally effective for
communication, in some circumstances even more effective. Of course,
their "syntax" makes it a little harder to learn them, but would you
dismiss those languages only because of the "syntax"?

Pascal

Vassil Nikolov  <vniko...@poboxes.com> wrote:

... foo(...)
{
        ... {
                ... {
                        /* Deeply nested in some function */
                        if (foo) /* See, I've forgotten a '{' */
                                bar;
                                baz;
                                blah;
                        }
                        blaz;
                }
        }

And tools like paren-matching (:set showmatch in vim, that magic
paren highlighting thing in emacs, ...) help for C like syntaxes, too.

  Well, at least you are aware of your handicap.

| Now this, regardless of what you all say about how good it is, puts lisp
| behind the eight-ball when it comes to readability.

  Look, if you spent the time you spent complaining about it just working
  with Common Lisp, the problem would go away by itself.  However, since
  you have gone public with your whining, there is a natural psychological
  barrier to growing a clue: It is easy to recognize and fix a mistake made
  in good faith, but it is hard for many people to recognize that they did
  something stupid, and they spend a lot of time and effort defending their
  stupidity so as to make it appear less stupid.  This tends to slow down
  learning.  All good things come later to those who defend everything they
  do.  Successful people make and fix more mistakes than the unsuccessful.

| But like I said, Java never has this problem.

  This would carry more weight if you said you never had any problems with
  Java whatsoever.  So far, it appears that the /only/ problem you have
  with Common Lisp is the parentheses.  That is pretty good, actually.

--
Erik Naggum, Oslo, Norway

However, note that people can only recognize that they have done
something stupid with hindsight.

Pascal

Excerpts from real C header files:

#define FromHex(n) (((n) >= 'A') ? ((n) + 10 - 'A') : ((n) - '0'))
#define StreamFromFOURCC(fcc) ((WORD) ((FromHex(LOBYTE(LOWORD(fcc))) << 4) + (FromHex(HIBYTE(LOWORD(fcc))))))
#define ToHex(n) ((BYTE) (((n) > 9) ? ((n) - 10 + 'A') : ((n) + '0')))
#define MAKEAVICKID(tcc,stream)  MAKELONG((ToHex((stream) & 0x0f) << 8) | (ToHex(((stream) & 0xf0) >> 4)),tcc)

#define va_arg(AP, TYPE)      \
 (AP = (__gnuc_va_list) ((char *) (AP) + __va_rounded_size (TYPE)), \
  *((TYPE *) (void *) ((char *) (AP)     \
         - ((sizeof (TYPE) < __va_rounded_size (char) \
      ? sizeof (TYPE) : __va_rounded_size (TYPE))))))

#define PLAUSIBLE_BLOCK_START_P(addr, offset)    \
((*((format_word *)       \
    (((char *) (addr)) + ((offset) - (sizeof (format_word)))))) == \
   ((BYTE_OFFSET_TO_OFFSET_WORD(offset))))

There is a fundamental tension between ease of debugging and ease of
writing code.  Imagine the space of all possible strings and consider
the subspace of all syntactically correct (well-formed) strings.  If
every syntactically correct string is far away from its nearest
neighbor, then it would be virtually impossible to make a typographic
error that couldn't be easily seen (and possibly corrected by the
computer).  Consider a language in which all numbers needed to be
written out longhand.  You'd virtually eliminate errors that occur
because of a finger hitting the wrong key.  However, such a language
would be quite verbose and difficult to write.

If the semantics were such that nearness in syntactic space lead to
extraordinary distance in semantic space, I imagine that even simple
`braino' errors would be easy to spot.  If `<' meant `compare for less
than' and `>' meant `string upcase', you'd quickly discover those
cases where you meant the former but typed the latter.  On the other
hand, the intellectual burden of using such a language would be much
higher.

  This is a completely vacuous statement.  What are you talking about?

| However, note that people can only recognize that they have done
| something stupid with hindsight.

  They can realize with hindsight that even at the time they did it, it was
  stupid.  If they rebel against this realization by trying to make it not
  stupid at the time, such as by defending themselves, they make matters
  much worse since even this is stupid at the time, to be realized later.

  You seem to make an assumption that people do not do stupid things.  This
  is not so.  The problem is that people do not /think/, and therefore do
  stupid things because they do not pay attention at the time.  To /think/
  is a choice, perhaps the only choice.  Not to think is /really/ stupid,
  but some people respond only with emotions when this is pointed out.

--
Erik Naggum, Oslo, Norway

(defun statement-list ()
  (and (statement) (sl*)))

(defun sl* ()
  (if (match '|;|)
      (or (and (statement) (sl*))  t)
      (error "Expected \";\" on line ~s, but read \"~a\""
                *line-number* *lookahead*)))

where statement is some function that breaks down to parsing assignments and
expressions.

When parsing

b = a/(b+23) * a/b-1);

everything looks all good if you read as far as
b =  a/(b+23) *  a/b  - 1

then you hit the dangling paren instead of the end of a valid statement.
the parser can't just throw in a ;  ... what the programmer actually meant
is ambiguous:

b = a/(b+23) * a/b  -1;    or
b = a/(b+23) * (a/b -1);  or
b = a/(b+23) * a/(b-1); or
b = a/((b+23) * a/b -1);

Wait until I start on my next assignment, then it'll happen all over
again :-)

--
Mel

--
Mel

--
Mel

--
Mel

  Do you admit to being learning-impaired or to think that being learning-
  impaired is a joking matter?  Either is pretty tasteless.  If humor is
  your calling, why are you not interested in joking about the silliness of
  your mistakes and how easily you could have avoided them with a little
  more concentration and dedication to your goal of making each and every
  one of all the mistakes you ever make in your life once and only once?

  Cockroaches can do it.  Pigs can do it.  Even sheep do not repeat their
  mistakes.  Granted, they live much shorter lives, do not vote for George
  W. Bush except in Florida, and their death is usually well planned and
  deemed for a good cause (just as in Texas), which could warp anyone's
  ethics, but I think human beings should learn from their mistakes, too.
  For instance, if I were to visit the USA soon, no doubt some IRS person
  would have read comp.lang.lisp while waiting for the lines to grow long
  enough, and I would regret the mistake of posting anti-Bush materials.
  I can wait for the American people to correct /their/ mistake, but I do
  not have particularly high hopes that the GOP will admit to theirs.  See?
  If people make the same mistake all over again, that sure is no laughing
  matter.  This is really, really serious.  Learn from your mistakes today!

--
Erik Naggum, Oslo, Norway

  But the sad thing is that by being vacuous, he commits the same error.

--
Erik Naggum, Oslo, Norway

Other languages have {, }, [, ], and various other bits of
syntactic aspartame which Lisp doesn't need.   Strictly speaking
Lisp doesn't even have parentheses, except by convention.   (
is just a read macro, which tells the reader that a list of items
follows, which is terminated by ).   So if you don't like those
parentheses, you could always replace them.   But then how would
you represent a list of items?   And in what way is a sequence of
expressions different from a list?

But I have a solution for you.   You complain of Lisp's arcane
syntax, but only of this.   You pine for C's familiar mixture of
parentheses, braces, what have you.   There is a language out
there, very popular it is too, which looks like C but acts more
like Lisp.   It's called JavaScript.   Perhaps you'll find it
more to your liking.

  But it is harder to learn becuase you resist it!  We all know this.  Yes,
  it is not uncommon to resist change.  Lots of dumb people resist changes
  of all kinds, whether they will benefit from them or not, in fact more
  often than not, they resist changes they /will/ benefit greatly from.
  What is so tragic about people who keep insisting that things are hard to
  learn is that saying makes it so.  Have you ever heard of a person who
  admits to thinking "I can'to do this!" over and over until he finally
  succeeded?  No?  I know I have not.  Why not?  What is the #1 advice they
  give to athletes who want to win so badly they are willing to abuse their
  body to the extreme, to experience more pain than they were ever meant to,
  to break every reasonable and rational limit to human performance?  To
  get into the winning mindset.  Not only /can/ they beat the odds against
  them, they /have to/.  Not that I want you to go overboard and ignore the
  finely tuned instructions that are embedded in our finely tuned bodies
  that pain means a mistake, but you should not yield to resistance if you
  want to succeed.  Learning is hard work.  Succeeding is hard work.  If
  you only plan to do what you find easy to do in your life, you /will/ go
  nuts in no time.  Boredom kills people, literally.  Every bored moment of
  your life is an experience of what death is like.  If it is hard to learn,
  that means you have to use your brain and concentrate to succeed.  This
  has "good for you" written all over it.  If Java was easy to learn, you
  would go mad if you were to program in it for real.  As I have said on
  several occasions: Life is too long to be good at C++, meaning that if
  you spent the decade it takes to become good at it, you would have wasted
  the opportunity to be good at something worth being good at, and you
  would have to spend the rest of your miserable life programming in C++.
  Yes, scream.  Now, being good at Java takes the average Joe a good while,
  and he can expect to use it for long enough to both be worth it and to be
  worth more than the alternatives.  But if you found Java easy to learn,
  you are not the average Joe.  Java is not for you.  The only things worth
  becoming good at are things that are hard to learn, but not all things
  that are hard to learn are worth being good at.  The only thing you know
  is that if it is too easy to learn, it is not worth wasting brain time on
  it.  Quit whining about how hard Common Lisp is to learn.  Start whining
  about how easy Java was and how much you hate wasting your time on the
  easy stuff: Yell "BOOORING!" at it and "Gimme something my dog can't do!"

--
Erik Naggum, Oslo, Norway

Prolog > Lisp > Java > C > Assembly language.

C frees you from having to think about register allocation,
Java frees you from having to think about memory allocation
and cleanup, Lisp frees you from having to represent symbols,
or write code which manipulates them, Prolog frees you
from having to write code which does pattern matching or
backtracking.

I never said I didn't like lisp, I'm just sure I like the people who use
it though.

--
Mel