In Snap 6.0, there is a feature to add a number to a list. But I've thought about it and it just doesn't make sense. They are different types of, um, stuff! It's like adding 3 sheep to 5 trees. Binary operators are supposed to be based on same types, right?
Dunno how much math you know, so I'm not sure quite how to answer, but let me start by saying that mathematicians multiply vectors by scalars all the time. It's true that that doesn't raise the same issue about units (physicists are always multiplying meters by newtons and the like), so you're mathematically right that addition is less well supported.
The situations in which it's useful to add scalars to vectors tend to be related to databases. You have a list of the salaries of everyone at the company, and you decide to give everyone a $3/hr raise. Or you have data about a bunch of people's ages as determined three years ago.
More generally, it makes sense when you consider the vector not as a different kind of stuff, but as a container for stuff. You have a box of donuts and you want to add cinnamon to all of them.
Does that help?
Agreed and disagreed. When I say I am going to add 1 to some previously written numbers like 2, 3, 4, I mean that I am going to add 1 to either any of them or to 2. At least, that is how it is done daily among common people (anybody except for mathematicians).
Doesn't it depend what the numbers mean? Ages are the clearest example. If we all met a year ago and someone says "we're a year older now," you wouldn't add 1 to only one person's age.
But really the justification for it is that it turns out to be useful in programs sometimes. One example that comes up in APL code is that they represent Booleans as 0 and 1, but they have 1-origin array indexing, as we do for lists. So you have an array B of 0s and 1s that you want to present to a user as false and true, so you say 'FT'[B+1] and you get an array of F for False and T for True.
True. But then I would say something like add 1 to all items in list. And I do not know anything about APL.
Sure. I don't want to argue about human-language idioms. How you say things in words is sometimes misleading in programming. One of the standard beginner mistakes is
IF X=(3 OR 4) ...
because in English that would mean "X=3 or X=4" but that's not what it means in any programming language.
I don't want to argue at all, really. If you don't like this programming notation, don't use it! We're not going to take away MAP.
Yes, but looking from that point of view, you would have to rename blocks in Snap! to sound like other languages.
Yeah. But it would be much simpler if it was in the other way.
I'm sorry, I don't understand what you're saying. If anything, we should make them not sound like words at all. (True story: When Chevrolet introduced a car called the Nova, which was supposed to sound like a hugely energetic explosion, and then people told them "no va" means "doesn't go" in Spanish. So then when Standard Oil wanted to change their name, they hired linguists to come up with something that can't possibly be words in any human language, and the linguists told them to use "xx" in the name, and that's how they became Exxon.)
The difficulty is that you want to use words so that people can remember which of the hundred-odd blocks is which. But then people think they can use the blocks in all the ways they use the words in ordinary speech. This isn't so bad when the word is "move," for example, which really does only have one meaning (not counting the '60s English rock group). But a common connective like "or" has a dozen different meanings in different contexts. Maybe we should call it FTTT. ;~)
What other way?
none of these are false
Just to be clear, are you upset that the top block produces the same output as the map block below it?
I guess I can sympathize to a degree, but Snap! isn't typed like many other languages. There are languages where each command is free to interpret its inputs however it likes. In this case, there has been an explicit decision to adopt some of the semantics of APL with respect to numeric operations. I can confess to being impressed by APLs power and conciseness, while being unimpressed by its syntax.
Anyway, I think the interpretation of 'number + list' as the same as 'map <1 + []> over [list]' is sensible. The only alternative that would make sense to me would be 'add <1> to ', which would insert the number at the end of a list. That would be much more surprising to me. Alternatively, you throw an error, and lose the expressivity of APL.
I don't think you can praise the "conciseness" while objecting to the syntax!
APL is really the only language that gives me moments of text-language envy. The MAP expression you cite really isn't any less concise or powerful than
(map (lambda (x) (+ 1 x)) '(1 2))
but it doesn't hold a candle to
1+1 2
I'm unimpressed by my timidity in expressing my dislike of APL syntax
;~P
I mean, if you want Snap!'s syntax to be like other text-based programming languages then you need to say goodbye to many blocks like ask, move, say etc.
Saying or executing 1 + 2, 3, 4, 5 returning 3, 3, 4, 5 instead of 3, 4, 5, 6.
I love the new facility - mapping without having to do all the mouse work 
Oh, I see. Being like other languages isn't a goal at all. I was just saying that, as in most languages, using familiar English words as names for procedures is a two-edged sword. It's great because people can remember which procedure is which, but it opens up the possibility of beginners thinking they can be used exactly as the words can be used in English, as in the x=(3 or 4) bug. That doesn't mean we should change the names, although I bet fewer APL beginners make the same mistake with x=(3∨4), just because it doesn't look like English.
As for 1+2 3 4 5, it's true that that APL notation takes some getting used to. But there's no ambiguity between 
and 
. That's a great advantage we have as a blocks language!
Indeed.
[scratchblocks]
if<(list(3)(4))contains(x)>then
[/scratchblocks]
super...?
I agree.
So maybe we should call [scratchblocks]<<>and<>>[/scratchblocks] ×××√
Sure, I wasn't saying it was impossible to write a correct Snap! program conveying that idea. But beginners often literally want to write
and of course that doesn't work.