Add "ker" as a standard symbol?

[GarkGarcia]

I think we could add the ker symbol to the symbols table. It's pretty common in Algebra, just like dim (which is included in the symbols table).

The expression ker would then be parsed as symbol('ker', :ker). Here is an example of it's use in context:

ker T = { v in V : T(v) = 0_W }

[GarkGarcia]

@pepijnve What do you think?

[pepijnve]

No objection from me, but we are deviating for asciimath.js then. Does that matter? I don’t really know.

Perhaps it would provide more flexibility if we define a way for users to extend the symbol table that doesn’t require code changes. The introduction of the SymbolTableBuilder should make that pretty easy. I’m thinking, for instance, that you could pass an optional block where appropriate that gets the builder (prepopulated with all the default symbols) passed in and then you add extra symbols in the block.

[GarkGarcia]

No objection from me, but we are deviating for asciimath.js then. Does that matter?

Indeed, we'd be deviating from the standard - if you can call it one. I personally don't mind this kind of change, since it wouldn't rely impact the language semantics. I also think that ker is common enough for us to include it by default.

Perhaps it would provide more flexibility if we define a way for users to extend the symbol table that doesn’t require code changes.

I was thinking about the same, we could introduce an extension model that relies on adding symbols to SymbolsTable, but there are some complications.

First of all, I believe there are three kinds of extensions:

1. Collections of abbreviations. Collection of key-value pairs, where key represents an expression that should be replaced by value. Something like { :key => 'ker', :value => 'text(ker)' }. Those would behave similarly to C macros, for examples. Notice this type of extension can be described using a data format, such as JSON or YAML.

2. Collections of symbols. A collection of key-value pairs, where key describes a symbols and value describes how key should be processed by each renderer. Something like {:key => 'ker', :value => {:mathml => '<mo>ker<mo>', :latex => '\\ker'}.Those would behave similarly to behave similarly to (1), but they'd be able to customize the behaviour symbol at the renderer level. Notice this type of extension can be described using a data format, such as JSON or YAML.

3. Extensions which require changes to the parser. Those would behave like hygienic macros. They would be much more flexible, yet much harder to implement.

[GarkGarcia]

Anyway. I believe we should create an issue to discuss this. However, this isn't really a priority at the moment.

[pepijnve]

@GarkGarcia 83886c4 takes care of the first necessary step to make the symbol tables extensible. I'm inclined to leave an external configuration system outside of the scope of this library. Seems better to leave that to the tools that make use of it.

[GarkGarcia]

I'm inclined to leave an external configuration system outside of the scope of this library. Seems better to leave that to the tools that make use of it.

Fair enough, makes sense to me.

[opoudjis]

Just as a random comment, @pepijnve : we had a document with ∓ in it, and we considered asking for support of pm as an operator in asciimath, since pm is already used in LaTeX.

I have rejected that approach. I do not think it is appropriate to extend asciimath on our own initiative, and to extend it to cover all of LaTeX. We do also support LaTeX, and I think it is appropriate for us to use LaTeX if we encounter symbols absent from AsciiMath, rather than make up idiosyncratic AsciiMath.

The extensible symbol table, though, is good news, and we may end up using it if it becomes available.

[GarkGarcia]

I have rejected that approach. I do not think it is appropriate to extend asciimath on our own initiative, and to extend it to cover all of LaTeX. We do also support LaTeX, and I think it is appropriate for us to use LaTeX if we encounter symbols absent from AsciiMath, rather than make up idiosyncratic AsciiMath.

I agree, and this is mostly why there's a question mark at the end of the title of this issue (even though I failed to express myself in clear terms). I think adding a couple of commonly used symbols such as ker and pm to our default symbols table is fine, but it is quite limited and it fails to address the bigger issue of extensible.

As a mathematician (or a student of mathematics, really), I think the main shortcoming of AsciiMath as opposed to LaTeX is that there is no default interface for defining new symbols/macros. This is hard to do because, unlike LaTeX, AsciiMath isn't a sand-alone language and it is purely declarative (which is why I love it, this is not the problem). Being purely declarative means that it is quite tricky to implement an ergonomic macro system, since it is assumed that a AsciiMath expression represents a mathematical expression that should be formatted and not anything else (i.e. a macro). Not being a standalone language means the extensibility mechanism is largely delegated to the host language/software, which complicates the creation of a standard.

I'm not saying that AsciiMath should be a procedural, stand-alone language, far from it (again, those are the reasons why I love AsciiMath). I'm just saying that this traits complicate our extensibility story, and I think that extensibility is something we need to get sorted out at some point. Of course, this is not an issue with asciidoctor/asciimath per-say, it's more of an issue with AsciiMath in general. I remember @pepijnve and I explicitly decided to not adding "functions that read macros from CSV/JSON" or something like that because we agreed we should keep this library at a lower level (those sorts of things should be implemented by the host language/software).

The extensible symbol table, though, is good news, and we may end up using it if it becomes available.

As far as I remember those are already available, but they do not support custom parameterized macros: you can define new symbols like pm but you can define new "AsciiMath functions" akin to color or root.