Skip to content

Made singleton types inhabitable, and subtypes of the type of the value

Xavier Montillet requested to merge xavierm02/inhabit-singleton-types into dev

Motivation and Context

In typescript, it is common to use union types combined with singleton types to represent disjoint unions, so we want singleton types in JsLIGO.

Description

Let v be a value of type A (e.g. v = "hello" and A = string). The singleton type {v} (pretty-printed as simply v by the compiler) should have the following properties:

  • {v} is a subtype of A: for any value v2:{v}, we have v2 : A
  • it does not contain any other value: for any value v2 : A, v2 : {v} iff v2 = v

(Note that the subtyping relation currently implemented in the compiler is fairly weak so that e.g. {"a"} * {"b"} is not a subtype of string * string)

Known problems

> ligo compile expression jsligo "do {const a : 1 = 1; return a;}"
Error(s) occurred while parsing the Michelson input:
At (unshown) location 0, unexpected int, only a primitive can be used here.

This may be related to how ligo compile expression works because in a contract, this works just fine:

const f = (_x: int) => {
  const a : 1 = 1; return a;
}

@entry
const entry = (p: nat, s: int): [list<operation>, int] => {
  let result = f(p + s);
  return [list([]), result];
}

This may also be related to the use of TB_type_int z instead of TB_int in spilling, which is here because sapling uses int singleton types.

Component

  • compiler
  • website
  • webide
  • vscode-plugin
  • debugger

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Performance improvement (non-breaking change that improves performance)
  • None (change with no changelog)

Changelog

Checklist:

  • If a new syntax has been introduced, put a message on slack ligo-lsp
  • Changes follow the existing coding style (use dune @fmt to check).
  • Tests for the changes have been added (for bug fixes / feature).
  • Documentation has been updated.
  • Changelog description has been added (if appropriate).
  • Start titles under ## Changelog section with #### (if appropriate).
  • There is no image or uploaded file in changelog
  • Examples in changed behaviour have been added to the changelog (for breaking change / feature).
Edited by Xavier Montillet

Merge request reports