Hi Michael,
All you would need to add to OMeta in order to support "streamed output" (if
I haven't completely misunderstood your question) is a new kind of semantic
action that adds a new value to the end of the output stream. In other
words, just like
... -> (x + y)
produces a value,
... >> (x + y)
would add the same value to the output stream.
Implementation-wise, you would need to add an output stream (instance
variable or property) to your OMeta grammar objects, and make sure that the
output stream interacts well with backtracking. For instance, matching the
string 'x' with myRule (shown below)
myRule = foo bar
| baz,
foo = 'x' >> 1,
bar = 'y' >> 2,
baz = 'x' >> 3
should not result in the output stream holding a 1 and a 3. After all, the
first choice (foo bar) has failed halfway through, so it would be confusing
if some of its stream output persisted. I think the only sensible thing in
this case is to make the OR operator restore the stream to its original
state (empty, in this case) before trying the next choice. So in the end,
the output stream would only hold a 3.
This semantics should be pretty straightforward to implement.
Hope this helps!
Cheers,
Alex
p.s. I think that one of Ian's parser frameworks had / has support for
"streamed output", but I don't know any details, so it may or may not work
in the way I've described here.
On Tue, Mar 10, 2009 at 2:23 PM, Michael FIG <[email protected]> wrote:
> Hi all,
>
> I'm writing to ask Alex, Ian, or anybody else about a good way of
> extending OMeta or another grammar system to include optional streamed
> output.
>
> I've been experimenting with Figure, a small runtime environment
> written in C that has some similar sensibilities as COLA, but with the
> following different features:
>
> * Preferred single inheritance, with fallbacks to prototype delegation
> with separate self/state values (like libid's split between
> stateful_self and self).
>
> * Prototype multiple dispatch (see Saltzman and Aldrich) for
> high-level functions dispatched via a symbolic name followed by tagged
> arguments. Low-level functions are calls made with an integer as the
> head of a list and any arbitrary arguments (which don't need to be
> well-formed objects).
>
> * "World" argument to every high-level function reifies stack
> information, current object model, fundamental data types, any
> thread-specific information, etc.
>
> * Lisp-like signalled conditions with restarts allows for implementing
> exceptions or other unusual control flow (one frame signals a
> condition, any number of intervening frames offer possible actions in
> response, and an outer frame decides what to do).
>
> * Optional early binding allows lexical scoping and bypasses multiple
> dispatch for optimization or compiling down to zero-runtime code.
>
> * Aside from external threading libraries used explicitly by other
> components (such as pthreads, pth, libcoro, etc), multiprocessing is
> implemented by arranging parsers as a pipeline and invoking them with
> a specific scheduler. This requires a small extension to OMeta or
> Ian's new grammars to allow a grammar's production to return a stream
> of values (which reduces to a list if the caller expects a single
> value instead of a stream).
>
> I'm currently working on the grammar and scheduling features. I
> intend to implement the garbage collector as another parser pipeline.
> I'm quite interested in working on this system until it bootstraps and
> then merging anything useful with John's Church-State and/or COLA.
>
> If you would like to play with the system as it exists so far, it's
> currently available at:
>
> http://michael.fig.org/figure.c
>
> It's short on documentation, but there's a few pithy comments in it.
>
> Have fun,
>
> --
> Michael FIG <[email protected]> //\
> http://michael.fig.org/ \//
>
> _______________________________________________
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
