HigherOrderCO/Bend

Add option to write raw hvm in bend programs

Closed this issue · 0 comments

Is your feature request related to a problem? Please describe.
While adding some of the native numeric operations, I noticed that to support them properly they'd need to be names that get special treatment by the compiler.
In my view this is a bit of a hack and leads to poor maintainability.

A solution to this would be writing raw hvm code in Bend which can be called as a function or assigned to a variable. This would allow us to write these operations succintly with a very general way of dealing with any future similar situations.

Describe the solution you'd like
Defining a native hvm definition like we define bend functions.

hvm to_f24:
 ($([f24] a) a)

Here, we must specify something that HVM can read as a Net (aka an inet package). This translates to a combinator in lambda calculus, so it's already conveniently shaped like a function.

**Describe alternatives you've considered**
Allowing inline hvm assembly in the form of a variable assignment.
```rs
# obviously not a good syntax, but something like this
let_hvm to_f24 = ($([f24] a) a)

Since here hvm native code must still be a combinator, I don't think there's any advantage other than locality, but that could be solved with local function defs. It also has the risk of the syntaxes clashing and creating parser ambiguities.

Additional context
This also would allow us to write things that don't obey lambda calculus by allowing us to write nets that don't obey normal lam/app polarity. This was requested by Noam Y on discord.

For example:

# This function causes two ports to be linked and returns *.
# This can be used to interpret a lambda as an application and apply something to it for example.
hvm link_ports:
  (a (b *))
  & (c a) ~ (d e)
  & (e b) ~ (d c)

Currently we can sort of hack this in using tuples in ways they're not really meant for. This is a bit more elegant.