~kvik/wiki.9front.org

wiki.9front.org/language-ideas.md -rw-r--r-- 2.6 KiB
b0f24297Sigrid Solveig Haflínudóttir 9p on unix: change the 9pfs url 5 months ago

#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