[Cuis] Brainstorming question: what non-trivial uses can you think of for an object-based parser? (strings not invited)

[Thierry Goubier]

Hi all,

first post here about Cuis, and this is a question I am interested in... I
do believe the viewpoint institutes documents have a few answers about that
(parsers for network protocols, etc...). But still...

I'm in a strange position about OMeta which is I don't see the benefits. I
do have the same position about PetitParser, but with even worse data
points which is I know precisely the performance loss of going the petit
parser way.

I have been writing compiler front-ends for the past 7 years, first with
Flex / Bison and C, and then with Smalltalk / SmaCC (I maintain SmaCC for
Pharo). I see the work done by John Brant and Don Roberts first hand (RB,
SmaCC, generalised refactoring in SmaCC) and I know that both OMeta and
petit parser are using for me what is a very limited form of parsing, with
additionally a large performance penalty. Moreover, grammars produced in
the PetitParser case are as long, if not longer than the equivalent SmaCC
grammar.

So what are the benefits of OMeta? Note that SmaCC would very easily do
parsing over any kind of objects, not only tokens.

Thierry

2015-05-22 6:49 GMT+02:00 Phil (list) <pbpublist at gmail.com>:

> OK, I know we've been going on and on about OMeta recently but this one
> has a Smalltalk-centric twist:  it really just struck me that sure,
> OMeta can parse strings like nobody's business, but one of its claims to
> fame is that it is actually a fully object oriented *object* parser.
>
> So forgetting about all applications involving strings, what real world
> uses can you think of where an object parser might come in handy?  You
> have all of the capabilities that a parser brings to bear in terms of
> pattern matching and being able to speculatively introspect objects in
> its search, but on any arbitrary collection or stream of objects.  Keep
> in mind that anything coming in over the wire (i.e. network) has already
> been serialized so reconstituting it as an object graph seems
> inefficient and of questionable value if the sole purpose in doing so is
> to perform a task you could have easily done in it's default text/binary
> form... but maybe I'm looking at it wrong.
>
> The only thing that really jumps out at me is locally generated
> time-series data (be it midi, audio, video, whatever) where you are
> trying to prototype a solution without an existing framework and/or
> experiment with with what the framework you are developing should look
> like?  Another possibility (and I'm reaching here) is maybe some sort of
> funky resource caching/scheduling scheme?  Would the value just be at
> the investigative/prototyping stage or can you think of reasons why it
> would make sense to stick with a parser-based approach longer term?
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150522/e14d4f88/attachment-0004.html>