You should be able to use Unicode in the SLIF DSL source. I'm treated
this as a possible Marpa bug, and investigating. -- jeffrey
On 12/19/2013 03:25 PM, Durand Jean-Damien wrote:
This gist is my attemps for the perl6 advent day 18:
https://gist.github.com/jddurand/8047822
Jeffrey, I might have had a source encoding issue but well:
- test suite worked with suit ~ [\x{2665}\x{2666}\x{2663}\x{2660}]
- test suite failed with suit ~ [♥♥♦♣♠]
- grammar failed to compile with suit ~ '♥' | '♥' | '♦' | '♣' | '♠'
In fact I wonder: yes Marpa supports unicode when parsing, for sure.
But is there an encoding restriction on the SLIF source itself (sorry
if this is already documented)
Thanks / JD.
Le jeudi 19 décembre 2013 04:05:09 UTC+1, Jeffrey Kegler a écrit :
This could be an opportunity for someone to write an event
tutorial, like the one Paul was talking about. Marpa will handle
the Unicode nicely.
As I see the solution in outline, if each card is a lexeme, you
define an "after lexeme" named event which updates a hash,
similarly to what is done in the Perl 6 example's "card" token
routine. (If cards are higher level than lexemes, you use a
"completed" event instead.) If checking the hash indicates a card
is a duplicate, you don't need to read on -- you stop and report
failure. If you read the end of input without failure, you go on
to call $slr->value() to obtain the value.
Note the conclusion points out a major advantage of Marpa's
approach. Marpa's events are called once and only once, when an
instance of that event occurs. So what, you say? Well, if your
parser gets its power via backtracking, it means you will have a
very hard time predicting when and how many times the rule and
symbol routines are called. Marpa never backtracks, and each rule
and symbol instance is encountered and dealt with once and only once.
If the Perl 6 grammar in the post were expanded, and started to
require backtracking, it would fail in mystifying ways. This
could be prevented by having the routines track the number of
times they are called for each instance of their rule or symbol,
in each Perl 6 parse, and dividing their logic into that part
which should be executed repeatedly, at each encounter, and a part
which should be executed only once, the first time that a rule or
symbol instance is encountered. But what happens if on the first
encounter you execute the once-only logic, but then backtracking
determines that that particular parse path will not be used? Hmmmm.
In my very biased opinion, I think a Marpa solution might look
relatively simple and elegant.
Happy hacking, jeffrey
On 12/18/2013 01:53 PM, Jakub Narębski wrote:
I have just read article on parsing on Perl 6 Advent 2013
Calendar series,
"Day 18 – A Grammar with Duplicate checking"
https://perl6advent.wordpress.com/2013/12/18/day-18-a-grammar-with-duplicate-checking/
<https://perl6advent.wordpress.com/2013/12/18/day-18-a-grammar-with-duplicate-checking/>
I wonder: how such grammar can be implemented in Marpa's SLIF parser
(or perhaps there exists Perl6 Grammar rules parser for Marpa?),
and if
duplicate detection must be put in procedural code.
--
Jakub Narębski
--
You received this message because you are subscribed to the
Google Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected] <javascript:>.
For more options, visit https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
You received this message because you are subscribed to the Google
Groups "marpa parser" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "marpa
parser" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
