From ... From: Erik Naggum Subject: Re: Lisp syntax, what about resynchronization? Date: 1999/06/09 Message-ID: <3137929073322259@naggum.no> X-Deja-AN: 487516915 References: <3137888706865673@naggum.no> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Tom Breton | 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