🚀 go-pugleaf

In article <1991Mar05.021953.11576@comp.vuw.ac.nz>, steve@comp.vuw.ac.nz (Steve Cassidy) writes:
> My terms look like:      447:[class24]/[a]/[class42, e, #]/[ey]
>                       RuleNo:LeftContext/Graph/RightContext/Phon

Operators make for pretty input, but inefficient storage.
On a typical Prolog system, storing
	RuleNo:LeftContext/Graph/RightContext/Phon
will give you a tree looking something like
	:(RuleNo,
	    /(                                        ,Phon))
		/(                      ,RightContext)
		    /(LeftContext,Graph)
which takes 4*3 = 12 words of overhead in addition to the elements stored.
To access	RuleNo		costs	1 "compound" unification step
		LeftContext		4
		Graph			4
		RightContext		3
		Phon			2
If instead you used
	rule(RuleNo,LeftContext,Graph,RightContext,Phon)
then the space overhead would be 6 words, and accessing each element
would take 1 "compound" unification step.

As I said, operators are pretty, so if you are reading rules, it may pay
you to read them in operator syntax, and then flatten them:

	flatten_rule(RuleNo:LeftContext/Graph/RightContext/Phon,
		rule(RuleNo,LeftContext,Graph,RightContext,Phon)).

so that computations can use the more efficient form.  You can use the
same rule to re-introduce the operators for output.

I'm interested in hearing about Prolog-based work on morphology.  Any
more information available about the application/project?

-- 
The purpose of advertising is to destroy the freedom of the market.