On Tue, Feb 17, 2015 at 10:09 AM, Geoffrey Irving <[email protected]> wrote:
> The main > issue I see is that arity abstract functions are not first class in > that they can't be stored in data structures. That makes certain > kinds of functionality programming less intuitive, since it means > libraries designed around arity abstract functions would force users > into somewhat unintuitive allocations for many kinds of callback code > (even if these allocations were explicit). For mutated (therefore monomorphic) slots, I agree with what you are saying. As a practical matter, I'm not sure that's all that much of an issue. First, we deal with it all the time in other languages. Second, you can always choose to do impedance matching with a lambda. But more generally, I'm not sure this is much different from the situation for, say, integers. Given the definition: def SomeSortOfInteger = 1 there are 8 candidate types for SomeSortOfInteger. Unless it's mutable, we simply allow it to be polymorphic. Why isn't it the same for abstract function types? shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
