Refactoring Snap!

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.

Snap! primitives refactored script pic (7)

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

  1. 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.
  2. library functions implemented using JavaScript calls will also be considered Snap! primitives, for this purpose.

nice project! You could simplify move even slightly more using hyperblocks:

[edit] thanks to @loucheman for pointing out a bug in my original script!



sorry Jens, it doesn't work...

(it work 1 time from (0,0)...)

Always go to position (3.09 , 9.51)

Oh, you're right, I forgot to add the position!, lemme edit it....

Exactly the formula I was trying to find last week! Life is well done!

Perhaps it has something to do with the phenomenon recently described in a different topic … ?

I adopted @jens’ version in the project, and credited you as well. Thanks!

I read somewhere that a programmin language that entirely consists of call and make a block is doable, i don’t remember where but i think it’s in the manual somewhere but I couldn’t find it

So really all that’s needed is 1 block

I don't need credit for reporting a bug...

Not even that, just CALL and gray rings. You read it here. It's the Snap! version of lambda calculus.

did you ever finish refactoring?

I got as far as the project my OP links to.

You could do loops via recursion.

untitled script pic - 2023-12-11T091847.980