On Sun, Mar 29, 2015 at 11:54 PM, Keean Schupke <[email protected]> wrote:
> I am assuming that the inference happens in the first compiler pass. > Actually in my scheme, because type inference is compositional the parser > outputs code already with inferred types. > I would prefer a scheme where we can type check a single unit of compilation. I'm still trying for that, but we will only be able to do code generation at the granularity of assemblies. > As long as we are dealing with a complete module (a reasonable assumption) > then we will have the full arity abstract (and concrete where necessary) > types for each term. > I agree that what you say is true, but I don't think we need to go that far. If we want to type check at unit-of-compilation grain, we simply require that cross-unit references be declared in the same way that module specifications are declared. > As such the function concretization pass only has to deal with fully > determined arity abstract types. > I'm not sure what you mean by "fully determined" here. > So in my scheme I plan to use normal curried types for arity abstract > functions. This leaves concrete arity functions, which I plan to use > multi-parameter arrows and bracketing. > I *think* that your multi-parameter arrows and bracketing are equivalent to my cfn syntax, and are merely a different notation. I'm certainly not stuck on the cfn notation. I adopted it here mainly to make the discussion clearer. I do suspect that we need *some* distinction in our notation to differentiate concrete arity from abstract arity, but both your proposal (bracketing) and mine (cfn) seem to have that. I'm less comfortable with using curried types for abstract function types, because there remains this issue of needing to track where required returns occur even while the function type is not yet concretized. This is driven by allocation constraints in BitC, so I'm not sure if it is an issue in your language or not. > As I want to check all arity abstract arrows have been removed after the > function concretization pass I will need to use a different arrow for > concrete arity functions so: > > a -> b -> c > > might become > > a b => c > > Depending on available definitions. > Checking certainly makes sense, but that arrow is already taken for qualified types. Since you plan to use bracketing, it seems to me that an alternative is to require that all concrete function types have bracketed arguments. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
