Implicit conversion to boolean in if and while statements

[Rick Johnson]

On Saturday, February 9, 2013 10:50:25 PM UTC-6, Chris Angelico wrote:
> [...]
> I don't understand. Wouldn't freezing an array (list) result in a
> tuple? And, why should there be no literal syntax for them?
> 
> Having a convenient literal notation for every basic type is extremely
> handy. 

Actually i must admit that you are correct. Of course the problem with literal syntax is symbol congestion. But i have a solution. A solution that can survive the limited number of grouping chars that python employs now. Except, i will define them explicitly

{}: denotes ANY mapping object.
[]: denotes ANY mutable sequence object.
(): denotes ANY immutable sequence object.
<>: Hmm, there must be a good use for this one!

The key to removing complexity is to declare the literal syntax much the way Python "represents" a "set". Observe:

py> set([1,2,3])
set([1,2,3])

Using this syntax we can apply "grouping" chars in proper context when writing literal syntax. The only problem is how do we make this syntax unique enough to avoid confusion and complexity???  Some hypothetical literal syntax, "syntaxes", include:

<set>[1,2,3] # Set literal
<set>(1,2,3) # FrozenSet literal

set=>[1,2,3] # Set literal
set=>(1,2,3) # FrozenSet literal

set::[1,2,3] # Set literal
set::(1,2,3) # FrozenSet literal

set<[1,2,3]> # Set literal
set<(1,2,3)> # FrozenSet literal

<set[1,2,3]> # Set literal
<set(1,2,3)> # FrozenSet literal

set([1,2,3]) # Set literal
set((1,2,3)) # FrozenSet literal


...and to avoid conflicts with the "set" function, we just remove the set function! Only the types list, dict, and tuple(bka:StaticList!) should have a built-in constructor function, the remaining should have a typical OOP style constructor:

mySet = Set([1,2,3])
mySetLiteral = set([1,2,3])