Discuss: PlutusTx Eq instance generation should delegate to BuiltinData equality
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Necesita aclaración
- Estado de actividad
- Estancado
- Stack tecnológico
- haskell
- Área
- blockchain, tooling
Línea de trabajo
Revisa la generación existente de instancias Eq de PlutusTx y compárala con el enfoque de igualdad de PlutusData mostrado en el issue. Lee la implementación referenciada en plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs y, a continuación, resuelve cómo deben especificarse las representaciones canónicas para tipos como Set y Map antes de decidir qué se considera completado.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
In Plutarch the general consensus is that we perform Eq by simply delegating to the underling PlutusData representation.
instance PEq FooTrivial where
(#==) = \l r -> pdata l #== pdata r
PlutusData equality operation is a builtin which is naturally much more performant then doing the obvious field by field comparisons (which is done in PlutusTx PLA types and is generally a practice adopted https://github.com/IntersectMBO/plutus/blob/b34d6ca2c4bbe54c324337eb813a5f6a522b475c/plutus-ledger-api/src/PlutusLedgerApi/V2/Tx.hs#L84).
However, we do assume that there's a single canonical PlutusData representation for all types, which might not be the case for semantically richer types like Set or Map (for example, the underlying AssocMap PlutusData representation can use ascending or descending ordering etc). This is solved by agreeing on a well defined PlutusData representation for any type that might be ambiguous in that regard.
cc @peter-mlabs
- Lenguaje dominante
- Haskell
- Estrellas
- 33
- Forks
- 1
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de mlabs-haskell/lambda-buffers
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
mlabs-haskell/lambda-buffers#296 ·
-
Create a more user friendly CLIAbierto
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
mlabs-haskell/lambda-buffers#295 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 20/100
mlabs-haskell/lambda-buffers#294 ·
-
Dykstra HFAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
mlabs-haskell/lambda-buffers#293 ·
-
Nix-free pathAbiertodevops
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
mlabs-haskell/lambda-buffers#292 ·
Todos los issues de mlabs-haskell/lambda-buffers
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
A failed JNA download is reported as a corrupt zip, because `curl` in `Makefile` lacks `--fail`Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
objectionary/phino#1884 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Eval plugin errors on `:seti`Abiertocomponent: hls-eval-plugin status: needs triage type: bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
haskell/haskell-language-server#5144 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
[BUG]: -std selection does not work with COBOL -> GnuCOBOL 1.1Posiblemente ocupada @Anandb71 la tomó hoy. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
compiler-explorer/compiler-explorer#9272 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
alunduil/siren-json.hs#247 ·
Los mantenedores suelen responder en 1 día