[HN Gopher] Show HN: FixScript, an embedded/standalone language ...
___________________________________________________________________
Show HN: FixScript, an embedded/standalone language with custom
syntax additions
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
Author : jezek2
Score : 28 points
Date : 2023-01-09 19:56 UTC (1 days ago)
(HTM) web link (www.fixscript.org)
(TXT) w3m dump (www.fixscript.org)
| antiatheist wrote:
| 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`
| jezek2 wrote:
| 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
| Simran-B wrote:
| > 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 wrote:
| 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).
| [deleted]
| sgammon wrote:
| [flagged]
| dang wrote:
| " _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.
| danielEM wrote:
| Does it also compile to C?
| jezek2 wrote:
| 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.
| danielEM wrote:
| 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.
___________________________________________________________________
(page generated 2023-01-10 23:02 UTC)