State of the Languages

Project Updates
,
#1

Welcome to the first post in the Tezos language series. We’ll give you a peek behind the curtain of Tezos smart contract language development on a weekly basis.

Let us know if you have

  • feedback
  • suggestions
  • a language you would like to add

This week in development

LIGO

The LIGO team was pelted with GitLab issues and spent most of their time keeping up.

Developers made suggestions as well as bug reports via Gitlab—a lot of them—so LIGO will adjust their process to sort bugs and suggestions into different categories in order to prioritize better.

SmartPy

The SmartPy team worked hard this week to finish their next release.

In addition to new features they will announce soon, this release will be SmartPy’s first open source version.

Thanks for reading, and check back next week for a new update!

Eowyn on behalf of the LIGOlang team

10 Likes
#2

Readers, thank you for your excellent feedback on our last report. We hope you enjoy this week’s insights into Tezos smart contract language development.

Let us know if you have:

  • feedback
  • suggestions
  • a language you would like to add

Recent development

Albert

The Albert team recently submitted an academic article to the 2020 edition of the Trusted Smart Contract Workshop. It provides, among other things,

  • an overview of the current state of Albert
  • details on how Albert compiles to Michelson
  • an example smart contract written in Albert

For more detail you can peruse their academic article here:

Albert, an intermediate smart-contract language for the Tezos blockchain

LIGO

The LIGO team has been working on a diverse set of improvements. They:

  • changed the calling conventions in CameLIGO and ReasonLIGO to make them more similar to OCaml/Reason. In particular, the following equivalences now hold, as one would expect:

    fun x y -> z
  ~=
fun x -> fun y -> z

(* when f is not a built-in operator: *)
f x y
  ~=
(f x) y

  • fixed a bug which prevented using failwith in both branches of a conditional.

    let main ((b, _) : bool * unit) =
  if b
  then failwith "b is true"
  else failwith "b is false"

  • improved many unhelpful “not a X” type errors, along with errors related to typing built-in operators (e.g. “wrong types”, “bad X”.)

  • added a record update operation to all syntaxes, e.g. {r with b = 2048; c = 42} in CameLIGO.

  • added support for Tezos key and signature literals as type-annotated base58 strings. For example ("edpk..." : key).

  • added syntax for ‘attributes’ to all syntaxes, including an “inline” hint which will encourage the compiler to inline a particular definition, even if it is used more than once.

SmartPy

The SmartPy team shipped its first open source release this week!

Now they are back to working on SmartPy core current projects:

  • the testing framework
  • Michelson static analysis / decompilation.

Thank you for reading. Check back soon for more updates!

Eowyn on behalf of the LIGOlang team

3 Likes
#3

Thank you for following the latest in Tezos smart contract language development! We’re introducing two new Tezos smart contract languages in this installment: SCaml and Archetype.

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Archetype

The Archetype team worked on preparing the next release: 0.1.13

  • Reorganized tests with more than 220 unit tests (previously ~50 tests).

  • Implemented the ‘rational’ type. Rational values enable easy formulation of computations, like percentage and ratio. For example, in the following snippet, the exec action transfers 20% of the transferred amount to the argument address dest:

    archetype rational_rat_tez_mult
action exec (dest : address) {
effect {
    var m = 0.2 * transferred;
    transfer m to dest
    }
}

    It is transcoded to amount div 5 where div is the euclidean division.

  • Implemented the duration type. Duration values are used to compute dates by addition/subtraction of a duration to a date. In the following snippet, the exec action transfers if current date is one week after last_exec date

    archetype rational_duration
variable last_exec : date = 2020-01-01
action exec (dest : address) {
    called by admin
    effect {
        if now > last_exec + 1w then (
        last_exec := now;
        transfer transferred to dest
        )
    }
}

LIGO

