Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
July 2, 2016 05:38
Subject:
Re: Indented here docs?
Message ID:
3A5B2208-B21E-462A-933A-371C1316EAEE@cpan.org
Matthew Horsfall wrote:
> My C is rusty so some extra eyes would be wonderful.
I have done a cursory reading. It mostly looks good but I do have a few observations. First:
> These syntaxes are all supported:
>
> <<~EOF;
> <<~'EOF';
> <<~"EOF";
> <<~\EOF;
What about <<~`EOF`? I think your patch covers it, but it is untested.
> + /* Shift left 1 char, nuke first \n */
I don’t understand why you shift left one char. (I have not run it through a debugger.) If you did s++ before scanning the heredoc delimiter, then why does PL_tokenbuf not already hold the right value? (I am probably missing something obvious.)
> I haven't tested with PERL_STRICT_CR,
PERL_STRICT_CR has probably not been tested for more than a decade. :-) In any case, the non-PERL_STRICT_CR builds (the normal builds) are the more complex, so I don’t think you need to worry.
> and there's other logic inside
> of scan_heredoc that I haven't figured out what it's for yet (starting
> with the lines (in toke.c):
>
> /* inside a string eval or quote-like operator */
> if (!infile || PL_lex_inwhat) {
That code parses the heredoc when the rest of the ‘file’ is inside a single buffer. See the comments above S_scan_heredoc that explain the two approaches.
The beginning of that block is scary code to deal with things like "${s//<<END/e}". (Welcome to perl 5!) The actual here-doc parsing happens after the ‘if (PL_lex_inwhat)’ block.
You need to modify that code, too. I think your existing tests will fail if you put them inside a string eval.
In fact, you would probably end up repeating a large amount of code, so you may want to put some of it in static functions.
> I'd love to see this make it into blead (or something like it).
Me three.
We currently have a policy that new features go through an experimental period for a while. I think that would have to apply to this feature, too. And then you can use <<- without having to worry (for now) about breaking existing syntax.
I agree with Zefram and others that the exact sequence of tabs and spaces found before the closing delimiter should be required on each preceding line, and that anything else should be an error.
Thread Previous
|
Thread Next