On Wed, Feb 18, 2015 at 9:42 AM, Jonathan S. Shapiro <[email protected]> wrote: > 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?
Presumably the difference would be that there isn't a type that means AnyKindOfInteger. It's a reasonable point, though. Incidentally, there probably *is* a type class that means AnyKindOfInteger (or at least could be), and it's possible arity genericity could be expressed using the basic type class mechanism. I'm not saying this is a good idea as such, but it does make me happier about the theoretical cleanliness. It also reminds me of Rust dropping functions as a primitive concept in favor of traits. Geoffrey _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
