Newsgroups: | comp.compilers |
From: | J.C.Highfield@loughborough.ac.uk |
Keywords: | design, Occam |
Organization: | Loughborough University, UK. |
References: | 95-04-013 95-04-186 |
Date: | Sun, 30 Apr 1995 12:24:50 GMT |
scooter@mccabe.mccabe.com (Scott Stanchfield) writes:
>>[use indentation rather than { } to show block structure ]
>
>Although I kind of agree, I think we run into _lots_ of trouble when different
>editors use different tab stops, and different people use different tabs
>in their style, and people use "expand" with a different tabstop than they
>should.
Occam uses two spaces as a unit of indentation, and uses the
indentation to show the block structure. This gets around the
problem of differing tab sizes.
Using indentation instead of block start and finish markers
seems to cut down the amount of incorrectly structured program
particularly for novices, but all that indentation can make the
programs very hard to read on a small screen unless you have some
technique of handling the extreme program 'width'. Printing out
the program also suffers these problems.
Occam programming systems usually get around this with folding
editors, where a 'fold' contains code which inherits the indentation
of the fold. When you enter a fold you see the code it contains
starting in column 1. This is works OK for programming. However, I
have never seen a good solution for printing out these programs. You
either print them out as a 'flat' file, where all the folds are
expanded and so the text runs off the right side of the page (or
wraps around) or you use a fancy fold-aware listing program that
prints out the contents of the folds after the code containing them -
equivalent in some ways to printing functions after the code that
calls them but in my experience much harder to read.
I like Occam and folding editors, but I don't think I will be
encouraging the use of significant indentation in major programming
languages until I see a good way of handling the printout problem.
Julian
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.