Re: Ignore break line sometimes

Hans-Peter Diettrich <DrDiettrich1@aol.com>
Sat, 11 Feb 2012 17:28:36 +0100

          From comp.compilers

Related articles
Ignore break line sometimes geovanisouza92@gmail.com (Geovani de Souza) (2012-02-11)
Re: Ignore break line sometimes DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-02-11)
Re: Ignore break line sometimes gneuner2@comcast.net (George Neuner) (2012-02-11)
Re: Ignore break line sometimes monnier@iro.umontreal.ca (Stefan Monnier) (2012-02-12)
Re: Ignore break line sometimes Pidgeot18@verizon.invalid (Joshua Cranmer) (2012-02-12)
Re: Ignore break line sometimes kaz@kylheku.com (Kaz Kylheku) (2012-02-13)
Re: Ignore break line sometimes bc@freeuk.com (BartC) (2012-02-14)
Re: Ignore break line sometimes genew@ocis.net (Gene Wirchenko) (2012-02-19)
[3 later articles]
| List of all articles for this month |
From: Hans-Peter Diettrich <DrDiettrich1@aol.com>
Newsgroups: comp.compilers
Date: Sat, 11 Feb 2012 17:28:36 +0100
Organization: Compilers Central
References: 12-02-010
Keywords: parse, design
Posted-Date: 12 Feb 2012 01:16:14 EST

Geovani de Souza schrieb:
> I'm trying write an parser to my compiler, and I'm interessed to
> ignore the break line (\n) sometimes. E.g:
>
> if true then [\n] foo(); [\n] end; [\n]
>
> So, in the first line, the '\n' after 'then' isn't important, but in
> the second "foo();" could replace the need of the semicolon to
> conclude the statement, or still, in the 'end'.


That's why many (compiled) languages ignore line ends and other
whitespace, and require explicit statement termination, e.g. by a
semicolon. Interpreters instead often prefer the "one statement per
line" approach, with the option to concatenate statements by e.g. a colon.


IMO you should make a decision about the meaning of whitespace in
general, and of line endings in detail, in your language.


Please give an example that would compile differently when linefeeds are
    removed, and then answer yourself the question whether this really
will make sense.


DoDi



Post a followup to this message

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