The LIGO team is making its way towards a more mature compiler:

  • Refactoring the AST to turn some built-in cases into functions. The more expressive the type system, the more cases we can turn into functions, and the less cases there are, the easier it is to modify the compiler. The new typechecker helps as it slowly passes more and more tests.

  • Improved the documentation by rewriting a large chunk of it and automatically testing the examples in the docs. Experience tells us these can quickly get out of sync, and the CI is more proactive in noticing errors than we could ever be.

  • Working on an interpreter for LIGO independent of the Michelson backend, to be able to unit-test LIGO code directly in LIGO.

  • Error messages are improving everywhere: after the work on the current typer’s error messages, we’re just starting work on propagating source locations and other info to know where errors come from in the new typer. The ReasonLigo parser errors are also being improved. Finally, some lexical checks have been added for duplicate constructors or record fields, use of reserved words as identifiers, etc.

  • An [@@inline] (in CameLIGO, and [@inline] in ReasonLIGO) annotation was added, it indicates that a function should be inlined at its call sites

Better task management:

  • Increased visibility for issues that need review from multiple people

  • Developing new processes so intentionally delayed tasks are not forgotten

In the larger context of the community:

  • we have worked on making Tezos more efficient (investigation in gas pricing, storage and amendments)

  • we’re preparing for the WebAssembly summit and for upcoming training at Nomadic Labs on February 12th (https://training.nomadic-labs.com/training.html).

SCaml

  • The first Docker image of SCaml is out at https://hub.docker.com/repository/docker/dailambda/scaml. It’s still simple but you can try SCaml easily by running:

    $ docker run dailambda/scaml:1.0.3 scamlc xxx.ml

  • Implemented the type-checking of classes of types (such as comparable, packable, storable, and parameterable) in SCaml so that invalid uses of comparisons, closure creations, contract storages and parameters are detected at SCaml level.

  • Added --convert and --revert options to scamlc command to convert and revert SCaml values to Michelson values.

  • ML types are converted to Michelson types now with annotations of record field names and variant constructor names. For example, the following ML type definition:

    type config = 
  { title          : string
  ; beginning_time : timestamp
  ; finish_time    : timestamp
  }
        
type action = 
  | Vote of string
  | Init of config

    is converted to the following Michelson type, with %-annotations:

    (or :action
   (string %Vote)
   (pair :config %Init
      (string %title)
      (pair (timestamp %beginning_time) (timestamp %finish_time))))

    This makes the output Michelson code easier to read, especially for deciphering the structure of storages and parameters.

SmartPy

The SmartPy team has continued working on

  • the testing framework

  • decompilation

  • new constructions to handle lambdas

  • inter-contract communication

Thanks for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

1 Like
#4

Thank you for following the latest in Tezos smart contract language development!

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

No recent updates.

Archetype

The Archetype team added several new features:

  • addupdate method for assets

     archetype effect_method_asset_addupdate
 ...
 action exec () {
   effect {
     my_asset.addupdate("my_id", {value = 3})
   }
 }

    is equivalent to

     archetype effect_method_asset_addupdate
 ...
 action exec () {
   effect {
     if (my_asset.contains("my_id")) then
       my_asset.update("my_id", {value = 3})
     else
       my_asset.add({id = "my_id"; value = 3})
   }
 }

  • bytes as a buitin type

    variable b : bytes = 0x1af0

  • a_contract.my_entry(args) has been replaced by transfer 0tz to a_contract call my_entry(args)

  • Froze api verification for release

  • Continued to add tests for verification (~20 tests)

In addition, they began to write a language reference page, which you can find here:
https://docs.archetype-lang.org/archetype-language/archetype-reference

LIGO

The LIGO team worked on a major rewrite of the online documentation along with a new reference presentation to prepare for the Nomadic Labs training session and hackathon. They also attended the WebAssembly summit and WebAssembly CG meeting. A useful takeaway: writing documentation can reveal missing features!

In addition to participation in these events, they

  • Simplified the Abstract Syntax of LIGO by removing redundant cases (this is required in order to develop new features in the compiler)

  • Did code cleanup & CI maintenance in preparation to auto-generate some LIGO boilerplate.

  • Worked on a switch allowing LIGO users to decide which version of the Tezos protocol to use

Michelson

No recent updates.

SCaml

The SCaml team is working on community planning. Tezos Japan and BlockChainJam are planning a hands-on using SCaml in Tokyo in March (https://www.tezos.or.jp/2020/01/30/smartcontract-for-begineer/). SCaml will provide technical advice for their tutorial materials.

The hands-on is targeted at Japanese engineers, many of who have difficulty with English documents. SCaml provides an open door to writing Tezos smart contracts, since it is just OCaml and there are already good OCaml books and tutorials in Japanese.

SmartPy

The SmartPy team worked on several points related to the SmartPy explorer (Michelson typing and pretty-printing, decompiler plumbing, faster UI, etc.) and is slowly approaching a new release. This will reach https://SmartPy.io/dev in the next few days or weeks.

Other elements that are currently tested:

  • private entry points that exist in tests but not on-chain yielding very nice testing and development idioms
  • a few improvements to the SmartPy type inference engine to improve overloading when necessary (e.g., euclidean division)

SmartPy also has a few secret projects that we’re especially excited about! We hope to be able to share these in the next few weeks.

Thanks for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

2 Likes
#5

Thank you for following the latest in Tezos smart contract language development!

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

No recent updates from the Albert team.

Archetype

version 0.1.13

The Archetype team just released version 0.1.13, which is the last alpha version before the 1.0 release. For more details please see: https://github.com/edukera/archetype-lang/blob/dev/CHANGES.md

Notable changes:

  • multi-criteria sort function for assets
    archetype multi_sort
asset my_asset identified by id {
  id : string;
  v1 : int;
  v2 : int;
  v3 : int;
} initialized by {
  {"id0"; 1; 2; 7};
  {"id1"; 1; 3; 9};
  {"id2"; 1; 3; 8};
  {"id3"; 1; 2; 6}
}
action exec () {
  effect {
    var res = my_asset.sort(v1, asc(v2), desc (v3))
    (* res = ["id0"; "id3", "id1", "id2"] *)
  }
}
  • Transformations of intermediate representation
  • Bug fixes
  • Continuing to write language reference documentation https://docs.archetype-lang.org/archetype-language/archetype-reference

LIGO

The LIGO team continues working to improve the core of the language. Recent and upcoming developments include:

  • Added a tail recursive function to the language
  • Adding an AST pretty-printer to help debugging programs
  • Adding optimization passes

Beyond the work on LIGO, the team is also

  • Adding new features to Michelson for better interactions between smart-contracts
  • Adding new helpers to Michelson for integration with higher-level languages
  • Writing blog posts that detail how Tezos can be made simpler, and Michelson better

New website development includes

  • dark mode
  • a new logo
  • continued improvements to the documentation

Michelson

No recent updates from the Michelson team.

SCaml

version 1.1.0

The SCaml team released SCaml 1.1.0 “Salting” just after Tezos protocol upgrade 006 “Carthage”.

Since Carthage is a maintenance release of Tezos 005 “Babylon” there is no big change in Salting. It fixes some bugs and improves usability. Specifically:

  • SCaml is now installable via a simple shell script using Docker.
  • SCaml specific errors now have error codes.
  • Added more tests and examples.
  • SCaml record field and variant constructor names are now annotated to Michelson.
  • Added --scaml-convert and --scaml-revert for value conversion between SCaml and Michelson.
  • Michelson’s type “classes”, such as comparable, packable, parameterable types, etc. are now checked by the SCaml type checker.

Documented surprises

SCaml is a strict subset of OCaml. Ideally, within its limited language features, any valid OCaml program should be valid SCaml. Unfortunately there are some exceptions, therefore we have detailed surprises OCaml programmers may encounter in SCaml.

The most unintuitive SCaml surprise is the restriction of no unpackable free variable occurrence in function bodies. This comes from the same restriction in Michelson’s function closures, so the other functional language compilers to Michelson should have the same kind of restrictions. We have documented several ways to work around this restriction.

Social: the virus turned every meeting virtual

Japan and other Asian countries are experiencing 2019-nCoV situation few weeks prior to Western countries. All meetups are canceled around us to slow down the epidemic.

Our Tezos hands-on using SCaml planned on 2020-03-21 is not an exception, but we are planning to make it virtual. This is a challenge since hands-ons are more bidirectional than usual tech meetups, but it is an unstoppable change in tech communities this year.

SmartPy

No recent updates from the SmartPy team.

Thank you for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

2 Likes
#6

Thank you for following the latest in Tezos smart contract language development. The last few weeks have been challenging, but we’re happy to see people use their time stuck in quarantine to learn and develop skills in writing Tezos smart-contracts!

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

No recent updates from the Albert team.

Archetype

The Archetype team added

  • Crypto functions: blake2b, sha256, sha512 and check_signature
  • Functions concat, slice and length for string/bytes types

Then also worked on

  • SmartPy output
  • Fixing bugs

LIGO

The LIGO team worked on

  • Refactoring the code base for better JSON outputs (error/values)
  • The boilerplate generator.
    In the past we factorized parts of the code that were similar, but those parts are somewhat arbitrary and make refactoring and changes more difficult (if you need to update a common part for just one of its use cases, it becomes a problem). It was useful to reduce the amount of code while there was little automation; now that we can generate some parts of the boilerplate we can start to bring back each AST in a single file without grouping the common parts of the AST in a separate file.
  • A pure OCaml substitute for cpp, which is now under unit testing before integration and release.
    Currently, the LIGO compiler relies on the C preprocessor (cpp) to textually combine several contracts into one by means of the #include directive, and perform the conditional compilation of contracts by means of the #if directive. The use of a preprocessor is meant as a temporary solution until a proper module system is designed which will enable the type-safe composition of contracts based on their abstract representations. In the meantime, cpp is an external dependency of the LIGO compiler, and a relatively large piece of software, so the substitute will make the LIGO distribution lighter.

SCaml

The SCaml team has nothing special to report for SCaml this time. They are busy with main core development.

SmartPy

No recent updates from the SmartPy team.

Thank you for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

1 Like
#7

Thank you for following the latest in Tezos smart contract language development. We have fresh updates on all your favorite languages, including first-quadrimester updates on Albert and Michelson!

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

January - May 2020

Basile Pesin wrote the first prototype for the Albert compiler in summer 2019 during his internship at Nomadic Labs. Since the beginning of 2020 the focus of Albert developers is to turn this prototype into a Minimal Viable Product for a first release of the Albert compiler.

This includes

  • adding many tests
  • measuring their coverage
  • improving error reporting
  • improving documentation
  • certifying in Coq parts of the compiler pipeline

Most notably they have proved type and semantics preservation for the Albert backend optimizer that operates at the Michelson level.

For more information about the Albert language, see the Albert website. Albert development happens on its public Gitlab repository.

Archetype

The Archetype team is finalizing the 1.0 version of Archetype transcoder. It will provide full support for LIGO and Whyml generation.

Following feedback from early adopters, Archetype syntax has been enhanced:

  • The get method is removed from the asset collection API; retrieving an asset is now done straightforwardly from its key with map-like bracket syntax; for example, the syntax to access field f of asset with key k from the
    my_asset collection is now:

    my_asset[k].f

    As a consequence, it is no longer possible to create a local asset variable, which could make believe you were dealing with an object physically detached from the storage, when the reality is that that field’s updates were automatically synchronized with the storage.

    The double update syntax is sill valid though: for example, in order to update integer field f to 1 the following two expressions are possible:

    my_asset.update(k, { f = 1 });

    my_asset[k].f := 1;

  • It is now possible to update asset collection fields straightforwardly in the update syntax. For example, consider the following assets declaration:

    asset simple_asset {
  str : string;
}

asset my_asset {
  id : string;
  assets : simple_asset collection
}

    The following instruction adds 2 simple assets to the assets fields of asset with key "k":

    my_asset.update("k", { assets += [{"str1"},{"str2"}] });

The LIGO generated code has been improved and optimized to reduce its size, including:

  • use of native LIGO syntax to access maps
  • transcription of an asset collection to a map or a set, based on its structure and usage

At last, on the verification side, the Whyml Archetype theory is being verified. This is the library the whyml-transcoded contract relies on.

LIGO

The LIGO team finished an in-house OCaml generator that can be used to derive

  • comparators
  • printers and exporters
  • other repetitive functions on AST nodes

This will make it possible remove some boilerplate (comparators are extremely fragile to maintain: it’s very easy to add a case to the AST, and update the so that it produces incorrect results 1% of the time), and make it easier to write more intermediate ASTs. It should be possible to use that generator to automatically derive transformations from one AST to the other, only requiring specification of how to handle the parts that actually change.

Added new features:

  • Michelson_pair type: This allows users to define a data structure as they would in Michelson, including ‘%’ annotation.
  • Verbatim string: delimited with {| ... |} instead of " ... " verbatim string are not escaped.
  • Code insertion: a new expression has been added to allow the user to write Michelson code inside LIGO. This code will be present in the produced contract. This feature targets the advance Michelson user who wants specific code to be run instead of LIGO generated code

Error messages, Michelson coverage and bug fixes:

  • Began to refactor error reporting mechanisms to enhance user experience
  • Continued work on error messages, fixing bugs, and support on all Michelson features

Michelson

January - May 2020

The Michelson interpreter is implemented inside the Tezos protocol that is subject to the on-chain governance process. Since the successful activation of the Carthage proposal in March 2020, Nomadic Labs, Cryptium Labs and Marigold work on a new protocol amendment proposal that can be followed on Cryptium Labs’ Gitlab repository.

Michelson updates activated in proto-006 Carthage

Carthage is a housekeeping release, so no deep changes to Michelson were made; primarily small bugfixes. The most noticeable one is that comb pairs can now be used as set elements and to index maps and big maps.

For a detailed description of the Michelson changes in Carthage, see the Carthage protocol documentation.

Reviewed Michelson updates for proto-007

Nomadic Labs, Cryptium Labs, and Marigold plan to soon inject protocol amendment proposals whose main new features are Sapling and Baking accounts. These proposals will also contain changes to Michelson. The most important ones:

  • Refactoring
    • MR 53 Gas accounting is now better separated from the rest of the interpreter.
    • MR 65 Checking for equality of types in the type-checker has been simplified.
    • MR 157 The performance of the interpreter has been improved by identifying some bottlenecks; this will allow for a reduction of gas costs (to be computed).
  • Gas
    • MR 58 Gas units have been rescaled by a factor of 1000 so that the cost of very cheap instructions such as stack manipulations can be observed on execution traces.
  • Type system
    • MR 52 An empty type called never has been added
    • MRs 64, 72, and 135 The following types are now comparable: pair, or, option, unit. chain_id, mutez, key, key_hash, and signature
  • New instructions
    • MR 71 the LEVEL instruction has been added, it gives access to the level of the current block
    • MR 75 The SELF_ADDRESS instruction has been added, it is equivalent to SELF; ADDRESS but it is also allowed in lambdas
    • MR 54 The very common UNPAIR macro has been promoted as an instruction.
  • Legacy
    • MR 125 The three legacy instructions that are obsolete since the activation of the Babylon protocol (STEPS_TO_QUOTA, CREATE_ACCOUNT and the legacy version of CREATE_CONTRACT) have been removed.

Other Michelson updates planned for protocol 007 proposals

The following changes are planed for the proto 007 proposals and are currently under review:

  • Sapling

    • In order to support smart contracts managing shielded tokens, types for Sapling states and transactions have been added together with instructions to initialize a sapling state and to verify and apply a transaction on a state.

  • Baking accounts

    • The new stateful baking accounts will be associated with a new kind of key hash, called baking_key_hash and exposed as a new Michelson type.
    • An abstract type of PVSS keys pvss_key is also added
    • Baking accounts run a fixed Michelson script performing multisignature authentication. In order to interact with the chain in meaningful ways, new instructions are added to change the keys, to participate in votes, and to deactivate or reactivate delegation. These operations are of a new baking_operation type that can only be emitted by a baking account.

  • Combs

    • In Babylon, several n-ary instructions (DIG, DUG, DIP, and DROP) were added to provide cheap access to stack elements located deep in the stack. For protocol 007, a similar mechanism is planned for comb pairs and comb ors.

  • Tickets

  • Voting power

    • A VOTING_POWER instruction is added returning the number of rolls held by a baker according to the last voting snapshot.

Michelson updates discussed for future amendments

The following features were discussed and could be proposed in a future protocol amendment proposal:

SCaml

Language

SCaml now supports multi-compilation units. This is not an entirely separate compilation, but now users can write library modules to share codes between smart contracts. For this change, [@entry] attribute is now mandatory for the entrypoint definitions.

SCaml.Contract.contract' is added to access a contract entrypoint with the given name.

SCaml supports exception raising by raise. Users now can define custom exceptions and throw them. The exception values are encoded to Michelson values and used for FAILWITH opcode for later investigation. Since Michelson exceptions are always fatal, there is no way to catch these exceptions in SCaml.

Test environment

The SCaml team is working on 2 testing frameworks:

  • Sandboxing/testnet
    This is to test SCaml contracts by actually running in Tezos. The execution results are decompiled back to SCaml values so that the correctness can be checked in OCaml. They are now playing with Flextesa to launch sandbox nodes and run contracts.

  • Simulation in OCaml
    Given emulation semantics of SCaml primitives in OCaml, they can simulate the execution of SCaml contracts in OCaml. This is more ambitious than the former and has to assume the correctness of the compiler, but if it works they can run tests very efficiently in native code.

Social

SCaml did their first SCaml hands-on remotely, using Zoom, as an experiment for a larger event in the near future. It was fun and went smoothly; very good to obtain some experience in remote hands-on. They hope to soon publish the material, which will be available in Japanese.

SmartPy

The SmartPy team is working on the following:

  • building, together with Cryptonomic, a bridge for Chainlink oracles in Tezos
  • working on their next open source release that will contain everything from SmartPy.io/dev + a few specific enhancements in the SmartPy CLI including out-of-the-box sandbox integration
  • added the recent FA2 SmartPy template in SmartPy.io/dev
  • still working on their decompiler (now expected first release in June)
  • continuing the work started with the Faucet Importer and the Ledger Hardware Wallet integration in SmartPy.io

Thank you for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

5 Likes
#8

Thank you for following the latest in Tezos smart contract language development. We have fresh updates on all your favorite languages.

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

No recent updates.

For more information about the Albert language, see the Albert website. Albert development happens on its public Gitlab repository.

Archetype

The Archetype team has released Archetype 1.0

You can find the full announcement here.

LIGO

The LIGO team:

  • added code injection to the compiler, which allows the user to insert Michelson code in the middle of a LIGO contract. This is useful when you want to use specific code, such as optimized Michelson.
  • completed a prototype certified compiler, from a language similar to a subset of LIGO’s intermediate “MiniC” language, to a subset of Michelson. This is believed to be the first comparable proved theorem for a compiler targeting Michelson. There is much work left, but after this compiler is extended to target most of Michelson and optimized in some ways, it could be extracted from Coq and used inside LIGO.
  • completed a toy compiler from Michelson to native via LLVM, capitalizing on a robust optimizer and backend to achieve a 100x speedup. It eliminates overhead caused by Ocaml, and permits optimized memory layouts, allocation sinking, etc.
    This could in theory make Tezos much faster if the compiler were completed and adopted, and could allow running Michelson code standalone native, or even baremetal, without the blockchain. This would create the possibility to use the security and safety infrastructure of the blockchain tools to produce extremely secure code for use in many ordinary applications, and to run on a microcontroller, or in an OS kernel.

Michelson

No recent updates.

SmartPy

The SmartPy team has been busy working on a new release.

A big step: many improvements to the SmartPy.io editor and explorer in the next few days.

Adding a new page called Wallet; this page will help keep track of

  • originated contracts
  • contracts of interest
  • keys (public, private, with a Ledger Hardware Wallet, from a faucet, etc.)
  • view transactions
  • send transactions, etc.

The language has seen many improvements as well; an important step has been, under the hood, to use slightly more functional structures. They remain exposed as usual through the same regular Python syntax, but this shift helps in two directions: some contracts may directly benefit from this but it also helps greatly for the SmartPy decompiler (not yet ready for a real preview but getting closer).

The team also played with alternative compilation techniques to reduce the gas used in transactions. This is noticeable for bigger contracts.

Last but not least, they made improvements to important templates such as FA1.2 and FA2.

Further details will be available in the post associated with the new release.

SCaml

Latest stable version: 1.2.0 pre7

The SCaml team brushed up SCaml compiler while waiting for the new Tezos protocol candidate version 007 proposal. The latest stable SCaml version, 1.2.0 pre7 is publicly available:

1.2.0 pre7 has the following changes compared to 1.1.0:

  • New optimization loop using K-normal form
  • SCaml.ppx, SCaml compiler embedded in OCaml pre-processor
  • Lots of bug fixes

SCaml.ppx

SCaml.ppx is a big step towards the goal of SCaml: a seamless Tezos smart contract programming environment within OCaml ecosystem. With SCaml.ppx, contracts now can be built within Dune, de facto standard build system of OCaml!

In brief:

SCaml’s standalone compiler scamlc is not easily usable within Dune. Dune is not a generic build system but highly specialized for OCaml: it does not know how to use scamlc . SCaml.ppx works around this difficulty by embedding SCaml compiler in an OCaml pre-processor. SCaml modules are compiled by OCaml compiler + SCaml.ppx to OCaml object files embedding SCaml intermediate representation. Linking these OCaml object files produces an executable to emit the final Michelson program. This is roundabout but is the most reasonable solution to integrate SCaml in Dune to our knowledge.

Next SCaml release 1.2.0 supports Protocol 007

The SCaml team is waiting for the official proposal of a new Tezos protocol version 007. Once announced, they will implement and release SCaml version 1.2.0 in few days.

Thank you for reading, and check back soon for our next update!

Eowyn on behalf of the LIGOlang team

1 Like
#9

Thank you for following the latest in Tezos smart contract language development. We have fresh updates on all your favorite languages.

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

In the past months the Albert compiler developers focused on testing. They are following a coverage-based methodology; the coverage infrastructure relies on an instrumentation by the bisect_ppx tool of the OCaml code extracted from Coq. A new feature has also been added to the language: the return instruction. The type of this instruction is return x : {x : a} -> a; a typical use-case of this instruction is in combination with iterators.

For example, doubling all elements in a list can now be done as follows:

def double : {n : nat} -> nat =
	two = 2;
	n = two * n;
	return ndef double_all : {l : list nat} -> {l : list nat} =
	l = map x in l do double{n=x} done

Archetype

The 1.1 version of Archetype was released last month. 1.1 completes the M1 milestone of the feature to transcode to archetype an existing contract: https://forum.tezosagora.org/t/archetype-1-1-and-fa1-2-contract/2110. Milestone M2 is on the way.

On the verification side, the Archetype team is working on the specification of contract entry failures. It will be possible to specify the state of the contract storage in case of a failure.

LIGO

The LIGO team:

  • completed and published the new VScode extension for LIGO. Check it out! VScode ligolang-publish.ligo-vscode
  • removed the dependency on the Tezos protocol from all LIGO compiler passes. This will make it easier to support targeting new protocols. It is also now possible for users to compile contracts which use new or experimental instructions, without any change to LIGO, by using the “Michelson insertion” feature and the --disable-michelson-typecheck option.
  • ported LIGO’s last compiler pass (the one which emits Michelson code) to Coq, with a nice extraction to OCaml. They are still integrating it with the rest of LIGO; for now there is only a proof of type preservation. They will prove some kind of semantic preservation and port more passes from OCaml to Coq.
  • worked on a LIGO test framework, which uses the LIGO interpreter. It allows us to test interoperation of contracts, assert for failure, and more
  • Alexandre Moine, a student pursuing a master’s degree in France, collaborated with the LIGO team to develop a linter for LIGO. The first version is available at https://github.com/nobrakal/lint_ligo/

The new linter supports the detection of:

  • deprecated built-ins
  • unused variables
  • code smells
  • mixed dialects for PascaLIGO (the LIGO documentation currently only features the so-called terse dialect, but some savvy programmers use the verbose one as well)

The linter is extensible in two ways:

  • by adding deprecated names
  • by contributing code patterns that match code smells. Hopefully the community will be interested in contributing more code patterns.

Technically, the underlying matching technique is based on the paper by Christian Rinderknecht and Nic Volanschi. Theory and Practice of Unparsed Patterns for Metacompilation. Science of Computer Programming, 75(3):85–105, March 2010. http://crinderknecht.free.fr/pub/scp2010.pdf

Michelson

No recent updates.

SmartPy

The SmartPy team worked recently on several subjects:

  • Chainlink support, in particular for the Chainlink Hackathon that is currently happening
  • elements towards a decompiler yielding further very nice optimizations in generated contracts including new “global” ones
  • migration of SmartPy.io to React (partially shipped)
  • some new features in the Michelson Editor https://SmartPy.io/dev/michelson.html which benefits from general improvements in the framework (better error reporting, instant typing, example generation, etc.)
  • improved documentation and examples
  • support of new test networks
  • experimental support for some new operations and types coming in future proposals

SCaml

The SCaml team just released SCaml 1.2.0. This supports Tezos Delphi protocol upgrade proposal, and newly supports scaml.ppx which can shift Tezos smart contract programming entirely within OCaml eco-system. With scaml.ppx SCaml smart contract code is embedded into OCaml executable, which generates the final Michelson code.

You can now use your favorite OCaml tools (Dune, Merlin, etc) freely to write smart contracts in SCaml!

Thank you for reading! Check back soon for our next update.

Eowyn on behalf of the LIGOlang team

2 Likes
#10

Thank you for following the latest in Tezos smart contract language development. We have fresh updates on all your favorite languages.

Let us know if you have:

  • feedback or suggestions
  • a language you would like to add

Recent development

Albert

No recent updates.

Archetype

Archetype 1.2 was released mid-September.

Archetype now straightforwardly generates Michelson, without the need for transcription to another language. The command is:

$ archetype -t michelson mycontract.arl > mycontract.tz

Archetype 1.2.1 was released beginning of October with support of the TZIP16 metadata specification.

The command to add metadata is:

$ archetype --metadata-storage mycontract.json -c mycontract.arl

Please refer to the metadata TZIP16 documentation page for more information.

The Archetype team is working on milestone M2 to verify any deployed contract in Archetype.
The verification of the Archetype implementation of FA1.2 was released beginning of October. The presentation article is available here.

LIGO

The LIGO type environment is now preloaded, which allows for a CLI option to switch between protocols (Carthage and Dalphanet for now). This will make the work for future protocols support much easier.

Michelson

Since the last update in May, the Michelson team has mostly worked on the Delphi protocol proposal and on finalising the new Michelson features that are being tested on the Dalphanet test network and will be proposed for protocol 008. In more detail, Michelson has undergone the following developments:

  • Delphi (Protocol 007)
    • Optimisations
      The Michelson interpreter and type checker have received optimisations reducing the amount of computation done in the concurrency monad. Gas accounting has also been simplified and optimized.
    • Benchmarking and Gas
      A generator of well-typed Michelson scripts of arbitrary size has been developed, it has been used to benchmark the Michelson type checker; this has allowed to refine the type checking gas model and greatly reduce the gas price of type checking. New benchmarks
      on modern SSD disks has also enabled a reworked gas model for I/Os.
  • Protocol 008
    • Comb pairs
      The proposal for comb pairs has been improved to make the representation more readable and size efficient. Comb pairs can now be represented as n-ary pairs or sequences.
    • Tickets
      A second implementation of tickets relying on linear typing has been proposed. Which implementation to include in the next protocol proposal is being discussed.
  • Future
    Many optimizations of the Michelson interpreter and type checker are being studied. To simplify the development of Michelson tooling, efforts are being put to export the interpreter step function at the RPC level. This is needed for implementing support for the TZT unit test format in tezos-client and would also simplify the implementation of off-chain views. Last but not least, work is ongoing to make the documentation of the Michelson language much more interactive; a preview of this new documentation is available at https://michelson.nomadic-labs.com.

SmartPy

The SmartPy team has been busy with several projects.

  • Michelson to Michelson optimizations.
  • Michelson to SmartPy decompiler. They hope to be able to show a nice first version before the end of the year.
  • Improvements and documentation to code organization, design patterns, inheritance or mixins.
  • A great new React-based IDE that will be available in beta very soon. They will switch the full SmartPy.io to this technology eventually.

SCaml

No recent updates.

Thank you for reading! Check back soon for our next update.

Eowyn on behalf of the LIGOlang team

4 Likes
Home Learn
Get Started Wiki
Developers Stack Exchange

Be part of the conversation