On 30 March 2015 at 14:27, Jonathan S. Shapiro <[email protected]> wrote:
> 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. > A module is smaller than a unit of compilation in my view. A file can contain many modules. > 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. > See above, a compilation unit is bigger than a module. > 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. > All type constraints resolved. Not with type variables left that we could replace with type-terms. > 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 think I agree. Multi parameter arrows with backets just seem to be good syntax to me. I think brackets are best used for nesting, and a multi-parameter arrow matches the semantics of a call operation. > > 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. > I don't see why we need to track that. If the value returned is never used, we don't care if its a function, and we certainly don't need to know its arity. > 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. > Well there's still ~> which is quite readable in ASCII. Keean.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
