anthonycanino1 / ent Goto Github PK

Currently we allow a ModeSubstType and a regular Type to be able to match on type system methods (typeEquals, isSubtype, descendsFrom, isImplicitCastValid, isCastValid). What this means is that if the type system attempts to check a type against one that has been substituted instead of erroring we forward this call to the ModeSubstType's base type.

This allows much more of the type system to type check without horribly affecting soundness. The alternative is to make sure every possible type is always mode substituted, which is tricky to do with the compiler internals, not external code (as that can be caught and fixed in the class loader).

mcases work correct when the assumption is made that they will be resolved on use, and mcase types see through to the base type. Things like the following work, but are not sound...

class A {
  mcase<int> f1 = mcase<int> {
    low: 0;
    mid: 1;
    high: 2;
  };

  public int getF1() {
    return this.f1;
  }
}

However, attempting to return an mcase does not work...

public mcase<int> getF1() {
  return this.f1;  // Will error
}

This is more of a design issue on how mcases should be implemented. Will revisit.

ModeValues use should be restricted to attributor and snapshot bounds only. Currently they can used anywhere (but it will always cause a compile error).

See
ModeValue_c.java

Compile /tests/simple/ConMap.java to trigger error. Grep 'BUG18' to see exact spot. Basically need a way to compare to JL5SubstTypes actual type args linearly (not from the maps from a Subst object).

There is a way to get that information, resist later.

Right now a type's mode type will be set to the wildcard mode type if the mode type is elided. This helps us prototype, but eventually an elided mode type should create a mode type variable that is then subject to inference.

Just like generics can be extended, the same needs to be done with generic mode types. This needs to get added in, and is probably closely related with the java.lang.Object issue.

polyglot encapsulates type substitutions on generic classes (SubstClassType) with a Subst object (similar to our ModeSubst object). One major difference is that Subst objects are unique (all equivalent substitutions use the same object) which is cached for performance and equality checks. Our ModeSubst should be converted to something similar.

See
panda.types.ModeSubst.java
panda.types.ModeSubstEngine.java

We currently attempt to output JL5 code (we use JL5OutputExtensionInfo) by using an extension rewrite pass. There are two issues with this.

• If extRewrite is defined for a polyglot node, it rewrites to JL, not JL5.
• If extRewrite is NOT defined then Node.java will call copy(NodeFactory) which itself not always defined.

The quick solution is to extend the node (with a PandaExt) and manually copy it during the rewriting. A better solution is to figure out exactly how polyglot removes java 5 constructs and perhaps tap into that to be more consistent.

Serialization/deserialization needs to be handled inside Panda if we ever want to seriously produce energy libraries.

The issue is that ModeTypes are not ClassTypes, thus deserialization does not link created mode types properly (one set of .class files has a different 'WildcardModeType' than another). In other words, we loose reference equality.

The same issue will happen with declared modes, but for now there is a hack in place (done in the deserialization of ModeSubstType) to fix wildcards and dynamics.

Arrays do not currently support mode types. An array will be given a ModeSubstArrayType in the type system, but the language does not support anything further.

This is a nontrivial issue. Array dims have to be handled, which means that mode type have to be substituted across the dims (i.e. what does a String@mode[] mean?). Will revisit.

If we allow wildcard mode types to be carried through to the runtime (this is done until inference is implemented) then we need a way to properly allow an mcase resolution for an object with a wildcard mode type.

Either default it to high, or translate wildcard mode types before passing to the runtime (this could lead to issues as well).

We allow Field Access and Call's to also work on types that have not be mode substituted (same as issue #5). This is for code that is loaded that has not been given a mode substituted type (but all compiled code will not hit this).

We will revisit this issue.

TypeVariables are an interesting problem for mode substitution. Right now they are ignored, but they need to be handled. The problem is that type variables really gain their type when they are instantiated, but that instantiation needs to be checked against the constraints.

Our constraint checking is going to have to add and save some information to the type system. Simply erasing generics is not going to work.

Issue can be seen when compiling sunflow (SunflowGUI.java:484) on type <anonymous subtype of java.awt.event.ActionListener@mode<*>>.

Break at PandaNewExt.java:152. Temporarily passing up to parent language for now.

Currently (related to previous issue as well) not all classes are substituted (java.lang.Object) being one of them.

A lot of this can be seen when working with generics (java generics) and the warning are left in the compiler to remind me to return to them.

Method mode type parameter subs looks like it causes many of these issues to pop up, reminder to revisit.

snapshot is currently implemented and working in the language. There are some simple optimizations that can be should be added however.

• Semantic checking for what will statically always fail. This check will need to take in to account the range of the attributor and the range of the snapshot.
• Remove range check if snapshot will never fail. This requires some new functionality to be added to the runtime (unsafe PANDA_Snapshot.snapshot etc).

See
panda.ast.SnapshotExpr.java
panda.runtime.PANDA_Snapshot.java

Some of the builtin classes are not substituted which becomes a problem after all other classes have been. Polyglot creates singleton objects for these classes which can be intercepted and substituted, but they may need to be substituted with a type variable. The actual problem arises when a class subclasses these, which may need a specific work around versus some kind of major substitution, since that is not really the right answer.

i.e.

String extends Object is originally ParsedClassType extends ParsedClassType, but String will be substituted at inst time, resulting in something like ModeSubstClassType extends ParsedClassType. A ModeSubstClassType should handle this, since if the parent class was not declared with a mode, it should be the same as the mode assigned to the child.

Currently the attributor does not allow a ModeValue to be returned that contains a ModeTypeVariable (an attributor cannot resolve to a mode type variable). This should be relaxed.

We need to translate these properly; I write directly to JL5 from Panda which will recheck a switch over a string and fail in the JL5 pass.

See issue #14. It's the same problem.