JsLIGO improvements

marked the checklist item add support for iterating over maps (@lesenechal.remi, !1949 (merged)) as completed

marked the checklist item add support for iterating over maps (@lesenechal.remi, !1949 (merged)) as incomplete

marked the checklist item add support for iterating over maps (@lesenechal.remi, !1949 (merged)) as completed

changed the description

//missing find_opt function

let find_opt : (f : (x : _a) => bool, xs : list<_a>) => option<_a> 
    = (f : (x : _a) => bool, xs : list<_a>) : option<_a> =>
    match(xs ,list([
      ([] : list<_a>) => None(),
      ([x,... xs] : list<_a>) => {
          if(f(x)) { return Some(x); } else {return find_opt(f, xs); } 
        } 
    ]));

I've added this one to the list.

Implemented.

Add List.empty or even better, let z : list <int> = [];

Same comments apply for Set

How can we simplify this code that actually works but is almost unreadable ?

const _test_mutation = () : bool => {

  let log = (mutations : list<[bool,mutation]>) : bool => {
    if(List.size(mutations) == (1 as nat)) {Test.log("Mutation issue found"); Test.log(Option.unopt(List.head_opt(mutations))); return false;}
    else return log(Option.unopt(List.tail_opt(mutations))); 
  };

  return match(Test.mutation_test_all(PokeGame.main,_tests) , list([
  ([] : list<[bool,mutation]>) => {Test.log("No mutation errors"); return true;},
  ([head,...tail] : list<[bool,mutation]>) => {
    if(List.size(tail) == (0 as nat)) { Test.log(head); return false;}
    else return log(tail); 
    }
  ]));
}

Ideally we should be able to remove almost all of those annotations with the new type system

changed the description

replace match by switch

This goes in favor of deprecate match function Extend switch statement with pattern matching capability instead of Add support for match expression

Ideally i would be very happy to have jsligo that is valide TS. This would be a valide pattern matching in both with this feature

type a = ["a", string];
type b = ["b", string];
type c = ["c"];
type t = a | b | c;
const snd = (tuple : t) : string => {
    switch (tuple[0]){
        case "a": {
             return tuple[1]; 
        }
        case "b": {
             return tuple[1]; 
        }
        case "c": {
             return ""; 
        }
    }
};

I support it but doesn't seem that simple.

Whatever I'm not in favor to implement a Stage1 proposal.

If we cannot have pattern matching exhaustiveness with switch, i would recommand to keep the situation as is, and reconsider this feature when we either have time to implement switch or when match expression is at least stage3 of TC39

Discriminated unions have been implemented, and although they are a bit of a hack and have some limitations, I believe this is good enough for the audience.

Destructuring in function parameters <= yes, because we need to pass always a table of fields as unique parameter of a function, would be better to have several parameters

i.e : func([arg1,arg2,arg3]) to be func(arg1,arg2,arg3) on func definition, this allows to have const func = (arg1 : type1,arg2 : type2,arg3 : type3) : typeReturn => {...}

I think it is about destructuring records & lists, destructuring on tuple is already ok.


//works in 0.50.0
const tuple_params = ([a,b] : [int, string]) : string => b;
const params = (a: int, b:string) : string => b;

// would work with param destructuring
const record_params = ({a,b} : {a: int, b: string}) : string => b;
const list_params = ([a,b, ...rest] : list<string>) : string => b;

Context is while defining a function with several arguments, we are obliged to use func([arg1,arg2,arg3]) and would be nice to allow func(arg1,arg2,arg3)

Destructuring of objects in function parameters have been implemented. ~~Tuples was already possible.~~

Correction: tuples was not possible, but have now been implemented.

is it possible to have implicit casting sometimes with no compiler error ? Like this example :

let b: int = (5 as nat) * 5;

failwith("Address"+Tezos.get_source()+" is not an admin")

is it possible to use the spread syntax without list keyword ?

let larger_list: list<int> = list([5, ...my_list]); // [5,1,2,2]

replaced by

let larger_list: list<int> = [5, ...my_list]; // [5,1,2,2]

Does this work also with 2 lists as argument ? OR does exist a List.concat() function to do this?

ps : same questiosn applies for "Set"

This is a bit heavy :

let my_set: set<int> = Set.literal(list([3, 2, 2, 1]));

why not let my_set: set<int> = [3, 2, 2, 1] ? <= btw, here the compiler could detect that there is an issue because one value is duplicated

ligo would not allow implicit casting

let my_set: Set<number> = [3, 2, 2, 1]

is not valid TS

ok

General question about Exceptions :

when failwith is reached, there is no way of catching it , right ? Is is possible to introduce try/catch mechanism ?
can we "classify" Exception ? meaning a function can throw different type of Exception. type failwith = ["UserNotFoundException"] | ["InvalidAddressException",address] ?

It would be interesting but I don't think there is a way to interecpt runtime errors in Michelson?

Would be one day ? or it is designed to never have it ?

Probably not. There is only 2 possibilities for an exception in MICHELSON:

Explicit FAILWITH
CREATE_CONTRACT that fail.

Which means except for functional error management you can mostly be managed by if/else

in typescript we can have UNION of types

Is it something similar to jsligo Variant ?

jsligo : type coin = ["Head"] | ["Tail"];

typescript : type coin = Head | Tail;

If variant is more a enum than an union type, is typescript syntax for variant possible to do and still work?

enum coin {
  Head= 'Head',
  Tail= 'Tail'
}

The jsligo syntax in your exemple is a union of nuplets (here with 1 element) . It is also valid TS so that's fine to me.

Enum doesn't give more. It's a variant literal string or number. They are not very useful even in TS.

In TS you have discriminated union that give a more elegant way to emulate variants with parameters, but this require to have literal string types. I'm not sure ligo want / can manage this type?

JsLIGO improvements

Type system

Syntax

Modules

Stdlib

Designs

Child items ...

Activity