[m-users.] Returning error instead of stopping early during parse

[Zoltan Somogyi]

On Wed, 21 Aug 2019 23:07:42 -0400, Philip White <philipwhite at cedarville.edu> wrote:
> one_or_more should be running
> parse_factor twice, and failing the second time;

Yes, it should be doing that. From your description, it *is* doing that.

> I assume that this
> happens, but that it interprets the failure as an end to it's iteration
> and that some other part of the parser will succeed.

That is correct. That is its job: to find how many items there are in the
in the input for which its parameter (in your case, parse_factor) will
succeed. If parse_factor fails if b is not defined (I presume this means that
it is not in NameStack), then it is correctly telling you that there is only one
factor in the input: since b is not defined, parse_factor says it is not a factor.

If I were you, I would pay no attention whatsoever to semantic issues
(such as which names are defined and which are not) during parsing.
Dealing with semantics only when parsing has successfully completed
and you have a complete parse tree is *much* easier, and allows you to
generate *much* better error messages. This is a standard application
of separation of concerns.

Zoltan.