Development

Oliver's ideal language

Last modified April 10, 2007 | Revision 20

Ollie has been inspired to try and describe his perfect language again.

Unlike Brehaut, Oliver would like his compiler to actually find errors ;) and therefore prefers static typing.

While dynamic typing might have advantages (i point i find dubious myself, but language niceness is so subjective there’s no point trying to rank them … except perl, perl is clearly of the devil) i think statically typed languages can match them, especially if it supports full type inference.

So things it would need:

  1. Statically typed
  2. Syntactically enforced whitespace
  3. The concept of non-nullable types — if something should not be null, why should it be possible? — in fact this should possibly be the default, a la Haskell’s maybe type
  4. Value types (eg. structs, unboxed primitives)
  5. Functions as a type
  6. Parametric typing
  7. Object orientation with interfaces

Things that would be nice:

  1. Type inference, the more the merrier
  2. Lambda expression
  3. Higher ranked and higher kinded types (related to Need 6.)
  4. Reflection
  5. Garbage collection — no language i write is going to reach even gcc in terms of speed, so i might as well get some niceness
  6. List comprehensions — though it’s difficult to imagine a nice way to allow programmer specified concrete types…
  7. Matching — the real reason functional languages can be so concise cf. imperative languages

Formal(ish) description

Type system

Things to discuss

  • Inheritance semantics
  • Overload resolution
  • Constraint enforcing
  • Model? OO as done by Java/Python, etc, or as provided by Hindley-Milner?

Operator overloading

Am desperate to be able to integrate type class style operator overloading, as it enforces (to an extent) operator consistency. eg. 

class Eq a where
    == :: a -> a -> Bool
    x == y = not (x /= y)
    /= :: a -> a -> Bool
    x /= y = not (x == y)

It would be nice to be able to tidy it up syntactically, and i suppose just defining interfaces for sets of operations should be all that is necessary… sigh

Basic syntax

Braces! This will be yet another c-like language, we’ll call it YACLL in the hope people will find it while looking for parser generators :D

A few rules:

  • w == word character, so a-z, A-Z, _, and equivalent glyphs from other languages (unicode ftw!)
  • d == digits 0-9
Type syntax
  type_list ::= type (‘,’ type)*
  type ::= < identifier > (‘<’ < type_list > ‘>’)? | < function_type >
  function_type ::= ‘function’ (‘<’ Ident (‘,’ Ident)* ‘>’)? ‘(‘  < type_list > ?  ‘)’ ‘:’ < type >

Comments

Given that you have braces, what do you mean by ‘syntactically enforced whitespace’? — mattw

I mean that the grammar will enforce “correct” indentation, think two-fold protection against coding blunders — pythons whitespace rules mean accident indenting changes have an effect on the program logic, whereas brace styled language can just “lie” about what’s going on. However if you have braces there’s nothing stopping you from also requiring whitespace, but incorrect indentation won’t change program logic — it would be syntactically invalid :D Ollie

Last modified April 10, 2007 | Revision 20