siromivel/lambdeth

A functional library for the EVM built in Solidity

lambdeth's Issues

Explore Possibly Preventing Buffer Over/underflow

I don't know that this is possible, but it would be really nice if we could ensure safety while functions being passed into Lambdeth are executed. Solidity does not allow operator overloading so we should explore any other avenues to enforce use of SafeMath.sol or similar libraries.

If this isn't possible it's not terrible, production contracts should be audited either way this would just be a nice way to take some of the burden off of security auditors.

Unique is Omitting 0

I ran into this while making map support currying(#10) - it looks like unique is omitting 0 from the resulting array. I check contains thinking that may be the problem but it seems to handle 0 just fine. Looking at this now but wanted to ensure it is documented, so creating an issue for it.

Explore Architecture for Handling More Types

Having lots of bytecode in a single contract is fairly costly; I'm thinking it will be ideal to have a contract for each type we want to support and link them together in some master contract for ease of use. Alternatively they could each live as a separate library on-chain, although I can see that being somewhat painful for end-users to navigate.

May also consider breaking up the actual functions if we end up with a lot of them, possibly exposing them like: Lambdeth.iterators.map() or Lambdeth.sort.quick().

Listing Lambdeth as an EVM Package

Levi, Tara, it was great meeting you at EThDenver. Hope you got some well-deserved rest.

We believe Lambdeth could be a great EVM package for the ecosystem once is finished.
Once the code is complete and deployed to mainnet, we could list it on our repository so the community can use it. You have more info about the process here (Create an EVM Package)

Here is the registry: https://registry.zeppelinos.org/

If you have any questions, please feel free to reach out at [email protected]

Documentation

Currently the readme is where we're documenting Lambdeth; at some point before this gets too big we should explore a better system (possibly a ReadTheDocs integration.)

Method Chaining or Currying

Ok, this one's a bit of a doozy. The 0.x Lambdeth API is similar to Lodash and doesn't allow easy currying. It's an open question whether or not implementing chaining or currying is even a good idea as it may invite users to write extremely costly lines of code. Method chaining will definitely take some work to implement in Solidity but I think it may be possible with some creativity.

Implement Quicksort

For now I think it's probably sufficient to just expose a quicksort implementation - we can add bubblesort etc.. downstream if users actually want them; quicksort should be good for most use cases.

Refactor Tests to use ZOS

We ran into some major issues working with the ZOS proxying in tests at ETHDenver and ended up just writing some old-fashioned tests with Truffle - we should refactor these very soon to properly test the proxying system.

Implement String Methods

Implement Find/Contains

I'm not sure if we should bother implementing both of these - a reasonable find method should return the value in question which makes it perfectly capable of being used as a "contains" with a typecast. Maybe just expose contains as a wrapper on find for some syntactic sugar. I was probably too hasty with this, I've implemented contains only as it seems cleaner to always be able to return something, especially in an EVM execution context where throwing may lead to reverting an entire transaction which may be very undesirable behavior for a library like this. It seems like if a user wants some specific value if it is present in the array it is safest to call a contains method that returns a bool indicating presence or absence of a value and then they can simply use the value from there.

If we get to a point where we can build generic iterators for struct arrays we might want to revisit developing a method to return the actual value present in the array, for simple data types it seems excessive.

Implement concat

Add CI

We can integrate with Travis(https://travis-ci.org/) for free!

Implement Address Methods

We may want to support both mappings and arrays for these as it's a pretty common pattern to store addresses in a mapping.

Implement Splice/Slice Methods

Gas Cost Profiling

We should get some statistics on the gas costs involved in using our initial map and filter methods.

Consider Implementing a `keyBy` Method

Take an array, returns a mapping with keys from the array's values.

At the moment a solidity function cannot return a mapping type(mappings only exist in storage) - this could be a fun problem to play with!