Handle AssemblyScript's typed Array syntax

[Y--]

Hi!

Thanks again for this great project!

I was playing with some AssemblyScript code and was surprised by the difference between i8[] and Int8Array.

For example, let's say I have:

export function getInt8ArrayLength(array: i8[]): i32 {
  return array.length;
}

Then when I execute it like this:

getInt8ArrayLength(new Int8Array(3));

I get unrelated numbers like 44381.

Now, I'm not very familiar with AssemblyScript so I am not sure if this should simply be forbidden (explicit runtime error?) or correctly handled. I was able to reproduce that behavior in AssemblyScript directly:

export function getInt32ArrayLength(a: i32[]): i32 { return a.length; }
export const Int32Array_ID = idof<Int32Array>();
export const i32a_ID = idof<i32[]>();

Then:

getInt32ArrayLength(__newArray(Int32Array_ID, new Int32Array(3))); // returns a wrong integer
getInt32ArrayLength(__newArray(i32a_ID, new Int32Array(3))); // works well

So the question is: do we have any way to know if the exported function argument's types?

I've started a branch here https://github.com/sutoiku/as-bind/tree/as-typed-arrays with tests that reproduces the behavior:

Let me know your thoughts.

Thanks!

Y.

[torch2424]

Hello!

Thanks again for this great project!

You are welcome! Glad that you are enjoying using it! 😄

I was playing with some AssemblyScript code and was surprised by the difference between i8[] and Int8Array.

Ah! So yeah I noticed you are using an array of a number type, vs. a TypedArray.

So, if I'm not mistaken, an Array in JS / AS is more of a dictionary-like list object, whereas a TypedArray is a specific type of view over a binary buffer. Thus, they are very similiar, but fundamentally do different things (especially in conjunction on how they are represented in memory).

So unfortunately, they can't be used interchangeably. So I would recommend just using a Int32Array type, or convert between the two as needed.

And at this time, as-bind only supports TypedArrays, and not normal arrays yet :( . Let me know if this makes sense! Thanks! 😄

[Y--]

That makes total sense indeed, thanks for the clarification on the semantics!

I was wondering if there was a way to explicitly raise an error when one tries to call a function that declares an array of a number type as an argument with a TypedArray input (and the other way around)?

[torch2424]

That makes total sense indeed, thanks for the clarification on the semantics!

You are welcome! 😄

I was wondering if there was a way to explicitly raise an error when one tries to call a function that declares an array of a number type as an argument with a TypedArray input (and the other way around)?

Ah! That's a good idea for the interem. As this seems to be a common hiccup people experience, for example #28 . Adding an error for unsupported types until we support them would be great! Let's keep this issue open so we can implement that 😄

[Y--]

Excellent! Thanks!
I'm happy to give it a shot. Is there a way to do reflection on a function's arguments in AssemblyScript?
Or were you thinking of some other way to implement this?

[torch2424]

@Y-- Oh yay! Thank you for wanting to pick this one up! 😄

So I'm not too sure about the reflection, but I'm sure @dcodeIO or @MaxGraey would know :)

And the way I would have implemented it, was to add export const i32a_ID = idof<i32[]>(); to the entryfile. And if the ID in memory for the object doesn't match the one we expect (Similar to how the loader verifies if an object is a string), then we can error and let the user know 😄

[torch2424]

closed by #66 😄 🎉

[Y--]

@torch2424 I think this issue remains: there is still no compatibility between an array of a number type as an argument with a TypedArray input (and the other way around). We unfortunately haven't have time to work on it yet, but I still think it is relevant.
I just rebased the branch and the tests are still failing the same way :-)

[torch2424]

Oops! My apologies, I'll re-open than! 😄 @Y--