Tue Mar 20 01:22:58 EDT 2007
a safe language?
[ 1 + ] : inc
[ 2 + ] : inc2
is it possible to make a safe language without too much trouble?
something like PF. without pointers..
[1 2 3] [1 +] for-each
the interesting thing is that i can use code in ram if i unify the
memory model. i think it's time to start to split one confusing idea
- a 16/24bit dtc forth for use with sheepsynth dev: control computations
- a self contained safe linear language for teaching and simple apps
* no raw pointers as data
* no accessible return stack, so it can contain raw pointers
* no reason why numbers need to be 16 bit: room for tags
- number [num | 1]
- program [addr | 0]
* symbols refer to programs, special syntax for assigment
* assigning a number to a symbol turns it into a constant
* for, for-each, map, ifte, loop
[ 1 + ] -> inc
1 -> inc
[[1 +] for-each] -> addit
the above is enough for structured programming, but map and for-each
don't make much sense without the data structures.. so programs should
be lists, at least semanticly. since flash is write-once, a GC would
make more sense than a linear language.. so what about:
purrr/18 -> purrr -> conspurrr
maybe it's best to stay out of that mess.. cons needs ram, not some
hacked up semiram.
what about using arrays? if programs are represented by arrays instead
of lists, not too much is lost:
[1 2 3 4] [PORTA out] for-each ;; argument readonly = ok
[1 2 3 4] [1 +] map ;; argument modified in place (linear)
the latter one needs copy-on-write.
[[+] [-]] [[1 2] swap dip] for-each
[1 2 3] [1 +] map -> test
1. arrays are initially created in ram, as lists?
2. when assigned to a name, they are copied to flash
3. assignment is a toplevel operation, effectively (re)defining constants
4. flash is GCd in jffs style.
5. words can be deleted.
in ram: one cell is 3 bytes: 2 bytes for contents + 1 byte next
pointer. this leaves room for 256 cells, or 768 bytes.
it might be interesting to make assignment an operation that's valid
anywhere: persistent store.. on the other hand, that encourages misuse.
- free lists make no sense in flash
- they do in ram
- persistent store rocks
in order to make this work, i need to write a flash filesystem first.
problem: does redefining a word redefine all its bindings? it
should. so each re-definition needs to be followed by a
recompilation. nontrivial. this gets really complicated...
can't we represent code as source, and cache it in ram? it looks like
variable bindings should really be in ram. but what with persistent
damn. dumbing it down aint easy. i think maintaining the late binding
approach is infeasible. maybe it's good enough to clean up the
semantics a bit? 1->1 syntax->semantics mapping (i.e. choose is the
only conditional) so code can be used as data using 'map'. maybe that
does make sense.. 'map' as 'interleave'.
ok, that's enough.