Suggestions for the assoc block

Well, Snap! doesn't normally use things like ":" in blocks - it uses explicit language so I'd vote no for using it for this block

image

Exhibit1
image
This means nothing at first glance and once the assoc block has been renamed - it would be my primary candidate for next renaming :slight_smile:

[edit due to limits of sequential posting]

I like this syntax

image

so I'm now proposing one of these

image

Are you trying to instantiate the saying "more Popish that the Pope himself"? :stuck_out_tongue_winking_eye: because if Brian himself proposed it, the argument against it can not be that the word 'dictionary' is not yet part of current terminology in Snap!, I guess.

Yeah, those are better in my opinion, but to me the Brian's one with dictionary is still better.

key: _ value: _ is a constructor, not a selector. It would be better named pair with key: _ value: _. But in any case, I don't think there is any official Snap! terminology, except I guess in the help text for ASSOC. It's true that I think in terms of association lists rather than dictionaries, but we've long since decided that we should give things human-readable names instead of, e.g., CONS, CAR, and CDR. The only reason MAP is still called MAP is that I never found a short alternative that didn't suggest that the block mutates the input list. (Of course new list with _ called for each item of _ would do, but is absurdly long for such a centrally important function.)

I'd be happy with either key-value pair with key _ in _, @cymplecy's idea with different prepositions, or my find _ in dictionary _. Two arguments in favor of the former: It really clarifies both the domain and range of the function, and it avoids possible confusion with a Javascript data type.

Well - I'm no linguist - but I don't think those are the right prepositions to use (and like I said before - there is an exising block that returns the value only of of a key-value pair so I think use the same syntax - but of course - its not my game :slight_smile:

image

It does; but it does so at a high price paid in terms of human readibility (I should add "lay human" readibility, I guess).

Because of that price, although the quality of Simon's solution is - I agree - higher for cs-knowledgable (non-lay) users, I would happily settle for less pricey solution. My 2 cents.

Oh I see, it's in the Web Services library, which I've never used. Sigh, okay, let me rethink all this.

I don't think many users, even less so beginners, would see Web Services library as setting a precedence (in a lawyer's jargon, I think they talk about precedence and such).

I think you're thinking of "precedent," which means "a similar situation that came up before," not to be confused with "precedence," which means stuff like multiplication before addition. :~)

Yeah, not being a native English speaker doesn't help.

I personally like absurdly long names. It makes programs more readable (and largely self-documenting and self-explanatory). Given the way Snap! works the length doesn't necessarily make it slower to construct or edit programs. It is true that it consumes more screen real estate but is that so bad? I seem to remember Alan Kay saying many decades ago that functions/procedures should be "mind size". Perhaps many shorter functions/commands is a better style than fewer longer ones.

Oh, I was convinced that it is only me having this (acquired?) taste.

Yes, well, I agree, but every so often Jens has an attack of short-name-itis. His goal is that blocks should fit in the palette without the need to scroll sideways. Then we have to redo all the pictures in BJC. In the libraries, though, long names seem to be okay.

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