[m-rev.] for review of the concept: delete free/1

[Julien Fischer]

On Sat, 22 Jul 2023, Zoltan Somogyi wrote:

> Delete mer_inst's free/1 functor.
> 
> This functor was intended to have the same semantics as free/0, while
> containing the type of the value it was applied to. However, commit
> 87e7e3bafa641d0205c8b129e55940b01acd5235, the commit in which Fergus
> introduced this function symbol, also contained an "XXX temporary hack"
> in which the code that was supposed to create a value using this function
> symbol when propagating a type into a free/0 inst, just ignored the type,
> and left the inst as free/0. THIS TEMPORARY HACK HAS REMAINED IN THE CODE
> SINCE 1994.

It is rather stretching the definition of "temporary" a bit ;-)

> In a few places, we did hand-create insts using free/1 for code created
> by the compiler itself. However, as far as I can tell, no free/1 inst 
> ever described any code read in from source files. This meant that
> any code in switch arms for free/1 in switches on insts was never tested
> in any meaningful sense. And predicates such as inst_merge_4, which
> processed several kinds of insts without doing a complete switch on insts,
> simply lacked code handle free/1 at all.
> 
> This diff deletes the free/1 function symbol. It does so NOT because
> the type stored as its argument is not useful, but because it is useful
> NOT JUST for free insts, but for ALL insts. This means that any mechanism
> for providing information about the type of the value that an inst applies to
> should work for all inst. This can be done

s/inst/insts/

> - either by passing along the type with every inst, and stepping into
>   the argument types of each argument of a function symbol as we process
>   bound insts, in every operation that operates on insts that needs
>   type information.
> 
> - or by including a type in ALL the function symbols of the inst type.
>   (We could do this either by adding a maybe(mer_type) field to each
>   function symbol, which would be "no" before the propagate-types-
>   into-modes pass, or by adding just a mer_type field, which would
>   be a special dummy value before that pass. I (zs) prefer the latter.)

I would also be in favour of the second approach.

> The second option would involve reintroducing a free/1 function symbol
> into the inst type, but this would replace the existing free/0
> function symbol, and it would inherit all the code that currently
> handles free/0, NOT the code being deleted by this diff for handling
> the *current* free/1.
> 
> The first option would be easier to implement if only one or maybe two
> operations needed type info, the second would be both easier to implement
> and more efficient if more operations needed that info.

That's fine otherwise.

Julien.