Development driven by constraints

Language specification

  1. Positional arguments should not be callable as named arguments. This would make an argument's name a part of the public interface. Changing the name afterwards would thus be a breaking change.
  2. The order of named arguments should not matter.
  3. Named arguments and dictionaries should be unified.
  4. Automatic partial application or automatic currying should not exist, as this would disguise argument count errors.
  5. It should be ergonomic to use tables and dictionaries together with string formatting or string interpolation.
  6. Private global variables should be possible.
  7. Private class and object fields should be possible.
  8. The syntax of nested expressions should mix different kinds of brackets in order to increase readability. Moss does this quite well with a mixture of parentheses, square brackets, braces and keywords.
  9. There should be no index operation for iterators. This would confuse iterators with arrays and thus lead to subtile bugs.
  10. The syntax f[a] for functions means, iterators need to check the number of given arguments, as iterators coincide with functions with no arguments.
  11. The function len should not be defined for iterators. This would confuse iterators with arrays and thus lead to subtile bugs.

Object system

  1. Destructors should be possible.
  2. The function type(x) should return null in case x has no type. Otherwise it cannot be used for type guards in general. For the same reason, x: T should return false for every object T if x does not implement the operation.

Implementation

  1. A new object on the call stack should have refcount==1. For example, if A() computes a large matrix, then A().map(f) and A()+B etc. do not need a memory allocation, because the buffer can be reused. Rust offers get_mut(this: &mut Rc<T>), make_mut(this: &mut Rc<T>) and try_unwrap(this: Rc<T>). Thus, as a further implication, ownership of Object is needed, because &Object does not allow access as &mut Rc. However, matrix types have an inner Rc of the buffer, therefore it suffices to check strong_count, which needs only &Rc.

Pixel graphics

  1. It should be allowed to draw to more than one buffer.
  2. It should be allowed to draw relative to a position.
  3. There should be at least one good monospace bitmap font in all sizes from one size to doubled size, containing the standard sizes for 60 ppi up to 160 ppi. For minimalism it should be stored as a matrix in a raw buffer, i.e. in the PGM format. Each font file should contain at least the first 256 Unicode code points. A font file containing just the first 256 code points should be arranged as 32*8. — Currently an adaption of Vera/DejaVu Sans Mono is used.
  4. The font loader should also be able to load GNU Unifont.

Vector graphics

  1. It should be allowed to draw to more than one buffer. Some alpha blending and anti-aliasing techniques need intermediate buffers.
  2. It should be allowed to draw relative to a position and scale.
  3. Buffers with floating point color depth and alpha depth should be available.
  4. Colors and alpha values should be given as floating point numbers.
  5. There should be convenience functions to convert between color spaces.