HOF aren't case sensitive?

What is the reason for this?
1
(should return aAa)
2
(should return aAa)
3
(should return false)
4
(should return 3)

edit:
strange fact:
4
(not the same philosophy here!)

A lot of Snap! is case insensitive

Index reporter is one of them.

I suggest writing your own or refactor your code and use the library string blocks which can deal with cases

i know how, the question is why...

I believe the philosophy was inherited from Scratch which used it to keep things simple for young programmers

I've found an alternative for pure string:
defaut reporter:
1

alternative:
1

2

(this alternative doesn't work for list...)

To test case sensative strings, use this block
untitled script pic (1)

It tests for exactness, as in, "aaa" ≠ "AaA". It does also have a bit more to it for lists, but I won't get into it here. The help dialog actually has more info.

Thank you very much, problem solved for keep and find first !

I have to rewrite "contains" and "index of" blocks...

Because languages should be case insensitive altogether! The question should be "why on earth is Foo a different variable from foo?"

This issue really pushes my buttons. Scheme identifiers were always case insensitive until there was a hostile takeover of the language by C programmers in R6RS and suddenly they became case sensitive.

In natural language, in almost all contexts upper case is a decoration, e.g., sentences start with capital letters, but the first word represents the same thing that it does in lower case. In English, titles are lower case except when applied to a name, so Senator Feinstein is the senator from California. The title is capitalized next to a name because it's part of the name, the same as "Jr." is part of the name. But the word represents the same office whether or not it's capitalized! There isn't an office of senator and a different office of Senator.

People's names are capitalized by convention, and people argue that in that context capitalization isn't a decoration, but if someone refers to "brian harvey" you'll understand that they mean the same person as "Brian Harvey." And the username "jens" represents the same person as the name "Jens" in text.

It kills me that identifiers are case sensitive in Snap!, so you can have a block foo and a different block Foo. Imho this is the biggest misfeature in Snap!. It's just asking for capitalization bugs. It would be hard to fix at this point because there may be projects out there that use this misfeature, so we'd have to flag new projects to which it doesn't apply. And also, I can't convince Jens about this. But I don't think I'm the only one who uses capitalization as a decoration in discussions in the forum; people say "Why does ITEM do such and such?" or "The bug in your program is that you call your FOO block with a list input when it wants a text string" even though the block is really named "foo."

But we inherit this mistake from Scratch, which made a lemming-like decision to follow the rules of C-family languages. Grrr.

P.S. "HOFs" are the same thing as "higher order functions." There isn't a different thing called "Higher Order Functions."

Back in the day, programming language names were rendered in all caps, so there was a language named "LISP" and another named "FORTRAN." Then one day there was an official decision that from then on language names would have only initial capitals, but "Lisp" and "Fortran" are the same languages they were before that change.

for the record, Jens strongly disagrees with case-insensitivity in Snap! but here we are, and it's not going to change.

public class Foo {
//...
}
//...
Foo foo = new Foo();
System.out.println('A' == 'a'); //false
System.out.println("A".equals("a")); //false
System.out.println("A".charAt(0) == "a".charAt(0)); //false
System.out.println((int) 'A' == (int) 'a'); //false
//primitives boolean, byte, short, long, float, and double vs their wrapper classes
//keywords class and void vs their classes

Yes? What was that supposed to prove? I already explained that C-family languages get it wrong. It's not our goal to be a C-family language!

  • Where is the line for case-sensitivity? [Additional question: how should the C's, Java[Script], etc. work instead?]
  • Class names usually start with an uppercase letter (seeing Foo, I know that's a class).
  • Variable names usually start with a lowercase letter (seeing foo, I now that's a variable).
  • 'A' == 'a' These have different codepoints; should they be equal?
  • "A".equals("a") Should this be true? If so:
  • "A".charAt(0) == "a".charAt(0) Should this be true?
  • (int) 'A' == (int) 'a' If the chars are equal, should this be true?
  • boolean, byte, short, long, float, double: All lower-case, these are primitives and can't be identifers
  • Boolean, Byte, Short, Long, Float, Double: Starting with an uppercase, these are their wrapper classes
  • class, void: These can't be identifiers; Class, Void: These are classes

The answer to all of those questions is that lower case letters and upper case letters should compare equal in every context, period. (There should be an IS IDENTICAL TO (kinda like JS ===?) that lets you make case-depended comparisons.) Simple, uniform rules are easiest to remember and understand.

There is a chicken and egg problem about your examples. C has those naming conventions because it has case-dependent comparison. If it had correct comparison, they'd have used some different convention, e.g.,

  • class(foo), either instance(foo) or just foo
  • separate namespaces for classes and instances
  • spaces in identifiers, and then "class foo" vs. "foo"

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