[m-rev.] for review: module_add_type_defn

[Julien Fischer]

Hi Zoltan,

On Wed, 28 Jun 2017, Zoltan Somogyi wrote:

> 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?

No.

> 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*.

Agreed.

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

My guess would be that the code for adding types was never updated
properly when the current version of solver types was added.

Julien.