[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enhancement request: enabling Variant in C parsers
From: |
Akim Demaille |
Subject: |
Re: Enhancement request: enabling Variant in C parsers |
Date: |
Sat, 18 Aug 2018 17:44:45 +0200 |
> 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.
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/17
- Message not available
- Message not available
- Message not available
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/18
- Message not available
- Message not available
- RE: Enhancement request: enabling Variant in C parsers, Victor Khomenko, 2018/08/18
- Re: Enhancement request: enabling Variant in C parsers,
Akim Demaille <=
- Message not available
- Message not available
- Message not available
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/19
- Message not available
- Message not available
- RE: Enhancement request: enabling Variant in C parsers, Victor Khomenko, 2018/08/19
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/19
- Re: Enhancement request: enabling Variant in C parsers, Rici Lake, 2018/08/19
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/19
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/23
- Re: Enhancement request: enabling Variant in C parsers, Hans Åberg, 2018/08/21
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/23
- Re: Enhancement request: enabling Variant in C parsers, Hans Åberg, 2018/08/23
- Re: Enhancement request: enabling Variant in C parsers, Akim Demaille, 2018/08/23