I miss this possibility and I guess there is a way to do it ? This way a custom block can change the value of a variables.
Like this?
The input variable is typed as “Any (unevaluated)”, hence the ƛ (lambda):
or:
This suggestion might be easier for the OP to understand if you use a Reporter-type input to INC instead of Any (unevaluated), to make the call not so magical. Just a suggestion.
In my post (#2) I've íncluded a second implementation of INC now, using SET and CALL instead of CHANGE. Is that what you meant to suggest?
I also tried a more literal interpretation of your suggestion: changing the input type to "Reporter", but couldn't get it to work as intended. Perhaps I misunderstood. If this second (literal) interpretation is (more or less) what you actually meant to suggest: what would be your envisaged implementation of INC with a reporter as input, and how should it be called?
This way?
But the ring of the Reporter slot is removed when the variable is dropped and must be manually recreated. So it does not differ from an explicitly ringified param of "Any type".
Maybe the unevaluated slot should be unconditionally decorated with a ring or just a gray "halo".
Oh, right, I forgot about that. Never mind.
You're right - it does work this way, but calling the block is rather complicated (both conceptually and practically), so in all it's definitely not an improvement over the use of "Any (unevaluated)".
BTW I like your proposal to visually mark unevaluated inputs (they're not only among the more powerful of Snap!'s features, but also among the most complicated to use).
That defeats the object of the exercise! If you want it visually marked, make it Reporter type.
Ideally (from a user’s point of view), the data type of each input slot within a block is to be recognizable at first glance. Actually in Snap! this feature has already been implemented to a large extent, though indeed not fully.
Nope. I disagree. Ideally (from a user's point of view) the thing I try to do should Just Work™ without me having to know anything about how it works.
So, in the paradigmatic example, reporter IF just works, because the then and else parts aren't evaluated in advance; only one of them is evaluated, depending on the value of the first input.
From a computer science teacher's point of view, what's ideal is that it's possible to expose how things work, but not necessary, especially not necessary as a precondition to using whatever it is.
If there's a Big Idea lurking inside the thing I'm trying to do, by all means we should expose the Big Idea. But, do you think the fact that there's a type called "Any (Unevaluated)" is a Big Idea? No, the Big Idea is that users can change the syntax of a language, making it their own language. In the case of unevaluated inputs, we are introducing normal order evaluation (in specific contexts) to what would otherwise be a purely applicative order language. But you can use unevaluated inputs in even stranger ways, e.g., use a text input field as a keyword, so you can turn Snap! into a text language!
That's changing the syntax of the language big time, and special forms (what the grownups call unevaluated inputs, more or less) were always understood as dipping our toes into metaprogramming, years ago.
I’m not sure if I agree, overall.
I do agree that from a teaching point of view one should be able to introduce a concept in the simplest possible way such that it can be used, and then gradually reveal more details.
However if you want users (students) to truly grasp the concept of first-class procedures - would that qualify as a “Big Idea”? - wouldn’t you need to explain the difference between a (pre-evaluated) value and an (as yet) unevaluated variable?
If a user is going to define a block involving an unevaluated data type for an input, they are on advanced terrain anyway. Wouldn’t it be easier for them to be able to reuse that block without having to dive into its data definitions in order to verify input data types? Because they can see it at first glance, by the shape of the input slot. Like with 
vs. 
, and 
vs. 
.
Or is this all about being able to introduce 
without having to explain about the order of evaluation at first?
What could be wrong with a subtle shape or background colour difference to indicate an argument is supposed to be of unevaluated type? A difference that would probably be ignored by novices but appreciated by advanced students (“selective perception”).
the idea behind unevaluated slots is abstraction. An unevaluated slot in Snap! abstracts the concept of rings away, which is precisely why we've invented it. Keep in mind that this only comes up because Snap! auto-lambdafies code inside C-shaped slots, a concept unknown to text-based syntax. The idea is not to support "advanced" concepts or to teach "advanced" stuff ("passing a variable as reference" - gee, I mean, c'mon, that's just putzing around with C quirkiness^^), but to make a UI that doesn't require students to learn about procedure-as-data (rings) before using certain blocks in introductory activities, specifically the reporter version of IF/THEN/ELSE.
I rest my case.
I think you're trying to have it both ways here. People should notice the marking exactly when you want them to, and not otherwise. I don't think there's any such thing as a "subtle" syntax.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.