<div dir="ltr"><div>Philip,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 5, 2019 at 3:48 AM Philip Bernhart via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I don't understand the way OMeta2 matches this rule:<br>
<br>
scheme =<br>
  letter (letter | digit | $+ | $- | $. )*)<br>
<br>
when used in this way:<br>
  UriParser matchAll: 'http' with: #scheme => anOrderedCollection($t $t<br>
  $p)<br>
<br>
why does it forget the $h?<br>
<br></blockquote><div><br></div><div>By default, an OMeta rule (method) will return the last match.  In your example it will be the parenthesized expression so the first letter will appear to be ignored when if fact it wasn't: you didn't tell OMeta to do anything with it so it just matched it and moved on.  To use the contents that were matched, you want to use the 'consumed by' operator which is just to enclose the expression you're interested in with angled brackets like so:</div><div><br></div><div>scheme =</div><div> <letter (letter | digit | $+ | $- | $. )*)></div><div><br></div><div>or you could save the consumed contents to a variable for use in a semantic predicate or action later:</div><div><br></div><div><div>scheme =</div><div> <letter (letter | digit | $+ | $- | $. )*)>:foundScheme</div><br class="gmail-Apple-interchange-newline"></div><div>(Note: there's also an 'index consumed by' variant which uses @<...> syntax and you can nest them to get both)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Also why does OMeta2 sometimes cause an endless loop within the<br>
image with showing an hourglass as cursor without being able<br>
to quit that with ALT-. / CMD-. ?<br></blockquote><div><br></div><div>That's almost always due to a 'bad' parser specification.  In practice, it's usually a * or ? in your source code that results in zero occurrences, as a result the overall rule succeeds and then gets stuck in a recursive loop matching that same rule until you OOM.  An easy way to detect this type of problem (and not hang your image) is to load the OMeta2Extensions package and have your parser be a subclass of OMeta2Debug while you are developing.  Once everything is working, then change the parent class back to OMeta2 which should be otherwise transparent as far as your parser code is concerned.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
When building parsers which package should be used PetitParser or<br>
OMeta?<br>
<br>
What do you think?<br></blockquote><div><br></div><div>I use OMeta almost exclusively so obviously would recommend it.  As far as which is right for you, it depends on what you're trying to do / looking for.   If you are just going to be munging data files, Petit will probably be easier to use and offer better runtime performance.  If you're looking for leverage in developing DSLs, have larger (in scope) projects and/or have lots of permutations of your parsers, I'd say OMeta is the way to go.  My thumbnail comparison would be that Petit is more conventional and easier to use while OMeta is more powerful and general.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
Philip<br>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a></blockquote><div><br></div><div>Phil </div></div></div>