Atlast – Autodesk Threaded Language Application System Toolkit(fourmilab.ch)
fourmilab.ch
Atlast – Autodesk Threaded Language Application System Toolkit
https://www.fourmilab.ch/atlast/
9 comments
Not by chance, it seems suitable for the scripting needs of Autocad:
- A REPL alone, without defining either primitives from the application side or words on the user side, is already well-formed and very useful, and ready to be incrementally evolved into a very powerful scripting system that can do more with easily understood elementary commands rather than with a complex framework.
- A clearly understood application global state, mostly consisting of a complex document, obviates the need to keep significantly complex data structure on the scripting side, where they would live, at best, in a fragile and unstructured stack.
- Interaction consisting mostly of thinking what to do next, giving commands with a GUI or a REPL and then waiting for computation, rendering and I/O is a good fit for a very terse language with simple interpretation semantics.
- The unstructured nature of Forth-like programs makes high-level specialized commands easy to write, without pointless restrictions and without boilerplate. Narrow commands for specific needs and neat layering of general and abstract commands are compatible and well-supported approaches.
- A REPL alone, without defining either primitives from the application side or words on the user side, is already well-formed and very useful, and ready to be incrementally evolved into a very powerful scripting system that can do more with easily understood elementary commands rather than with a complex framework.
- A clearly understood application global state, mostly consisting of a complex document, obviates the need to keep significantly complex data structure on the scripting side, where they would live, at best, in a fragile and unstructured stack.
- Interaction consisting mostly of thinking what to do next, giving commands with a GUI or a REPL and then waiting for computation, rendering and I/O is a good fit for a very terse language with simple interpretation semantics.
- The unstructured nature of Forth-like programs makes high-level specialized commands easy to write, without pointless restrictions and without boilerplate. Narrow commands for specific needs and neat layering of general and abstract commands are compatible and well-supported approaches.
Has anyone successfully implemented this? Fascinating approach, but outside of the "manual" I can't seem to find much information about it.
Yes.
Used it in a production paint program I ported from Ikonas to SGI 4D+ machines.
It worked completely as advertised. I started out just using it to read a settings file. But then I realized that I could use the REPL to change the settings on the fly. After that, I wrote a flexible GUI library, then I was writing core paint functionality in it. It wasn't fast enough for hardcore image processing, although I prototyped a lot of stuff in it before converting to C, but it was dynamite for gluing things together.
My program somehow upended itself, going from a big chunky main loop to lots of little functions in C, glued together with ATLAST. It was almost magical -- I got rid of so much C code and I could add new stuff in minutes instead of hours!
The GUI was a sort of "Tektronix-chic", with flat buttons and LED style numeric readouts. It was completely defined in ATLAST so I could easily change layouts and functions without a recompile.
The "chassis" of zPaint (which included ATLAST) was later used for two commercial products -- zScope (waveform monitor and vectorscope) and zMatte (chromakey with spill suppression). Although it defined the user interfaces for both of those programs, the REPL wasn't exposed to the user (although the zscope manual had a very detailed explanation of how the setup file worked).
Unfortunately, they were both kind of niche products (especially on expensive, niche machines), but I do know zScope was used by Digital Domain in their film scanning pipeline for the "Apollo 13" movie.
Using ATLAST was a very pleasant experience. It integrated very well with ANSI C of that time and it was very compact. The documentation was absolutely stellar and I never had any problems with it that I couldn't solve. It's showing it's age now -- I seem to recall modern compilers frown on some of the memory tricks it does.
Because of that, something like Lua is probably a better choice for new projects, but at the time, it was a huge step forward for me.
Thanks, Mr. Walker!
Used it in a production paint program I ported from Ikonas to SGI 4D+ machines.
It worked completely as advertised. I started out just using it to read a settings file. But then I realized that I could use the REPL to change the settings on the fly. After that, I wrote a flexible GUI library, then I was writing core paint functionality in it. It wasn't fast enough for hardcore image processing, although I prototyped a lot of stuff in it before converting to C, but it was dynamite for gluing things together.
My program somehow upended itself, going from a big chunky main loop to lots of little functions in C, glued together with ATLAST. It was almost magical -- I got rid of so much C code and I could add new stuff in minutes instead of hours!
The GUI was a sort of "Tektronix-chic", with flat buttons and LED style numeric readouts. It was completely defined in ATLAST so I could easily change layouts and functions without a recompile.
The "chassis" of zPaint (which included ATLAST) was later used for two commercial products -- zScope (waveform monitor and vectorscope) and zMatte (chromakey with spill suppression). Although it defined the user interfaces for both of those programs, the REPL wasn't exposed to the user (although the zscope manual had a very detailed explanation of how the setup file worked).
Unfortunately, they were both kind of niche products (especially on expensive, niche machines), but I do know zScope was used by Digital Domain in their film scanning pipeline for the "Apollo 13" movie.
Using ATLAST was a very pleasant experience. It integrated very well with ANSI C of that time and it was very compact. The documentation was absolutely stellar and I never had any problems with it that I couldn't solve. It's showing it's age now -- I seem to recall modern compilers frown on some of the memory tricks it does.
Because of that, something like Lua is probably a better choice for new projects, but at the time, it was a huge step forward for me.
Thanks, Mr. Walker!
I deployed Atlast into a consumer media device in the mid-90's.
Essentially I used it as a scripting language for writing user facing setup GUI dialogs.
The justification was that the GUI screens were art-directed by an offsite team and changed at a rate faster than the team could react to.
Some fundamental GUI words in Forth made things compose-able and quick (at least for me).
I thought was great, as I'm a Forth fan(atic), but "normal" SW folks didn't take too kindly to it.
Since I wrote a crap-ton of Postscript code in a previous job, it worked well with the thought process developed there.
In retrospect, if I'd known about TclTk, I might have gone down that path though.
Essentially I used it as a scripting language for writing user facing setup GUI dialogs.
The justification was that the GUI screens were art-directed by an offsite team and changed at a rate faster than the team could react to.
Some fundamental GUI words in Forth made things compose-able and quick (at least for me).
I thought was great, as I'm a Forth fan(atic), but "normal" SW folks didn't take too kindly to it.
Since I wrote a crap-ton of Postscript code in a previous job, it worked well with the thought process developed there.
In retrospect, if I'd known about TclTk, I might have gone down that path though.
the linked source-archive (at the bottom of the page) compiles without problems on a modern OS, or do you mean an application using it?
Looking for any software projects that have successfully adopted this approach for extensibility.
Anything embedding Lua, TCL or Rexx should be nearly identical in structure.
https://en.wikipedia.org/wiki/Rexx
https://en.wikipedia.org/wiki/Rexx
Other than being Forth-based, is this significantly different than any of the other embeddable scripting languages, like Guile or Lua?
> "Autodesk's connection with this program is purely historical: it is neither endorsed, used, nor supported by Autodesk, Inc."