I’m a little late in this game, but I don’t quite buy that there is a problem with specialization of type-classes during separate compilation.
Consider macros (not C-macros, but macros based on AST manipulation). Can you support macros defined in another module? Of course you can, you just need to separate compilation into different phases, one dealing with macros and one dealing with regular compilation. You will have some naming ambiguities to take care of, but besides that there’s no real reason to abandon macros. As part of compiling a module, you get code and symbols – but also the table of macros, that are really a mapping from identifiers to ASTs. I believe type class specializations are in a similar category. While the specializations done for the same module can be done on the fly, external modules need to get access to the type class AST in order to properly specialize a new `sort` function with a different ordering. Thanks, PKE From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan S. Shapiro Sent: Wednesday, January 07, 2015 4:41 PM To: Discussions about the BitC language Subject: Re: [bitc-dev] Instance Coherence Revisited On Thu, Jan 1, 2015 at 1:44 PM, Keean Schupke <[email protected]<mailto:[email protected]>> wrote: My understanding is that it is a different type system, so the rules are different. Its okay for types to depend on values in a dependant type systems. You gain the ability to type these kind of things, but lose decidability. I agree. I claim that the requirement for values to be statically resolvable constants restores decidability *provided* you are willing to specialize hard enough. shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
