ArrayBuffer equivalent in motoko?

For some low level task, one would need to manipulate the underlying bytes. Do we have JS ArrayBuffer/TypedArray equivalent in motoko?

Take for example, currently I don’t find a way to hash a big Nat. Hash.hash takes Nat, but it really just works on Nat32. I want to turn Nat to multiple Nat32 and hash them.

cc @Ori

You can use [Nat8] or Blob. This is how some of the hashing functions work current (SHA256 and SHA224)

Could you explain how to convert an unbounded Nat into a [Nat8] or Blob?

Theoretically I can loop and mod 0xff like crazy to chunk a Nat down to pieces. But obviously I’d like to avoid that route, that’s why I ask this question in the first place.

I wish to access the underlying bytes of a Nat, and simply map each byte into a Nat8.

Yeah that was my answer, chunk it down using bitwise commands and mod 255. This is essentially how it will work in future (e.g. someone will make an ArrayBuffer library that just uses [Nat8] and has functions for each of these). Currently doesn’t exist in Motoko (publicly) but it’s not too hard to create one.


Oh, sad to learn that.

Does it exit privately? :sweat_smile: Like somewhere in “mo:prim” ?

I know there are some motoko libs out there that aren’t public yet from community devs and most likely dfinity devs too. It may be within mo:pirm haha - although I think dfinity don’t want people to rely on that going forward.

There are dev grants available, could be an idea for someone to apply for funding to build out additional types link ArrayBuffer etc (with corresponding functions like fromNat, fromText etc).

How about using a Buffer?

I don’t think we have anything better in prim and would discourage anyone from relying on functionality exposed via prim.

For now, you’ll need to do the arithmetic yourself, I’m afraid. Sorry about that.

1 Like

Might I ask, what does the byte encoding of a Nat looks like? Sorry I couldn’t find corresponding ref resource :sweat_smile:

Currently Nat and Int are implemented using wrappers around LibTomMath ( but that’s an implementation detail that could change. There is no way to access the raw representation from Motoko (by design). That doesn’t mean we couldn’t provide some way to iterate over the raw bytes in future though, if desired.

1 Like