Re: bison for nlp

Akim Demaille <[email protected]>
Newsgroups gmane.comp.parsers.bison.general
Message-ID <[email protected]>
Hi!

> Le 7 nov. 2018 à 10:09, r0ller <[email protected]> a écrit :
> 
> Hi Akim,
> 
> The file hi_nongen.y is just left there as the last version that I wrote manually:) If you check out any other hi.y files in the platform specific directories (e.g. the one for the online demo is https://github.com/r0ller/alice/blob/master/hi_js/hi.y but you can have a look in hi_android or hi_desktop as well) you’ll see how they look like nowadays.

You have tons of

   logger::singleton()==NULL?(void)0:logger::singleton()->log(2,"vm is NULL!");

you could introduce logger::log, or whatever free function,
that does that for you instead of having to deal with that
in every call site.

> Numbering tokens was introduced in the very beginning and has been questioned by myself quite a many times if it's still needed. I didn’t give a hard try to get rid of it mainly due to one reason: I want to have an error handling that tells in case of an error which symbols could be accepted instead of the erroneous one just as bison itself does it but in a structured way (as bison returns that info in an error message string).

Where are these numbers used?

> Though, I could not come up with any better idea when it comes to remapping a token to a symbol. As far as I know bison uses internally the tokens and not the symbols for the terminals and it's not possible to get back a symbol belonging to a certain token. That's it roughly but I'd be glad to get rid of it. However, if it's not possible and poses no problems then I can live with it. By the way, are there any number ranges or specific numbers that are reserved?

Some numbers are reserved, yes: 0 for eof and 256 for error (per POSIX).  For error, Bison can accommodate if you use 256.  EOF must be 0.


> Not using the C++ features of bison has historical reasons: I started writing the project in C and even back then I used yacc which I later replaced with bison. When I started to shift the project to C++ I was glad that it still worked with the generated C parser and since then I never had time to make such an excursion but it'd be great. I also must admit that I wasn't really aware of it. The only thing I read somewhere was that bison has a C++ wrapper but have never taken any steps into that direction.

I don’t know what you mean here: this is bison itself, there’s
no need for a wrapper, and the deterministic parser itself is
genuine C++, not C++ wrapping C.  The GLR parser in C++ though _is_
a wrapper for the C GLR parser.

> Now I think I'll find some time for it -at least to check it out:) Could you give me any links pointing to any tutorial or something like that? It’d be very kind if you could help me in taking the first steps, thanks!

I would very like to have your opinion on the open section of the
documentation about C++.  It’s recent, and it probably needs polishing.

https://www.gnu.org/software/bison/manual/bison.html#A-Simple-C_002b_002b-Example


_______________________________________________
[email protected] https://lists.gnu.org/mailman/listinfo/help-bison
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.