Set VAR to blank in custom code fails

Sorry dardoro, I did not quite understand what you meant.

Do you mean to make that block and then use it to set the scanData to it ?

Also, for the other answers:
I had written that tell block also worked.

However, I now understand why the problem was caused by the "for each item" usage. I will be careful of that in the future.

Thanks.

Yes
ScanErr script pic (1)

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 untitled script pic (12), 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 untitled script pic (12) list block is the same as having untitled script pic (13) behave the same as untitled script pic (14), 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. :~)

Can I further piggy back and request adding the library

untitled script pic (4)

as relabel option on

image

I've lost count of the number of times I've had to load the list Library just to get at that one block

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
untitled script pic


to work like the corresponding feature in MAP and friends (even though we'd have to redo a ton of pictures in BJC).

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?

image

[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

image

maybe something like this

image

could square the circle?

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?

Could you give an example of what you mean?


I basically never use that ITEM upvar. Who needs it?

In the for each block, the item is exposed and explicit - I like explicit :slight_smile:

In map it isn't

Maybe a compromise is to expose the value in both forms but keep the index and list vars hidden

image

FTAOD I've never been a fan of empty slots getting auto-magically filled - shoot me now! :slight_smile:

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 untitled script pic 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; untitled script pic just seems to be crying out for something to go in that empty slot. (And untitled script pic 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. :slight_smile:

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 :frowning:

But I'm glad of opportunity to discuss the issue :slight_smile:

And I feel changing the for each block is far less of a big job/visual change, especially if done over a period

I seriously doubt...
bug_ implicit slot filling script pic
bug_ implicit slot filling script pic (1)
It quickly becomes counterintuitive and fails badly.

There was already a thread about this Strange implicit slot filling

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 untitled script pic (15) seemed to just be a primitive version of untitled script pic (16), 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
image

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.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.