RFC: move gnovm/pkg/gnolang/precompile.go out of pkg/gnolang/

[piux2]

Description

we might want to move gnovm/pkg/gnolang/precompile.go out of gnovm/pkg/gnolang/

For following reasons:

• precomplie is part of off chain tools for devs to validate the gno files by leveraging local go build tool chains before we upload files to gno.land chain. these are not part of the language specs

• gnovm code should not depends on gno.land configurations.
  

  gno/gnovm/pkg/gnolang/precompile.go

  Line 22 in 7464b94

  const (

  
  

  gno/gnovm/pkg/gnolang/precompile.go

  Line 31 in 7464b94

  var stdlibWhitelist = []string{

• Above const and vars do not determine gno.land chain settings, nor language specs. They merely need to match with a specific version of deployed gno.land chain either locally or remotely, so that we can accurately validate gno files against a specific chain run time.

Proposal:

• Put precompile.go in something like gnovm/pkg/tools , move chain specific information and lib list to a config file so that people can use it as a template when they fork gno or migrate gno to other chains.
• A feature in a separate RFC: gno.land chain publishes these settings.
• A separate RFC: combine gno precompile and build as a validation tool to avoid confusion, since we only leverage go build tool chains to validate gno files, syntax, import paths and injected native method signatures. The binary out of precompiled gen.go and the building process serves no purpose.

Open for suggestions and comments.

[moul]

The path gnovm/pkg/tools isn't clear in my opinion.

To make it clearer, I suggest moving it to gnovm/cmd/gno/precompile.go, gnovm/cmd/gno/internal/precompile.go, or gnovm/pkg/precompile.

Also, it's worth noting that we might use it for GnoffeeScript later. Check this: gnolang/hackerspace#22.

---

My opinion: I think we should move to cmd/gno/internal/precompile.go for now. We can decide where to put it for wider use later.