Issue with normalizing custom commands in math expressions; grouping fails.

Issue with normalizing custom commands in math expressions; grouping fails.

[Mikael Öhman]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

This might be a TexMath bug, I'm not sure, but I think the issue is when 
output is written by Pandoc.

Here is a minimal sample

\documentclass{article}
\usepackage{amsmath}
\newcommand{\vecx}{\mathbf{x}}
\begin{document}
$\hat\vecx$
\end{document}

When exporting to MathJax from pandoc, this is normalized to 
$\hat\mathbf{x}$
which isn't correct. It should be
$\hat{\mathbf{x}}$

(I tend to leave out brackets when possible as its faster to type, and 
clutters up long equations less.)

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pandoc-discuss/-/SSH76iXekBwJ.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.


[-- Attachment #2: Type: text/html, Size: 1169 bytes --]

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[John MacFarlane]

+++ Mikael Öhman [Mar 30 12 04:39 ]:
>    This might be a TexMath bug, I'm not sure, but I think the issue is
>    when output is written by Pandoc.
>    Here is a minimal sample
>    \documentclass{article}
>    \usepackage{amsmath}
>    \newcommand{\vecx}{\mathbf{x}}
>    \begin{document}
>    $\hat\vecx$
>    \end{document}
>    When exporting to MathJax from pandoc, this is normalized to
>    $\hat\mathbf{x}$
>    which isn't correct. It should be
>    $\hat{\mathbf{x}}$
>    (I tend to leave out brackets when possible as its faster to type, and
>    clutters up long equations less.)

Yes, it's a texmath issue - pandoc uses its functions for macro
resolution.  What you're pointing out is that the macro replacements
should include the grouping braces.  I agree, this is a bug, perhaps
even more obvious from:

```
% pandoc --mathjax
\newcommand{\vecx}{a + x + c}

$\hat\vecx$

<p>\(\hata + x + c\)</p>
```

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[Tillmann Rendel]

John MacFarlane wrote:
> What you're pointing out is that the macro replacements
> should include the grouping braces.

This is not correct. In TeX, macros are expanded to their definition 
*without* the grouping braces. For example, the following works in latex:

   \documentclass{article}
   \newcommand{\macro}{\mathbf}
   \begin{document}
   $\macro x$
   \end{document}

Currently, pandoc normalizes the math snippet to

   $\mathbf x$

which is correct. It would be wrong to normalize it to

   ${\mathbf} x$

instead, because \mathbf needs an argument and latex produces an error 
message when confronted with this variant.

> ```
> % pandoc --mathjax
> \newcommand{\vecx}{a + x + c}
>
> $\hat\vecx$

In latex, the semantics of this math snippet is as follows: \hat is a 
macro with one argument. In this case, the argument is \vecx. The 
overall call \hat\vecx is replaced by the body of the \hat macro, with 
every occurence of #1 replaced by \vecx. When processing reaches such an 
occurence of \vecx, it is replaced by its body, that is, a + x + c. So 
the \hat macro seems to operate on the whole sum expression because \hat 
is expanded before \vecx is expanded.

Now if we want to normalize math snippets by expanding \vecx before 
\hat, we need to make sure that \hat operates on the overall expansion 
of \vecx. We can achieve this by wrapping the expansion of \vecx in a group:

   $\hat{a + x + c}$

So unlike in the case I described above, here it is indeed correct to 
wrap the result of macro expansion in a group, because the original 
macro occurence was used as an argument to some macro.


So sometimes we need the braces, and sometimes we don't. A sound and 
complete normalization procedure for tex would need to distinguish these 
two cases by deciding whether a macro call is used as an argument to 
some other macro or not. In this case, \hat occurs to the left of \vecx, 
and we know that \hat takes one argument, so \vecx must be an argument. 
In the general case, however, we cannot statically decide whether a 
macro takes arguments. That depends on the macro's definition, which can 
be influenced by the rest of the TeX code in the file as well as all 
included packages. In fact, we couldn't even decide if we knew all that 
code (by Rice's theorem, because TeX is a Turing-complete language).


More thoughts on parsing TeX as well as an analysis about which TeX 
features are actually used by users can be found in the following paper:

   Sebastian Thore Erdweg and Klaus Ostermann.
   Featherweight TeX and Parser Correctness.
   In Proc. of the International Conference
   on Software Language Engineering (SLE), 2010.

   http://www.informatik.uni-marburg.de/~seba/publications/sle10.pdf

Tillmann

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[Mikael Öhman]

[-- Attachment #1: Type: text/plain, Size: 4109 bytes --]

I don't think TexMath necessarily need to follow exactly how latex works, 
but I think this part should be improved upon.

I'm going to try and implement some better parsing than this. Two parts to 
this
1. Add LaTeX output (from the parsed tree back to Strings).
2. Move applying of custom macro commands before checking for "built in" 
commands, then recurse and treat them as part of the tree (potentially with 
some unknown node at the end, which is left as-is).

So, fully parsing into the tree (with all custom commands normalized).
Unless someone else volunteers, I'll start with 1, as its a prerequisite 
for fixing this problem.

On Saturday, March 31, 2012 10:43:10 PM UTC+2, Tillmann Rendel wrote:
>
> John MacFarlane wrote:
> > What you're pointing out is that the macro replacements
> > should include the grouping braces.
>
> This is not correct. In TeX, macros are expanded to their definition 
> *without* the grouping braces. For example, the following works in latex:
>
>    \documentclass{article}
>    \newcommand{\macro}{\mathbf}
>    \begin{document}
>    $\macro x$
>    \end{document}
>
> Currently, pandoc normalizes the math snippet to
>
>    $\mathbf x$
>
> which is correct. It would be wrong to normalize it to
>
>    ${\mathbf} x$
>
> instead, because \mathbf needs an argument and latex produces an error 
> message when confronted with this variant.
>
> > ```
> > % pandoc --mathjax
> > \newcommand{\vecx}{a + x + c}
> >
> > $\hat\vecx$
>
> In latex, the semantics of this math snippet is as follows: \hat is a 
> macro with one argument. In this case, the argument is \vecx. The 
> overall call \hat\vecx is replaced by the body of the \hat macro, with 
> every occurence of #1 replaced by \vecx. When processing reaches such an 
> occurence of \vecx, it is replaced by its body, that is, a + x + c. So 
> the \hat macro seems to operate on the whole sum expression because \hat 
> is expanded before \vecx is expanded.
>
> Now if we want to normalize math snippets by expanding \vecx before 
> \hat, we need to make sure that \hat operates on the overall expansion 
> of \vecx. We can achieve this by wrapping the expansion of \vecx in a 
> group:
>
>    $\hat{a + x + c}$
>
> So unlike in the case I described above, here it is indeed correct to 
> wrap the result of macro expansion in a group, because the original 
> macro occurence was used as an argument to some macro.
>
>
> So sometimes we need the braces, and sometimes we don't. A sound and 
> complete normalization procedure for tex would need to distinguish these 
> two cases by deciding whether a macro call is used as an argument to 
> some other macro or not. In this case, \hat occurs to the left of \vecx, 
> and we know that \hat takes one argument, so \vecx must be an argument. 
> In the general case, however, we cannot statically decide whether a 
> macro takes arguments. That depends on the macro's definition, which can 
> be influenced by the rest of the TeX code in the file as well as all 
> included packages. In fact, we couldn't even decide if we knew all that 
> code (by Rice's theorem, because TeX is a Turing-complete language).
>
>
> More thoughts on parsing TeX as well as an analysis about which TeX 
> features are actually used by users can be found in the following paper:
>
>    Sebastian Thore Erdweg and Klaus Ostermann.
>    Featherweight TeX and Parser Correctness.
>    In Proc. of the International Conference
>    on Software Language Engineering (SLE), 2010.
>
>    http://www.informatik.uni-marburg.de/~seba/publications/sle10.pdf
>
> Tillmann
>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pandoc-discuss/-/Jvec3CTxKGsJ.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.


[-- Attachment #2: Type: text/html, Size: 4811 bytes --]

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[John MacFarlane]

One note: I orginally added the macro parsing and resolution code to
texmath, but now I think it would be better to make it part of pandoc's
latex reader.   This would make it possible to use macros outside of
math contexts.

Perhaps we could keep the existing macro code in texmath for backwards
compatibility (if anyone is using it), but I hate to see effort put
there when the way forward is pandoc's latex reader. (I don't know
of any users of texmath outside of pandoc -- if there are, we could
keep the old macro code in texmath for backwards compatibility, without
using it in pandoc.)

Does that make sense?  Mikael, would you be interested in attacking
this problem in the pandoc's latex reader, and extending macros to all
contexts (not just math)?

John

+++ Mikael Öhman [Apr 04 12 14:31 ]:
>    I don't think TexMath necessarily need to follow exactly how latex
>    works, but I think this part should be improved upon.
>    I'm going to try and implement some better parsing than this. Two parts
>    to this
>    1. Add LaTeX output (from the parsed tree back to Strings).
>    2. Move applying of custom macro commands before checking for "built
>    in" commands, then recurse and treat them as part of the tree
>    (potentially with some unknown node at the end, which is left as-is).
>    So, fully parsing into the tree (with all custom commands normalized).
>    Unless someone else volunteers, I'll start with 1, as its a
>    prerequisite for fixing this problem.
>    On Saturday, March 31, 2012 10:43:10 PM UTC+2, Tillmann Rendel wrote:
> 
>      John MacFarlane wrote:
>      > What you're pointing out is that the macro replacements
>      > should include the grouping braces.
> 
>      This is not correct. In TeX, macros are expanded to their definition
>      *without* the grouping braces. For example, the following works in
>      latex:
> 
>         \documentclass{article}
>         \newcommand{\macro}{\mathbf}
>         \begin{document}
>         $\macro x$
>         \end{document}
> 
>      Currently, pandoc normalizes the math snippet to
> 
>         $\mathbf x$
> 
>      which is correct. It would be wrong to normalize it to
> 
>         ${\mathbf} x$
> 
>      instead, because \mathbf needs an argument and latex produces an
>      error
>      message when confronted with this variant.
> 
>      > ```
>      > % pandoc --mathjax
>      > \newcommand{\vecx}{a + x + c}
>      >
>      > $\hat\vecx$
> 
>      In latex, the semantics of this math snippet is as follows: \hat is
>      a
>      macro with one argument. In this case, the argument is \vecx. The
>      overall call \hat\vecx is replaced by the body of the \hat macro,
>      with
>      every occurence of #1 replaced by \vecx. When processing reaches
>      such an
>      occurence of \vecx, it is replaced by its body, that is, a + x + c.
>      So
>      the \hat macro seems to operate on the whole sum expression because
>      \hat
>      is expanded before \vecx is expanded.
> 
>      Now if we want to normalize math snippets by expanding \vecx before
>      \hat, we need to make sure that \hat operates on the overall
>      expansion
>      of \vecx. We can achieve this by wrapping the expansion of \vecx in
>      a group:
> 
>         $\hat{a + x + c}$
> 
>      So unlike in the case I described above, here it is indeed correct
>      to
>      wrap the result of macro expansion in a group, because the original
>      macro occurence was used as an argument to some macro.
> 
>      So sometimes we need the braces, and sometimes we don't. A sound and
>      complete normalization procedure for tex would need to distinguish
>      these
>      two cases by deciding whether a macro call is used as an argument to
>      some other macro or not. In this case, \hat occurs to the left of
>      \vecx,
>      and we know that \hat takes one argument, so \vecx must be an
>      argument.
>      In the general case, however, we cannot statically decide whether a
>      macro takes arguments. That depends on the macro's definition, which
>      can
>      be influenced by the rest of the TeX code in the file as well as all
>      included packages. In fact, we couldn't even decide if we knew all
>      that
>      code (by Rice's theorem, because TeX is a Turing-complete language).
> 
>      More thoughts on parsing TeX as well as an analysis about which TeX
>      features are actually used by users can be found in the following
>      paper:
> 
>         Sebastian Thore Erdweg and Klaus Ostermann.
>         Featherweight TeX and Parser Correctness.
>         In Proc. of the International Conference
>         on Software Language Engineering (SLE), 2010.
> 
>         [1]http://www.informatik.uni-marburg.de/~seba/publications/
>      sle10.pdf
> 
>      Tillmann
> 
>    --
>    You received this message because you are subscribed to the Google
>    Groups "pandoc-discuss" group.
>    To view this discussion on the web visit
>    [2]https://groups.google.com/d/msg/pandoc-discuss/-/Jvec3CTxKGsJ.
>    To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>    To unsubscribe from this group, send email to
>    pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>    For more options, visit this group at
>    http://groups.google.com/group/pandoc-discuss?hl=en.
> 
> References
> 
>    1. http://www.informatik.uni-marburg.de/%7Eseba/publications/sle10.pdf
>    2. https://groups.google.com/d/msg/pandoc-discuss/-/Jvec3CTxKGsJ

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[Mikael Öhman]

[-- Attachment #1: Type: text/plain, Size: 6318 bytes --]

Still, the macros need to be part of TeXMaths parser as well, no?
The intention was to make custom macros just part of the normal parsing 
procedure, then write used the parsed tree to write a normalized LaTeX 
string (if you want to use MathJax, otherwise you could go for MathML 
directly).
Anyway, my initial work was just to add the LaTeX output from TeXMath.

On Thursday, April 5, 2012 1:35:37 AM UTC+2, fiddlosopher wrote:
>
> One note: I orginally added the macro parsing and resolution code to
> texmath, but now I think it would be better to make it part of pandoc's
> latex reader.   This would make it possible to use macros outside of
> math contexts.
>
> Perhaps we could keep the existing macro code in texmath for backwards
> compatibility (if anyone is using it), but I hate to see effort put
> there when the way forward is pandoc's latex reader. (I don't know
> of any users of texmath outside of pandoc -- if there are, we could
> keep the old macro code in texmath for backwards compatibility, without
> using it in pandoc.)
>
> Does that make sense?  Mikael, would you be interested in attacking
> this problem in the pandoc's latex reader, and extending macros to all
> contexts (not just math)?
>
> John
>
> +++ Mikael Öhman [Apr 04 12 14:31 ]:
> >    I don't think TexMath necessarily need to follow exactly how latex
> >    works, but I think this part should be improved upon.
> >    I'm going to try and implement some better parsing than this. Two 
> parts
> >    to this
> >    1. Add LaTeX output (from the parsed tree back to Strings).
> >    2. Move applying of custom macro commands before checking for "built
> >    in" commands, then recurse and treat them as part of the tree
> >    (potentially with some unknown node at the end, which is left as-is).
> >    So, fully parsing into the tree (with all custom commands normalized).
> >    Unless someone else volunteers, I'll start with 1, as its a
> >    prerequisite for fixing this problem.
> >    On Saturday, March 31, 2012 10:43:10 PM UTC+2, Tillmann Rendel wrote:
> > 
> >      John MacFarlane wrote:
> >      > What you're pointing out is that the macro replacements
> >      > should include the grouping braces.
> > 
> >      This is not correct. In TeX, macros are expanded to their definition
> >      *without* the grouping braces. For example, the following works in
> >      latex:
> > 
> >         \documentclass{article}
> >         \newcommand{\macro}{\mathbf}
> >         \begin{document}
> >         $\macro x$
> >         \end{document}
> > 
> >      Currently, pandoc normalizes the math snippet to
> > 
> >         $\mathbf x$
> > 
> >      which is correct. It would be wrong to normalize it to
> > 
> >         ${\mathbf} x$
> > 
> >      instead, because \mathbf needs an argument and latex produces an
> >      error
> >      message when confronted with this variant.
> > 
> >      > ```
> >      > % pandoc --mathjax
> >      > \newcommand{\vecx}{a + x + c}
> >      >
> >      > $\hat\vecx$
> > 
> >      In latex, the semantics of this math snippet is as follows: \hat is
> >      a
> >      macro with one argument. In this case, the argument is \vecx. The
> >      overall call \hat\vecx is replaced by the body of the \hat macro,
> >      with
> >      every occurence of #1 replaced by \vecx. When processing reaches
> >      such an
> >      occurence of \vecx, it is replaced by its body, that is, a + x + c.
> >      So
> >      the \hat macro seems to operate on the whole sum expression because
> >      \hat
> >      is expanded before \vecx is expanded.
> > 
> >      Now if we want to normalize math snippets by expanding \vecx before
> >      \hat, we need to make sure that \hat operates on the overall
> >      expansion
> >      of \vecx. We can achieve this by wrapping the expansion of \vecx in
> >      a group:
> > 
> >         $\hat{a + x + c}$
> > 
> >      So unlike in the case I described above, here it is indeed correct
> >      to
> >      wrap the result of macro expansion in a group, because the original
> >      macro occurence was used as an argument to some macro.
> > 
> >      So sometimes we need the braces, and sometimes we don't. A sound and
> >      complete normalization procedure for tex would need to distinguish
> >      these
> >      two cases by deciding whether a macro call is used as an argument to
> >      some other macro or not. In this case, \hat occurs to the left of
> >      \vecx,
> >      and we know that \hat takes one argument, so \vecx must be an
> >      argument.
> >      In the general case, however, we cannot statically decide whether a
> >      macro takes arguments. That depends on the macro's definition, which
> >      can
> >      be influenced by the rest of the TeX code in the file as well as all
> >      included packages. In fact, we couldn't even decide if we knew all
> >      that
> >      code (by Rice's theorem, because TeX is a Turing-complete language).
> > 
> >      More thoughts on parsing TeX as well as an analysis about which TeX
> >      features are actually used by users can be found in the following
> >      paper:
> > 
> >         Sebastian Thore Erdweg and Klaus Ostermann.
> >         Featherweight TeX and Parser Correctness.
> >         In Proc. of the International Conference
> >         on Software Language Engineering (SLE), 2010.
> > 
> >         [1]http://www.informatik.uni-marburg.de/~seba/publications/
> >      sle10.pdf
> > 
> >      Tillmann
> > 
> >    --
> > 
> > References
> > 
> >    1. 
> http://www.informatik.uni-marburg.de/%7Eseba/publications/sle10.pdf
> >    2. https://groups.google.com/d/msg/pandoc-discuss/-/Jvec3CTxKGsJ
>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pandoc-discuss/-/FaEQUdvo8lUJ.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.


[-- Attachment #2: Type: text/html, Size: 8502 bytes --]

Re: Issue with normalizing custom commands in math expressions; grouping fails.

[John MacFarlane]

+++ Mikael Öhman [Apr 05 12 01:56 ]:
>    Still, the macros need to be part of TeXMaths parser as well, no?

I suppose that's true, since we need macros to work for markdown input,
too, not just LaTeX.

So why don't you go ahead with the plan you described?  It sounds
sensible to me.

John

>    The intention was to make custom macros just part of the normal parsing
>    procedure, then write used the parsed tree to write a normalized LaTeX
>    string (if you want to use MathJax, otherwise you could go for MathML
>    directly).
>    Anyway, my initial work was just to add the LaTeX output from TeXMath.
>    On Thursday, April 5, 2012 1:35:37 AM UTC+2, fiddlosopher wrote:
> 
>      One note: I orginally added the macro parsing and resolution code to
>      texmath, but now I think it would be better to make it part of
>      pandoc's
>      latex reader.   This would make it possible to use macros outside of
>      math contexts.
> 
>      Perhaps we could keep the existing macro code in texmath for
>      backwards
>      compatibility (if anyone is using it), but I hate to see effort put
>      there when the way forward is pandoc's latex reader. (I don't know
>      of any users of texmath outside of pandoc -- if there are, we could
>      keep the old macro code in texmath for backwards compatibility,
>      without
>      using it in pandoc.)
> 
>      Does that make sense?  Mikael, would you be interested in attacking
>      this problem in the pandoc's latex reader, and extending macros to
>      all
>      contexts (not just math)?
> 
>      John
> 
>      +++ Mikael hman [Apr 04 12 14:31 ]:
>      >    I don't think TexMath necessarily need to follow exactly how
>      latex
>      >    works, but I think this part should be improved upon.
>      >    I'm going to try and implement some better parsing than this.
>      Two parts
>      >    to this
>      >    1. Add LaTeX output (from the parsed tree back to Strings).
>      >    2. Move applying of custom macro commands before checking for
>      "built
>      >    in" commands, then recurse and treat them as part of the tree
>      >    (potentially with some unknown node at the end, which is left
>      as-is).
>      >    So, fully parsing into the tree (with all custom commands
>      normalized).
>      >    Unless someone else volunteers, I'll start with 1, as its a
>      >    prerequisite for fixing this problem.
>      >    On Saturday, March 31, 2012 10:43:10 PM UTC+2, Tillmann Rendel
>      wrote:
>      >
>      >      John MacFarlane wrote:
>      >      > What you're pointing out is that the macro replacements
>      >      > should include the grouping braces.
>      >
>      >      This is not correct. In TeX, macros are expanded to their
>      definition
>      >      *without* the grouping braces. For example, the following
>      works in
>      >      latex:
>      >
>      >         \documentclass{article}
>      >         \newcommand{\macro}{\mathbf}
>      >         \begin{document}
>      >         $\macro x$
>      >         \end{document}
>      >
>      >      Currently, pandoc normalizes the math snippet to
>      >
>      >         $\mathbf x$
>      >
>      >      which is correct. It would be wrong to normalize it to
>      >
>      >         ${\mathbf} x$
>      >
>      >      instead, because \mathbf needs an argument and latex produces
>      an
>      >      error
>      >      message when confronted with this variant.
>      >
>      >      > ```
>      >      > % pandoc --mathjax
>      >      > \newcommand{\vecx}{a + x + c}
>      >      >
>      >      > $\hat\vecx$
>      >
>      >      In latex, the semantics of this math snippet is as follows:
>      \hat is
>      >      a
>      >      macro with one argument. In this case, the argument is \vecx.
>      The
>      >      overall call \hat\vecx is replaced by the body of the \hat
>      macro,
>      >      with
>      >      every occurence of #1 replaced by \vecx. When processing
>      reaches
>      >      such an
>      >      occurence of \vecx, it is replaced by its body, that is, a +
>      x + c.
>      >      So
>      >      the \hat macro seems to operate on the whole sum expression
>      because
>      >      \hat
>      >      is expanded before \vecx is expanded.
>      >
>      >      Now if we want to normalize math snippets by expanding \vecx
>      before
>      >      \hat, we need to make sure that \hat operates on the overall
>      >      expansion
>      >      of \vecx. We can achieve this by wrapping the expansion of
>      \vecx in
>      >      a group:
>      >
>      >         $\hat{a + x + c}$
>      >
>      >      So unlike in the case I described above, here it is indeed
>      correct
>      >      to
>      >      wrap the result of macro expansion in a group, because the
>      original
>      >      macro occurence was used as an argument to some macro.
>      >
>      >      So sometimes we need the braces, and sometimes we don't. A
>      sound and
>      >      complete normalization procedure for tex would need to
>      distinguish
>      >      these
>      >      two cases by deciding whether a macro call is used as an
>      argument to
>      >      some other macro or not. In this case, \hat occurs to the
>      left of
>      >      \vecx,
>      >      and we know that \hat takes one argument, so \vecx must be an
>      >      argument.
>      >      In the general case, however, we cannot statically decide
>      whether a
>      >      macro takes arguments. That depends on the macro's
>      definition, which
>      >      can
>      >      be influenced by the rest of the TeX code in the file as well
>      as all
>      >      included packages. In fact, we couldn't even decide if we
>      knew all
>      >      that
>      >      code (by Rice's theorem, because TeX is a Turing-complete
>      language).
>      >
>      >      More thoughts on parsing TeX as well as an analysis about
>      which TeX
>      >      features are actually used by users can be found in the
>      following
>      >      paper:
>      >
>      >         Sebastian Thore Erdweg and Klaus Ostermann.
>      >         Featherweight TeX and Parser Correctness.
>      >         In Proc. of the International Conference
>      >         on Software Language Engineering (SLE), 2010.
>      >
>      >         [1][1]http://www.informatik.uni-
>      marburg.de/~seba/publications/
>      >      sle10.pdf
>      >
>      >      Tillmann
>      >
>      >    --
>      >
>      > References
>      >
>      >    1. [2]http://www.informatik.uni-marburg.de/%7Eseba/
>      publications/sle10.pdf
>      >    2. [3]https://groups.google.com/d/msg/pandoc-discuss/-/
>      Jvec3CTxKGsJ
> 
>    --
>    You received this message because you are subscribed to the Google
>    Groups "pandoc-discuss" group.
>    To view this discussion on the web visit
>    [4]https://groups.google.com/d/msg/pandoc-discuss/-/FaEQUdvo8lUJ.
>    To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>    To unsubscribe from this group, send email to
>    pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>    For more options, visit this group at
>    http://groups.google.com/group/pandoc-discuss?hl=en.
> 
> References
> 
>    1. http://www.informatik.uni-marburg.de/%7Eseba/publications/
>    2. http://www.informatik.uni-marburg.de/%7Eseba/publications/sle10.pdf
>    3. https://groups.google.com/d/msg/pandoc-discuss/-/Jvec3CTxKGsJ
>    4. https://groups.google.com/d/msg/pandoc-discuss/-/FaEQUdvo8lUJ

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to pandoc-discuss+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pandoc-discuss?hl=en.