Generated blueprint identifiers are ambiguous for polymorphic types

[emiflake]

Describe what the problem is?

The plutus.json generated by the Aiken compiler generates ambiguous, or otherwise unparseable identifiers.

Here's an example.

Let's say we define the datum like so:

use aiken/crypto.{VerificationKeyHash}
use cardano/transaction.{OutputReference}

pub type Datum {
  owner: ExampleWrapper<VerificationKeyHash, Int>,
  output: ExampleWrapper<OutputReference, (Int, Int)>,
}

pub type ExampleWrapper<t, extra> {
  get: t,
  extra: extra
}

We are using a type from the standard library, but we wrap it.

This will generate two instances of ExampleWrapper:

"hello_world/ExampleWrapper$VerificationKeyHash_Int": {
   ...
},
"hello_world/ExampleWrapper$cardano/transaction/OutputReference_Tuple$Int_Int": {
   ...
},

CIP-57 of course does not say anything about these identifiers, but these are essentially unparseable in a consistent way without doing a lot of heuristics. Does the second example mean ExampleWrapper<OutputReference, Tuple<Int>, Int> or ExampleWrapper<OutputReference, Tuple<Int, Int>> It's not possible to determine this, without knowing in advance the arity of all involved type names. And this is not exposed in the plutus.json.

Someone using the plutus.json code generated by the Aiken compiler will essentially have to deal with very ugly identifiers.

What should be the expected behavior?

In my opinion, since $ is already not a valid symbol in many languages (including Rust, the language of the compiler), the identifier should just be fully quantified using the normal syntax, namely, in the last example:

hello_world/ExampleWrapper<cardano/transaction/OutputReference,Tuple<Int,Int>>

This way, it is at least parseable consistently, and then, any users of this can easily convert in a backwards compatible way:

identifier.replace(/>/g, '').replace(/</g, '$').replace(/,/g, '_')