fixscript.org
Feel free to ask any question about it, it's hard to describe what it is all about in a single blog post. For examples of a more complex code I recommend looking into to the "src" directory in the SDK. And here are some documentation links:
This kind of separation bothers me a lot in Markdown for static site generation. You typically use Jinja-like templating on top of regular Markdown, and there's a preprocessing step for the templating. This is sometimes limiting in my opinion, as there is a fixed order of operations (preprocessing, then Markdown parsing/rendering). And the two styles of markup are very different. reStructuredText / Sphinxdoc is nicer in that regard because there is a consistent syntax that is arbitrarily extensible.
Can you show some examples of FixScript's extensibility, ideally showing that it's better than a C preprocessor?
I expect that each of the radically different styles will have their set of token processors, although some would be possible to use regardless of the style.
Token processors can also work together. For example the "classes" have an API for other token processors to work with the static types. More info here: https://www.fixscript.org/docs/classes/#api
Examples of this are in the "native/extern" and "io/transaction" token processors. The docs for them: https://www.fixscript.org/docs/native/ and https://www.fixscript.org/docs/io/transaction.html
Most of the simpler token processors don't have dedicated documentation, you can look at the beginning of their source code for the usage. You can see the *.fix files in the root of the "src" directory in the SDK. There is a convention that general purpose token processors reside in a root of the sources.
Namely the "autoinit" is able to insert an initialization check to every public function (after being processed by other token processors) to make sure the common init function is called. The "macros" is implementing a simple to use macros so you don't have to write token processor directly for each use case. The "optional" is able to insert specific code depending on the availability of other source files. The "unpack" provides a nice syntax for retrieving of individual variables in an array (used in callbacks and to provide multiple return values).
Would be nice to have some simpler docs though, is there a REPL?
I can't figure out how to build the sources from the download page, and I don't see any packages in distrorepos yet.
EDIT: Nevermind, pointing `fixbuild` to a directory and script file works: `./fixbuild -src dir -m main`
There is no REPL available. I'm not decided if to build one, depends on what it could be useful for? I certainly use Python REPL as a calculator but maybe it's not that common usage of it. There is also a plan to have online sandbox to play with.
Great that you were able to figure it out. You can also add a "-c" parameter to create a "build.fix" file so that you could use just "fixbuild" for repeated builds (from any subdirectory of the project).
More information about this: https://www.fixscript.org/docs/sdk/fixbuild/build.html
If I get an idea this might be useful for, will definitely consider using.
What have been your main use cases? or targets?
I've tried it as an experiment a long time ago but was very unsatisfactory. I've already did some other transpilers to C in the past and can say that it is a terrible compiler target (you'll hit a lot of edge cases pretty fast with sometimes really awkward workarounds and very slow and memory hungry compilation).
Unless you're doing something very close to C the optimizations don't really help for performance either.
A fully optimizing AOT compiler is on the plan in a more distant future. I might try to revisit the idea to output to C from an already language specific optimized compiler output. Probably again as an experiment only. I don't see much of the upsides.