Re: [Factor-talk] EBNF peg parser ensuring full parse

[John Benediktsson]

I think most EBNF uses would want to use ``parse-and-throw`` and not the
current ``parse-and-ignore``, but perhaps it makes sense to define both.  I
would be a little concerned about word explosion also, plus discoverability
/ subtle bugs if both ways are defined.

I like the idea of adding your additional parse words, and perhaps
refactoring a little bit their names ``(parse)`` more like ``parse``, and
``parse`` seems more like a ``parse-result``.  Pull requests welcome!


On Tue, Jan 17, 2017 at 12:46 PM, Chris Double 
wrote:

> On Wed, Jan 18, 2017 at 4:24 AM, Jon Harper 
> wrote:
> >
> > Should we add words to do this more easily ?
> > maybe
> > : parse* ( string parser -- ast remaining )
> > : parse-all ( string parser -- ast ) ! throws when remaining not empty
> >
> > Maybe EBNF: can define several words ? (but it's bad for grepability...)
>
> I think the parse* and parse-all words are a good approach, and
> document the usage with . Having EBNF: define multiple words can
> result in a bit of word explosion but I think it's useful too. You can
> get the functionality from an EBNF: word with code like:
>
> EBNF: foo rule= ("a" | "b")* ;EBNF
> "abbaXbba" "rule" \ foo rule (parse) remaining>>
>
> Having EBNF: generate a foo* and  a foo-remaining would probably be more
> useful.
>
> --
> http://bluishcoder.co.nz
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] EBNF peg parser ensuring full parse

[Chris Double]

On Wed, Jan 18, 2017 at 4:24 AM, Jon Harper  wrote:
>
> Should we add words to do this more easily ?
> maybe
> : parse* ( string parser -- ast remaining )
> : parse-all ( string parser -- ast ) ! throws when remaining not empty
>
> Maybe EBNF: can define several words ? (but it's bad for grepability...)

I think the parse* and parse-all words are a good approach, and
document the usage with . Having EBNF: define multiple words can
result in a bit of word explosion but I think it's useful too. You can
get the functionality from an EBNF: word with code like:

EBNF: foo rule= ("a" | "b")* ;EBNF
"abbaXbba" "rule" \ foo rule (parse) remaining>>

Having EBNF: generate a foo* and  a foo-remaining would probably be more useful.

-- 
http://bluishcoder.co.nz

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] EBNF peg parser ensuring full parse

[Jon Harper]

Hi list,
when using the peg.* parsing words to parse a sequence of elements, what is
the best way to detect invalid input ? By default the parsing stops when
rules don't match (end of input, or bad input),

For example, consider the following case:
"abaXbba" [EBNF rule= ("a" | "b")* EBNF] ! V{ "a" "b" "a" }
"abaabba" [EBNF rule= ("a" | "b")* EBNF] ! V{ "a" "b" "a" "a" "b" "b" "a" }

Sometimes, in the first case, you want the parsing to throw, or to return a
boolean or return the remaining text to parse.

The following works, but uses low level words:
"abbaXbba"  (parse) [ ast>> ] [ remaining>>
empty? ] bi

The following also works (I think)
"abaXbba" [EBNF rule= ("a" | "b" | . => [[ "invalid" throw ]] )* EBNF]
or with lookahead
"abaXbba" [EBNF rule= ("a" | "b")* !(.) EBNF]
Those two work, but then you can't use the same parser for both behaviors,
and they use "advanced" (actions or lookahead) features for a simple task.

Should we add words to do this more easily ?
maybe
: parse* ( string parser -- ast remaining )
: parse-all ( string parser -- ast ) ! throws when remaining not empty

Maybe EBNF: can define several words ? (but it's bad for grepability...)

Or maybe just document the existing solution with  and remaining>>
What do you think ?

Cheers,
Jon
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk