Language extensions (discussion)

[GarkGarcia]

Are there any current discussion on creating extension mechanisms for the language? I believe creating a standard mechanism to express language extensions could help improving adoption while avoiding the proliferation of non-standard dialects — which is a big issue in other markup languages such as Markdown.

As far as I'm aware, there are two main approaches for this:

1. Creating an extension model: a standard mechanism for creating language dialects and hooking suitable parsers to the existing parsing/rendering infrastructure. An example of this approach is the extension mechanism provided by the asciidoctor tool-chain.

2. A macro system: a standard mechanism for declaring abbreviations. An example of this approach is, of course, TeX. This approach can get messy. LaTeX itself is cautionary tale in this regard.

The first option is very reliant on tooling, which makes further discussions on language-design much easier. However, it also makes language-extension design a lot harder. Creating a suitable parser would be an unavoidable concern for anyone creating an extension.

As stated in (2), the macro-system approach tends to get messy quickly. It's extremely hard to design a language that works great for macro declarations and for displaying equations. However, this approach lowers the barrier for entry for extension development.

I personally think the first option is the better way to go — not only for AsciiMath, but for light-weight markup languages in general. It wouldn't require any changes to the language itself, but I believe official endorsement would help making it a standard.

The first approach is also a lot more flexible, since developers would be able to leverage existing programming languages instead of having to rely on a macro-system

[drlippman]

Keep in mind AsciiMath the language is separate from the various actual processors, most notably MathJax. There's only so much that can be done at the language level.

It might be possible to add a basic definition-style macro system into the language itself, where the user could define a custom abbreviation symbol like you suggested. It would be a little odd, since it would have to be defined inside a math expression. And whether or not that macro definition would persist as the math processor processed other expressions on the same page would depend on the implementation of the renderer.

AsciiMathML.js itself has a newcommand function for adding new symbols. MathJax has a way to expand the AsciiMath syntax as well by providing access to the symbol table.

For your (1) idea, I'm not sure how hooks could be built into the language that could work universally across all processor implementations. For example, if using MathJax to render, I'd imagine it would have to provide a way to register those hooks.

[GarkGarcia]

Keep in mind AsciiMath the language is separate from the various actual processors, most notably MathJax. There's only so much that can be done at the language level.

I'm aware. That's one o the reasons why I prefer the first idea: it doesn't require any changes to the language itself.

AsciiMathML.js itself has a newcommand function for adding new symbols. MathJax has a way to expand the AsciiMath syntax as well by providing access to the symbol table.

That's great!

For your (1) idea, I'm not sure how hooks could be built into the language that could work universally across all processor implementations. For example, if using MathJax to render, I'd imagine it would have to provide a way to register those hooks.

You're right. Those hooks would have to be processor-specific. But maybe the language itself could provide a mechanism for requiring extensions (something like LaTeX's \usepackage).

Also, we could create a standard for declaring collections of abbreviations. Something like a JSON schema resembling the following:

{
    "abbreviations": [
        {
            "abreviation": "ker",
            "code": "text(ker)"
        }
    ]
}

That would make it possible to use the same extensions across different processors (as long as they are simply collections of abbreviations).

Additionally we could also provide a mechanism for declaring custom "funcions" or operators. Something like:

{
     "abbreviations": [
         {
              "abbreviation": "myfuction",
              "arguments": ["x", "y", "z"],
              "code": "sum_(i = x)^y z_i"
         }
     ]
}

It doesn't need to be JSON file, and it doesn't need to use this specific schema. I'm mostly brainstorming.

[davidfarmer]

I have been following what AsciiMath has been up to for a long time, and I recently started looking at what Gark is doing. I am not sure exactly where Gark is going, but my guess is that what is wanted is something that looks like AsciiMath and extends AsciiMath in the sense that any currently valid AsciiMath expression is valid in the extension and has the same interpretation. What I still don't understand is what is the problem to be solved? When I started thinking about this, the problem I wanted to solve was how to encode more semantic information in the source. For example, but can you tell that n(n+1) is multiplication and not function application? But without understanding the problem, I don't see how to discuss the solution. But one thing I am pretty sure of: macros cause headaches. Giving everyone the ability to make their own macros, usually ends up with a mess that does little good. Most macros just save a few keystrokes, and there are better ways to do that.

…

On Thu, 30 Apr 2020, David Lippman wrote: Keep in mind AsciiMath the language is separate from the various actual processors, most notably MathJax. There's only so much that can be done at the language level. It might be possible to add a basic definition-style macro system into the language itself, where the user could define a custom abbreviation symbol like you suggested. It would be a little odd, since it would have to be defined inside a math expression. And whether or not that macro definition would persist as the math processor processed other expressions on the same page would depend on the implementation of the renderer. AsciiMathML.js itself has a newcommand function for adding new symbols. MathJax has a way to expand the AsciiMath syntax as well by providing access to the symbol table. For your (1) idea, I'm not sure how hooks could be built into the language that could work universally across all processor implementations. For example, if using MathJax to render, I'd imagine it would have to provide a way to register those hooks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, orunsubscribe.[AABTULCFV5QILWL4JSPREHTRPIAGXA5CNFSM4MWWBHNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5 WW2ZLOORPWSZGOEUKX7QA.gif]

[GarkGarcia]

I am not sure exactly where Gark is going, but my guess is that
what is wanted is something that looks like AsciiMath and extends
AsciiMath in the sense that any currently valid AsciiMath expression
is valid in the extension and has the same interpretation.

I'm currently studying markup languages that can serve as a viable alternative to LaTeX in the academic document preparation space. I'm interested in improving support for AsciiMath in the Asciidoctor tool-chain, besides discussing language extensibility — which I think is something that could be improved.

Right now, I'm working on implementing LaTeX output support for asciidoctor/asciimath, so that asciidoctor-mathematical and asciidoctor-latex can support AsciiMath.

But without understanding the problem, I don't see how to discuss
the solution.

Fair enough. I hope this comment helps in that regard.

But one thing I am pretty sure of: macros cause headaches.
Giving everyone the ability to make their own macros, usually
ends up with a mess that does little good. Most macros just
save a few keystrokes, and there are better ways to do that.

I agree. I don't think integrating a macro system is the way to go. Keep in mind that my standardizing abbreviation proposal does not involve the creation of a macro system. As stated in #111 (comment), there are alternatives to macros in the excitability front.

[GarkGarcia]

Anyway, that was bit off-topic.

@drlippman I'd like your input in this. Do you think this is a relevant discussion? I'd also like @pepijnve's input.