[m-rev.] for review: do occurs checks on the parse tree

[Julien Fischer]

On Thu, 3 Oct 2019, Zoltan Somogyi wrote:

> On Wed, 2 Oct 2019 19:50:50 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
>> That looks fine.
>
> Ok. Attached is the updated diff, for postcommit review by Julien.

The diff looks fine.

> This diff does not yet try to filter out false warnings, because we first need
> to decide how that should be done. There are four possibilities for f in X = f(...X...)
> that we need to consider for that:
>
> 1. It is defined as a data constructor, and not defined as an executable function.
> In this case, it is clear we should generate the warning.
>
> 2. It is not a data constructor, but it is an executable function.
> In this case, it is clear we should NOT generate the warning.
>
> 3. It is defined neither as a data constructor or as an executable function.
> This will definitely yield an error from the type checker, so whether we generate
> a warning as well does not really matter.

It does matter in the sense that the warning will just be noise in this
case (i.e. we should not generate it).

> 4 It is defined *both* as a data constructor and as an executable function.
> In this case, a warning may be on point, or it may be misleading, depending
> on what the typechecker eventually decides.
>
> The question is: should we generate a warning in case 4? If yes, we can do that
> by passing down the set of data constructors to superhomogeneous.m,

Specifically it only requires the set of non-zero arity data constructors. 
(Not having to deal with enums would be advantageous since enums are
quite common and can get quite large.)

> the X on the LHS to the ancestor var map when processing X = f(...). If not, we can
> do that by passing down the set of executable functions to it, and *clearing* the initial
> ancestor var map when processing the ... in X = f(...) if the f is an executable function.
> I see no reason to pass both the set of data constructors and the set of executable
> functions; depending on how we want to handle case 4, one or the other won't be
> needed.
>
> I prefer "yes" on case 4. Any other opinions?

I prefer "yes" on case 4 as well.

Julien.