|[16 earlier articles]|
|Re: Is the dangling else a syntax bug? email@example.com (2001-07-23)|
|Re: Is the dangling else a syntax bug? firstname.lastname@example.org (Joachim Durchholz) (2001-07-23)|
|Re: Is the dangling else a syntax bug? email@example.com (2001-07-27)|
|Re: Is the dangling else a syntax bug? firstname.lastname@example.org (2001-07-30)|
|Re: Is the dangling else a syntax bug? email@example.com (Mike Dimmick) (2001-07-30)|
|Re: Is the dangling else a syntax bug? firstname.lastname@example.org (2001-07-30)|
|Re: Is the dangling else a syntax bug? email@example.com (Joachim Durchholz) (2001-07-30)|
|Re: Is the dangling else a syntax bug? firstname.lastname@example.org (2001-08-02)|
|Re: Is the dangling else a syntax bug? email@example.com (2001-08-02)|
|Re: Is the dangling else a syntax bug? firstname.lastname@example.org (2001-08-06)|
|From:||"Joachim Durchholz" <email@example.com>|
|Date:||30 Jul 2001 01:26:03 -0400|
|Posted-Date:||30 Jul 2001 01:26:02 EDT|
VBDis <firstname.lastname@example.org> wrote:
> "Joachim Durchholz" <email@example.com> 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 :-(
Yes. I don't know how the language communities handle this.
In practice, the problem is two problems:
1) The source code becomes unreadable.
2) Ambiguities on the interpretation of tabs.
Problem (1) is a problem for all languages with indentation.
I had problem (2) solved in my own toy language by requiring that two
consecutive lines must have "compatible" initial whitespace, i.e. it
must either be the exactly same sequence of tabs and space, or the
whitespace of one line must be a proper prefix of the whitespace of
the other line. (This isn't the whole story, multiple indentation
poses some problems.)
> 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.
Or every construct must have a multiple-line equivalent.
Early Basics allowed you to write
IF cond THEN statement
which was quite handy at time (though the language as a whole sucked).
> [Line-oriented languages with continuation markers work fine. I used
> to use one, For-something. -John]
Don't know why, continuation marers are making life miserable in C.
Reformatting code in a multi-line macro is a pain.
[As someone noted above, they work fine in Fortran. C gives you the worst
of both worlds, line oriented preprocessor, token oriented everything else.
Return to the
Search the comp.compilers archives again.