wrong error msg

wrong error msg

[Ray Andrews]

Probably not worth reporting but:

     echo "Restore \"${previous?\"? (y/n)"

in a script reports: " unmatched " " whereas it should be an unmatched 
curly where the first question mark mistakenly is . Mind, it's quite 
something how the parser usually figures these things out, and sometimes 
it must be a judgment call trying to discern one's intentions.

Re: wrong error msg

[Bart Schaefer]

On Mar 1,  6:20pm, Ray Andrews wrote:
} Subject: wrong error msg
}
} Probably not worth reporting but:
} 
}      echo "Restore \"${previous?\"? (y/n)"
} 
} in a script reports: " unmatched " " whereas it should be an unmatched 
} curly

The error message is correct.  Try it outside of a script and you can
see what's happening:

torch% echo "Restore \"${previous?\"? (y/n)"
dquote braceparam dquote> 

Note it's still waiting for you to close the inner quote, the brace,
and an outer quote.  If end-of-file is received there, the first
error (unwinding the stack right to left) is unmatched quote.  It
doesn't report the other two things that aren't matched.

This is because for example
  echo "Outer quote ${var:="inner quote"} outer again"
is valid syntax -- you can include nested double quotes inside ${...}.
The result might be a "bad substitution" depending on what else is or
isn't inside the braces but that doesn't affect parsing the quotes.

Re: wrong error msg

[Ray Andrews]

On 02/03/17 08:47 AM, Bart Schaefer wrote:
> torch% echo "Restore \"${previous?\"? (y/n)"
> dquote braceparam dquote>
Well shucks.  I never understood those things, I always presumed it was 
some bizarre message, not a triple message.  So bloody obvious now that 
I see it.   But I don't see how the parser finds trouble with dquotes.  
Boiling it down:

     $ echo "${previous"
     dquote braceparam dquote>

  Are you saying that, working left to right, the parser sorta can't 
consider the dquote closed since it becomes 'distracted' by the unclosed 
brace?  IOW, until the brace is closed it doesn't know that the second 
dquote is 'available' since it could be something that's ...

   echo "Outer quote ${var:="inner quote"} outer again"

... right, the dquote could be within braces so the parser doesn't know 
that it is free to close the outside quote and leaves the issue 
unresolved and then simply reports the unresoved issues.   Thus the 
second dquote is actually seen as another error -- an unclosed quote 
within an unclosed brace within and unclosed quote, yes?  Whereas a 
human would tend to parse it outside-in and thus match the dquotes first 
and then see the unmatched brace -- thus a single error.   But an 
interpreted language probably doesn't have that liberty.  I think I get it.

But why is it 'worse' in a script?  I'd expect more finality at EOF and 
thus, if anything, better messages.  Anyway I think I can finally really 
use those error messages, that's huge, many thanks.

Re: wrong error msg

[Bart Schaefer]

On Mar 2, 12:32pm, Ray Andrews wrote:
}
} ... right, the dquote could be within braces so the parser doesn't know 
} that it is free to close the outside quote and leaves the issue 
} unresolved and then simply reports the unresoved issues.   Thus the 
} second dquote is actually seen as another error -- an unclosed quote 
} within an unclosed brace within and unclosed quote, yes?

Yes.

} Whereas a human would tend to parse it outside-in and thus match the
} dquotes first and then see the unmatched brace -- thus a single error.

As usual, computers are much better at following what you did say than
they are at following what you intended to say.

} But why is it 'worse' in a script?

It's not really 'worse' -- but in a script there's no opportunity to
print the PS2 prompt and wait for you to figure out what you meant.
It just goes on reading from the file until it manages to find a
matching quote, and then goes on until it finds a matching brace,
and so on, probably piling up mismatched elements until it reaches
end of file and has to pick one of them to complain about.

Note that *none* of this is actually an *error* until the point at
which the input runs dry and there is still something left to close,
or until all the pairs have been closed and the thing that remains
doesn't make sense (e.g., "bad substitution").

Re: wrong error msg

[Ray Andrews]

