The Spirit Of Nutmeg - Spicery/Nutmeg GitHub Wiki

In addition to the Design Goals, we have a much looser set of ideals about what kind of experience we want Nutmeg to deliver. We haven't formalised this in any way, so this is just my first attempt at capturing this.

Firstly, we want programmers who are using Nutmeg to have a relaxing and enjoyable experience. We want them to get started without having to build a personal library of bits and pieces of low-level code. We want mistakes to always be detected and clearly reported. We don't impose complicated rules on how source code is written and organised. At the same time, we also want to support programmers who are trying to scale up their applications & are looking for those rules.

Concrete examples of what this means to us are:

• We emphasise easy-to-indent outfix syntax (e.g. if .... endif)

  • We shun significant whitespace - with the exception of long-strings where we can't sensibly avoid it. No tabs vs spaces wars for us.
  • We use outfix syntax to avoid hacks like curly braces to group statements. No 1TB style wars here.
  • Experience with outfix syntax (in Poplog) has shown that this leads to a high level of uniformity and quality without imposing any discipline.

• The built-in data types are powerful and flexible.

  • You can do a lot with them without having to write any custom classes.
  • They come in immutable and mutable flavours, support sealing and snapshotting, so flipping from imperative to functional styles is easy.
  • But they don't do implicit type coercion (i.e. runtime overloading) because we want accidents to be detected.

• The Nutmeg toolchain never enforces any discipline on programmers but supports them via policies. e.g. particular naming conventions.

  • Policy enforcement (warnings, errors) are a matter of team/organisational choice.
  • Local policy violations can be detected in imported libraries, because policy compliance is part of libraries's meta-info.

• The Nutmeg toolchain always allows you to run a program, unless a team policy prevents it

  • In particular syntax errors only stop the unit (file) they occur in from loading.
  • And type errors do not prevent methods from being compiled (obviously they may generate a type exception at runtime)

• The order of definitions in units is never important.

• We provide a robust run-time engine

  • All run-time type errors are detected and errors are clearly raised.
  • Garbage collection is a must-have, as we don't want programmers to be fussing over store management.