I also think that the question of input stream encoding is orthogonal to the issues of parsing. There is no technical reason why there could not be a unified and extensible Chicken input stream library that can be used by all the different parser libraries available. The problems solved by lexgen/abnf's style of input streams are:
1) handling of different data structures such as strings, char lists, ports, and byte vectors 2) handling of UTF-8 encoding 3) handling input streams with meta data attached to them, such as position information If others agree on having an input stream library with these properties, I think we should work towards a unified solution. -Ivan On Fri, Mar 27, 2015 at 10:32 AM, Moritz Heidkamp <[email protected]> wrote: > Hi Matt, > > On 27 March 2015 18:18 CET, Matt Gushee wrote: > >> BTW, in case you are interested, I was going to use comparse, which is a >> bit easier to learn (don't know about performance), but found that it >> didn't support UTF-8, which in my world is not acceptable. > > as the author of Comparse I wonder how you got that impression? For > example, Medea (a JSON parser which is implemented in Comparse) fully > supports UTF-8 and even validates it to be well formed. > > As for performance: I've recently made some improvements to it when used > on character based input types (strings and ports, really). In my > (grantedly not scientifically rigorous) benchmarks, this makes Medea the > fastest of the available JSON parsers for CHICKEN, for example. > > Moritz > > _______________________________________________ > Chicken-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/chicken-users > _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
