Glue language notation thoughts

[Avery D Andrews]

Playing around with glue semantics notation (for the ultimate purpose of
including glue semantics in a new version of my Windows LFG system),
I'm wondering if people have looked into notational alternatives that
might be a bit more readable.  In particular, the 'new glue' notation has
an a visually hard-to-parse correlation between an arbitrary order of
lambda abstractions on the left, and the order of implications on the
right; I think it would be an improvement to replace this with direct
reference to the semantic projections inside the meaning, so that for
example the constructor for 'like' might look like this, using
underscripting:

 like(X,    Y) : h
    f_sig  g_sig


Or in a typographically linear format, maybe something like this:

 like(@f_sig, @g_sig) : h

Or when we need to make multiple use of one f-structure reference:

 shave(@f_sig:X, X)

(I'm not sure if this would ever actually be useful).

The benefit is that the irrelevant linear order is eliminated from
the notation, and the relationship between the variable positions
in the semantic structure and the f-strucure locations and semantic
types of their fillers is represented by the immediate and direct
one of typographical co-location.

A uninstantiated common noun meaning would look like this:

  dog(@(^_sig var)) : @(^sig restr)

Quantificational determiners will still look horrible, but could
be improved by the use of macros:

 CN    = (^_sig var -o ^_sig restr)
 Q[V]  = (^_sig -o V)

So we would get:

 every(X, @CN(X), @Q[H_sig](X)) : H_sig

or:

 every(@CN, @Q[H_sig]) : H_sig


which aren't too bad.

And perhaps the explicit parameterization of the Q macro could be elimated
with the use of a symbol, say, '*', designating whatever appears to the
right of the ':'.  Then we could improve quantifiers somewhat, and
do an operator adjective this way:

  alleged(@*) : f_sig var -o f_sig restr

The first meaning constructor for an intersective adjective
would look like this:

  Swedish(@^_sem var) : @^_sem

While the second one would look like this:

 lm X.@(^sem var -o ^sem)(X) and @*(X)
   : ((adj e ^)_sig var) -o (adj e ^)_sig cond)

which isn't wonderful, but I think a bit more readable than (33) on
Dalrymple (2000:266).

The lambda abstraction could be dispensed with if there is appropriate
polymorphism for 'and', so that it apply to type e->t as well as t in the
natural way, and the use of iofu could be eliminated if the constructor
were introduced by the c-structure rules rather than the lexicon:

  NP  ->    .... AP  .....

   @(v_sem var -o v_sem) and @*:@CN


I find it sort of intriguing how the * notation and the macro fit
together.

Well anyway I'd appreciate hearing if people working on implementations
have already figured out something to this general effect.

 - Avery Andrews