Many Snap! primitives are redundant
While researching the arguments for user-defined libraries (which I'll probably raise in this forum later), I found that 15% or so of Snap! (v.8.2.3) primitives are, in my view, redundant: they can easily be recreated with just a few other Snap! primitives, without much loss in runtime performance. If performance is not considered, many more primitives might be called redundant (a third, at least).
This inspired me to propose a refactoring project
Let's see how many of the (currently:185, not counting parameters and "relabel") Snap! primitives can be recreated with a limited set of other Snap! primitive blocks.
The idea is to end up with a short & simple subset of essential Snap! stuff, which may collectively be named: "s!" As far as I'm concerned the effort is primarily for fun.
Invitation to join
If you would like to contribute implementations, you are most welcome! Please post your contributions below.
I've already done a few sample refactorings in this project. E.g.
I am going to add the best (shortest, most readable, fastest … funniest?) implementations to this project - citing the names of the contributors, of course. Moreover, this forum topic will probably remain accessible for a long time (I suppose).
Notes
- where two or more blocks can be mutually implemented as a function of the other, I suggest choosing the simplest implementation, and considering the other block as truly primitive.
- library functions implemented using JavaScript calls will also be considered Snap! primitives, for this purpose.