Beginning specs for a language I'd like to implement at some point

Hoarse

Programming language proposals:

- strongly typed
-- explicit conversion
- all operators can be overloaded
- all types should have properties and be extensible
-- perhaps one primitive type "byte" or "bit" with no properties?
-- a = "string" : A syntax for typing
-- alt: var a = "string" - inferred typing
- functions calls look like "range (x, y)"
-- definitions like "def range : A (x : B, y : C) {}"
--- generic definition: "def <T> range:A (x : B, y : C) {}"
--- void like "def run (x : B, y : C) {}"
- generic declarations like "<T>"
-- generic type extends like "<T : SuperT>"
-- generic type extends + interface like "<T : SuperT & InterfaceA & InterfaceB>"
- ALL methods are type extensions
- standard flow control (if/else, switch/case/default, try/catch)
-- non-standard flow control: need parallel command for blocks ("let"? also, "when" for event triggers? built in event bus?)
--- ability to define new flow controls?
- only immutable objects
- prefer structs/modules
- no globals
- () is ONLY used for explicit tuples (including argument sets)
-- can be overloaded just like any other operator, however
--- speaking of which, is operator overloading something we'll even be able to do?
- function overloading is a must

- sets use set theory: {1,2,3}
-- {1,2,3} - {2} = {1,3}
-- {1,2,3} - {2,4} = {1,3}
-- {1,2,3} + {1,4} = {1,2,3,4}
-- Also need {1,2,3} N {2,3,4} = {2,3}
-- and {1,2,3} U {2,3,4} = {1,2,3,4}
-- and {1,2} x {3,4} = {{1,3},{1,4},{2,3},{2,4}}

- vectors are a type of list, delimited by <> - <1,2,3>
-- <1,2,3> + <2,4> = error, not same length
-- <1,2,3> + <2,4,6> = <3,6,9>

- basic lists (read: queues) look like [1,2,3]
-- mostly act like sets as above, but have the following differences
--- [1,2,3] + [1,4] = [1,2,3,1,4]
--- [1,2,3] - [1,3] = [1,2,3]
--- [1,2,3] - [1] = [2,3]
--- [1,2,3,1,2,3] - [1,2,3,1] = [2,3]

- stacks look like |1,2,3|
-- same as above except:
--- |1,2,3| + |1,4| = |4,1,1,2,3|

- lists are just reverse stacks so no reason to implement them individually, queues are functionally the same and should fulfill standard purposes