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

[Zoltan Somogyi]

On Thu, 3 Oct 2019 10:54:06 +1000 (AEST), Julien Fischer <jfischer at opturion.com> wrote:
> > Ok. Attached is the updated diff, for postcommit review by Julien.
> 
> The diff looks fine.

Thank you.

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

That is exactly what the "really" qualifier in my mail above was meant
to convey.

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

Good idea.

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

Ok, I will do that then. But not right now; I am working on changing
some of the type representation data structures, and I would rather
do this change just once.

Zoltan.