if you're using a string and an integer index, you're going to have 
problems with multi-byte utf8 (if i understand the docs correctly).

i think there should be *some* abstraction.  then people can (ab)use that 
to do things you don't expect.  and julia's iterators are as lightweight 
and hopefully-optimised away as you can get.

cheers,
andrew

On Tuesday, 3 June 2014 21:43:03 UTC-4, Abe Schneider wrote:
>
> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>

Reply via email to