Confusion about erasure in Fasta

[peter-ahe-google]

When erasure was first added to package:kernel, it was supposed to only be used to fake strong mode support (see 120c8c3).

When I encountered generic methods in Fasta, I simply created type parameters and installed them on the kernel FunctionNode. However, that's only supposed to happen in strong mode. Without strong mode, type parameters of generic methods should be ignored.

But now that Fasta is starting to support strong mode, we need to turn off erasure so that we can actually start running code in strong mode on the VM.

So it seems like erasure should just be removed?

[peter-ahe-google]

@kmillikin @sigmundch

[kmillikin]

The current status is that we need this pass (or an equivalent in the VM) because the VM does not support generic functions yet. It can be done as the very last transformation before writing out a binary that will be consumed by the VM.

The plan is to remove it as soon as support for generic functions works in the VM. That implementation is underway.

[sjindel-google]

Generic functions are supported, in that the VM will turn them into dynamic, in the same way erasure does (except for converted closures, where type parameters are actually used).

So I think erasure can already be removed.

[floitschG]

The VM also has a flag, where the generic arguments are not ignored.

[sjindel-google]

@floitschG: That flag mostly affects the source-to-flowgraph builder; there are still many holes in the implementation of generic methods for the kernel-to-flowgraph builder.

I've also just found that there are still cases where the VM will crash when it discovers generic methods in kernel (rather than replacing the parameters with dynamic, as it normally does). So more work in the VM is needed before we can disable erasure.

[a-siva]

Is this a duplicate of #30455 ?

[peter-ahe-google]

@a-siva not really, but also kind of. As long as erasure is removed, there's no confusion about how it's used.

[sjindel-google]

Type erasure is dead.