[m-rev.] for review: module_add_type_defn

[Zoltan Somogyi]

On Wed, 28 Jun 2017 15:00:10 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> >
> > Do you (or anyone else) have any opinions on the issues marked by XXXs in the
> > affected code, old and new? For example, the attached program compiles just fine
> > both before and after this diff, but I think that the definitions of foo1 and foo2
> > should both get an error, and one of rafe's old comments says that foo3 should
> > get one too.
> 
> Every type in the attached program should should result in an error.
> All three types are declared as solver types but (1) the definitions
> lack the 'solver' keyword and (2) they also lack the 'representation'
> attribute which is mandatory for all solver types (See the "Solver type
> definitions" section of the reference manual).

OK, we seem to be agreed on that. I will get on to it once we settle
the next question, which is: suppose a type has a proper solver type definition,
with a representation clause and everything. Should that type be allowed
to have any foreign_type definitions?

I would say no: if the solver state is stored in a foreign language data
structure, that should be expressed by the *representation type* being
a foreign type, not in having a foreign_type definition for the *solver type*.

However, the existing implementation says yes; it allows having both a
solver type and a foreign type definition for the same name.

> > And should it be an error to declare (not define) a type in both
> > the interface and the implementation section of a module?
> 
> It's an error for predicate declarations, so I suppose for consistency
> it ought to be for types as well.  (Note that typeclass and instance
> declarations in both the interface and implementation are also both
> also currently allowed.)

If noone objects, I will do this soon as well.

Zoltan.