[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Enhancement request: enabling Variant in C parsers

From: Victor Khomenko
Subject: RE: Enhancement request: enabling Variant in C parsers
Date: Sat, 18 Aug 2018 15:32:17 +0000

Hi Akim,

> > My main concern is memory management. With Variant the destructors are
> called automatically, but in C parsers I currently have to use %union with
> pointers and explicit "delete". This is not exception-safe and results in ugly
> code littered with "delete" statements. (Using api.value.type is not good
> enough as it makes the types monolithic, so I’d have to select the
> corresponding members manually.)
> 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"

> 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, but checking types after AST is 
built has serious disadvantages:
  * the locations must be stored in the AST to report errors
  * 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]