On Wed, Apr 1, 2015 at 5:28 AM, Keean Schupke <[email protected]> wrote:
> Apologies for net getting this. Even as a parameter 'keean' will be used > somewhere in the module where we can get the type of 'f' passed, or the > type will be declared when 'keean' is exported. > Who says keean is ever exported? There is absolutely no reason to believe that keean is ever used at all! Keean: you really need to stop arguing with the example. You've been given a challenge problems with certain constraints on what you are allowed to do. Please address the problem within the constraints, and stop insisting on magically derived information that the constraints do not permit. Even if what you say is true, the type of keean has to be derivable using only (a) information available from the lexical scope (and in this case we have no such information for f), or (b) information available by examining the body of keean itself. That's all you get. > In any case, I think I can type this without any information about 'f', by > inferring arity-abstract types with inferred concrete arrows. > > On 31 Mar 2015 23:59, "Jonathan S. Shapiro" <[email protected]> wrote: > > > def keean f a b c d tst { > > if tst > > f a b > > else > > f a b c d > > } > > Note, I have changed the inferred types from earlier, as the previous > scene had a problem if you inferred purely arity-abstract types. The > solution appears to always infer arity-mixed types with concrete arrows > where necessary. > > First use of f: > > a -> b => c > > Second use of f: > > e -> f -> g -> h => j > > Unifying these: > Well, that's the answer that *I* gave, but I don't understand how that relates to your fully abstract arrow types. Given the description that you gave of your fully abstract arrow types, I don't understand how to express what you wrote above (which uses call arrows) in your notation. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
