Enduring Principles from the Wyvern Project

What enduring principles can we learn from the Wyvern project? This page is intended to be a place to write down and organize rough ideas that may be later presented in formal papers or informal blog posts.

General design principles

• Name things

  • usability, reuse
  • mostly-nominal type system (not completely implemented)

• Investing in usability in turn increases safety

  • e.g. the safe navigation operator makes it feasible to do null checking at low cost

• Support different levels of assurance

  • some programs may want to be scripty and ignore types
  • some programs may want to prove absence of all errors
  • the architect should choose on a per program (or sometimes per-module) basis
  • this principle is not really implemented well at all right now

• Capability safety

  • Goal: (usable) security, engineering

Language dynamic semantics

• Can run programs that don't typecheck
  • Goal: usability(simple explanation of semantics), testability
  • Not implemented in the current design - main issue is a story for TSLs, but there may be minor issues as well

Language static semantics

• A simple static type system has a lot of value

  • Goal: usability, safety
  • primary value is in automatically-checked documentation

• Option types, with good support e.g. with the safe navigation operator

  • Goal: usable safety
  • important to document presence of null
  • but using explicit Options with flatMap / monad composition everywhere is extremely painful

Language constructs

• Exceptions

  • Goal: separate error handling code from mainline code; document error conditions separately as well
  • (temporary) A supporting mechanism for pre- and post-conditions, see below
  • not implemented yet

• Pre- and post-conditions and assertions

  • Goal: (usable) safety
  • clearer, more automated documentation of error conditions
  • assertions should (optionally?) include a reason
  • not implemented yet

Library design

Note: comparisons below are to the Java or Scala collections library

• Small interfaces with high power-to-weight (similar to Java; smaller than Scala)

  • Goal: usability

• Don't include optional operations (like Scala, unlike Java)

  • Goal: (usable) safety

• Don't include highly inefficient operations (like Java, unlike Scala)

  • Goal: (usable) performance

• Report errors via pre/postconditions, not exceptions

  • Goal: safety (harder to forget checks), usability (easier to understand failures)
  • Don't use Options to hide implementation problems, e.g. index out of bounds.
  • (still need to implement)

• Consistent interfaces with support for multiple (dynamically or statically dispatched) implementations

  • Goal: usability

• Consistent naming scheme

  • Goal: usability
  • (still need to form my own opinions on this)