Implement `net` and standard library for JS output

[jeapostrophe]

Alex

• [ ] stdlib.assert
• [ ] stdlib.uint256_to_bytes
• [ ] stdlib.keccak256
• [ ] stdlib.bytes_eq
• [x] stdlib.bytes_len
• [x] stdlib.bytes_cat
• [x] stdlib.bytes_left
• [x] stdlib.bytes_right
• [x] stdlib.random_uint256
• [ ] interact
• [ ] net.recv's implementation of abi.decode
• [ ] net.send's implementation of abi.encode

Faré + Matt

• [ ] Change the names in the JS output back to match the names of Alacrity primitives (renaming should be at the level of the stdlib implementation, not compiler implementation.)
• [x] net = new EthereumNetwork()
• [x] net.deploy --- Accepts the ABI and contract bytecode and the list of participant addresses and constructor arguments (empty), returns a contract object. Anyone can call this. A typically does. Probably written in callback-style.
• [x] net.attach --- Accepts the ABI and contract bytecode and the list of participant addresses and the address of a deployed contract, returns a contract object. Anyone can call this. B typically does. Probably written in callback-style.
• [x] ctc.send --- Receives the name of the message and an array of the values to send and the amount to pay for the call and the callback, prepends those values with the participants (which it knows), and sends the message. Calls the callback with nothing when the message is sent.
• [x] ctc.recv --- Receives the name of the event to listen for once and a continuation. Calls the continuation with the decoded values once it arrives AND the msg.value as the last argument. [In the future, this might need to be something like "transaction state" and we'd also look at the time, etc.]

[jeapostrophe]

Please update this with what is done

[fare]

What is done is the groundwork so the manual and automatic backends can share a lot of code including the frontend (that needs more work). The stdlib is complete, except that I didn't implement the inverses to msg-cat, that we don't actually need so far. I was blocked a bit by the issues I raised (#81 I believe), so I stopped at that point (also it was 4am). I have been thinking about what send and receive (and the factory equivalent make and attach) would look like. In both cases, we watch the chain for messages; in the case of the first make, there is an interface offering the user an option to create a contract with interact. In the case of attach, an option for the matching user to accept it. All other sends are the result of the continuation to a receive that watches the chain, computes a next step, and either takes an action, or registers some more input to be done with interact.

[fare]

I did the stdlib part, except the bytes left and right, that require knowing the size of the left, either statically (which our compiler doesn't provide) or dynamically (which the current Solidity implementation doesn't do—we use abi.encode, which doesn't).

[fare]

On my part, see my comments on #dsl about the need for descriptors. I can fake them for now.

[jeapostrophe]

I did the stdlib part, except the bytes left and right, that require knowing the size of the left, either statically (which our compiler doesn't provide) or dynamically (which the current Solidity implementation doesn't do—we use abi.encode, which doesn't).

The fact that abi.encode throws away the information means that it is not a valid implementation for cat. You could make cat x y = abi.encode( x.length, bytes-cat( x, y )) then use the length to split the bytes string.

[fare]

Yes. If we want to save space, we can make the length field 16-bit, since the quadratic cost of memory makes anything more than that size unaffordable, anyway.

PS: A block has a gas limit of the order of 8e6 GAS. The formula for memory cost is 3*(a+floor(a/512)), which for 65535 is already over 24e6. And that's just the memory cost (though it would dominate in this case.) Thus data of size 64K or larger are not affordably representable on the Ethereum blockchain (at the moment; that may or may not change in future years).

[fare]

If we're doing that way, maybe we want to call the functions pair, fst, snd, more in line with haskell

[fare]

(Haskell uses left and right for sums)

[AlexKnauth]

My work on this so far is on this branch: https://github.com/AlacrisIO/alacrity/tree/msg-cat Where I have msg_cat, msg_left, and msg_right.

[fare]

If we're doing that way, maybe we want to call the functions pair, fst, snd, more in line with haskell, that uses left and right for its binary sum.

[AlexKnauth]

The names pair, fst, and snd to me would imply that they're fully polymorphic to allow pairing any two values together. We will want to add fully polymorphic pairs/tuples eventually; these monomorphic bytes operations are not those.

[fare]

1. Give it monomorphic names msgPair, msgFst, msgSnd if you want. It's the underlying runtime substrate to the polymorphic concept.
2. The file js/stdlib.mjs is the wrong place. Put it in examples/rps-demo/common-{utils,runtime}.mjs for now, until we factor the runtime out of that directory when the demo is complete.
3. The implementation is not complete until EmitSol.hs emits code that is congruent with EmitJS.hs.

[AlexKnauth]

(1) That would make sense to me. msg-pair makes mores sense than msg-cat or bytes-cat since it correctly conveys that the two elements are still separate, and can be extracted unambiguously. (2) The stdlib.mjs functions should be part of the language runtime, not part of an "example use" of the language, so I don't think examples/rps-demo is the right place for it. (3) Yes. Though that's covered in a separate issue: https://github.com/AlacrisIO/meta/issues/69.

[fare]

(2) That's where it is now, and where you should put it to interact with the code we're writing, and where the other functions of the stdlib are as well as the previous iteration on this code. No doubt the stdlib will move at some point before release.

[fare]

(1) Actually, I prefer msgCons, msgCar, msgCdr — the names are appropriately low-level, shall speak to fellow language implementers, and is invisible from the end-user, anyway.

[jeapostrophe]

@AlexKnauth

1) Please have the names match the names in Alacrity as much as possible given the identifier restrictions in JS/Sol

2) Please put them in js/stdlib.mjs

3) Yes, #69 is the other task too

[fare]

1. stdlib complete in 79e8480, both JS and Solidity.

2. You can't put it in js/stdlib.mjs without moving in library import and initialization, and abstraction of whether they are imported from nodejs vs browser (ongoing work by matt), since crypto and bignumber support are not portable but provided by various libraries. That's not something we should work on before matt is done.

3. I did the solidity too. Needs tests and optimizations at some point. Not now (though, add tests at some point in the near future)

[jeapostrophe]

Great

[fare]

PS: regarding throwing away information, I was somewhat confused with abi.encodePacked that throws away length information. abi.encode doesn't; it has an (inefficient) protocol for representing arbitrary length data of size n bytes as 32*(2+ceiling(n/32)) bytes. In both cases, though, the type information is otherwise dropped, such that it is trivial to create an object of a different type with the same encoding and thus the same digest.

PPS: actually, abi.encodePacked throws away dynamic length information while making use of static length information, while abi.encode throws away static length information while making use of dynamic length information. Go figure.

[fare]

web3.js 1.0.0 exposes web3.eth.abi.encodeParameters which supports the equivalent of Solidity's abi.encode. Unhappily, we must use web3 0.20.x which is what metamask provides, and it is lacking this part (or failing to expose it). For the purposes of the rps demo, I will implement just the uint256 type, which is the only one we use (for now), and is trivial to support. Hopefully, by the time we need more, we will have something better than web3.js 0.20.x to deal with.

[mattaudesse]

Based on today's meeting with Jay we seem to be in agreement this is closable.