From: rh@smds.com (Richard Harter)
Newsgroups: alt.folklore.computers
Subject: Re: Indentation
Date: 31 Aug 92 09:07:13 GMT
Reply-To: rh@ishmael.UUCP (Richard Harter)
Organization: Software Maintenance & Development Systems, Inc.

In article <Q8E6H9J@math.fu-berlin.de> dww@inf.fu-berlin.de writes:
>sammy@anagld.analytics.com (Sam Blackburn) writes:

>> CODE SHOULD BE WRITTEN TO BE MAINTAINED!

>Amen, Brother!

Debora, you should consider a career as an American politician.  They
all use the same trick -- they stand up and tell us that they're for
all good things for all people and that proves that we should vote for
them and not their opponents.  Fine.  Most everybody agrees that code
should be written to be maintained.  Saying that you are in favor of
maintainability is a no-op; relating your experiences with a particular
compiler for a particular language says only a particular compiler
for a particular language is badly designed.  One has to make a real
case, and you haven't done that.

>In response to the folks that offered the hacks for the lexer:
>sure, it's no problem to write a hack, but what if you want to
>prove your program correct (Arrrrrgh! She used that *word*)? 
>Lexers should be deterministic, finite state automata. DFSA can't
>count, neither can push-down automata. So adding your little hack just
>blows apart all the mathematics you might be able to use in the
>proof of correctness.

I'm sorry, but I don't accept this.  To begin with, one can do proofs
of correctness for programs other than DFSA and push-down automata.
Secondly, it is not true that lexing for scope-by-indentation cannot
be done with a finite state machine.  I can say that because I've
done it -- all you need to do is to establish the indentation white
space as a lexeme.  Scope resolution does not (and should not) be done
in the lexer.  Where and how scope resolution is done depends on the
language grammar.  If the grammar is consistent with scope-by-indentation
scope resolution is a mechanical process and the algorithm for doing so
is provably correct.

>And then there's all the little wierd
>cases that pop up like empty lines and strange ways of doing continuations
>(occam again, to continue a string you do "This is a lovely string, don't*
>* you think?") and just all the pesky stuff that makes life hard for
>you.

I agree; wierd cases make for bad language translators and for bad
programs in the language.  But wierd cases just mean that the language
design is not consistent.

>No folks, elegance is not the only criterion for programming. I'm all
>on the side of maintainence. 

I love my mother too.

>As another argument for proper block markers, it's so comforting to
>use emacs to edit LISP or C or such which jumps back with the
>cursor to the block begin when you type the block end. That not only
>trains the eye, but helps avoid lots of block problems.

This may be your best argument, IMHO.  This is a INWIAUT argument.
[INWIAUT:  An obscure North American Indian tribe.  Also an acronym
for "It's Not What I Am Used To".]  It is legitimate to argue that
the intrinsic merits of a feature, whatever they might be, are
outweighed by the lack of standard tools supporting the feature.

I do wonder though.  Why is it nicer to have a cursor flickering
back and forth than simply seeing the block structure in front of
you?  To my way of thinking blocks that stretch across more than
one page are a pain regardless of how they are delimited -- and
if blocks are within one page I can see them.
-- 
Richard Harter: SMDS Inc.  Net address: rh@smds.com Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742.    Fax: 508-369-8272
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Xref: sparky alt.folklore.computers:13125 alt.religion.computers:565