- The easier to learn, the better.
- Best if easy to mentally parse "at a glance".
- Easy to understand structure "at a glance".
- Easy to type.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
type Foo | |
{ | |
var bar = 0 | |
} | |
func main() | |
{ | |
ref f : Foo | |
ref b : int | |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
func main() | |
{ | |
var nums = text[] # a dynamic array | |
ref n : text # a 'int' reference | |
nums += "foo" # add "foo" | |
nums += "bar" # add "bar" | |
nums += "baz" # add "baz" | |
n => nums[1] # 'n' refers to 'num[1]' |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
type Foo = | |
value : int | |
init Foo.new(v) = | |
value = v | |
proc Foo.bar = | |
echo(value) | |
proc main = |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
type Person | |
{ | |
var name : text | |
var age : uint | |
init new(.name, .age=) | |
init load(path) { # load from path # } | |
func greet() | |
{ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# syntax: | |
# [key] <name> [attributes] [types] | |
type Sprite | |
{ | |
var pos Vector | |
var rot Rotation | |
} | |
type Ship Sprite |
"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.
First, a gripe. I don't like the inconsistency of type
syntax. No other object is defined this way in the syntax. The following:
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)
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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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 |
OlderNewer