Miscellaneous

[rvanasa]

• Requires <system> capability to call CertifiedData.set().
• Updates Timer and Error modules to reflect changes to original base library.
• Removes deprecated hash functions.
• Updates trap messages to include the name of the relevant base library function.

[github-actions]

No description provided.

[crusso]

I guess we may need to make the Prim.setCertifiedData take a argument too to make this really safe (otherwise people can directly call Prim.setCertifiedData).

[crusso]

Doing this change may also break some third party libraries. But I guess we need to make break some eggs...

[rvanasa]

I guess we may need to make the Prim.setCertifiedData take a argument too to make this really safe

This is probably worth doing, since otherwise there isn't much of a benefit to changing the base library if people can go around it by importing Prim directly.

I'll roll this back to set : (data : Blob) -> () = Prim.setCertifiedData so that it preserves whether the prim function has the <system> requirement.

[crusso]

@luc-blaeser are you ok with renaming equalWIthin (and notEqualWithin) to equal and notEqual?
Also another option might be to make both of these curried functions, that take the epsilon as a first argument and return an equality/inequality function of the usual binary type:

  public func equalWithin(epsilon: Float) : (x : Float, y : Float) - > Bool =
       func(x : Float, y: float)  { ... epsilon ...  }
  }
 (and similarly for nonEqualWithin 

[rvanasa]

The motivation here is for API uniformity. I suppose we could curry the arguments, although I think equal(x, y, epsilon) is more consistent with how we handle the compare and equal functions for data structures.

On the other hand, it could be worth doing something different to reduce possible confusion about the argument order, given the equal(Float, Float, Float) signature.

[crusso]

Right, I thinking about the situation where you want to pass the equality function as a first-class argument (which is why we define it for convenience...)

I don't have a strong opinion...

[crusso]

If we aren't going to even provide any hash based data structures (are we?) I'd be tempted to get rid of this whole module Hash.mo. length seemes misnamed (should be maxBitIndex or something) and bit is probably an implementation detail of Trie.mo which uses the hash bits to index into a radix tree (IIRC). Might be worth checking if pos/length are used anywhere else.

[rvanasa]

Opened a separate PR for this: #129.

[crusso]

LGTM (see suggestions)

[crusso]

LGTM. We can always change the equal notEqual names back if @luc-blaeser feels strongly.

[crusso]

Do we even want notEqual, since its the literal negation of equal @luc-blaeser and we don't provide notEqual for other primitive types.

[rvanasa]

Seems reasonable to remove this function. I'll merge and open another PR to start working on the merge conflicts in parallel.