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