🚀 go-pugleaf

While it's true that one can use indentation to replace grouping, i
think this is quite dangerous.  Many programs feel free to change the
spacing in a program.  emacs will often convert between tabs and
spaces.  some implementations of cpp converts tabs to spaces.

unix make pays attention to whitespace, and it is one of the
"features" most regretted by the designers.

i don't think the fact that it can be turned off helps, one could
still receive someone else's code that uses it, and then you're hosed.

it's just plain gross.

just my $1/50
--

			IBM
Scott Draves		Intel
spot@cs.cmu.edu		Microsoft

In article <SPOT.91Jan18074828@WOOZLE.GRAPHICS.CS.CMU.EDU>, spot@CS.CMU.EDU (Scott Draves) writes:

> While it's true that one can use indentation to replace grouping, i
> think this is quite dangerous.  Many programs feel free to change the
> spacing in a program.  emacs will often convert between tabs and
> spaces.  some implementations of cpp converts tabs to spaces.

One has to distinguish between the off-side rule and the use of indentation
for grouping.  The off-side rule is, from what I can see, a potential
source of petty little disasters.  On the other hand, using identation as
the delimiter for grouping is IMHO *the right thing to do* in block 
structured languages.

The standard practice of using begin/end delimiters, coupled with using
indentation (standard programming practice) violates the single control
point principle.  It is a regular source of annoying little bugs, the
"dangling else" being the most notorious example.

The argument that many programs change spacing is not to the point;
programs that change source code text in an unspecified language using
arbitrary assumptions are, to put it mildly, not of professional quality.

> i don't think the fact that it can be turned off helps, one could
> still receive someone else's code that uses it, and then you're hosed.

This is actually a good point.  Language features which can be "turned
on or off, according to one's taste are bad features.  One of the most
notorious abuses of cpp is to use macros to make C to look like some
other language.

> it's just plain gross.

May I suggest in turn that the Algol tradition of treating programs as
streams of text to be processed by machines, rather than as text to be
read and written by programmers is a fundamental conceptual error.   It
is my impression that a reaction such "it's just plain gross" is just
another variant of "This is the way I learned to do it, so it must be
the only way to do it."  No doubt this is unfair on my part, so accept
my apologies in advance.  However, having worked with languages that
used begin/end and cousins and with languages that used indentation for
block structure, I can say I find the latter much more natural, once
one overcomes one's initial habits.
-- 
Richard Harter, Software Maintenance and Development Systems, Inc.
Net address: jjmhome!smds!rh Phone: 508-369-7398 
US Mail: SMDS Inc., PO Box 555, Concord MA 01742
This sentence no verb.  This sentence short.  This signature done.

aipdc@castle.ed.ac.uk (Paul Crowley) writes:

>I am both attracted to and repelled from the off-side rule - it provides
>potential both for more readable code and for horrendously intractable
>bugs.

>My question is: why not write the _language_ so that white space is not
>significant (except as a separator) but write a _filter_ which turns
>"off-side" code into "non-off-side" code.  That way, people who don't
>like the rule never have to think about it - foreign code can be pushed
>through the filter and then edited.

>A filter the other way might be nice but wouldn't be essential.

>...

>\/ o\ Paul Crowley aipdc@uk.ac.ed.castle
>/\__/ Trust me, I know what I'm doing.


Yes I agree with this _filter_ idea. My honours project in 1989 was
looking at initial Haskell specifications and included implementing
the formatting rules in a pre-processor / filter which inserted
brackets { } and semi-colons where appropriate. The modified source
was then given to the compiler.

In fact, the specification of the layout rule in the Haskell report is
actually specified as a translation on source code.

Having the pre-processor as a seperate entity allows any source code
to be processed before distribution to remove any possibility of
ambiguity.

-- 
Patrick Sansom                      | E-Mail:    sansom@cs.glasgow.ac.uk
Computing Science Research Student  | 
University of Glasgow               |

In article <SPOT.91Jan18074828@WOOZLE.GRAPHICS.CS.CMU.EDU> spot@CS.CMU.EDU (Scott Draves) writes:
>
>While it's true that one can use indentation to replace grouping, i
>think this is quite dangerous.  Many programs feel free to change the
>spacing in a program.  emacs will often convert between tabs and
>spaces.  some implementations of cpp converts tabs to spaces.

I really don't see this as a problem.  All the compiler has to do is to
convert tabs back to spaces before applying the off-side rule.  Many
compilers do this anyway to generate error messages that contain the
position of the erroneous character(s).  The fact that Miranda apparently
doesn't do this is to my mind a design error in Miranda.

Of course things get more complicated if people set tabs at different
intervals than the standard every 8th position.  But this can be dealt
with, for example by a special declaration to declare tab settings.

--
 Dave Berry, LFCS, Edinburgh Uni.      db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk

"The Berlin Wall; the border between East and West Germany.  It's very narrow."
"*Was* very narrow.  Get your tenses right."	-- Douglas Adams, THHGTTG.

It seems that in focussing on abstract syntax, folks designing lazy functional
programming languages like Miranda and Haskell have pretty much ignored 
concrete syntax. I have heard the comment - "who cares about concrete syntax ?
parsing is a problem of the 60s and 70s." Personally, I think that this is
a rather callous approach since it pays little or no attention to the 
usability of the language. Attitudes like this result in anachronisms like
the "off-side rule"  and white-space significance hanging around long
after the rest of the world has gone on.

