<html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-forward-container">In other words, building mod2 as a library should not be possible <blockquote type="cite" cite="mid:20210514181244.GX1331@kola.localdomain"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">without an error or at least a warning. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Ok, so it would be a warning like --warn-dead-preds but the analysis would be much more difficult. </pre> </blockquote> You phrased the intuition underlying my 'pragmatic user' remark. A library typeclass predicate should not be allowed to compiled into a library if there is no type to satisfy the typeclass constraint. <blockquote type="cite" cite="mid:20210514181244.GX1331@kola.localdomain"> <pre class="moz-quote-pre" wrap="">I don't know how difficult, but just for thought: :- module m1. :- interface. :- typeclass tc(T) where [ pred eval(T::in, int::out) is det ]. :- type foo ---> some [T] foo(T) => tc(T). :- func make_foo = foo. :- pred eval_foo(foo::in, int::out) is det. %-------------------------------------------% :- implementation. :- instance tc(int) where [ eval(I, I) ]. make_foo = 'new foo'(42). eval_foo(Foo, I) :- Foo = foo(X), eval(X, I). It's plausible that because: (1) make_foo is exported (2) make_foo returns a foo (3) foo has a class constraint tc(T) (4) the make_foo implementation returns a foo where the existentially quantified type variable T = int then we could deduce that 'instance tc(int)' is usable, but it's highly unlikely anyone will implement such a thing. Peter </pre> </blockquote> Stimulated piece of coding. If I understand you well, there might be convoluted cases in which an exported typeclass, without an abstract instance in the interface, could probably be used in a parent file if the type instantiation is somehow bootstrapped (or 'lifted up') by existential quantification plus symbol export in the interface of the module. But (reassuringly?) this does not work. Yes, your module m1 does build into a library, but the ominous "unsatisfiable typeclass contraint" error message pops up again if you try to import module m1 into a parent file and use 'eval' like this: <blockquote> :- module test4. :- interface. :- import_module io. :- pred main(io::di, io::uo) is det. :- implementation. :- import_module int, string, list. :- import_module m1. main(!IO) :- eval(42, I), io.format("this int: %d\n", [i(I)], !IO). </blockquote> Building your m1 module (as-is) and test4, using DEV compiler (at HEAD), with: <blockquote> /usr/local/mercury-DEV/bin/mmc -E --make libm1 /usr/local/mercury-DEV/bin/mmc -E --make test4 </blockquote> I obtain: <blockquote> test4.m:014: In clause for predicate `main'/2: test4.m:014: unsatisfiable typeclass constraint: test4.m:014: `m1.tc(int)'. ** Error making `Mercury/cs/test4.c'. </blockquote> So after all, implementing something like a '--no-unsatisfiable-typeclass' warning option in the compiler may well be easier than expected. Coming back to my first post code, I now realize I have to slightly correct my remark. An error message cannot and should not be issued at library compile time as it is correct Mercury syntax (and good common sense) to satisfy the typeclass instantiation constraint anywhere else than in module mod2. So it is not strictly necessary for an abstract instance declaration to be present in the **same** module as the typeclass declaration. E.g., the following builds and runs fine: <blockquote> %------- file mod3.m -----------------------------% :- module mod3. :- interface. :- import_module string. :- typeclass eval_type(T) where [ pred eval(T), mode eval(out) is det ]. %------- file mod4.m -----------------------------% :- module mod4. :- interface. :- import_module mod3. :- instance eval_type(string). :- implementation. :- instance eval_type(string) where [ pred(eval/1) is eval_string ]. :- pred eval_string(string::out) is det. eval_string(Result) :- Result = "a". %------ file test4.m ----------------------------% :- module test4. :- interface. :- import_module io. :- pred main(io::di, io::uo) is det. :- implementation. :- import_module string, list. :- import_module mod3, mod4. main(!IO) :- eval(S), io.format("this string: %s\n", [s(S)], !IO). %------------------------------------------------% </blockquote> So, the 'pragmatic' improvement that I am advocating could not go beyond a warning message at library compile time. Alternatively, it could be implemented in the linker after all the dependency graph has been resolved, if it is found that there is a typeclass with no one type to satisfy it. Fabrice. </div> </body> </html>