gaynor@porthos.rutgers.edu (Silver) (03/17/89)
I summarize heavily; please ignore minor misinterpretations, and correct major
ones if necessary. This is my second attempt at posting this message. The
first time, one of two things happened: either I mailed it to one of you by
mistake, or the posting failed silently (lemme know if you got it in the mail,
ok?). Yes, I'm pretty pissed off.
ACG = gaynor@rutgers.edu (myself)
VIC = vic@zen.uucp
JLG = jlg@lanl.gov
GVC = gvcormack@watdragon.waterloo.edu
FLS = seeger@poe.ufnet.ufl.edu
ELG = elg@killer.dallas.tx.us
RIC = holt@turing.toronto.edu
ETC = explicitly terminated comments
ITC = implicitly terminated comments
NETC = nesting ETC
NNETC = non-nesting ETC
_______________________________________________________________________________
ACG> [Not-improbable scenario flaming the originator of NNETCs.]
VIC> [If you don't like the language, don't flame the authors, ...]
Why not? We're the ones that are stuck using them! Although designers are not
_obligated_ to keep people happy, they'd better if they want their language to
be successful. Besides, there's the ol' freedom of speech gig. And I can
justify my position better than the opposing ones, I think. Besides their
utility (which is addressed later), there's a little point of internal
consistency which is not maintained.
Virtually all structured programming constructs are recursively defined in
almost all languages. That is, structured constructs nest. ETCs connote a
structured construct: an opening string, body text, and a closing string.
Yet they (commonly) do not nest, even though most other constructs do. So,
they are an inconsistency that one must note and conscientiously heed
whenever used.
VIC> [... write your own.]
Sounds like fun, I just might at that.
ACG> [NNETCs introduce bugs (implicitly, moreso than NETCs).]
VIC> People have problems in any language that they do not understand/
comprehend, that's why there a lot of people who are able to make money
teaching others how to program.
Huh? Are you trying to justify poor language design (specifically, hard to
understand or use) by the work it will provide for our teaching peers? Like
the field isn't tough enough without intentionally mucking up the medium of
expression? (Give an author a roll of wet toilet paper and a razor sharp #3
Dixon Ticonderoga to write with.) I must have misinterpreted you (so I didn't
summarize, for safety).
JLG> [Beginners have learning problems, but everybody has usage problems. The
issue is to reduce both of these sets of problems.]
Agreed. I think it's a complexity vs. utility trade-off, and the scales are
tough to balance. And each individual has their own set of scales.
VIC> [I program in C, and don't have any comment problems.]
Neither do I, mostly. But, as recent postings demonstrate, it is very easy to
make a mistake with ETCs that result in `correct' code. Also, I'm sure you
make use of the preprocessor just as heavily as I do. Imagine commenting out
the portions of code that you would otherwise #if into /dev/null. Now, upon
success, uncomment the same code.
JLG> [Note that C++ provides both NNETCs and ITCs. However, I doubt new
language designers would want ETCs, considering that they are somewhat
more difficult to use safely.]
GVC> [Given today's sophisticated text editors, do we even need ETCs?]
ELG> [ETCs are more flexible than ITCs, and some of us want that flexibility.]
RIC> [Note that ITCs nest...]
ITCs are great for commenting `the code to the left' - much more convenient
than ETCs in this respect. Most will agree that they work equally well with
comment blocks. I've found those that show a prefererence prefer ETCs so that
the entire body remains unsoiled, e.g.,
/*
#@^&*#@$%@
@%^ &$5 @$**3
^&&#^633%$#!!
*/
However, ITCs cannot be used to comment out very large or very small portions
of code _without_disturbing_its_structure_. Despite a smart editor (I'm a
religious GNU Emacs user/programmer), often I simply do not want to disturb my
code or its format. Also, how about commenting `the code to the right'? `the
code in the middle'? Always putting comments to the right makes it easier to
spot them within code, but there are many cases when their visibility is
irrelevent. I would use both if I had both, like Turing (RIC).
GVC> [The predominance of NNETCs over NECTCs are a result of the traditional
modelling of scanners as FSMs. In such a model, it is very difficult to
recognise NNETCs.]
FLS> [Isn't it trivial to hack FSMs into the NNETC mold?]
Yes, but let's not hack the problem into the model, but choose a model more
suited to the problem.
FLS> [What's so hard about using a pure FSM scanner?]
In a nutshell, its in remembering the level of opened comments. Ripping all
the non-essential details out of the problem, try implementing the following
trivial BNF with an FSM or regular expression: group = `(' group `)' | null.
Ok, so I think there are two directions: keep the FSM scanning model, but pass
comment pieces to the parser, which then handles them, or give the FSM a little
memory. Following the former line, to do this within the parser character by
character, this ...
cmt = cmt-open cmt-body cmt-close
cmt-body = null | char-no-braces cmt-body | cmt-body cmt cmt-body
cmt-open = `{', whatever
cmt-close = `'}', whatever
... will handle NETCs, my whole point of complaint. But making sure that this
production is handled (i.e., ignored) everywhere can be kind of hairy if the
definition previously didn't include white (on the assumption that the scanner
eats up white and comments). Otherwise, it would be trivial to tag this onto
white's definition.
The other direction involves souping-up the scanner's engine. Now where's the
ol' dragon book when I want it? I think `pushdown finite state automaton' is
the beast in question. GVC, sounds like you're pretty up on your readings,
care to comment?
Regards, [Ag] gaynor@rutgers.edu