ballercat / walt

:zap: Walt is a JavaScript-like syntax for WebAssembly text format :zap:

Home Page:https://ballercat.github.io/walt/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Array types in function arguments

ballercat opened this issue · comments

Overview

Array types should be acceptable function arguments. Currently, we do not have parser support for them.

Expected

A function can be declared with an array type as argument.

Actual

SyntaxError: 
function testa(arr: i32[]): void {
                       ^ Unexpected token Punctuator
Expected: "Identifier"
  at testa (unknown.walt:7:23)
walt.js:3238:12

Acceptance Criteria

  • Tests for the above case
  • Tests pass

Personaly I'm not a fan of i32[] syntax but it makes more sense right now because while we don't have generic types. After that it makes more sense to be more consistent and use Array<i32> syntax. It's more code but it's also valid and we're not creating special case for the array type.

Isn't it a goal to support most of the Flow syntax?

Flow supports both notatations and i32[] is a shorthand for Array<i32>.

https://flow.org/en/docs/types/arrays/

Yeah, so I assumed walt would do the same

Isn't it a goal to support most of the Flow syntax?

I want to clear something up. The goal is to use flow to accomplish a specific goal of using JavaScript syntax to write WebAssembly. Supporting most of flow would mean supporting most of JavaScript, which is unlikely.

The Array<i32> syntax does make sense if you expect flowtype to be re-implemented here. But re-implementing flow is not really a goal, simply a means to an end. I also wonder if there is a better argument made for the additional syntax other than I prefer it over the other because to me it's not clear why either superior to the other.

Having an i32[] syntax is good because it's simple to implement and simple to understand and it's rather stable at this point. I'd like to see this project move past the alpha stage and have some real-world examples out there before exploring additional syntax. Like @baransu said having an Array<> style syntax implies that there might be some generics-like stuff around, which there isn't.

Maybe we can add flow as a part of the compiler? As you said reimplementing it isn't the goal but maybe we can leverage work that already been done. If we want to follow JavaScript and Flow syntax we can add flow as the first step of the validation. After that we will have the quarantee that we have correct typing so compiler can focus on more important things.

Can Walt utilise the Flow AST?