The problem us not with specialisation, its with two or more instances for the same type.
As long as one instance is more specific I don't have a problem with them overlapping, I don't know if anyone else had an issue? Keean. On 9 Jan 2015 19:34, "Pal Engstad" <[email protected]> wrote: > 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]> 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 > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
