but it breaks associativity or is it commutivity?
Anyway you can't add THREE or more things in one expression (yet)
because adding OberonInt objects returns a two-tuple.
I could adjust the semantics of ObInt to accept such two-tuples and do
add_with_carry() but that's probably more trouble than it's worth.
Just gotta be careful with math expressions, eh?
Ocaml's match is very powerful, respect, but if I want more precise
error messages (that conform to the joytest suite) then the extra
utility functions must be implemented and employed.
After that it's definition loading and the main REPL loop and I think
that's it, eh?
...I'm just relearning C semantics. (And they are garbage, as is widely
known.)
I don't think there's much point to this (at the moment) because I don't
want to relearn C (at the moment) and Nim is available (at the moment.)
Really, I'm trying to do away with the entire relationship of C et. al.
to the underlying machine. (For instance, Nim gives you a much nicer
relationship, without the vast distance that, say, Python imposes.) I
should really look at other compiled languages, like Ocaml or Julia.
If one causes an error before the other is finished SIGKILL the other
job. (I do not know if this will kill the sub-tasks if any. The Python
docs say that with terminate() "descendant processes of the process will
not be terminated – they will simply become orphaned." but it doesn't
say whether that's true with kill().
Still needs the rest of the core functions and defs.
Could read defs from a file at compile-time?
Integer math? Boolean ops? Just type inference and maybe compiling?