Clarify wording up through 'Data types'

[brandjon]

Additional remarks:

• Note that octal int literals are 0oNNN, but octal escapes in string literals (a TODO for the spec) are \NNN.

• For bitwise operators, it's not obvious what the semantics for negative numbers are, although they'd have to be the same as Python's. Should Python's two's-complement operator (~) be included? It seems heavy-weight to include a whole new operator just for one odd use case.

• The built-in function cmp() isn't actually in Python 3 or the Java interpreter. The cmp arg to sorted() isn't in Python 3. Are we sure we want to keep it?

• Regarding trailing commas without parentheses: They're disallowed in tuples because, in the case of a singleton tuple, they make it easy for a single-character typo to cause a big semantic change. That's not a concern for lambda parameter lists, since their meaning is unaffected by an extra comma.

  (lambda x,: print(x)) (5) # 5

  Prohibiting the trailing comma would create a new difference between lambda param lists and named function param lists.

• We shouldn't support the & and | operators on mixed arguments of sets and literals, i.e. {5} | [6, 7]. Python doesn't allow this.

• Let's not specify what the type or boolean truth value of an arbitrary builtin is. Let it be defined by the builtin. We do this in Bazel for depset ("type(depset([])) == 'depset'", and "bool(depset([])) == False" if I'm not mistaken).

[alandonovan]

Thanks Jon, lots of good material in here. Just a quick first pass.

Should Python's two's-complement operator (~) be included? It seems heavy-weight to include a whole new operator just for one odd use case.

Every language provides support for the machine's basic ALU operations, and Skylark should too, even if Bazel doesn't need them.

The built-in function cmp() isn't actually in Python 3 or the Java interpreter. The cmp arg to sorted() isn't in Python 3. Are we sure we want to keep it?

I'd be ok with removing it. cmp is tricky, largely because of NaN.

We shouldn't support the & and | operators on mixed arguments of sets and literals, i.e. {5} | [6, 7]. Python doesn't allow this.

Fine. I think this may have been derived from depset behavior.

Let's not specify what the type or boolean truth value of an arbitrary builtin is. Let it be defined by the builtin.

Are you suggesting the truth-value of a type (e.g. list) be described in the section for lists, not under Booleans or the bool(x) function? Or are you suggesting that bool(list) should not be specified at all?

[brandjon]

Are you suggesting the truth-value of a type (e.g. list) be described in the section for lists, not under Booleans or the bool(x) function? Or are you suggesting that bool(list) should not be specified at all?

Sorry, I was referring specifically to the Built-ins subsection of Data types:

A Built-in is a function or method implemented in Go by the interpreter or the application into which the interpreter is embedded.
The type of a built-in is "builtin". A builtin value used in a Boolean context is always considered true.

Upon closer reading, I see I missed the critical wording "function or method", and had thought this was referring to any type implemented in native code (such as depsets). Maybe we can rename this concept to "builtin function" to avoid confusion, but keep the type() string as "builtin"? I'm not sure I like the type string either but I can't think of a better alternative OTTOMH.

[brandjon]

Every language provides support for the machine's basic ALU operations, and Skylark should too, even if Bazel doesn't need them.

Looking at previous times we've discussed this, there's also ^, << and >>. I presume you still want to include those as well?

[alandonovan]

^, << and >>. I presume you still want to include those as well?

Yes.

[alandonovan]

For cmp and sorted, see #28

[alandonovan]

For set|iterable, see #29.

[alandonovan]

For the type of built-in functions, see #30.