grammatica-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Grammatica-users] Identities


From: Matti Katila
Subject: [Grammatica-users] Identities
Date: Thu, 15 Sep 2005 21:48:28 +0300 (EEST)


Hello Grammatica people,


I have problems with identities used with Grammatica.
Currently Grammatica has primitive integer identity for tokens and
patterns. Thus can the user use those identity integers where they need
them by Node.getId() method, for example when analyzing parsed tree.
Token ids start from 1000, pattern ids from 2000 and generated pattern ids
from 3000.

Well, this sounds like good identity model for the first 10 seconds. Like
with web, you do not often use some ip address with it's numbers but domain
name instead.

I propose that Grammatica should add a grammar header declaration for
identity namespace which by default is empty. Then, instead of returning

    int getId();

in abstract class Node, it should return

    Object getId();

The nice thing with integers is that you can compare them with ==
operator, e.g., Node a, b; /* ... */ a.getId() == b.getId() would say
whether they are same integer number or not. So to be able to create
reference comparable objects I propose we use String.intern(). For example
in Node class:

    static public Object id(String createReferenceComparableString) {
       return referenceComparableString.intern();
    }

Now you can construct constant file by saying:

    public static final Object HEADER =
        Node.id("http://grammatica.percederberg.net/grammar#header";);

    public static final Object TOKENS = ;
        Node.id("http://grammatica.percederberg.net/grammar#tokens";);

    public static final Object PRODUCTIONS =
        Node.id("http://grammatica.percederberg.net/grammar#productions";);

The above example would be constructed if namespace
http://grammatica.percederberg.net/grammar was chosen and you still don't
need to use a.equals(b) in code.

Some cons with primitive integers too: they need to be wrapped with
Integer when put into map for example. That is, we might create a lot
of objects for every look up.

And finally to my problem with current identity "model".
When I use a two parsers in queue, first one as a lexer and the
second one as a parser, the identities intersect with each other.
I could fix it just by adding 3000 to parser identities but it would be a
hack over identity hack and I prefer better code and architechture in
overall.


   -Matti




reply via email to

[Prev in Thread] Current Thread [Next in Thread]