Collaborative articulation of how abstraction and language is employed in the computational manifestation of numbers -- including analysis of the role of syntax, semantics, and meaning in the specification and use of software interfaces.
The nfoCentrale Blog Conclave
nfoCentrale Associated Sites
While I think and post mainly about the theoretical abstractions that are important in getting Miser and the Frugal language done properly, I am also thinking ahead to the way the Miser engine can be delivered as a platform component (Windows DLL, .NET assembly, etc.) that hosts Miser on behalf of a software application. I have in mind that any kind of Frugalese user interface for a console application, including any interactive development environment (IDE), would be built atop a hosted oMiser engine as an important first case.
Because the Miser model is platform independent, it would be nice to have a platform-independent way to save, load, and interchange Miser “codes” in a neutral, highly-interchangeable format.
XML comes to mind. Although XML is not a compact binary format, it is a well-known, standard format for which a great number of problems are already solved, including versioning, the ability to deal with extensions gracefully, the complete hiding of the storage structure, and harmony with my intention that the Miser abstraction be universally comprehended. (That is to say, it shall seem as if there is only one oMiser in the world, and the fact that implementations are distributed and replicated is as invisible as can be practically achieved.) In the oMiser case, the XML stream would also be highly compressible using widely-available compression techniques.
The interchangeable “object code” among all oMiser implementations will be standardized in an XML stream.
I propose to abuse the purity of XML for this purpose. The XML will be well-formed but it won’t be the way XML would be naturally used to communicate a persistent format for oMiser Obs.
My basic plan is that the loadable Ob will be coded in a reverse-Polish notation conveyed in XML. The notation will have a syntactic structure that conforms to a BNF grammar such as
allowing the bottom-up build-up of an internal Ob representation as the XML stream is being read. Not every Ob operation needs to be implemented, only those needed for constructing constant Obs:
XML streams for the loadable format will be supported at the core level of an oMiser implementation. Given a handle on an Ob, there is an interface that will emit the XML stream for persistent representation of that Ob for any interchange purpose. Likewise, there is a low-level interface on every oMiser engine by which an XML stream is accepted and a handle for the corresponding Ob returned for use in the hosting application.
The XML representation will be flat. That is, the <oMiser:ob> XML element contains a flat sequence of <term />, <un-op />, and <bin-op /> elements. It is easy to process such a flat structure, and it is easy to ensure that such a structure is well-formed according to the grammar for〈ob〉given above.
There are three interesting challenges for this structure. These need to be explored to ensure that the choice of a reverse-polish Ob-loading is as practical as I intend for it to be:
I was reminded of all of this when I recently read the 2009-09-29 Rick Jelliffe post on context-free XML. The shoe-horning of the context-free reverse-Polish flat stream for〈ob〉as content for an XML <oMiser:ob> element creates a context-sensitive problem for expression in some sort of XML schema. This post is intended to elaborate on the comment that Rick’s post inspired from me. I trust this is useful context for that. (As usual, your mileage may vary.)
Discussing oMiser implementation considerations is long overdue in any case.
|You are navigating The Miser Project.|