Re: Is the dangling else a syntax bug?

wclodius@aol.com (Wclodius)
30 Jul 2001 01:20:10 -0400

          From comp.compilers

Related articles
[15 earlier articles]
Re: Is the dangling else a syntax bug? jcrens@earthlink.net (Jack Crenshaw) (2001-07-23)
Re: Is the dangling else a syntax bug? marcov@toad.stack.nl (2001-07-23)
Re: Is the dangling else a syntax bug? joachim_d@gmx.de (Joachim Durchholz) (2001-07-23)
Re: Is the dangling else a syntax bug? vbdis@aol.com (2001-07-27)
Re: Is the dangling else a syntax bug? wb@vestein.arb-phys.uni-dortmund.de (2001-07-30)
Re: Is the dangling else a syntax bug? mike@dimmick.demon.co.uk (Mike Dimmick) (2001-07-30)
Re: Is the dangling else a syntax bug? wclodius@aol.com (2001-07-30)
Re: Is the dangling else a syntax bug? joachim_d@gmx.de (Joachim Durchholz) (2001-07-30)
Re: Is the dangling else a syntax bug? marcov@toad.stack.nl (2001-08-02)
Re: Is the dangling else a syntax bug? vbdis@aol.com (2001-08-02)
Re: Is the dangling else a syntax bug? stephen_bevan@yahoo.com (2001-08-06)
| List of all articles for this month |

From: wclodius@aol.com (Wclodius)
Newsgroups: comp.compilers
Date: 30 Jul 2001 01:20:10 -0400
Organization: AOL http://www.aol.com
References: 01-07-153
Keywords: syntax
Posted-Date: 30 Jul 2001 01:20:10 EDT

>"Joachim Durchholz" <joachim_d@gmx.de> schreibt:
>
>>An interesting variation of this is the use of unindentation as "end"
>>marker. This has been done e.g. in Python and Haskell.
>
>Did you ever see source code with a mix of tab and space characters?
>Such text becomes unreadable to both a human and a compiler, when the
>tab size is changed to some user defined value. The whole source code
>then is bound to a specific editor :-(


The solution is easy. Define the language so that indentation using
tabs is illegal. If you want the convenience of automatically
indenting using the tab key, configure the editor so that depressing
the tab key results in the inserstion of an appropriate number of
space characters and not a single tab character. The
compiler/interpreter will then let you know if you have misconfigured
the editor.


If you insist on allowing tabs in the source for the language, tabular
indentation should a language defined mapping in terms of spaces, in
which case it is necessary to configure your tools (editors and
printers) to be consistent with the language. This is reasonably easy
to do on many systems, however, on UNIXs many tools assume a
consistent mapping of tabs to spaces, and changing that assumption
(particularly in printing) can be difficult, so if you insist on
allowing tabs and portability to UNIXs the language defined tabular
mapping should be that used on UNIX. Python has successfully
incorporated tabs using this interpretation.


If you object to configuring your editor just for this purpose, or
that beginners might not be aware of the need to configure the editor,
well tough. We configure the editors for so many other puposes in
editing the language, e.g., syntax highlighting and automatic
indentation even if not necessary that this is just a negligible
increment in that effort. If you object that your editor cannot be
configured to do the above, then either you need to learn more about
your editor or you need a much better editor. In addition, the
language will often provide an IDE with the necessary capabilities.


As to beginners, they make many mistakes with language syntax, but
readilly learn from their mistakes if the language implementation
provides appropriate error messages. Providing appropriate error
messages for the above problems is one of the easier tasks in language
implementation. At least this rule (consistent indentation) in
language design significantly improves legibility, unlike many of the
other decisions in language design.


><snip>
>The use of EOL as a delimiter was discussed in a recent thread, and I
>think that it's not a practical solution. Then at least continuation
>lines must be introduced at the same time, to allow to break long
>lines into multiple shorter lines.


The language designer can use EOL as a delimiter in several different ways


1. Require explicit continuation markers, e.g., Fortran. Test studies
in the 70s indicated that this was less error prone and more legible
for novices than the use of explicit statement terminators such as the
semicolon.


2. Require implicit continuation markers through indentation. This is
tricky, but doable, if indentation is also used to delimit blocks.


3. Allow arbitrarilly long lines. Requires a language sensitive editor to
automatically wrap lines in its display.
><snip>


William B. Clodius


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.