Newsgroups: comp.lang.lisp,gnu.emacs.help
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!dircon!rheged!simon
From: simon@rheged.dircon.co.uk (Simon Brooke)
Subject: Commenting LisP (was: emacs handling of commented parantheses)
In-Reply-To: wgd@zurich.ai.mit.edu's message of 26 Sep 94 07:00:14
Message-ID: <Cwr3wB.5oz@rheged.dircon.co.uk>
Organization: none. Disorganization: total.
References: <35q8tn$m10@Times.Stanford.EDU> <WGD.94Sep26070014@martigny.ai.mit.edu>
Date: Mon, 26 Sep 1994 19:09:46 GMT
Lines: 77
Xref: glinda.oz.cs.cmu.edu comp.lang.lisp:14845 gnu.emacs.help:23498

In article <WGD.94Sep26070014@martigny.ai.mit.edu> wgd@zurich.ai.mit.edu (William G. Dubuque) writes:

     From: vahe@sparcy.Stanford.EDU (Vahe Y. Avedissian)
     Date: 21 Sep 1994 21:34:47 GMT

     I've noticed that  our gnu emacs and also 
     Lucid's emacs seem to get confused with
     balancing parantheses when unbalanced
     parantheses occur in comment lines.

	...detail excised...

   I suspect your problem is due to the inability of the GNU Emacs
   parsing primitives to scan backwards correctly when there are
   characters with nontrivial syntax embedded in single-line comments.
   You can usually correct these problems by prepending a backslash to
   the commented-out paren or double-quote character that is being
   misinterpreted. Following is a related bug-report I filed which you
   may find helpful.

	... headers excised, what follows shortened ...

   In GNU Emacs 19.25.1 of Fri Jun  3 1994 on kleph (hppa1.1-hp-hpux9)

   'C-M-U' (backward-up-list) within the following string incorrectly
   moves to the start of the defun. 

   (defun foo () ; "
      )
   (progn "Bug: a C-M-U within this string goes to start of foo's def")

   Note that the lemacs (but not emacs) Info node on "Lists" says:

    "In Lisp and other languages where comments run until the end of a
    line, it is very difficult to ignore comments when parsing backwards;
    therefore, in such languages the sexp commands treat the text of
    comments as if it were code."

This raises an old but serious problem about the status of comments in
LisP. Common LISP (and indeed most modern LisPs) are quite clear about
this: comments exist in the source file, not in core.

The problem with this position is that if you load some code, and then
edit it in core, you don't see the comments; and if you subsequently
write the code out again, the comments are lost. The InterLISP
solution was to use a macro for comments, and that of course solved
the in-core editing problem. It raised a different problem, however;
because commetns existed in the code, they had to be handled by both
the evaluator and the compiler, and the value of the comment macro was
NIL. Consequently, the compiler might warn 'Value of comment used?',
and that was a warning worth heading. This notion of a comment with a
value is obviously a hack. It obviously didn't cause too much trouble,
because no-one ever bothered to fix it; and it should not be beyond
the wit of man to devise an interpreter which recognised and hopped
over the comment macro, or a compiler which stripped it out before
compiling. 

Richard Barbour's Procyon CL had an alternative solution, also a hack
in a way, but a more elegant one. This was to modify the reader so
that on reading commented defuns, etc, it would set up the function
with the uncommented code in the proper Common LISP manner, but would
store (as I remember it) a list of comments with their positions on a
property of the printname of the function. Then when the in-core
editor was invoked, the comments were retrieved and shown in the
editor.

The problem of backwards parsing clearly doen't arise in an in-core
editor, because you have the actual structure to work on.



-- 
    .::;====r==\              simon@rheged.dircon.co.uk (Simon Brooke)
   /  /____||___\____         
  //==\-   ||-  |  /__\(      MS Windows IS an operating environment.
 //____\___||___|_//  \|:     C++ IS an object oriented programming language. 
   \__/ ~~~~~~~~~~ \__/       Citroen 2cv6 IS a four door family saloon.
