ref: da93fd1812c354060a735336534ad244bd010d41
dir: /language-ideas.md/
# Language Ideas
This is meant to be more of a brainstorming thing than a specification.
## General Spirit
* minimum-noise
* trying to find a middle ground between imperative and FP that isn't just mashing the two together blindly
* readable (but not in some silly "looks like English" kind of way)
* writable WITHOUT an IDE / fancy editor.
* simple, as long as it doesn't compromise anything else. NOT C++.
* don't want to worry about abuse potential, trust developer to be sensible
* ultimately translates to C / machine code. but earlier implementation might be byte code
## Syntax
* good syntax is important, but don't fall for syntactic sugar or trying to make things too cute (fucking scala...)
* braces and semicolons
* generally a "flat" style is easier to maintain and debug imho, even if it's technically longer (where do you even add debug-prints in a giant stack of higher level functionals? unix pipelines are slightly easier here but not much)
* C-style type notation are too hard to parse and too hard to generalise for things like tuples, it's probably not worth it.
* postfix notation is surprisingly useful (think unix pipes)
## Type System
* some weird merger of Go and ML?
* want structs, union types, tuples
* haskell typeclasses / go interface
* parametric polymorphism
## OOP
* Basically, no.
* However, methods solve some tricky namespace problems. Maybe worth it?
## Modules
* Basically, Go.
## "Data-driven thinking" / Traits
In C you often end up with giant structs which looks like
struct MegaStruct {
a bunch of properties used by all
...
a bunch of properties only used by code A
...
a bunch of properties only used by code B
...
a bunch of properties only used by code C
This is bad for modularity, but there isn't a nice way (in C) to avoid it.
What you really want is a way to specify these things separately, together with the code that manipulates them; in fact keeping them separately in memory might be a good idea too (improves cache locality).
One approach is to define a bunch of "traits" like
trait MegaStructPartA {
only those properties used by A
}
An object is then only an accumulation of certain traits.
## Testing
* Being able to specify test-cases in-line seems like a good idea.
* Also properties for quickcheck-like testing
## Crazy Ideas
* laziness-on-demand: values can be lazy, so that you can do things like
a = async request_a();
b = async request_b();
c = a + b;
which issues both calls simultaneously.
* labels-as-closures: a goto-style label can be used in an expression to create a closure for the rest of the function