On 02/03/17 03:14 PM, Bart Schaefer wrote:
> As usual, computers are much better at following what you did say than
> they are at following what you intended to say.

Although IIRC the most natural parsing system is the way we do it -- 
outside-in, as, I believe, C does it, but I think the point needs to be 
hammered in that that's not available to an interpreter.  One of those 
deep breakages that ruin your life.
>
> } But why is it 'worse' in a script?
>
> It's not really 'worse' -- but in a script there's no opportunity to
> print the PS2 prompt and wait for you to figure out what you meant.
> It just goes on reading from the file until it manages to find a
> matching quote, and then goes on until it finds a matching brace,
> and so on, probably piling up mismatched elements until it reaches
> end of file and has to pick one of them to complain about.

I see, so rather than collect a cascade of errors, since it can't show 
the prompt it doesn't even try.  Well .... it could try couldn't it? I 
can see that it might have to abort that tho.  I'd have found my error 
faster if the command line style message had been shown.  And in the 
case of unclosings of every kind, isn't it a fairly simple list?
>
> Note that *none* of this is actually an *error* until the point at
> which the input runs dry and there is still something left to close,
> or until all the pairs have been closed and the thing that remains
> doesn't make sense (e.g., "bad substitution").
>
Absolutely.  Although surely  there are constructions that can't go on 
for ever?  Or are there?  My editor has nice syntax highlighting, and if 
you erase a closing quote, the entire rest of the file turns green (for 
quoted text) so there's no limit to that, at least.

Re: wrong error msg

[Bart Schaefer]

On Mar 2,  3:37pm, Ray Andrews wrote:
}
} Although IIRC the most natural parsing system is the way we do it -- 
} outside-in, as, I believe, C does it, but I think the point needs to be 
} hammered in that that's not available to an interpreter.  One of those 
} deep breakages that ruin your life.

Well, no, that's not really it.  The trouble here is that your "natural"
parse is wrong, and the difficulty arises from starting and ending the
matched pair with visually-indistinguishable tokens.  If we replace the
quote marks with square brackets for readability --

The actual meaning:
    echo [Restore \"${previous?\"? (y/n)[

Your "natural" parse:
    echo [Restore \"${previous?\"? (y/n)]

Whether the parse is left-to-right or outside-in doesn't matter.

C does not allow nesting of visually-indistinguishable tokens, so this
can't arise there.

} I see, so rather than collect a cascade of errors, since it can't show 
} the prompt it doesn't even try.  Well .... it could try couldn't it?

The "unmatched" message is coming from the lexer; the PS2 prompt comes
from the interactive input loop after the lexer stops.  There isn't
any "cascade of errors", there's only incomplete parser state, which in
a script is not really available at that point (due to differences in
the way input is processed for interactive vs. a file).

Hmm, you could force interactive mode to syntax-check your script like
this:

  zsh -o interactivecomments +o banghist -fnis < scriptfile
  % dquote braceparam dquote> zsh: unmatched "                                   
  % %                                           

but you'll get a LOT of output.

Re: wrong error msg

[Ray Andrews]

On 03/03/17 08:21 AM, Bart Schaefer wrote:


It gets to be a rather deep subject Sensei, probably not right for the 
list, but my interest in the subject is profound, tho I come at it from 
the study of language in general not programming languages per se.
> Well, no, that's not really it.  The trouble here is that your "natural"
> parse is wrong,

I'd say that 'natural' is whatever folks would be expected to do, and 
I'd assert that 'my way' is what most folks would do and that any 
consistent rule could be used, so nothing is 'wrong' a priori, tho of 
course it might not be the rule actually used!  (Unless of course my 
'natural' parse cannot ever be consistent!)
> C does not allow nesting of visually-indistinguishable tokens, so this
> can't arise there.

