[erlang-questions] Frames proposal

[Jan Burse]

Richard O'Keefe schrieb:
> Now Jan Burse and I have been arguing with each other about frames,
> but actually, that was a*lot*  more useful, because he focussed on
> semantics.

No I didn't care about semantics. The semantics is trivial since
as I interpret Erlang it does do some flow analysis of the given
code and sees to it that everything is ground, compared to normal
Prolog.

The flow analysis happens mostly implicit by having turned the
relation semantics of Prolog into a functional semantics. With
the sad result that one way to implement relation semantics in
Erlang is via continuation.

I was more concerned with usage and complexity. Your frames have
been invented many many times. I remember also some proposals
that retain the relational character, so that a pattern <{k1~v1,
k2~vn|F}> with a tail frame would become a first class citizen
of the language. These are then not called frames but rather
feature structures.

I guess one way to implement real feature structures in a logic
programming language would be to extend the unification so
that it works on feature terms with tail features. Feature
structures are very fashion in certain attribute grammar
formalism. Besides unification there can be further operations
between feature structures.

The simple syntax there for feature structures is [k1:v1,
k2:vn|F]. And it seems to be rather the rule than the exception
that a feature structure is open. This stems from the relation
ship of feature structures to equations, so the following
equations

       G:k1 === v1,
       G:k2 === v2

would correspond to the following feature structure relation:

       G===[k1:v1,k2:v2|_]

The (===)/2 in the two equations can be viewed as a
declarative combined setter/getter. So setter/getter
are by no way alien to logic programming and it is not
mandatory to go with a feature structure on the
surface of a language.

What seems to be a problem in the grammar domain is that
then practically highly recursive feature structures are
used. But some compilation techniques are able to flatten
them straight the way to records and removing all open
parts that are never closed. So that a feature
structure (*):

       [head:[cat:[n:A,v:B|_],agr:[per:C,num:D|_],
                           case:E,nform:F|_],bar:G|_]

Turns into:

        dag0(A,B,C,D,F,G)

In certain circumstances it can be also benefitial to turn
open parts into record positions. Maybe the grammar application
domain can provide further ideas for representing and optimizing
frame terms in Erlang, and vice versa. Most probably the
referenced paper below is already hopelessly outdated, and
people do even more clever things today. But anyway.

(*)
Compiling Feature Structures into Terms:
an Empirical Study in Prolog (1993)
by Andreas Schöter , Buccleuch Place
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.24.8407