Complete free-style syntax?

[TropicSapling]

operator +;
operator /;
operator =;
operator &;

// Never called
macro (a)++ {
    ...
}

// Never called
func (a) & (b) {
    ...
}

func (a) ++/ (b) -> ... {
    ...
}

func (a)==(b) -> ... {
    ...
}

func if (a) then (b) else (c) {
    ...
}

// Never called
func do (a) {
    ...
}

// Never called
func something -> ... {

}

func do something {
    ...
}

func do something else using (a) & (b) {
    ...
}

let x = ...;
let y = ...;
let var = ...;
let multiword var = ...;

if x++/y==123 then /* this does `(x ++/ y) == 123` */
    do something /* this does `do something` */
else
    do something else using var & multiword var; // this does `do something else using (var) & (multiword var)`

[TropicSapling]

I'll make a list of possible features here and fill in which ones I think P+ should have:

• Defining of operators
• Mixfix
• Mixing between operators and names in a function name as long as they are separated by args (i.e. let (var) = (val) would be allowed, but not doThat&ThatWith (something))
• Full mixing of operators and names in a function name (even doThat&ThatWith (something) would be allowed)
• Allow spaces (and any other whitespace?) in variable names
• Allow spaces (and any other whitespace?) in function names
• Custom precedence
• Allow variables and functions to start with numbers

Pros and cons with each feature

• Defining of operators:
  + Allows user-defined operators in libraries, you can define any character as an operator
  - Requires a new operator keyword or similar which makes the language bigger, therefore raising the learning curve
  - May cause confusion if a seemingly normal character (i.e. c) is defined as an operator

• Mixfix:
  + Allows for cool stuff like if ... then ... else ... and (arr)[(index)]
  + Makes it possible to define many more previously built-in language features
  + Makes some code easier to read
  - May cause confusion in certain cases if misused
  - Will probably make the compiler slower
  - Would it even be possible to parse?

• Mixing between operators and names in a function name as long as they are separated by args:
  + Makes it possible to define even more built-in language features like let (var) = (val)
  + Makes some code easier to read
  - May cause confusion, more than with normal mixfix
  - Will probably make the compiler slower
  - Would it even be possible to parse?

• Full mixing of operators and names in a function name:
  + Allows for almost any function name
  - Feels pretty useless?
  - Would it even be possible to parse?

• Allow spaces (and any other whitespace?) in variable names:
  + Allows for more possible function names
  - May cause confusion
  - Would it even be possible to parse?

• Allow spaces (and any other whitespace?) in function names:
  + Allows for more possible variable names
  - May cause confusion, might make it harder to distinguish variables and functions
  - Would it even be possible to parse?

• Custom precedence:
  + You can specify precedence for your functions
  - May cause confusion if precedence is unnatural
  - Is it even necessary in the first place? Implicit precedence might just work fine
  - Requires you to specify precedence instead of it being implicit, but perhaps make it optional?
  - Makes the language bigger, therefore raising the learning curve

• Allow variables and functions to start with numbers:
  + More possible variable names
  - You could name a variable something like 0x123 and that could make it get confused with hexadecimal numbers

[TropicSapling]

Defining of custom operators done in #230

[TropicSapling]

Everything else checked now also done :D