[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [imp-dev] Semantics of TypeStore
|
Hi Bob,
Good questions indeed. These are the responsibilities explained:
* TypeFactory: - construction and canonicalization of types (for which it caches the types, but that is an implementation detail of TypeFactory).
- TypeFactory does a limited amount of checking, i.e. whether Strings arguments are correct identifiers, and I think it should
start checking for null references in the future. Otherwise, it simply does what it says, which is construction of types.
* TypeStore: - Stores type declarations.
- It is basically a map from type names to types, providing storage and lookup by name. This only makes sense for types which
actually have programmeable names: aliases, abstract data-types and constructor types.
- TypeStore does more checking. It makes sure names do not overlap, i.e. names of alias types, names of constructors,
and names of fields of constructors. Because it collects several types in one store, it is able to see whether other types exist
that may clash. The limitations imposed by TypeStore on type declarations make sure that (de)serialization of values can be done
unambiguously and efficiently.
Example clients of TypeStores are IValueReaders and IValueWriters, which need to know what the definition of a type name is. E.g. when IValueReader
is called expecting a type "myInt", then the IValueReader would look up the definition of "myInt" in a TypeStore. Or when it finds a tree like "and(true,false)",
expection a "Boolean", it should look up the constructors for "Boolean" to find that a node named "and" of arity 2 indeed exists.
The other major client of TypeStores is TypeFactory. To create one of the named types, TypeFactory constructs it and stores it in a given TypeStore.
Example: TypeFactory.constructor(TypeStore s, String name, Type ... childrenTypes), builds a constructor type and stores it in the TypeStore.
By doing this we force the checking that TypeStore implements on all types that are constructed.
So:
* Caching is not an important consideration here, rather an implementation detail.
* Namespaces are not discussed or solved by either TypeStore or TypeFactory either, i.e. the actual names that are used for types are not qualified by storing
them in a TypeStore. This issue is left open by pdb.values as for now. Indeed, what you (Bob) are saying is that if we remove the import feature
from TypeStore, we don't step on the path of implementing namespaces of some kind.
* The TypeFactory is only an alternative implementation for "new Type()",
existing only because we want canonicalized types.
* TypeStores are "interfaces", i.e. collections of type declarations that are somewhat restricted.
A metaphor: like overloading method names in a Java interface is restricted, so are type declarations in a TypeStore restricted.
I hope this answers your questions!
Furthermore:
* we could do without the addAll() method alltogether; at least I don't need it to implement Rascal or lpg.analysis or java.core.analysis.
* Stan's suggestion about providing a base class with some default skeleton extensions is ok. I don't have a direct need for any extensions directly though,
so we could do with just a TypeStore with no imports and no addAll(). If the need arises, users of TypeStores can make their own extensions and propose
to contribute them to pdb.values if they appear generally useful.
Cheers,
Jurgen
On Wed, Feb 25, 2009 at 10:31 PM, Robert M. Fuhrer
<rfuhrer@xxxxxxxxxxxxxx> wrote:
Hi Jurgen,
Good questions.
It's true that always treating imports transitively could cause problems
since at this point there's essentially a single global namespace. E.g., if
TypeStore A imports TypeStore B imports TypeStore C, and A defines a
type Foo, a conflict arises if at some point TypeStore C starts exporting
a different Foo.
I think the addAll() proposal actually introduces another problem: now
clients of a TypeStore need to know where to find all of the other types
that are needed. In some sense this breaks TypeStore encapsulation.
We could try making encapsulation the default (i.e., importing a TypeStore
doesn't automatically import its transitive dependents), and permitting a
TypeStore to re-export types defined by its dependent TypeStores.
That said, I'm not sure that we're not conflating two issues here: the
notions of "interface" (or "module" or "namespace") and caching. To the
extent that TypeStores correspond to interfaces, all types are public
and necessary. Caching a type, on the other hand, shouldn't imply
exposing it to clients.
So, in other words, what's the real purpose of the TypeStore?
Canonicalization? Interface definition? Caching?
On Feb 25, 2009, at 11:17 AM, Jurgen Vinju wrote:
I was talking about TypeStore with Arnold Lankamp and we were thinking of removing
some functionality from it. Currently it implements an "import" functionality, which is designed
to lookup types through TypeStores that refer to eachother. The current implementation
does not interpret imports transitively. It simply searches for a type locally, and then in all
the imported TypeStores.
This design is inspired directly by the semantics of Rascal, but what if you want something different?
Sometimes you might want to have transitive imports, sometimes you don't. The fact that
we can discuss this is a hint that we may not want this functionality at all on the PDB level.
So, we could remove the import functionality from TypeStore, and instead add an 'addAll(TypeStore other)'
method to it. Then, the TypeStore acts like a store that manages (and checks) type declarations on the PDB level,
but nothing more. More advanced functionality could be implemented by user-defined sub-classes of TypeStore or
other classes that manage TypeStores. Or, direct API users in Java would probably need nothing more then this
simple TypeStore functionality.
What are your thoughts on this?
--
Cheers,
-------------------------------------------------
Robert M. Fuhrer
Research Staff Member
Programming Technologies Dept.
IBM T.J. Watson Research Center
IMP Project Lead (http://www.eclipse.org/imp)
X10: Productivity for High-Performance Parallel Programming (http://x10.sf.net)
