Re: Enhancement request: enabling Variant in C parsers

[Akim Demaille]

> Le 18 août 2018 à 17:32, Victor Khomenko <address@hidden> a écrit :
> 
> Hi Akim,

Hey!

>> I don’t understand what you mean here, by monolithic.  The parser needs a
>> single type to store all the possible types, so, yes, it is monolithic.
> 
> Well, I meant that bison looks inside the union and knows its members (I 
> could have used "opaque", but it would have an unrelated technical meaning in 
> C); however, I now found the following example in the documentation, so I 
> suppose I can try creating my own Variant-like type and the parser will still 
> know its members, so I withdraw my "monolithic" claim. If that works, it 
> would solve my problem, though having tool support would be nicer.
> 
> %code requires
> {
>       struct my_value {
>               enum{...} kind;
>               union{...} u;
>       };
> }
> %define api.value.type {struct my_value}
> %token <u.ival> INT "integer"
> %token <u.sval> STR « string"

I’m not sure I understand how this will really help you putting object in the 
stack: (non trivial) objects cannot into union.  I must be missing your point.

And really, I would like to understand what makes you think it is advantageous 
to develop complex storage types for C++ with the C skeletons, rather than 
using the C++ skeleton.

>> Your code is not typical.  Traditionally you build an AST in the parser, and
>> process the tree elsewhere.  That’s why you have so many deletes imho.
>> Using the syntax_error exception, you could still raise a syntax error, as 
>> if it were
>> from YYERROR, but from your routine (however, I don’t think type errors
>> should be handled by the parser).
> 
> I don’t mean to be confrontational or anything,

So far, so good :)

> but checking types after AST is built has serious disadvantages:
>  * the locations must be stored in the AST to report errors

Yes.  But even when generating code, it’s kind of useful to be able to report 
where it’s coming from.  But that depends on the use case, agreed.

>  * there is a risk that errors will not be reported correctly, or will be 
> reported in a wrong order; e.g. the type error could be due to some missing « 
> )", so the parser will happily plough through it and report a syntax error 50 
> lines later in some innocent fragment of code, and the AST is never completed.

I do not understand what you mean here.  If there’s a parse error and you 
invested in error recovery, the parser _must_ build a valid AST.  So the error 
recovery rules (using the error token) must create a node.  Then you have the 
choice of using an existing node from your ast, say a dummy int, which can 
later produce spurious typing errors, granted.  But on this regard, I don’t see 
how typing-as-I-parse helps.  Also, a better strategy in to introduce a new AST 
node to represent precisely that there was an error here, so that the type 
checker that keep silent when checking it.

Still, type checking typically requires resolving names, binding from uses to 
definitions, i.e., deal with context sensitive matters.  And backing context 
sensitive issues into a context parser is, IMHO, a sure way for the spaghetti 
hell.  Keeping the two modules separated is probably slightly more expensive 
(in terms in runtime performance), but waaaaaay easier to maintain, debug, 
upgrade, etc.