On 1 May 2015 at 19:20, Jonathan S. Shapiro <s...@eros-os.org> wrote:
> On Tue, Apr 28, 2015 at 8:26 PM, Keean Schupke <ke...@fry-it.com> wrote: > >> I actually prefer to allow instance definitions that are not put into >> implicit scope automatically. Then a separate directive brings an instance >> into implicit scope, otherwise it must be passed explicitly... >> > I tend to agree, though from a purely pragmatic perspective a convenience > syntax to do both at once is helpful. E.g. by inserting a keyword "default" > before an instance binding. > > I think the main points are: > It seems we think similarly on this: > > 1. merely defining an instance shoudn't require that you bring it into > scope as an implicit resolution > I agree, my idea of allowing record types to function as type classes might be going a bit far for BitC. In my own project a record with associated types can function as a module, a record and a type class. The way I separate module signatures from module implementations seems to cause problems for ML people, but I think module signatures should be types, and module instances should be entirely value-level. > 2. instances should be named, if only so that their visibility, import, > and export rules can be rationalized with the rules for every other kind of > binding i the language. > In my scheme instances are records, so are first class values, and therefore have the name of whatever variable they are assigned to, just like functions. > 3. some instances are defined in the preamble, and are so close to ground > that we don't want to have to explicitly "open" them. BitC has some special > rules about implicit import for preamble definitions for this reason. > There's no semantic change; it's purely a pragmatics issue. > There is no reason instances cannot be brought into scope (I use the 'use' keyword) in global scope. I would enforce instance coherence though, although I plan to allow backtracking which means coherence is defined as only one match including all the dependencies. Keean.
_______________________________________________ bitc-dev mailing list bitc-dev@coyotos.org http://www.coyotos.org/mailman/listinfo/bitc-dev
