Closed ToonTalk closed 6 years ago
jmoenig
commented
7 years ago I would love to get of the red one and make the green one universal for everything, but Brian disagrees because he loves to have everything about lists together. So we keep both :-)
cycomachead
commented
6 years ago I don't want to be involved in this debate because I feel like it's been litigated too many times...
But I am curious:
Also having the same name for incompatible reporters means that it interferes with the story that if blocks become transparent (leaving only their text behind) that one has a textual program since two different programs yield the same textual program.
Is this really a fair story? I guess Snap! mostly enforces this for custom blocks -- but depending on your textual representation, variables and functions could technically share the same namespace (as they would in Ruby) and you'd lead to problems.
jguille2
commented
6 years ago For me this issue is clear and it can be closed: I like only one universal length but current situation is also fine.
The other comments about duplicate names is another thing. I think this is not critical and it should be treated carefully and calmly... and it is not only affecting to a textual representation.
For example:
var is indistinguishable!
brianharvey
commented
6 years ago I agree that the asymmetry is weird, and it would be okay with me if the two blocks both worked for everything. It wouldn't even kill me, if people are worried about having two blocks with the same name, to make the one in the list palette green!
The help is not so very wrong, because numbers are words. (You're a Logo guy, you know that!) Lists were added to the domain of the green one because of an uprising by teachers a while back. But having two blocks is something we inherited from Scratch.
jguille2
commented
6 years ago Leaving aside the duplicate names issue, and returning to the length block, I think we have different options... but maybe we can think globally about our typed slots. Some notes:
In Scratch there are two blocks, but they act differently. Operators length block has a text input. Then, if I put a list into this slot, this list is converted to string (concatenating list items). The result is different for each case.
Scratch does the same in other cases (letter of, join...) but yes, it is its only option, because it can not do many things with lists (it reports a string when we call a list variable).
We can do many things in Snap! But maybe we need a constant and general criteria. Now we have:
Then, the background discussion is if we want typed slots or not. If we want string slots, then list entries will report an error or we will convert these entries to strings.
So for me, it is clear.
merlin2v
commented
6 years ago One thing I have been annoyed with, is how you cant have two blocks with the same name even if one is a reporter and one is a block 
and 
brianharvey
commented
6 years ago Hoo boy, many different issues at once here...
First of all, Joan, thank you for your (as usual) very detailed analysis!
About the implicit conversion of lists to strings, I've never really been happy about that, not because I don't like it in principle, but because I think if we're going to do it, we should invent a good print form for lists. In BJC we use
{item, item, item...}
This is an issue not only for lists:
I don't know how to handle that case, but surely we can do better than this! Even if we just punted and used #procedure as the print form for all procedures, it'd be better than the current behavior. (And, btw, doing lists right would also require an escape mechanism for commas in items.)
At one time we were tossing around the idea of supporting printforms for abstract data types, so for example you could have a Fraction adt whose printform would be
When Things Slow Down™, we should revive this discussion.
About LENGTH OF, I can't for the life of me understand why everyone thinks it's the green one that should be privileged. Almost all the time, I think of text inputs as symbols, rather than as text strings, so it's very unusual that I want to know their length, whereas to me it seems useful and natural to want to know the length of a list. I think the best solution would be to have two different-colored blocks with the same semantics, working for text and lists. But as long as I can find the block in with the list blocks, I don't want to fight about it.
About the more general question of naming, I think that example with a variable and a Variable-color block with the same name is self-evidently a misfeature. I would be happy with a single namespace, which would be more Schemely, and therefore is Obviously Right™. I'm aware that there's an issue about invalidating old projects. I propose that we gather together all the non-backward-compatible changes we've ever considered, do them all at once, calling it Snap! 5.0, increase the xml-file version number, and maintain the ability to read old projects by the old rules. (This would also be the time, Joan, for HSL colors and 0-255 RGB.)
Orthogonal to the namespace question, I also think it should be possible (with a confirmation dialog) to shadow primitives globally in a project. (Technically, instead of one global frame, you have a primitive frame in which "raw" Snap! things are defined, and a global frame that's initially empty, in which users can define stuff. And the global environment includes both frames.) I'm thinking of the "fuzzy Logo" lessons we used to teach, in which we'd make an initial environment with
(although the notation wasn't this nice in Logo). The goal is to get kids to draw a square, by using feedback from X POSITION etc. There might be fuzzy turning, too.
There should be a better place to have discussions like this. Let's get the forum going...
jguille2
commented
6 years ago Yes @brianharvey, too many different issues... We can write down the subjects of 'naming and a single namespace' and 'printforms for every data' for later (When Things Slow Down™ :sleeping:)
But trying to close this issue, I try to show explicitly the subject of the "two different length reporters".
Current behavior. I think it is no bad... so one option is to close directly this issue. We have:
An alternative. We can use the 'green operator blocks' playing only with text inputs. Then we can convert list inputs to a plain text (yes, I know there are other types... but without a general printform for every object, we can use these blocks with strings, numbers and lists). Note that 'length of' blocks acts different here. We'd have:
Other alternative. Both with current behavior and with the alternative, we have two blocks with the same name. I think this is clear into the palette:
But in a text representation, or when they are used... then it's not that clear
or
So, we can consider to change one of these blocks. I don't know what's better... We can play with "length" and "size", or with the explicit "list length" or "string length"...
Anyway... you can choose a modification or close this issue. Thanks!
brianharvey
commented
6 years ago Okay, I hereby declare that we have too many fires to put out to worry about this one right now.
cycomachead
commented
6 years ago That doesn’t mean we should close this!
Putting off a fix until later means the issue should be open.
FWIW, I think a green block in the lists palette isn’t too bad.
OTOH, we could solve the issue in other ways: the reason we want a length block with lists is for convenience, and relevance. It’s a problem if students feel like Snap! is slow to write code with or that they can’t find relevant blocks to use. I think it’s also clear that this is a problem faced in many different situations. So, the solution becomes some way of displaying contextually relevant blocks—regardless of the category or type.
-- Michael Ball From my iPhone michaelball.co
On Nov 27, 2017, at 10:21 AM, Brian Harvey notifications@github.com wrote:
Okay, I hereby declare that we have too many fires to put out to worry about this one right now.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
The green 'length of' works fine for words, lists, numbers (and more?). However, its 'help' says it only works for words. The red 'length of' only works for lists (as its help says) and signals an error otherwise.
Is this a sensible design? Why not just have one such reporter that works for all sensible data types? Also having the same name for incompatible reporters means that it interferes with the story that if blocks become transparent (leaving only their text behind) that one has a textual program since two different programs yield the same textual program.