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

[Zoltan Somogyi]

On Thu, 03 Oct 2019 10:58:12 +1000 (AEST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > 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.
...
> > > 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.

The attached diff implements this. For post commit review by anyone.

Zoltan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Log.occurs
Type: application/octet-stream
Size: 1230 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200415/26df45c9/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DIFF.occurs
Type: application/octet-stream
Size: 16796 bytes
Desc: not available
URL: <http://lists.mercurylang.org/archives/reviews/attachments/20200415/26df45c9/attachment-0003.obj>