Please sign in to comment.
Mailing list post
- Loading branch information...
|@@ -0,0 +1,21 @@|
|+The obvious roadmap for Marpa interface writer is, when I finish Marpa::R2, to upgrade to it. But there is another possibiity. Marpa::R2 will have a low-level interface to Marpa -- libmarpa, a C language library. There will also be a Marpa::R2:Thin -- a fast, no-frills Perl interface to libmarpa.|
|+Interface writers switching to the "thin layers" (Marpa::R2::Thin and libmarpa) will face a considerably more challenging conversion -- they will have to redo everything currently done at the Perl layer by the "thick layers" (Marpa::XS and Marpa::R2). In making design choices, whenever the thin layers could gain in efficiency or flexibility, I chose to do so, even at the price of programmer-friendliness. This goes against the prevailing wisdom and/or fashion, but my reasoning was that a decision against user-friendliness was something that an upper layer could always undo, so that I was in fact giving the programmer the best of both worlds.|
|+Because of the difficulty of working directly with the "thin" layers, I do not expect that typical application writers will use them directly. Instead, they are targeted at writers of higher-level interfaces, who now are forced to incur the overhead, and work within the restrictions, of Marpa::XS. For writers of higher-level interfaces, use of the thin layers will have several advantages.|
|+1.) The thin interfaces avoid almost all Perl overhead of Marpa::R2, and therefore interfaces built on them should run much, much faster. The Marpa::R2::Thin methods will go straight to XS -- that is, directly to C code.|
|+2.) The thin interfaces do not have the restriction of the "thick" interfaces. The "thick" interfaces make many choices that the "thin" layers leave up to the user. These choices are not minor or matters of detail: among them are all naming conventions, most defaults and almost the entire semantics.|
|+3.) Much more object orientedness. The thin layers will have separate objects for (in sequence) grammars, recognizers, bocages (parse forests), parse orderings, parse trees and parse valuators. Objects in each class in this sequence will have a one-to-many relationship to objects in the next class in the sequence.|
|+4.) At the libmarpa level, there are no strings, which means that all decisions involving strings are up to the higher levels. Symbols and rules are integers in libmarpa, leaving naming conventions up to the higher levels. Similarly, errors are represented by integer codes.|
|+5.) Token values are only tracked as a convenience for the higher levels (which could track them themselves) but even they are coded as integers -- the intent is that interfaces using libmarpa's token values will typically index an array with them to get at the actual token value. This leaves all questions of what an token value actually is up to the higher level.|
|+6.) Even though libmarpa has a valuator, almost all of the semantics is left up to the interface. libmarpa's valuator does not directly maintain the evaluation stack -- instead it issues instructions on how to manage it. These instructions indicate the rule or token involved, where the result goes in the stack, and, in the case of a rule, where the operands for its semantics are to be found. What goes on the stack, and what form the semantics of rules and symbols take, is left entirely up to the higher-level.|
|+7.) Libmarpa's valuator may sound strange, and it does in fact take some getting used to, but it offers two major advantages over callbacks. First, and most important, the problems of debugging semantics (say, for example, Perl closures), inside the environment of a C library are avoided. All code is executed in its native environment. Second, libmarpa's valuator is faster than callbacks.|
|+8.) Note that, if you really do think callbacks are the right way to do semantics, the upper layer can also convert libmarpa's instructions into callbacks. This is, in fact, exactly what Marpa::R2 does at this point.|