Make foreign types include translations

[GoogleCodeExporter]

Provide an explanation of what the project should entail:

Foreign types currently just translate to "Object". It would be nice to be able 
to provide a more specific type.


Provide a concrete example of a problem this project will fix:

IOToken, Location, List, etc. All should translate to a more specific type than 
Object.


Provide a short guide on how to start this project:

Foreign types are found in modification:ffi.  Note that a solution should also 
deal with type substitutions, so [String] turns into ConsCell<StringCatter>.


Provide a rough expectation of what the set of patches completing this
project might look like:

1. A patch that solve central problem 1 (somehow!) described below.
2. A patch introducing type parameters.

Probable challenges in completing this project:

There are two central problems:
1. Where to put the translation string?
  a) Storing it in the TypeExp is wrong. Both innately and for several practical reasons. For one, because it would be repeated everywhere (e.g. in interface files) the type appears, which is unnecessary.
  b) Storing it in a DclInfo is right, but won't work.  The trouble is we can't always go from a TypeExp to a DclInfo, which is necessary because we produce translation types from the TypeExp.  The trouble is if you have three grammars x --> y --> z, where z declares the type, and y declares something using that type, and x uses that thing from y.
  c) Java has no 'typedefs' or anything of that sort, so it's extra difficult.
I do not know how to solve this problem at this time.

2. There exists multiple mechanisms for dealing with type translation.  One of 
these mechanism lacks type parameters, for use in getting .class objects, but 
this could probably be eliminated.

Additional Information:

Original issue reported on code.google.com by [email protected] on 28 Dec 2012 at 12:20

[tedinski]

A note: one might think "perhaps I can just add a translation to the type, oh well if that's not very elegant." But this would exacerbate a build problem.

Consider what happens if we change a type without doing a clean build. Grammars that import it see a different type translation, but they don't get re-translated to use it! Worse, they could see their interface files changed! Which means we'd need to re-analyze (and re-translate? And recurse?) them, too.

So to solve this we'd need a good solution to #36

[tedinski]

Current status:

We can supply a basic class (i.e. not parametrized like Foo<T>) now. This is accomplished by piggy-backing the information on the TypeRep. Ah well. Works.

Remaining work: deal with type parameters.

Note about build bug: this bug won't manifest if we never change how types translate. :) So if this is only used in the standard library and doesn't change, the bug shouldn't be experienced.

[krame505]

The build bug here is now fixed in #670, I think the only task left here is supporting type parameters.