OK, a variable, not a reporter. But how the underlying tools work is not relevant to a user: they are not part of the language (Snap ! may someday be ported to a different environment, and it will still be the same language). From a user point of view, a set of blocks is redundant if, and only if, at least one of the blocks may be expressed in terms of other block(-s) within the set.
Yes, but those other blocks include the ones about variables. I don't see what distinction you're drawing.
This has become a rather theoretical discussion … that having been said:
What I mean (regarding the currently 17 blocks within the Motion category) is that, from a user perspective:
- in order to be able to construct Snap ! blocks from other Snap ! blocks, one needs a minimum set of Snap ! blocks which I choose to call “true primitives”, and
- the size of this set is 4.
The obvious choice for a set of true primitives would be the GO TO (position), and POINT IN DIRECTION commands, plus the POSITION and DIRECTION reporters.
If, following your proposal, one would be going to derive DIRECTION from making a MOVE (n) STEPS (which is a bad plan in the first place because of its side effect), one would still end up with a set of 4: GO TO, POINT IN DIRECTION, POSITION, and MOVE (n) STEPS; the latter, after all, can not be constructed from only the other 3 true primitives (i.e. without DIRECTION).
You can use blocks from the sensing category to recreate the position and direction reporters, so the only true motion primitives are POINT IN DIRECTION and GO TO POSITION.
also, @bh, while the mechanics of direction can be recreated using variables, the visual representation of a rotating sprite is much more difficult to replicate.
Yeah, you got me. This is why we don't have a minimal palette. But this is an exercise in seeing how little you can get away with.
Yes, so I was saying that if you want all the Snap! Features, the two motion blocks you need are GO TO and POINT IN DIRECTION
Oh I see, yeah, if you want the sprite to turn.
Although... It'd be quite a bit more work, but you could have the sprite itself be invisible, and have MOVE (written in Snap!) erase and then redraw the costume, and have SET DIRECTION (written in Snap!) do the linear algebra to change the internal picture of the costume to be facing the new direction.
Or, an in-between approach, use the built in costumes and use the NEW COSTUME feature to make a rotated version of the costume.
I still say you don't need SET DIRECTION as a primitive.
yeah, that could work if you could figure it out.
these can be used instead of motion reporters:
I agree with @starbox614, by now: while either GO TO or GO TO X: Y: and either POINT IN DIRECTION or POINT TOWARDS are true Snap ! primitives, both POSITION and DIRECTION reporters could be replaced with reporters from the Sensing category (I hadn’t been aware of that before; and I guess that they were introduced after POSITION and DIRECTION).Thus the Motion category has not 4, but just 2 true primitives .
I strongly disagree with @bh’s absurdly theoretical approach of POINT IN DIRECTION - replacing costumes by “rotated” versions would be utterly impractical, to say the least.
POINT TOWARDS can be replicated using POINT IN DIRECTION(direction TO target)
That’s why I wrote:
I was confirming that it is POINT IN DIRECTION
How do you suppose Snap! actually does it?
Not sure I understand what you mean.
Anyway, GO TO X: Y: can easily be expressed in terms of GO TO:
I rewrote 15 of the 17 current Snap ! primitives from the Motion category in terms of other Snap ! primitives: Snap! primitives refactored. As for the other categories, it's a work in progress.
As a user I don't know (and, frankly, I don't care) what's "under the hood"; any programming language deliberately abstracts from that. Like I wrote in post #62:
You may or may not agree with what I consider a meaningful definition of redundancy within a (programming) language. If you agree I respectfully challenge you to code a POINT IN DIRECTION implementation using only other Snap ! primitives (not being POINT TOWARDS, of course).
I mean: a full implementation, e.g. 
and 
must report the same results as with the regular Snap ! 8.2.3 implementation of POINT IN DIRECTION ... Good luck 
No, it's not worth my time just to prove a point to you. But if I were going to do it, I'd just translate the JS code in those primitives to Snap!.
I wouldn’t have done it either. 