Great deal of attention has been paid to ensuring that the semantics of these 
languages is rigorously specified and "clean". I would expect that a fraction
of this rigor and cleanliness would carry over to the specification of syntax.
....


anurag

>All this to save a few characters?

The point, I think, is not save a few characters,
but to save a few lines (and saving lines is useful,
because it allows you to get more of a program
on the screen).

Consider C indentation rules:
	if (test) {
	    statement1;
	    statement2;
	}

Note the final line. This is needed for the final delimiter,
but contains no useful information. It wastes cathode rays/paper.
It puts extra white space in a useless and ugly place.

You could use a Lisp-style of formatting, where the final
delimiter is on the last "real" line:
	if (test) {
	    statement1;
	    statement2;}
But now the last statement is different from the other(s),
which is esthetically ugly and makes updating error-prone.

I find it hard to take seriously people's concerns about
tabs. A program with tabs whose intervals are not every
8th character is already non-portable (it will look a mess
when viewed on a normal system), and it is in any case
an easy problem to fix in your editor, in your
communication software, or with an explicit filter.

So, I believe it may be reasonable to make syntactic use of
indentation. The specifics of Haskell's particular off-side
rule is a different issue. I suggest that the rule
should be relative indentation of lines, not syntatic units.
That is, I would prefer something like:
	if (test)
	    statement1
	    statement2
instead of:
	if (test) statement1
	          statement2
-- 
	--Per Bothner
bothner@cs.wisc.edu Computer Sciences Dept, U. of Wisconsin-Madison

I think the people arguing for significant use of whitespace have good
intentions, but they're a little misguided.  Basically i think they're solving
a problem that doesn't exist.

In C the syntax of statements and blocks is so simple, i can state it in less
than a line: a statement ends with `;', and `{' and `}' delimit blocks.  I've
been using C for a long time and i have a number of gripes about the language,
but this is not one of them.  The syntax is simple and easy to use.

Because of the simple syntax, editing C code is easy.  You can cut and paste
arbitrary blocks, without having to adjust the indentation if you don't feel
like it.  A neat property is that you can hit M-q (fill-paragraph) in Emacs,
and the code may become very hard to read but it still works fine.

In English the rule is simple: sentences end in `.' and questions end in `?'.
You could propose a scheme where periods are optional at the end of a line,
and add some way to indicate that a sentence continues to the next line.  But
if someone did this, people would laugh at him.  Why fix what isn't broken?

Also there is the issue of readability.  Some people claim that the form
without a semicolon `looks better'.  This is clearly a matter of taste, and it
probably depends on whether you're used to reading pseudo-code or C code.  I
actually like the other form better.  If you use a normal indenting style,
it's true that the semicolon is redundant, but a little redundancy can make it
easier to read.

In FLs we have a number of schemes which make use of whitespace.  But what do
you gain from this?  What it comes down to is that you can avoid typing a
semicolon or braces in some cases.  But these schemes are more complicated
than those they replace.  Some languages say that you can use a semicolon to
separate statements, but that it's optional in certain cases depending on
surrounding whitespace.  By the time you have rules like this, the elegance
has been lost, and you have to wonder if it wouldn't be easier to just always
put the semicolon.

Just my 2pf worth in the offside-rule/concrete-syntax discussion:

Since concrete-syntax and parsing are "solved problems" :-)
I am attempting to formally prove properties about a scanner and
parser for a subset of OCCAM, a language using the offside rule.

You would not believe the amount of effort needed to prove that the
simple algorithm of counting spaces works properly! The problem is
always in "going back", i.e. reducing the indentation level. One must
prove that the algorithm doesn't go back past 0, etc. This property
makes the algorithm "non-compositional" : you can take 2 properly
indented pieces of code that are syntactically legal, and after
concatenating them get an indented piece of code that is not legal.

The continuation algorithm for occam is unpleasant : one may only
use a new line after a binary operator (because we know that something
else must be coming...) or after certain keywords, and the indentation
can be *more* but not less that the previous line. 

Comments have to be indented at least as much as the *following* line,
and what do you do with blank lines and tab characters and on and on.

For the folks that feel this is context-free for a fixed k : have you
ever written out the LR(80) tables for such a grammar? Theoretically,
one can write a nice van Wijngaarden grammar (aka two-level grammar) that
has an infinite number of members of the token class "level parenthesis",
but unfortunately I have found no efficient way of transforming such
a grammar into code except by LL methods. 

As others have said: why on earth would one introduce so much muck
just to save a keystroke? Belonging to the Ann-Landers-School of
if-you-turned-it-on-turn-it-off-if-you-opened-it-shut-it, I like
the clarity of proper begins and ends. But then I am just a Lisp
hacker which explains a lot.

Debbie Weber-Wulff
FU Berlin
weberwu@fubinf.uucp

For all of those who've been saying that programming languages such as
Miranda and occam, where leading whitespace is used in place of begin..end
are difficult to implement, not context free, beyond the capability of
lex and yacc, a crime against nature, etc...

You might want to ftp to watserv1.uwaterloo.edu, and pick up the occam
compiler there which uses lex and yacc, and see for yourself how really
*trivial* it is to implement this feature!

--
--Bill Kinnersley