Why would I ever do this
In nearly all use cases, there is no benefit of expending extra effort to add 0
if someone else (or yourself) tries to use the code in a hof, the implicit slot thing will ruin the program beyond the time loss of pressing the 0 key.
Then use
() - (x::variables)
Outside of a HOF,
(0) - (x::variables)
Inside of one!
yes, but it is very possible that you forget each time.
(((0) − (x::variables)) input names: ((#1)) @<>)
Imho we should have a monadic 
primitive right next to the dyadic one in the palette. One of my perennial arguments with Jens is that he thinks having a NEG option in the monadic-everything block is adequate. Maybe it would be good enough if the primitive looked like 
, but I don’t think even that would work, because users would have to understand the variadic input syntax in order to use monadic minus. When users argue about the best workaround for an awkwardness in the language, that means we’re falling down on the job.
I kind of agree with Jens. There already are 3 ways to negatize a number:
[neg V] of (n) (-1) × (n) $<:> (0) - (n)
And the first is very convenient. It’s only second on the list, and it’s not hard to find at all.
It looks peculiar, both when expanded and collapsed.
(@:> - ()::operators)
I kind of agree with Jens. There already are 3 ways to negate a number
Yes, but if you’re a second grader learning math in Snap! (as some of the users in the EDC math project are), the only one you already know is monadic minus. The point I was trying to make is that what determines whether a block is necessary or not isn’t whether the language is Turing-complete (for which all you need are
and 
), but whether the tools we provide fit with the users’ understanding. Nobody who isn’t a Snap! programmer, and not even all of them, knows what NEG means.
Oh yes, I agree, especially since it’s the left input that’s variadic, so the arrowheads kind of look backwards. That wasn’t my preferred solution, just an attempt at a compromise.
If you’re a second grader, chances are when you see -3
You think:
Negative three
Instead of:
3 gets negated by the (monadic) minus function.
That’s a good point.
Maybe
[negative V] of () ::operators
Or
[- V] of () ::operators
Could work, and the old option would be hidden but still work.
If the young children are taught through a sandboxed project (a microworld), then the author of the project could define a custom block that looks like (- ()::operators). About potentially confusing them when they move on to an unrestricted coding environment, just tell them that that block is for the sake of simplicity.
As with the cryptic abbreviations used in libraries: OOP, S4A, APL, API and MQTT.
If you’re a second grader, chances are when you see
−3
You think:
Negative three
Instead of:
3 gets negated by the (monadic) minus function.
That’s fine, although I’m sure they think “minus three” rather than “negative three.” :~) But, “-3” looks like what they’re thinking, whereas the alternatives you suggest don’t.
If the young children are taught through a sandboxed project (a microworld), then the author of the project could define a custom block that looks like (- ()::operators).
Yes, that’s true. But, what is the positive virtue of using a notation nobody understands, instead of the notation that everybody understands?
As with the cryptic abbreviations used in libraries: OOP, S4A, APL, API and MQTT.
No, I won’t give you that one. The fundamental ideas behind those libraries are used by specialists. You have to know what they’re about before you have any interest in the libraries. But everyone understands negation; it’s part of our general human heritage.
P.S. The beginning of this discussion about monadic minus came from the observation that our use of an empty input slot to mean an implicit function argument conflicts with the interpretation of an empty input slot as meaning zero. Negation is really the only situation in which people naturally rely on the empty slot being interpreted as zero, but I argue that in their heads they’re not thinking “I want to subtract this number from zero and isn’t it convenient that Snap! doesn’t make me put an actual 0 in there”; they’re thinking “minus 3” and the only minus on offer is the dyadic one, so they just ignore the left slot and make the block look as much as possible like what they’re thinking. In other situations the default zero is arguably the wrong thing; in particular, I think that 
with empty inputs should report 1, not 0. (I imagine only a math lover would actually use it with both slots empty, but I claim that most people would expect 
to report 3 rather than 0.)
So I think that in a perfect world an empty slot wouldn’t imply a default input value, and then the implicit parameter notation for functions wouldn’t conflict with anything. I know empty-means-zero is one of the sacred ideas we inherited from Scratch, and I suppose it’s not so bad for their purposes, but for us it gets in the way.
I am not sure what you meant by "nobody understands" in this. (- (n)::operators) is clear in intent: negating the number one. If you used () - (n) instead of the one with the makeshift substitute, what could the empty input mean? An accidental empty slot? An implicit input in a procedure?
I did admit,
By the way, I don’t know if I am remembering wrong but I swear I saw a post from a leader discouraging the use of (() - (n)), instead suggesting ((0) - (n)).
I know, as a math lover (the main rival to computer science and physics for my attention), that I am not the target of this post, but nevertheless, for myself, I think “I want to subtract this number from zero and isn’t it convenient that Snap! doesn’t make me put an actual 0 in there”. :~)
That’s actually how I think about [neg V] of () - “neg” doesn’t stand for “negative”, it stands for “negation”. I don’t read it as “negation of number” either, I read it as “take the negation of number”.
To what end? You can use the collapsed version to get the identity… I like to think of myself as a math lover, but you have me concerned! 
handle the “-3” already.
Algebraic notation -x is a shortcut for -1*x
Given x=-1 => -x => 1, there is nothing obvious nor intuitive in the -x expression.
It requires proper knowledge. In Poland, negative numbers are introduced in 6th grade, at the age of 12-13.
So the whole problems seems like splitting hairs.
I am not sure what you meant by “nobody understands” in this. (- (n)::operators) is clear in intent: negating the number one. If you used () - (n) instead of the one with the makeshift substitute, what could the empty input mean? An accidental empty slot? An implicit input in a procedure?
Sorry I wasn’t clear. When I said “nobody understands” I was referring to the Snap! primitives, not to somebody providing a monadic minus in a project.
By the way, I don’t know if I am remembering wrong but I swear I saw a post from a leader discouraging the use of (() - (n)), instead suggesting ((0) - (n)).
Yeah, someone said that. And indeed, if you want to negate a number in the context of a higher order function, you must use an explicit zero. But I view this as a deficiency in Snap!, which I am proposing to fix by adding a monadic minus primitive. I’m arguing that NEG OF, which purports to solve the problem, is an inadequate solution because (1) it’s buried in a menu, and (2) it’s not the customary notation anyway.
I’m going to move this discussion to its own topic; I’m sorry it hijacked a thread about something else.
I know, as a math lover (the main rival to computer science and physics for my attention), that I am not the target of this post, but nevertheless, for myself, I think “I want to subtract this number from zero and isn’t it convenient that Snap! doesn’t make me put an actual 0 in there”. :~)
Really? I don’t believe you. I bet most of the time you just think “minus 3,” and if (as a math lover) you stop to pay attention to how you’re thinking, it’d be “the additive inverse of 3” rather than “subtract 3 from 0.” Those two expressions have the same value, but they don’t have the same meaning.
To what end? You can use the collapsed version to get the identity… I like to think of myself as a math lover, but you have me concerned!
Yeah, now that we have variadic ×. I was really thinking of the old days when it was just dyadic.
Algebraic notation −x is a shortcut for −1∗x
Well that’s one way to think about it. I think about it more as a notation for “the additive inverse.” The fact that multiplying by -1 gives the additive inverse is a theorem.
So the whole problems seems like splitting hairs.
Well, it’s not at the top of my list of Snap! deficiencies. But I don’t see any downside to providing a monadic minus, and it’d avoid the ambiguity of empty input slots.
Guys what are we even talking about
( () - (num)) is the best and easiest way to convert a number to a negative unless you’re using a hof
I don’t get your point