I've been trying to decide on a syntax for map type definitions.

Currently, in python vyper, it looks like this: map(address, bytes[100]). This is another one of those cases where I think the syntax was designed somewhat to accommodate the python parser. I don't much like map(...) because it's not visually distinguished from regular call syntax i.e. fn(..).

An alternative to this could be to use the syntax that python has adopted in the standard typing module. This looks like GenericType[TypeParameter] and so map type definitions would then look like map[address, bytes[100]].

However, I still don't like this because, again, it's not visually distinguished from other common syntactic elements like array indexing or dimensions (bytes[100] as in the example above or some_list[i] to access the ith element).

This is all a question of how to design a syntax for specifying type parameters to some generic type. Both Rust and C++ have a syntax for this that is somewhat distinct from other syntax: GenericType<TypeParameter, ...>. If we used that, map type definitions could look like this: map<address, bytes[100]>. I sort of like this because it's clearly different from other syntax in python and it should already be familiar to people who have used languages like C++ or Rust.

I think such a syntax might also be useful for specifying other meta parameters for a type. This is maybe sort of a wacky idea, but perhaps adopting this syntax could open the door to things like the following:

type uint256 = int<bits=256, min=0, max=2 ** 256 - 1>
type int128 = int<bits=128, min=-(2 ** 127), max=(2 ** 127) - 1>
# up, down, left, right.  min and max could default to 0 and 2 ** bits - 1 respectively
type direction = int<bits=2>
type indexable_str = string<max_len=255>

I remember there was a discussion at one point concerning the way to specify the maximum length of dynamic-length byte arrays in vyper. Maybe something like this could be useful for that:

# Currently, in python vyper, this means a dynamic length array with max length
# of two.  However, this is a bit confusing since the same syntax has a
# different meaning in solidity and in many other languages.  So then let's
# just say that this defines a constant-length array...
bytes1[2]

# ...and then we'd instead specify dynamic-length arrays in this way
bytes1[]<max_len=2>

# ...or using a shorthands like these...
bytes1[]<2>
bytes1[<=2]

# ...which, internally, are re-written to...
bytes1[]<max_len=2>

I'll admit that the examples above are maybe a bit awkward or clunky. But the point is that an extensible syntax like an angle bracket parameter list (extensible in the sense that the list can have one or more items) might be useful in specifying meta info about types. And there already appears to be a need for this.