Seems like a very useful and missing element of the developer ecosystem currently. However a lot of languages will not work well for generating Plutus which is a very limited subset of Haskell. Might need a DSL abstraction to avoid multiple disparate implementations of the generator.
Solidity (or other user language) → SDK → DSL → Generator → Plutus
But when I finished reading the plutus-core spec, I felt my understanding of plutus-core was incomplete, and I needed a disassembler to analyze some of the existing scripts in order to fill in the gaps.
I wasn’t really thinking of a DSL as a compilation target for other languages. Rather as something ‘kind-of-high-level’ that can be written directly and understood by 99% of the world’s programmers.
That last requirement essentially means C-like syntax.
I also don’t know how many of the ‘abstract’ typing features of plutus-core (polymorphism etc.) are really necessary for validator scripts. I think that in most financial use-cases these scripts should be exceedingly simple, and can be simply typed at compile-time. Algebraic data types are probably also not necessary.
There is only one ‘Haskellism’ that I haven’t fully figured out yet. There is a clear need for builtin lists, which in plutus-core are implemented as linked-lists. This of course is where all of Haskell’s recursiveness comes in: getting the length, getting an element, mapping, filtering, folding etc… Should the DSL include some builtins that perform these basic functions (allows conventional indexing using brackets)? Or should the DSL allow programming these methods directly (simplifies the compiler a bit)?
I would be nice to hear your thoughts on this.
Perhaps I will start a new thread in the forum where we can discuss the design of this DSL.
I attempted using TinyCBOR for serialize/de-serialize but I think most people are using cardano-serialization-lib these days and Nami also has a custom extension of that library which adds functionality and fixes some issues.
Glow attempted something like this but I think development has slowed as they ran into snags trying to support too many platforms due to the lofty goal of being the DSL to all smart contracts. Ultimately this is something that will be needed still in the next 5-10 years as side-chains and cross-chains become standardized.
That is definitely a new topic and could honestly require a CIP and a month of discussion from people with more expertise than me. Initial thought is there are enough multi-paradigm languages that functional “limitations” could be transcribed. For example it is unpopular but totally possible to write purely functional code in C++ especially with lambdas in newer standards.
Therefore it could be possible to create an interpreter or translator in the DSL to converge upon a more Haskell friendly format. For example using linked lists for arrays, vectors, sets, and other similar “listable” data structures. Any language that has the concept of a function should be supported in the DSL albeit with a heavy amount of helpers or built-ins exposed through language specific SDK as you allude.
Alternative designs worth considering would be MBSE which arguably is what Marlowe is all about.
That’s right. The spending transaction contains the flat encoded Plutus-core script, wrapped twice in a cbor bytearray. They call this wrapping the text envelope (I don’t entirely understand why it is done).
Less is more. It conserves bytes and allows for simpler transaction storage on the ledger. It does seem like one layer of compression or a single hashed representation would have been enough though … I obviously don’t entirely understand either