Subject: Re: Lisp syntax, what about resynchronization?
From: Erik Naggum <erik@naggum.no>
Date: 1999/06/09
Newsgroups: comp.lang.lisp
Message-ID: <3137929073322259@naggum.no>

* Tom Breton <tob@world.std.com>
| Which really doesn't address the problem, sorry.

  it seems you're reading awfully fast, but slow down so you get the issues
  that are attempted communicated, OK?

| I've assumed from the start that we were dealing with code that was
| automatically indented.

  but at which level?  there are two major schools, here:  one, which SGML
  adherents tend to belong to, says that at no point in time shall the
  syntactic wellformedness of the total system be in jeopardy, which means
  you cannot at any time perform a task in two steps that causes the whole
  document (SGML) or form (Lisp) between these two steps to break the rules
  of syntax.  this school favors structure editors and completely automatic
  indentation and also storing the document or code in a non-text form when
  they think they can get away with it.  the core principle of this school
  is that structure is "a priori".  the other major school, which you will
  find intrinsic to the Emacs philosophy, is that writing highly structured
  material is a cooperation between user and editing software.  at no point
  in time can there be a guarantee that the structure is complete, but you
  can check for it, and you can cause it to become complete once you detect
  where it is not.  the core principle of this scool is that structure is
  "a posteriori".  I generally tend to be an a posteriori kind of guy, and
  I think a priori kinds of guys pretend to know the unknowable, and since
  you don't listen very well, but assume you already know what I said
  before you actually read it, that rhymes well with the a priori school.

  I assume here that since you drag in the compiler, which is THE WRONG
  PLACE to do this kind of checking and recovery and resynchronization, the
  reasons for which I explained and you did not understand, you want some
  form of cooperation between editor and the human, instead.  that
  cooperation is at its best when it is completed before the compilation
  starts.  less syntactic mess means better cooperation between user and
  editor (Lisp).  more syntactic mess means the compiler is the only tool
  that could ever figure it out (C++).

| Inspecting the indentation does not neccessarily reveal errors.

  I didn't say "inspect", Tom.  what I said was, _when_ you are editing,
  and you are inserting and deleting parenthesis, you will naturally have
  expectations as to what the indentation will be.  that is, if we're still
  assuming that programmers are humans.  you give me the impression that
  you argue in a world where they are not, which rhymes well with my own
  great vision of the future, where computers program people, but this is
  still some ways off, and until then, we have to deal with people typing
  and seeing what they do.  so instead of your silly interpretation of
  inspecting the indentation, I _actually_ said we should watch the
  _changes_ that Emacs makes to the indentation when we reindent code that
  has been changed.  you have obviously never done this, so let me explain
  what it means: suppose you add a binding to a LET form, but you forget to
  close the outermost parenthesis in what you added.  reindent.  watch how
  completely unrelated lines suddenly move.  this is such a fantastically
  simple task most people have to be shown it to understand that it is NOT
  a question of inspecting a _static_ indentation, but of watching Emacs
  make _unexpected_ changes to indentation.  the rule of thumb is: if
  something you don't expect to move, moves, you've made a mistake, and
  undo the indentation immediately, and go fix it.

  however, the interesting point here is that your suggestion does not
  reveal errors in a slightly different, but in principle identical, way to
  what you argue against in my counter-suggestion: the reason is computers
  _still_ don't know the _intention_ of the human programmer, because what
  we look at is a failure to communicate the intent properly in syntax.  in
  the case of SGML (or XML, if you want), that flaw is at the core of the
  braindamaged design: you cannot communicate or even think of structure in
  SGML without knowing it a priori _and_ with full knowledge of the intent
  of the users of that structure.  if you try to do otherwise, you will
  fight structure (or make users fight it), and resort to a posteriori
  means of re-establishing the syntactic structure, when the intent is
  gone.  which is what this silly "resynchronization" proposal is all about.

| Unless you are focussing on which level you intend an expression to be
| in, one level looks very like another.

  no wonder you're seriously confused about this issue to begin with.

| > Lisp's simple, unlabeled, explicit-structure-marking syntax solves all
| > of these problems.
| 
| No, and I explained why.

  I see.  no, you did not explain why, Tom.  you cannot _both_ accuse me of
  not getting your point _and_ tell me you already explained what I bring
  up, which must of necessity be something other than your issues.  this
  only means you are not listening to anyone but yourself.

| I think you did not understand what was proposed if you say that.

  sometimes, one person's brilliant idea is a brilliant person's laugh.

  and in this case, my reason for leaving SGML behind was that the kind of
  silly thing you proposed for Lisp was proposed for SGML about once a
  month by various people who thought they had grokked SGML, but hadn't.
  it finally dawned on me that the complexity of the syntax made this
  almost _necessary_ for SGML, so it had to come up, and one of the least
  productive solutions, XML, won the day.  I was there, at the conference
  table where the first thoughts that became XML surfaced.  a few months
  earlier, I had proposed the need for a special marker for empty elements
  -- and then retracted that proposal because it led to new problems -- but
  guess what survived in XML!  and now we have the same stupid issues that
  caused people to think long and hard and come up with XML come to Lisp
  because John McCarthy made the acute observation that XML is basically
  parentheses with labels on them, but some people didn't get the meaning
  of that: drop the stupid labels in XML.  it was _not_ an invitation to
  add labels or (syntactic) markers to Lisp.

  however, I don't expect anyone to understand this unless they actually
  understand SGML, and very few people do, least of all the people who
  think it's great, so I just wanted to put it in writing in case someone
  gets the message.

  structure only appears a priori evident to people who didn't build it.

#:Erik
-- 
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century