Yeah, that's a good point. I think instead of using a string an iterator should be used. It should be fairly easy to replace the string-implementation with an iterator-implementation.
On Tuesday, June 3, 2014 9:27:05 PM UTC-4, andrew cooke wrote: > > > > 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 >>>>>>>> >>>>>>> >>>>>>>
