𝔉𝔦𝔩𝔴𝔦𝔱 PhilipWitte

val everyone: list[Person] = new(size:50, step:25, max:250)

enum Emotion {
  Relaxed, Happy, Angry, Distress
}

type Vector[T:int|num] byRef: tuple {
  var
 x, y, z: T

Nimrod - Unified Command Syntax

RULES

<command> <ident> <pragma> <type> : <body>

<command> <ident>
  <pragma> <type> :
    <body>

After a recent reddit post and the resulting IRC discussion it caused on Nimrod's syntax, I came up with a couple of changes to the syntax which have a realistic migration path (in theory), and allow for Nimrod to expand to a syntax which could end most of the complaints we here from the C/Java/etc camp, without stepping on the toes of those already happy with the existing syntax.

Instead of a lengthy explanation, i'm sure the code can somewhat speak for itself..

# First, we change set's to @{} instead of {} which..
# ..is consistent with seq and allows us to repurpose {}
var mySet = @{ A, B, C }
var mySeq = @[ a, b, c ]

import StrUtils, Times


type Vector = tuple[x, y, z, w:float]

# factories
proc new(x, y, z, w:float): Vector {.noSideEffect, noInit, inline.} =
  result.x = x
 result.y = y

Nimrod Engine Ideas & Goals

Key

using - template which essentially "from EXPR import nil" + some selection
part - macro which defines a part of the app/game (corresponds, by name, to editor data)
mode - built-in part state system component (multi-state. easy transition declaration)
on - app/game event logic (can be user-defined in editor)

Changes I would love to see in Nimrod.

"Good Syntax" is often heavily subjective. So it makes sense to allow people to program in the styles they like best. I would argue that there is also value in the ability to lock-up and restrict syntax features (for things like compile-to-OpenCL, or game scripts), but that's beyond the scope of this document.

Many programmers prefer empirical style to functional. In the order to attract these people to Nimrod, and to give all developers freedom of expression, I have a few ideas on how to change and extend Nimrod to support a more empirical coding style, in addition to it's already great functional style.

type

First, a gripe. I don't like the inconsistency of type syntax. No other object is defined this way in the syntax. The following:

	var
	vertArrayObject: GLuint
	vertBufferObject: GLuint

	proc init =
	var verts = [
	0f32, 0f32, 0f32,
	4f32, 0f32, 0f32,
	0f32, 4f32, 0f32,

	import StrUtils

	# ---

	type Vec4* {.incompleteStruct, importc:"__m128", header:"<xmmintrin.h>".} = object
	type Vec4Array = array[0 .. 3, float32]

	# ---

	proc setVec4 (w, z, y, x:float32): Vec4 {.importc:"_mm_set_ps".}

	# Change set's to @{} instead of {}
	# which is consistent with seq
	var mySet = @{ A, B, C }
	var mySeq = @[ a, b, c ]

	# Force ':' where ever a "body" is consumed which
	# allows both indent style and bracket-style

	# the follow types are all identical..
	type Foo* {.final.} = ref object:


	import StrUtils, Times


	type Vector = tuple[x, y, z, w:float]

	proc new(T:typedesc[Vector], x, y, z, w:float): Vector {.noSideEffect, noInit, inline.} =
	result.x = x
	result.y = y
	result.z = z