richardpawson
commented
2 months ago No way around this. It has to parse to be saved, otherwise you will not be able to load the program again.
N.B. I did consider adding the rule that you must make a field parse before you leave the field. Decided (in part on the advice of Michael Kölling and team, who had considered the same thing at one point in their design for Stride) that this would be too brutal.
Teachers do need to reinforce the message: don't leave fields incomplete (amber), or not parsing (red) for long - and certainly don't let them build up. It is OK to leave compile errors (e.g. calling a procedure that does not yet exist), but not parse errors. There really isn't any excuse for leaving parse errors and writing more code.
getting a hard to detect/correct parse error 2 minutes before the end of the lesson
This isn't a very realistic scenario. Parse errors are always localised to the field (c.f. compile errors). Worst case is you delete the contents of just that field, and put in the minimal code to parse - then save.
My nightmare scenario would be a Molesworth putting a lot of code in (without saving), then getting a hard to detect/correct parse error 2 minutes before the end of the lesson and not being to save it.
I'm not sure what, if any, is the answer to this.