Portability

[Emily M. Bender]

On Sun, Mar 21, 2010 at 8:26 PM, Mike Maxwell <maxwell at umiacs.umd.edu> wrote:
> Emily M. Bender wrote:
>>
>> The LKB is open source software, which means that even if the
>> binaries no longer run at some point, the software itself could be
>> recreated.
>
> ...assuming the underlying programming language is still available.  I once
> wrote a morphological parsing engine in two languages--versions of C and
> Prolog.  Both versions became obsolete before I finished.  While the C parts
> would have been easy to port to a newer version of C, the Prolog would not
> have easily ported to a newer Prolog (it had a proprietary interface to C
> code).

As Stefan points out, the Live CDs also serve to ensure the availability
of software into the future.  Surely there will be many reasons aside from
language documentation/preservation to be able to emulate the x86 architecture
for a good long time.

>> ...The GUI relies on CLIM, which is not open source, but
>> the important parts don't.  I believe that the PET system (written
>> in C++) is also open-source.
>
> Ah, well, if it's in C++ then it's probably portable (I thought it was still
> in lisp).

The LKB is in Lisp.  PET is in C++.

>> As for working with Pashto or Inuit.  First, I don't think the language
>> being described has any influence on whether the beach is
>> attractive enough to lure Stephan for a visit
>
> That was a joke :-).  Pashto is spoken in Afghanistan, which is land-locked,
> and in parts of Pakistan that are far from the ocean.  And while there are
> beaches where Inuit is spoken, global warming hasn't made them warm enough
> yet...

Oops --- I hadn't assumed you'd be doing the grammar engineering in
the field, I guess :-).

>> We assume a separation of morphophonology from morphosyntax
>> (see Bender and Good 2005, CLS).  Recent work in the DELPH-IN
>> consortium has increased the sophistication available for the
>> interface between a morphophonological analyzer and the LKB
>> (or PET), but someone else will have to provide the details on
>> that one.
>
> We do our morphology separately (using the Stuttgart FST at present), so
> that's not an issue for us.

Glad to hear it.  Is the Stuttgart FST system open-source?   What
kind of rule formalism does it support?  (Anything like XFST?  We're
starting to think about making the Grammar Matrix customization system
facilitate the development of morphophonological analyzers linked to
the HPSG grammars, and are looking for a good open-source FST system
to work with.)

>> Finally, regarding the desire to blend prose description with formal
>> analysis in a single document: In my experience, the grammars we
>> write are not organized typically easily mapped onto a linearized
>> prose description which reads well.
>
> That also would not be a problem; it's easy to use Literate Programming to
> take grammar fragments scattered in any order throughout the descriptive
> grammar and map them into whatever format and order the target environment
> requires.  We currently do a much more radical thing than that for our
> morphological parser, as the morphology is written in a generic XML scheme,
> which is translated into the SFST programming language after being mapped
> into the necessary order.

I would be very interested to see what this looks like with a well-commented
HPSG grammar.  (And to learn what kind of best practices it would require
me to adopt in writing my---already prolific---comments.)  We are also starting
to look into ontological annotation of grammars (with GOLD), which might
connect here.

>> My current sense of the best
>> solution is to have the prose grammar and the implemented grammar
>> join through the examples.  To wit: all of the example sentences
>> in the prose grammar should be exported into a test suite, which can
>> then be parsed with the implemented grammar.
>
> Yeap, we do that with the morphological examples in our descriptive grammar,
> so we could do the same with syntactic examples.
>

Glad to hear that this also works for you!

Emily