On 4/5/2022 1:51 AM, 3dcase via Discuss wrote:

Unfortunately, that's a very hard problem.  Sometimes it is possible to
point directly at the problem, but often the program isn't "wrong" until
long after the original error.  As a simple example, if you have a
missing close brace somewhere in the middle of a program, the program
probably isn't technically wrong until you get all the way to the end of
the file and find that there's no match for the original open brace.

This is a very common issue across all languages.

On Tue, Apr 05, 2022 at 09:12:44AM -0700, Jordan Brown wrote:

but in your example case, it would be easy to report: Missing close brace for
block opened on line xxyy.

This would put the user in the block that's missing the brace and not at
the end with "hmm. somewhere in the 1000 lines above there must be a missing
brace". With proper blocks of at most 50 lines, you point the user to the
50 lines where the error is and not "somewhere in your 1000 line file".

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
f equals m times a. When your f is steady, and your m is going down
your a is going up.  -- Chris Hadfield about flying up the space shuttle.

On 4/6/2022 3:39 AM, Rogier Wolff wrote:

1 {
2 {
3 }
4 {
5 {
6 }
7 }

Missing close brace for block opened on line 1.

Where was it supposed to be?

It could legally be after any of those lines.  The only place it
couldn't be is before the first line.  It happens that it was after line
5, but there's no way to know that.

If you just know, as a style convention, that no brace block is more
than 50 lines, yes, the user can know that the problem is in the 50
lines after the mismatched open brace.  But if, as a style convention,
you indented consistently, it's also easy to find the mismatch. 
Experienced programmers don't generally have trouble finding brace
mismatches.  Less experienced programmers, who are not obsessive about
indentation, may have more trouble.  Less experienced programmers are
also less likely to stick to small-module discipline, and more likely to
have trouble with even 50-line blocks.

Language processors that are built on parser generators, as OpenSCAD is,
have it even harder.  Nothing in such a program really deeply
understands the syntax.  All it knows is patterns, and so all it can
know is that what it's been given doesn't match any of the patterns.  It
doesn't "know" that braces come in pairs, because from the perspective
of the parsing engine a brace pair is just a pattern - it doesn't even
really know about the concept of matching.  Almost the only syntax error
that OpenSCAD has is "syntax error", because the functions doing the
processing don't know anything more than the fact that they've ended
up at a dead end, a point where they can't find a pattern to match. 
(Lexical errors add another four cases that might be considered parsing
errors.)  A hand-written parser can do much better, but is a lot more
work and a lot more error-prone.  I suspect that you can write a
language description that can specially detect cases like missing open
and close braces, but I'm not a compiler guy and am not sure - and it's
certainly more advanced use.

Oddly enough, I was just hand-writing a JSON parser last night: (I had a
use case that the convenient library parsers wouldn't handle.) In your
parser generator source, you pass along a stack (implemented using a linked
list or a c++ std::vector) of line numbers, When the parser sees an open
brace, or open paren or open bracket, you push a tiny struct that is an
enum for the type of open,  and the line number. When you see a close, you
pop the stack. When an error occurs, you can produce an error message: I
discovered on line 20 that the block opened on line 1 is not closed. Now a
human being, seeing an error message like that will use their text editor -
many allow you to modifier-click on a bracket character and select the
entire block. A human being will now quickly inspect the code and find the
mistake.  Yes, in your 1) 2) 3) example the compiler can't pin the mistake
down, but I make this mistake often enough to know it is pretty easy for a
person to find the mistake.

I suppose the correct action is for me to actually write this and send it
as a pull request. OK - that seems like a good starter task for a
contributor.

On Wed, Apr 6, 2022 at 9:43 AM Jordan Brown openscad@jordan.maileater.net
wrote: