On Tuesday, 3 June 2014 08:29:31 UTC-4, andrew cooke wrote: > > > > 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.. >
duh. this is equivalent to a julia iterator. 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 >>>>>>> >>>>>> >>>>>>