That's an excellent point.  Indeed we use quotes with the same presumed 
syntactic effect as {}[]() even tho, as you say, they are not visually 
different.  So whereas *we* know what we mean, the parser has no ability 
to mind-read.  Which makes nesting of quote marks necessarily illegal.  
It's merely theoretical at this point, perhaps that does defeat my view 
of this.  Anyway, I understand what zsh is doing now which is what is 
relevant here.
> Hmm, you could force interactive mode to syntax-check your script like
> this:
>
>    zsh -o interactivecomments +o banghist -fnis < scriptfile
>    % dquote braceparam dquote> zsh: unmatched "
>    % %
>
> but you'll get a LOT of output.
Deep magic.  Too deep for an innocent like me.

>

Re: wrong error msg

[Martijn Dekker]

Op 02-03-17 om 16:47 schreef Bart Schaefer:
> On Mar 1,  6:20pm, Ray Andrews wrote:
> } Subject: wrong error msg
> }
> } Probably not worth reporting but:
> } 
> }      echo "Restore \"${previous?\"? (y/n)"
> } 
> } in a script reports: " unmatched " " whereas it should be an unmatched 
> } curly
> 
> The error message is correct.  Try it outside of a script and you can
> see what's happening:
> 
> torch% echo "Restore \"${previous?\"? (y/n)"
> dquote braceparam dquote> 
> 
> Note it's still waiting for you to close the inner quote, the brace,
> and an outer quote.  If end-of-file is received there, the first
> error (unwinding the stack right to left) is unmatched quote.  It
> doesn't report the other two things that aren't matched.

Perhaps it would be a useful feature to report the other two things, too.

yash does exactly that:

$ yash -c 'echo "Restore \"${previous?\"? (y/n)"'
yash -c:1: syntax error: the double quotation is not closed
yash -c:1: syntax error: `}' is missing
yash -c:1: syntax error: the double quotation is not closed

Would this be difficult to implement in zsh?

- M.

Re: wrong error msg

[Ray Andrews]

On 04/03/17 06:00 AM, Martijn Dekker wrote:
>
> yash does exactly that:
>
> $ yash -c 'echo "Restore \"${previous?\"? (y/n)"'
> yash -c:1: syntax error: the double quotation is not closed
> yash -c:1: syntax error: `}' is missing
> yash -c:1: syntax error: the double quotation is not closed
That is the lap of luxury.  From one's first day with yash, one would 
know exactly what is wrong.

Re: wrong error msg

[Bart Schaefer]

On Mar 4,  2:00pm, Martijn Dekker wrote:
}
} $ yash -c 'echo "Restore \"${previous?\"? (y/n)"'
} yash -c:1: syntax error: the double quotation is not closed
} yash -c:1: syntax error: `}' is missing
} yash -c:1: syntax error: the double quotation is not closed
} 
} Would this be difficult to implement in zsh?

It's messy.  Zsh goes to some effort to *prevent* more than one error
from being reported, i.e., the routines that actually output the error
messages internally keep track of whether they've already been called
and skip printing if called again.

Anyway in zsh the unmatched quote is not the same one that yash is
reporting, if I'm interpreting the call stack correctly.  Zsh has
hit the error while trying to close the very first opening quote,
having already abandoned the input of the "${' and the second quote.
So the error in zsh wouldn't change without completely rearranging
the lexer/parser.

Re: wrong error msg

[Ray Andrews]

On 04/03/17 10:31 AM, Bart Schaefer wrote:
> } Would this be difficult to implement in zsh?
>
> It's messy.  Zsh goes to some effort to *prevent* more than one error
> from being reported, i.e., the routines that actually output the error
> messages internally keep track of whether they've already been called
> and skip printing if called again.
Sounds like it could be an option to just let her rip.  In my case, if 
I'd seen all three errors I'd have been able to figure out what was 
going on quite easily.  And there would have been the implicit message 
to remember that parsing is left to right.

Re: wrong error msg

[Bart Schaefer]

On Mar 4, 11:31am, Ray Andrews wrote:
} 
} Sounds like it could be an option to just let her rip.

Sigh.  No.  That would lead to the SAME error being reported multiple
times, by various parts of the code, and in other situations unrelated
to lexing/parsing (these error printing routines are used *everywhere*).

I'm done with this thread.