Monday, October 23, 2006
The grammar is not the code--except when it is the code
The more I think about ALG problems in the context of a tree adjoining grammar, the more I'm convinced that the grammar is the code. But first, two claims (for which I''ll defer defending--in time, gentler readers, in time)"
1 - In a quiet moment of reflection, we admit (at least to ourselves) that some measure of our motivation in developing ALG machines is to disturb (piss off , if possible) "real" writers. To do that ALG has to find and walk the line between utter conformity and chaos. If we are to be a viable threat to "real" writers, our output has to be recognizable as poetry--it has to conform to a greater or lesser degree to the forms of the near greats: the language poet, the memoir poet, the authentic poet, the confessing poet, the conceptual poet, and especially the academic poet. At the same time, our texts have to appear "original." More simply: While they are being same enough to compete, they have to be different enough to compel.
2 - In a well-behaved OOP application, all of the work should be done in objects, those little ontological islands of definition and capability. We are at our best when our programs exemplify the OOP programmer's mantra: Objects should be responsible for their own behaviors.
Our first two "serious" etc attempts tried very hard to be sets of collaborating objects: Poem objects that knew how to select utterance objects that knew how to select constituent objects that new how to select lexical objects, a veritable Russian nest egg of surprise.
But.... How to control the selection of the utterances in the first place. We want some fully-fleshed sentences, so we can compete with Poetry. We want some fragments so we can compete with Jacket. We want some lyricism (but not too much). And so on and so on and so on....
My programs inevitable contained (within the poem object) a very procedural method (Poem.Compose) that did a lot of weighted selections of different forms and that code gets really ugly, really fast.
But what if all of that were in the grammar? Even better: Why not right smack dab in the TAG nodes themselves? Let them decide when and what to adjoin and adjunct with. Let them make the lexical choices.
Then the grammar can be open-ended. As long as the programmed node types line up with their attendants in the grammar, we can just add new grammatical structures at any time and never touch the program. We can have multiple grammars, one for language poetry, one for memoir, one for confession, one for authenticity. We can define new grammars by splitting existing grammars into pieces and splicing grammars together. We can have one grammar for an initial stanza, another for the bridge, and a return to the first for the finale.
I have a prototype working. The code is so clean, I suspect faeries are stealing into my computer at night and replacing my heavy, swarthy code with their light and emphemeral programs.
BTW: Notice how a well-placed frame of skeptical quotation marks makes me sound especially arrogant and smart. Just part of learning how to compete in the academy.
# posted by Jim @ 4:42 PM 
