New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MathParser enhancement -- parametric math grammars #438

Closed
dginev opened this Issue Sep 3, 2013 · 5 comments

Comments

Projects
None yet
2 participants
@dginev
Collaborator

dginev commented Sep 3, 2013

[Originally Ticket 1762]

[0.9 milestone ticket, ignore prior to 0.8 release]

I am working on a second math grammar for LaTeXML, written in Marpa::R2 and now hosted at github at:
https://github.com/dginev/LaTeXML-Plugin-MathSyntax

I want to have an empiric way to compare the RecDescent grammar with mine as to eventually ensure coverage parity. To that end I am developing a test suite and an automated harness for math parsing, which will be applicable to both grammars. While at it, I think we could also make the actual grammar for LaTeXML::MathParser a parameter and push that into trunk, so that I can completely remove the math grammar code from the arXMLiv branch (and get yet a step closer to aligning the branch completely with trunk).

Here is the current diff between the branch and trunk versions of LaTeXML::MathParser, though I warn in advance the code is at a proof-of-concept stage.

49,55c49,50
<   my($class,%options)=@_;
<   require LaTeXML::MathGrammar;
< 
<   my $internalparser = LaTeXML::MathGrammar->new();
<   die("Math Parser grammar failed") unless $internalparser;
< 
<   my $self = bless {internalparser => $internalparser},$class;

---
>   my($class)=@_;
>   my $self = bless {type=>'undef'},$class;
59a55,76
>   if ($options{parser}) {
>     if (lc($options{parser}) ne $self->{type}) {
>       my $parse;
>       if ($options{parser} =~ /^LaTeXML::(\w+)$/) {
>         my $loadable = eval "require $options{parser}";
>         # TODO: Fatal if not loadable
>         my $internalparser = $options{parser}->new();
>         $parse = sub { $internalparser->parse(@_); }}
>       elsif ($options{parser} =~ /^marpa/i) {
>         require LaTeXML::MarpaGrammar;
>         my $internalparser = LaTeXML::MarpaGrammar->new();
>         $parse = sub { $internalparser->parse(@_); }}
>       else {
>         require LaTeXML::MathGrammar;
>         my $internalparser = LaTeXML::MathGrammar->new();
>         $parse = sub { my ($rule,$unparsed) = @_;
>                     $internalparser->$rule($unparsed); }
>       }
>       $self->{invoke} = $parse;
>       $self->{type} = lc($options{parser});
>     }
>   }
470a488
>     $$LaTeXML::MathParser::LEXEMES{$i} = $node;
480c498
<   my $result = $$self{internalparser}->$rule(\$unparsed);

---
>   my $result = &{$self->{invoke}}($rule,\$unparsed);
485c503
<     $result = $$self{internalparser}->$rule(\$unparsed); }

---
>     $result = &{$self->{invoke}}($rule,\$unparsed); }
492c510
<       $result = $$self{internalparser}->$rule(\$unparsed); }

---
>       $result = &{$self->{invoke}}($rule,\$unparsed); }
@dginev

This comment has been minimized.

Collaborator

dginev commented Sep 3, 2013

forgot the GitHub link

@dginev dginev added this to the LaTeXML-0.9 milestone Feb 17, 2014

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Jul 31, 2014

A random comment before I forget: Banging my head against subltly changing test cases due to trying harder to preserve color & style information in math, reminds me of an issue we talked about. Namely, if you install an optional Parser plugin, should it automatically be in effect, or only if you request it to be used?

The likelyhood that an alternative parser will alter test case results reinforces my opinion that plugins ought to be explicitly activated.

@dginev

This comment has been minimized.

Collaborator

dginev commented Jul 31, 2014

How is a plugin related to the core LaTeXML test suite? A plugin is installed after the core is successfully installed and is expected to bring its own test suite, e.g. with the various math parses it aims to create.

Btw, currently my parser plugin does not override the native LaTeXML parser, to the contrary it introduces a new --parse option that lets you choose between RecDescent and Marpa (and keeps the default as RecDescent).

@brucemiller

This comment has been minimized.

Owner

brucemiller commented Jul 31, 2014

To the first question: I still haven't figured out how plugins work in "development mode" (ie,, edit, make, make test, run from blib, repeat) vs "installed mode" (where everything is installed & combined into an official place; but also no clashes, so if you "reinstall" latexml after a plugin, that things work correctly).

To you second comment: that's essentially all I was asking for, so I guess "Never mind..." :>

@dginev

This comment has been minimized.

Collaborator

dginev commented Apr 22, 2018

Oh, this is still an open issue?

I am tempted to close here, as it is too open-ended, and we may be revisiting the details of plugins as a part of a larger effort. I'll just leave a reference to the lexeme branch as something recent and related #947 , but I can't see this issue as useful to me - and I was the one who opened it :>

@dginev dginev closed this Apr 22, 2018

@dginev dginev modified the milestones: LaTeXML-0.9, LaTeXML-0.8.3 Apr 22, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment