Hi all,
I agree this is a long way off but while on the subject...
I don't think it is possible to create a well defined API in quite that way.
Firstly you have to consider where the API might be used.
That gives you at least two environments:
web based - where _javascript_ is the only acceptable common denominator (until WASM is more mature - unless you want to mandate asm.js)
native - where C is still top dog for most portable API language - meaning you lose or have to wrap 'modern' functionality - OO, automatic memory management etc.
(though in practice you could get away with C++ on any gcc platform except for highly constrained embedded platforms)
What you could do instead is define a reference API in a specific language and encourage people to implement the same API (via wrapping lowest common denominators like the above).
You then built that to the highest quality possible but in layers so that implementors can gradually increases levels of compliance (like DOM level 1, level 2 for XML).
What I think is actually more important here is the domain model / ASG. This needs to be designed to reflect the semantics and should not be coupled too tightly to the syntax.
The model for extensions should be in terms of external 'routines' that manipulate the ASG possibly subject to some limitations.
The extensions are then as portable in principle as the low level API is.
I strongly agree with @David Jencks
"Cross (computer) language portability has a long and unsuccessful career in programming"
"We have a giant challenge to develop a grammar. Lets not add some known-to-be-unsolvable problems to our task list :-)"
We one caveat. I think the semantics are far more important than the syntax.
The reason I use asciidoc rather say markdown is that the semantics go furthest in principle towards 'doing anything with text'. Its like docbook without the ugly XML syntax.
Representing "meaning" is an even deeper rabbit hole than cross language portability - as its AI complete - but there is a good foundation to work from.
You don't need to go all the way down provided you have good abstraction mechanisms.
These should be based on the semantics wherever possible rather than text substitution.
Text substitution is an important use case however. I would like to be able to use asciidoc as a templating language instead of something like
Mustache | Mustache (template system)Mustache is described as a "logic-less" system because it lacks any explicit control flow statements, like if an... |
|
|
text substition seems easier to naive (and even not so naive) implementers but it stores up a wealth of problems for the future - like the C preprocessor.
Some kind of module mechanism will need to augment or replace includes as soon as possible (but likely V2).
There is a fundamental tension between trying to write freely, try to make text presentable and trying to fully represent the semantics.
The weapon against complexity is abstraction.
The web industry has learned there are seveal layers including:
stylesheets
Likewise the software industry has explored many kinds of abstraction:
composition
polymorphism
Hygienic macros
| Hygienic macroIn programming languages that have non-hygienic macro systems, it is possible for existing variable bindings to ... |
|
|
The first thing is to stabilize the
specifications for V1 which is enough work in itself but beyond that
these matters need to be taken very seriously
lest an even better semantic markup topples asciidoc off its throne.
Regards,
Bruce (randomly delurking user / collaborator)
