From: swatkins@fastmail.fm
To: Claudine Chionh <claudine@chionh.org>
Cc: 
Bcc: 
Subject: Re: nipl
Reply-To: 
In-Reply-To: <41A1C3B8.1020106@chionh.org>

On Mon, Nov 22, 2004 at 09:47:20PM +1100, Claudine Chionh wrote:
> Are you designing a new language? How will it work?

I think "designing" is too strong a word, it's more sort of evolving.
(perhaps wandering around in the dark!)

I'm not sure if you know about C - if not, the following won't make much sense!
Anyway, it's good for me to write down what I'm trying to do, and get my ideas
organized a bit.


It started off as "C / C++ with a nicer syntax"; when I was playing around with
plan 9 a few years ago I wanted to write a little program like the "emulate
three buttons" function in XFree86, which is trivial to do in Plan 9, but I was
feeling adverse to all the braces and semicolons in C, so I wrote a filter
called "brace" to let me write C code but with a syntax like python, where
indenting is used for blocks instead of braces.

I added a few more features later, such as automatically generating headers
from source, and shuffling the functions and declarations in the source so that
you can write things in any order, rather than bottom-up, and don't have to
worry about writing prototypes.  If you've ever tried writing something
sizeable in C it's a real pain doing this stuff manually.

I'm writing a library to go with it, the idea is to make it possible for
children to write interesting programs with graphics and sound / music in this
language, like I used to with BBC Basic in the "good old days" :)

I've implemented a basic "hooks" system, where you can override library calls
and write LD_PRELOAD-able hacks with a nice syntax, I want to do this for an
automatic version-control / syncing system I'm working on - a bit like CVS and
arch but you don't need to explicitly tell it to add or checkin or update or
rename or anything, it all happens automatically.


here's a little example, which draws a tree:

	<b/m.h>
	<b/gr.h>
	<b/error.h>

	int main()
		gr_init(400, 300)
		tree(0, -140, 0, 70, 10)
		event_loop()
		return 0

	tree(real x, real y, real a, real r, int depth)
		if depth == 0
			# draw a leaf
			coln("green") ; circle_fill(x, y, r/2)
		else
			# draw a branch and two smaller trees
			real x1 = x + r*Sin(a)
			real y1 = y + r*Cos(a)
			coln("brown") ; line(x, y, x1, y1)
			tree(x1, y1, a-30, r*3/4, depth-1)
			tree(x1, y1, a+25, r*3/4, depth-1)


Not very exciting; it's still basically just C, especially in this simple
example.  The image produced is attached!



Next few things I want to implement are:

- coroutines (ultra-lightweight threads).  In my opinion this is the single
  most vital thing which is missing from nearly every modern progamming
  language.  I think I'll probably use GNU Pth for this initially, although
  it's slow.

- hooks - I'm going to make so you can add hooks to any function without
  needing to use any special syntax, it's possible to do this in C without a
  performance penalty.

- a "buffer" abstraction (variable-length mutable string), to protect people
  from the common "buffer overrun" bugs, and to save me from having to
  reimplement this all the time!  and various other utilities

- exceptions and some resource management, the thing will help free memory for
  you, close files, etc; but I'm not going to use garbage-collection.

- a better syntax for pointers / references, perhaps like pliant's
  - no need to write *a all the time instead of a
  - no need to write a->foo all the time instead of a.foo

- namespaces
  - i.e. it lets you write:
      use my_favourite_graphics_library
      move(100, 100) ; draw(200, 200)
    instead of
      #include <my_favourite_graphics_library.h>
      my_favourite_graphics_library_move(100, 100)
      my_favourite_graphics_library_draw(200, 200)

- automatic library handling, i.e. it includes the appropriate headers and
  links to the appropriate libraries for you, based on what namespaces and
  functions you use

- sane object-orientation
  - automatic default inline accessor methods for every struct / class
  - syntax for accessing elements is the normal C struct syntax,
    but goes via the accessor methods; this doens't degrade performance
  - ...

- automatic type declarations (type inference)

- a better syntax for var_args, e.g. when writing new printf-like functions

- calling functions without parentheses and commas like pliant does - maybe

- sound and music support for the library

- perl compatible regular expressions
- more syntax for quoting, e.g. quoting multiple line strings