Tom Novelli
The person and contributor who created Retro Forth. http://bespin.org/~tom/
My current vision for Tunes:
A programmers' user environment, where anything you can do from the keyboard, you can do automatically with a program. Within reason.
LLL, Meta-translator, C-translator: Ideally we can compile any language into an intermediate parse-tree form, and from there to object code. With a sufficiently expressive intermediate form, this would work. Scrap the LLL and focus on this instead. Don't bother trying to translate BETWEEN different languages, comments and all - that's an intractable problem.
HLL: There's a trade-off between "foolproof" and "practical". I've been skeptical of anyting to do with automatic proof but I'm warming up to the idea of type safety. You CANNOT guarantee that a program is correct, but you can guarantee that it won't screw anything else up.
Libraries: Don't get carried away with standard libraries.. don't create extra abstraction layers by over-generalizing. This has been a tough balancing act in the past. Maybe metaprogramming will help get it under control.
- Streams, suitable for dumb terminals and voice
- Structured text, suitable for VT100 or braille terminal
- Graphics, suitable for raster or vector displays & printers
The Migration subproject looks like an exercise in world domination.. it goes way beyond the scope of Tunes. If Tunes has even better source-code compatibility than C and Unix, that's good enough for me.
Can you explain what you mean by "over-generalization"? -Tril
I'm worried about abstraction inversions. You know, when you're given a crappy API with function parameters for every possibility, and you end up writing your own simpler abstraction layer on top of it, just to cope with it. It's something that working programmers have to deal with. -Tom
This page is linked from: Credits Forth is NOT intrinsically slow Retro Small C tcn