Package code.type

This package abstracts a type.

See:
Description

Interface Summary

TypeExpression

Class Summary

FunctionType	The Function Type
Holder
HolderIterator	This class collects all the type expressions in a Holder class type expression cache into a convenient structure for iterating.
PredefinedTypes	Predefined type names
TableHolder
TypeConstructor	A Type Constructor
TypeConstructorApplication	A Type Constructor Application
TypeFactory	TypeFactory TypeFactory is responsible for the creation of types.
TypeHolder
TypeIdentifier	This is the abstract base class for all named type expressions in the FLVM.
TypeVariable	Represents a Type Variable.

Package code.type Description

This package abstracts a type. The type of any term is formed by a combination of objects from this package.

Overview

The abstract base class for all type expressions is TypeExpression. FunctionType, TypeConstructoApplication and TypeIdentifier are all TypeExpression s.

TypeConstructor and TypeVariable are the only two kinds of TypeIdentifier.

A FunctionType is used for any symbol that represents a mapping from a domain set to a range set. A TypeConstructor is used for a symbol whose type can be represented by an base type.

Details

Planned Enhancements

Flyweights and Factories for various "Type" objects

    Think about making a flyweight for each "Type" in Curry's module
    and also a Factory for objects of that class.

    For example:
    Instead of using "new TypeConstructor(typename)" every time you need a TypeConstructor,
    get the TypeConstructor from a factory.
    The factory should "cache" previously created instances of objects of that kind
    and return them (the flyweight objects) for future requests.
    If the requested object (some kind of type) is not cached,
    then create it, put it in the cache and then return it.

    This puts the intelligence of caching the objects in one place. eliminates several singletons.

    // TypeConstructor: Analysis of the problem
    Statically there are 28 uses of TypeConstructor in the code.
    Dynamically, just to load prelude once, it is invoked 509 times.
    Dynamically, to load prelude the second time, the total (including prior) invocation count was 1006.
    Implementing will improve the loading of modules.
    Implementing may not improve execution time. have not investigated this aspect.

    // TypeConstructor: Implementation Approach
    add a new data member
    static private cache of TypeConstructors;
    // decide the implementation. Hash table?
    // If you want a cache for Types then Trie is a better data structure.

    make the constructor for TypeConstructor private
    and in the constructor, once the object is constructed, add it to the cache of TypeConstructors.

    add new method
    static TypeConstructor getTypeConstructor (String name) {
        if ( name found in the cache )
        then return the found type constructor
        else { return new TypeConstructor (name) } ;
    }
    // OR (this is preferred)
    // add several makeXXX methods, one for each kind of type constructor &/or type subclass.
    //// this implements the factory.

    add several static TypeConstructor objects, one for each commonly occuring type.
    and change code to use these instead of calling the constructor.
    //// This implements the flyweight objects.

    Flyweights and Factories work well for classes that have immutable objects
    so that all data members of such a class could be public final.
    Instructions should be immutable.