how do you imagine a parser giving you somnething useable in case of *unparseable input*

Please provide a concrete test case.

> Please provide a concrete test case.

You could have easily created one just with the information provided in my report, but here is one:

```
<?php

if(

```

And here's another (see if you can spot the actual error, then imagine it being in a real-life-size file)


```
<p class="comment">
  <span class="comment_text"><?php echo $comment->text; ?></span>
  <?php
  	if (true) {
  		?>
  		<span class="comment_edit_links">
  		
  		</span>
  		<?
  	}
  ?>
</p>
```


> how do you imagine a parser giving you somnething useable in case of *unparseable input*

Well, I expect it to tell me why the input is unparseable.

By your reasoning, no userful error message would ever be given by any parser for any syntax error.

> Well, I expect it to tell me why the input is unparseable

to tell you something specific it needs to be parsed

> By your reasoning, no userful error message would ever be given by any parser for any syntax error

"Unexpected end of file" is pretty clear! you are opening more stuff with { as you close with }

> to tell you something specific it needs to be parsed

Then how comes you are able to give sensible error messages in other cases?


> "Unexpected end of file" is pretty clear! you are opening more stuff with 
> { as you close with }

It could be {, it could be ( or [, even "... and then you have to find which one.

And btw, it's not just not closing something that you've opened.

For example this:

```
<?php

$s =
```

> And btw, it's not just not closing something that you've opened.
>
> For example this:
>
> ```
> <?php
> 
> $s =
> ```

surely, you opened an assignment and never finished it

so from the view of a parser everyting after it is part of the assignment until ; appears and then averything after "that line" to ; makes little to no sense

Hi,

While bug reports and feature requests are always welcome, please keep in mind that PHP is not a commercial product, so you are asking people to volunteer their time and expertise to improve it. If you help those volunteers understand your request, and make clear that you appreciate their efforts, you're more likely to get their help in return.

The other thing to keep in mind is that PHP has been actively developed for 25 years. While it's possible that nobody got around to making these messages better, it's probably more likely that the problem is harder than you think. If you know how the parser works and would like to contribute an improvement, I'm sure it would be very welcome; if you don't, you may not be the best judge of how easy it would be to do.

Just to be clear: I'm not an expert on the parser either; and I agree the message could be more helpful. I wouldn't call it "not acceptable" though, because I've been a programmer long enough to know that some things are more difficult than they look.

Regards,
Rowan Tommins
[IMSoP]

Hopefully I'm not adding fuel to the fire, but exactly what error message should this code produce?

<?php

class Example {
  public static function doThing($param) {
    if ($param) {
      echo "Doing the thing";
  }
}

> While bug reports and feature requests are always welcome, 
> please keep in mind that PHP is not a commercial product, 

I'm not sure what makes you think I'm not taking that in mind.

> so you are asking people to volunteer their time and expertise 
> to improve it. 

I'm not asking anyone to do anything. I'm reporting a bug. Or a design flaw, or the lack of a feature that is usually expected of any modern programming language, call it what you want, but I'm just reporting it.

Then someone tried to make a ridiculous argument that the issue I'm pointing out doesn't exist, or that the request doesn't make sense, so I object to that flawed reasoning. I'm not demanding that anybody starts working on fixing it ASAP, I'm just objecting to that reasoning.



> If you help those volunteers understand your request, 

I think the "request" (or rather the report) is clear enough.

> and make clear 
> that you appreciate their efforts,

Oh ok sorry, my bad, I thought that was a given.
I APPRECIATE YOUR EFFORTS. I'm serious.


>  you're more likely to get their help in return.

I'm not asking for help. I'm reporting an issue.
Regarding the likelihood of anybody eventually volunteering their time to fix the issue or make the improvement, I would be surprised if that was in any way affected by how much one given random person (i.e. me) shows appreciation for it. Of course I don't expect anybody in the PHP developer community to be willing to help me or do anything for me, but fixing an issue that I report or implementing a feature that I suggest has nothing to do with helping *me*.


> The other thing to keep in mind is that PHP has been actively developed 
> for 25 years. 

That's why it's all the more astonishing that such an issue still exists. I guess there are priorities and some things remain unfixed for ages, then people get used to them and they become even less of a priority. PHP is not alone. Take for example MySQL, which still to this day has error messages that start with "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ..." (wasting more than 130 characters to say "syntax error" and then failing to unambiguously tell you where it is).


OR it could be *incredibly* difficult to fix. I never said it can't be. 
(((
Wait, I did. I said "you can easily do better". My bad. I don't know that. But I do *bet* you can reasonably easily do *a bit* better than "unexpected end of file" with something like "unexpected end of file before closing <whatever was the last thing in my stack>" or "Expecting <whatever> at the end of input" (like Java does).
)))

Anyway, I am just reporting the issue. You give it the priority it deserves taking into account the effort it requires. Just don't attempt to argue that it's not an issue or that it doesn't make sense. Other programming languages have done it.


> If you know how the parser works and would like to contribute an improvement, 
> I'm sure it would be very welcome;

Obviously that's not the case. I mean I don't know how the parser works, otherwise I'd love to contribute. The only contribution I can give is pointing out the issue which is what I've done. I don't expect to be thanked, but I'm surprised to be met with hostility as if I was talking nonsense.

I could have expected a reply like "Don't you think we already know that!?", but I definitely didn't expect one like "What else would you expect!?".


> if you don't, you may not be the best judge 
> of how easy it would be to do.

I have no pretention to be the judge of that.


> Just to be clear: I'm not an expert on the parser either; and I 
> agree the message could be more helpful. 

That is literally ALL I intended to report.

All I was suggesting is that you could think about the tone you use, and how people are likely to react based on that tone.

Imagine there are no eggs on the shelf in a shop, and the customer finds a member of staff. 

They could say: "Having no eggs on the shelf is NEVER acceptable. You have to make sure you're stocked up on eggs. It's unbelievable that you would let the eggs run out. You can easily stock enough eggs."

Or they could say: "There seem to be no eggs on the shelf. Are there any more in the store room please?"

Which do you think is most likely to get the customer their eggs? Which would you rather hear if you were the member of staff?


Similarly, you might have got more productive replies if you had framed your original report more politely, for instance:

The message "Unexpected end of file" for certain syntax errors is not very helpful - particularly in large files, where the actual error could be anywhere in the file. Would it be possible to include more details; for instance, if the error is an unmatched bracket or quote, could it say which, and perhaps even distinguish an unclosed if statement from an unclosed function definition?

The error message is generated by bison, and we have little control over how it looks like. This is a known disadvantage of using generated parsers, and I don't think we can address this short of switching to a recursive descent parser.

Turns out we *can* address this issue while using a generated parser! Yay!

Please see the GitHub PR and comment on how to improve it.