3 ms·

> FixScript allows any syntax changes and it's done as a preprocessing step. This kind of separation bothers me a lot in Markdown for static site generation. Y

> FixScript allows any syntax changes and it's done as a preprocessing step. 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?

jezek2 4y ago
It is preferred to have syntax additions in the same style, but I do see the need for multiple different styles. Like the mentioned Python-like style. 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 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/ https://www.fixscript.org/docs/native/ and https://www.fixscript.org/docs/io/transaction.html 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).

jezek2 4y ago

It is preferred to have syntax additions in the same style, but I do see the need for multiple different styles. Like the mentioned Python-like style. 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 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/ https://www.fixscript.org/docs/native/ and https://www.fixscript.org/docs/io/transaction.html 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).