include 'z.inc'
use interface

TEXT t(256), title='My Application'

devices.f db \
 'Key: ''%c''=%n=%hh=%bb' R\
 'Mouse: X/Y=%nx%n' R\
 'Click: %n. %n. Wheel: %n', 0

; !on.create: when application begins...

! create
; ...
!end

; !on.draw: when screen is redrawn...

! draw
locate
draw.red.fade
print t, devices.f, [key], [key],\
 [key], [key], [mouse.x], [mouse.y],\
 [mouse.1], [mouse.2], [mouse.wheel]
draw.caption.s t, CENTER
draw.title.bar title
!end

; !on.mouse: when a mouse event occurs...

! mouse
; ...
title.bar.input
redraw
!end

; !on.key: when a key event occurs...

! key
; ...
redraw
!end

; !on.timer: every x ms (set.timer x)...

! timer
; ...
!end    

TEXT t(256), title='My Application'
devices.f db \
'Key: ''%c''=%n=%hh=%bb' R\
'Mouse: X/Y=%nx%n' R\
'Click: %n. %n. Wheel: %n', 0

1) the symbol for itself
using LET when i can do in 3 digits in most cases MOV or
why "LET" instead of "SET" or "DIM". information should not be overloaded!
then an essential physical matter: the coder should type physically less.
possible compounded use of the symbol. pseudocode example

let [a]=2
let [a]=eax
let [a]=get[c]
let [get [c]]=3
let a = eax
let a[3] = eax
let a[c.field] = eax
etc..

2) the symbol against the rest
example problem: why using [ in let [x] where i may think to use [ to access only array.
or why not using SET that couples GET and may allow set[x = get[y]]
where [ nests itself

it is a mere permutational matter a syntax allowing labels
starting with letters [A-z], while prohibiting them when starting with digits [0-9].
this and all similiar choices are not trivial. for the case above, it impacts directly
on the hashing algo over labels. the bad choiche may drive to collisions or memory wasting.
and because it is all actually built on assembly, all will become harder to be parses,to be executed.

3) macro must not break the standard behavour of the engine
if i use [ for something like
let[x] = y it must not break/conflict with mov [eax],0
it must allow the user (note: assembly user!) to write it barely
mov eax,y
mov [x],eax

4) macro must not break inside macros
the solution to this conflict gives the ml flexibility.
the solution is writing guidelines in a BNF chart http://en.wikipedia.org/wiki/Backus%E2%80%93Naur_Form
also, the fact that it is a macro language includes still more restrictions
than it provides, because you have already rules from the engine running
underneath (i.e. fasm)

5) portability and/or running mode (emulated/native)

EXPRESSIONS

1. Parenthesis: ()
2. Unary: -a, ~a, &a, *a
3. Array, Structure: a[i], s.m or s->m
4. Function: f(a, b, c)
5. Multiply, divide: a*b, a/b, a%b
6. Add, subtract: a+b, a-b
7. Shift: a<<b, a>>b
8. AND, OR: a&b, a|b

DECLARATIONS

* Pointer: IMAGE *image     ; create address size variable
* Array: IMAGE images<4>    ; create fixed array
* HL array: IMAGE images[4] ; create dynamic ARRAY.INC
* Or: IMAGE images[?]       ; unknown #, index size is known    

CREATE, DESTROY

; "create/destroy" any object/class or create file or destroy pointer.

create object, ...
create image, pixels, w, h, bpp
create button, text
create caption, text, box, color
create menu, texts

create file
destroy pointer

LOAD, MOVE, DRAW, UPDATE, ETC

; "load/move/draw/update" any loadable/moveable/drawable/updatable object/class.
 
load object, ...
load image, file
load button, file
load tilemap, file

move object, ...
move image, x, y
move button, x, y
move tilemap, x, y

draw object, ...
draw pixel, x, y, color
draw box, b, color
draw image
draw image, x, y
draw button
draw window
draw etc

update object, ...
update button
update window
update dialog    

...Ultimately, my "Dream Language" would be the simplest pure English syntax

! main
load.defaults
!end    

! draw
font.height
let ecx=[screen.w], ecx>>1,\
 edx=[screen.h], edx-eax, edx>>1
!end    

! mouse
title.bar.input
redraw
!end    

1) use a portable graph library, example SDL -> this simplifies/makes stable your work
on what is graphics-concerned. app links against it automatically (dll or lib).
this solves ~40% of your work, granted.

2) improve the structure as in the file GRADIENTS.ASM.
first of all events/methods/object, because as far as i can suppose, graphics has to do
with AI and polymorphism, normally difficoult to be implemented nowadays.
the bare macro syntax then -> where macros expand to code for that platform.
the bare macro syntax should be realized only after having completed an abstract external superior view of the whole

What if the F in FASM meant something else? "Future Assembler"? Start a discussion in Heap: Flat or Future? At one time, humans thought the world was flat.