Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: FixScript, an embedded/standalone language with custom syntax additions (fixscript.org)
31 points by jezek2 on Jan 10, 2023 | hide | past | favorite | 9 comments
Hello, I want to introduce you to a programming language that I've been working on for a few years and is ready to be shared with a broader community.

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:

https://www.fixscript.org/docs/sdk/fixscript/index.html

https://www.fixscript.org/docs




> 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?


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

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).


The token processors seem interesting, and a great C/JS like syntax with a solid looking Python-like standard library.

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`


The documentation could always improve, what things are you missing or think would be better made simpler?

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


Yeah better docs would be useful, and IDE integration (vscode extension?) for syntax highlighting and build.fix creation would be useful.

If I get an idea this might be useful for, will definitely consider using.

What have been your main use cases? or targets?


Does it also compile to C?


It doesn't.

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.


Technically the only reason I'm still looking for languages that transpiles to C is an sdcc compiler that supports tons of microcontrolers that can't be programmed with anything else than C or assembly. So I guess, if you were to make an effort to make another target that is not C then LLVM would be probably a better spent time.


[flagged]


"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

This is particularly important for Show HNs: https://news.ycombinator.com/showhn.html - we want HN to be a place where people can share their work and get meaningful, respectful feedback. Criticism is fine of course but it should come with information and explanation.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: