Re: Use of punctuation in a language?

"Glen Herrmannsfeldt" <>
2 Nov 2003 14:47:59 -0500

          From comp.compilers

Related articles
Use of punctuation in a language? (Herbert) (2003-10-31)
Re: Use of punctuation in a language? (Derk Gwen) (2003-11-01)
Re: Use of punctuation in a language? (MattR) (2003-11-01)
Re: Use of punctuation in a language? (Glen Herrmannsfeldt) (2003-11-02)
Re: Use of punctuation in a language? (Joachim Durchholz) (2003-11-08)
Re: Use of punctuation in a language? (Robert A Duff) (2003-11-08)
Re: Use of punctuation in a language? (Ray Dillinger) (2003-11-11)
Re: Use of punctuation in a language? (James Cownie) (2003-11-11)
Re: Use of punctuation in a language? (Doug Landauer) (2003-11-11)
Re: Use of punctuation in a language? (Martin Ward) (2003-11-11)
[4 later articles]
| List of all articles for this month |

From: "Glen Herrmannsfeldt" <>
Newsgroups: comp.compilers
Date: 2 Nov 2003 14:47:59 -0500
Organization: Comcast Online
References: 03-10-129
Keywords: syntax, design
Posted-Date: 02 Nov 2003 14:47:59 EST

"Herbert" <> wrote in message
> Does anyone have any comments on the use of punctucation is a
> language, eg, compare the following two approaches?

> a = 3.4; b = 6.7;

> or

> a = 3.4 b = 6.7

> which is better, ease of reading for humans, issues regarding design
> of compilers (eg the punctuation-less version requires
> look-ahead?). Perhaps lack of punctuation is a bad language design?

It depends on what you mean by punctuation. Statement ending markers,
either explicit such as semicolon, or implicit end of line, are
certainly convenient both for the compiler and human reader. If you
compare languages with and without reserved words, you notice some of
the important parts of constructing a language.

Note that using the C preprocessor you could write programs using only
alphanumeric characters and white space, though with the addition of
some reserved words.

Both Fortran and PL/I have no reserved words, and depend on
punctuation and other language features keep some constructions from
being ambiguous. It is not hard to write programs that can be very
confusing to a human in either language. To make it even worse, blank
space is not significant in Fortran, except inside character string

There is a contest where the goal is to make the most obfuscated C
program, as C has a number of features that are pretty good at doing
just that.

> Any advice or comments would be gratefully received, I haven't seen
> anything in the books one this, so was wondering what others
> thought? We're designing a simple language for the exchange of
> models in molecular biology, we have an XML based one, but know we'd
> like a human readable one.

The problems in a data description language are somewhat different
than in a programming language, though maybe your models are related
to programs. With human readable as a goal, I would consider which
punctuation makes it more, or less, human readable. I would consider
the ease of writing a parser for it a secondary goal, though usually
the are related.

> [ Having used languages in which any string of characters is a valid
> program, I can report that I vastly prefer languages with punctuation
> because they make it harder to write a program that is syntactically
> valid but doesn't mean what I wanted it to. It's a little easier for
> compilers to parse languages with statement separators and explicit
> brackets, but I don't find that anywhere near as compelling as the
> human factors involved. -John]

Having a statement end punctuation at least allows the compiler to
limit the effects of errors somewhat.

It is nice to have programs that are one character away from a correct
program not be syntactically valid. There is a famous example from
Fortran 66, the assignment statement:

            DO 1 I=1.2

Replacing a comma in a DO statement with a period turns a valid DO
statement into a valid assignment statement.

A statement that I often use in AWK has slightly interesting punctuation:

while( getline < file > 0) {

The < operator is normally the less than operator, but as a getline option,
it specifies the file to read. The return value of getline is then tested
as the loop condition. Confusing or not depends on the person reading it.

-- glen

Post a followup to this message

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