On Tuesday, 3 June 2014 08:16:49 UTC-4, Abe Schneider wrote: > > Currently it only handles strings. The reason is that PEG theoretically > have infinite look-ahead. I think this can be made a little better by > having a stream that loads data on-demand. In general, I think PEG's choice > of memory over speed is good for many things, but you'll probably find some > data where an infinite look-ahead isn't a good idea. >
yeah, i'm sitting here now thinking about this. i just realised that what i have used in the past (i wrote lepl which was an alternative to pyparsing) is effectively an immutable stream. reading from one returns a tuple of (char, newstream) so you can cache the streams and re-use them on backtracking. but that doesn't fit well with julia's IOStream abstraction (from first glance at least). so i am stuck and came here to waste time reading newsgroup posts... > I have a very simple error handling in place (I based it on how > Parsimonous works), but it definitely needs a lot of work. One big question > I'm trying to figure out is whether it's better to return an error as a > value or raise an exception. I've gone with returning a value so (at a > later date) the errors can be collected. Also, errors are currently only > emitted for non-matches, but it should be possible for the transforms to > also emit errors. > ok, i will look at parsimonous, thanks. i never thought much about multiple errors. > I think everything but the rules are typed. The only reason the rules > aren't typed was that when I originally wrote the code I wasn't sure their > exact value at the time. I originally wrote EBNF for an entirely different > reason and got side-tracked when I realized I could write a parser with it. > > A > > On Monday, June 2, 2014 6:41:18 PM UTC-4, andrew cooke wrote: >> >> >> random, possibly clueless thoughts as i look at this: >> >> yes, transform rules by type would be nice! not sure what that means >> about having to generate a module within a macro, though (for namespacing). >> >> do you parse strings or streams? (or both?) i know nothing about julia >> streams, yet, but i imagine streams would make it easier to abstract away >> nasty book-keeping for error reporting (line number etc). >> >> do you have any support for error handling? >> >> why aren't any of your type contents typed? can julia infer that from >> use? if not, it will have a big impact on speed and memory use, i would >> guess. even better if they can be immutable. >> >> thanks, >> andrew >> >> On Saturday, 31 May 2014 21:10:37 UTC-4, Abe Schneider wrote: >>> >>> I should add that PEGParser's code is fairly new and untested (besides >>> having an uninspired name). I'm also hoping to have better action >>> semantics soon. >>> >>> On Saturday, May 31, 2014 2:17:27 PM UTC-4, andrew cooke wrote: >>>> >>>> https://groups.google.com/d/msg/julia-users/t56VxOX1vvk/nszQYWP_pm4J >>>> >>>> https://groups.google.com/d/msg/julia-users/6jz3Ow5SAAE/TgKHQ48gUG4J >>>> >>>> thanks! >>>> >>>> On Saturday, 31 May 2014 14:04:28 UTC-4, Isaiah wrote: >>>>> >>>>> There was a nice looking PEG system previewed a few days ago if you >>>>> search the users list (and I think there was another one several months >>>>> back by Michael Fox). >>>>> >>>>> >>>>> On Sat, May 31, 2014 at 1:22 PM, andrew cooke <[email protected]> >>>>> wrote: >>>>> >>>>>> are there any libraries for parsing in julia? either parser >>>>>> combinator or something more traditional (maybe a wrapper for something >>>>>> like antlr)? >>>>>> >>>>>> all i can find is an old discussion started by leah h in which jeff b >>>>>> suggests doing everything in julia. that included a pointer to >>>>>> https://github.com/astrieanna/juliaparsec/blob/master/juliaparsec.jl >>>>>> from dan l which is, well, as he says, rather basic. >>>>>> >>>>>> i'm not sure i agree, but i don't want to write my own combinator lib >>>>>> either. >>>>>> >>>>>> i guess i'm looking for things like a clean separation between >>>>>> grammar and implementation, support for errors with line numbers, speed, >>>>>> easy debugging... >>>>>> >>>>>> andrew >>>>>> >>>>> >>>>>
