Come on, @bh, that's intentional, and it was you who insisted on it. If it were for me I wouldn't support implicit empty-slot parameters inside the "for each" primitive at all, they're not needed because we already have an upvar for that. But you wouldn't have it, remember? You can't have both, empty slots as empty slots AND as implicit parameters.
I do agree with jens here. Having empty slots as implicit parameters makes sense on the HOF blocks, as there are no visible upvars, you have to click the arrow to get an option. Forcing you to use upvars in that case would make you have to click the arrow to get them every time you use them. However in the , the upvar is already visible, ready to use, so it makes sense that if you want to use the current item, you drag the upvar where you need it. In my opinion, having implicit parameters in the list block is the same as having behave the same as , which it does not.
Just my opinion, though.
Yes, I know it was I who insisted on empty slot substitution, as in the HOFs. I see FOR EACH ITEM as being in the same family, and they all inherit that behavior from CALL and RUN.
The part that I think is a bug is that primitive C-shaped blocks don't offer the same feature as custom ones, wherein you can put a ringed script in the slot and it turns into an inline Command input. That would allow both using a formal parameter to preempt substitution and also the value/index/list feature. I've been wanting both of those things while working on the APL library, actually; mainly the latter.
While we're on the subject, it's just occurred to me that a great use of the hidden relabel feature would be to have multi-list MAP and FOR EACH as relabel options for the regular ones. That would help speed things up!
You're totally entitled to opinions! But my immediate disagreement with Jens is about what question we're discussing, never mind what the answer is. :~)
Yes in principle, but at this time the relabel list for primitives is entirely separate from the relabel list for custom blocks. I think we all agree that that's an undesirable limitation and we should fix it When Things Slow Down™.
But actually given how the design has changed since I first made these higher order procedures in Logo, I'm now leaning toward
Might there be a chance that Snap! would cope with it being a hidden primitive behind relabel and still be in the library?
As long as it didn't get upset/confused when the library is loaded it could be quick win-win?
New syntax for block would be great but can see that it would be a lot of work - maybe just add it to the library and slowly deprecate the old version over a period?
[edit]
Had a bit more of a think about this and realised there's a bit of inconsistency between using item or value - even within the same blocks such as keep and find first
The value/index/list feature is kind of hidden in the HOFs so as not to overwhelm the beginner. And also to encourage people to build their code so as not to need the extra information. I think the same should apply to FOR EACH.
Question for everyone: Does anyone besides me use the feature of substituting values into empty input slots of FOR EACH scripts on purpose?
You mean, not in MAP either? It seems that most people like it in the HOFs but dislike it in FOR EACH. I've never really understood that position, but I seem to be a minority of one, which is why I asked who else uses it.
In my experience teaching text languages pre-Snap!, one of the common stumbling blocks for beginners is the difference between formal parameters and actual arguments. I was forever seeing students build special cases into their procedures instead of using the argument value, or putting the actual argument expression they intended to use when calling the procedure in the prototype, where a formal parameter belongs. It seems so much easier, to me, to say meaning "add three to whatever."
I dunno, every decade or so, someone invents a programming language in which they use "it" as a pseudo-variable meaning "the last result" and I always laugh at them, but maybe this is my version of the same thing. But, as in many other cases, I think the visual language changes what's understandable or not understandable. There's something really intuitive and self-explanatory, I feel, about that empty slot. It jumps out at me. That's why I keep wanting a monadic − block; just seems to be crying out for something to go in that empty slot. (And is even worse; you'd never use a text language that made you say that.)
As a seasoned practioner, I like the fact that I don't have to drag the upvar into the empty slot. Its a great shortcut.
But I repeat my description of it as being auto-magical - it is not at all obvious or makes much sense to a Scratcher.
In Scratch, the empty slot is a default value of 0 or ""
Changing to the concept of it gets auto-filled is a BIG mental step
That's why I'm suggesting the compromise - with very little hope of acceptance as I realise as it is probably far, far too late in the day.
And even if you said - fair enough - lets change - it would involve a LOT of images in the BJC course and manual to change the map type block references
But I'm glad of opportunity to discuss the issue
And I feel changing the for each block is far less of a big job/visual change, especially if done over a period
I personally have never used it, just because I never knew it existed. Like I said before, in the map block, you are not exposed to the upvars at first, so it makes sense to auto-fill. For me, the seemed to just be a primitive version of , so it never occurred to that it would auto-fill like the HOF blocks.
I'm not necessarily against the idea, just never used it, so it I could see how it would be confusing if you wanted an empty slot.
#LOL
You'd think that after all the discussions over the past few days, that it wouldn't have taken me 30 mins to work out why I was getting this error
I'm trying to imitate the BASIC language PRINT command so wanted a null parameter to just do a carriage return
I just couldn't work out why it wasn't detecting the 0 text size and getting that error until I worked out that it was filling it in with the row value! #LOL
[edit]
Has made me re-think how to go about this and I think I'll use multiple inputs instead
Just my two cents - For "Map", I use the empty substitution sometimes, but I think it doesn't make sense for C-shaped inputs.
To me, the ring inputs correspond to a lambda. A C-shaped slot, on the other hand, looks like a control block. For things like the "For" block, I would expect it to work as close to an ordinary C-shaped slot - like the ones on "If" - as possible. No input filling or other extra features. As seen in this thread, a blank input is sometimes desired and it doesn't really make sense to assume someone using a "For" block wants the extra inputs filled into empty slots.
Ideally, even "Report" blocks should not be captured when inside of a C-shaped input, but that would probably mess with the stack and break existing code.