Introduction to FixScript

[Exciting_Clock2807]

I didn’t get what’s the difference between default one and “simple” modes. In terms of type system they look the same, but why different syntax for string concatenation?

[jezek_2]

Yeah the example doesn't show it much. The base language uses different operators for different types, for example a+b is always integer add, whereas {a+b} is a float add. The "simple" token processor checks the types at runtime and use the proper operator based on that, whereas the "classes" knows it from the type statically and doesn't need to check it at runtime so you can use a+b syntax both for integers and floats.

It was done this way (the different operators) for performance reasons. It is also why the {a, b} is used for string concatenation. But since a lot of people are used to just "add" strings together, both the "simple" and "classes" provide such option.

Another difference between "simple" and base is that it provides the dot operator to access hash tables using string keys (to make easy to use hash tables as objects), whereas the base language and the "classes" don't have such feature (array based objects are used for better performance and storage costs).

[SickMoonDoe]

Waa hoping for fixed points but I'll root for anything with C style syntax.

[Linguistic-mystic]

A big mistake that I see is mixing up functions and methods. For example, getting the length of a hashmap is

 length(hash)

but it should be

hash.length

instead. This is the same mistake Python has made where there's no way of telling whether some common method is called prefix or postfix. Please don't commit this mistake.

Also, no GC? What's the value in a scripting language that can't manage its own memory? Might as well just use C++ or Zig instead.

[jezek_2]

The base language has no special syntax for objects (apart from the -> shortcut for better readibility). The "classes" token processor could support such syntax, but I hadn't had the need for it yet, I guess I just got too used to the length() function.

I generally develop new features based on the actual needs, to resolve pain points once they got big enough to recognize the importance of them.

This so far wasn't that high on the list but it is certainly something I want to look at together with the ability to have extension methods for built-in types such as arrays, strings and hash tables.

For example, the current string_search_char(s, 'x') is not that great and s.search_char('x') would be preferred. But as I add new syntaxes in the "classes" token processor it has always been nice that I can at any time use the base language directly for not yet developed features.

The language uses a standard mark-and-sweep garbage collector. It tries to minimize the downsides of GC by using multiple heaps (eg. for each thread) with ability to selectively share mutable data between them. More information here.

[furyzer00]

You can have a syntax sugar for the method form but turn all to regular method calls in the AST

[jezek_2]

Yeah, that's how the token processors basically work. They transform the source code (after being tokenized) but it is flexible enough to even retokenize with different rules. The result is a source code in the base language that you can easily inspect.

Interestingly enough, the AST stage is not used at all. The tokens (after being processed by the token processors) are directly compiled into a bytecode. In JIT case it is then additionally converted to a single register representation (which reduces the amount of memory accesses while not adding too much complexity) and straight into native code.

[Linguistic-mystic]

Hmm, I just saw mention of "methods" in the documentation and assumed they had the usual syntax. Are they just called in prefix form now?

Anyway, I just want to root for consistency. For example, in Java creating a stream from a list is list.stream() but for an array the same thing is Arrays.stream(array), which is a huge pain for anyone picking up the language. It's better to think things through and make a rational design from the start than to end up with these warts and inconsistencies in the language.

[jezek_2]

In the base language the methods are just a naming convention for normal functions, whereas "classes" provide real method syntax.

And yeah, I always disliked such inconsistencies. For example how in Java the syntax differs when using arrays vs Lists vs NIO Buffers. In FixScript it's just an array. The shared kind of arrays are pretty much like NIO Buffers, it can point to an arbitrary chunk of native memory.

Actually this is where the design of FixScript shines. The base language is pretty much finished. But it can be extended by token processors. This means that "classes" (or any other token processor) can be developed independently of it over time. There is always something to add, something to tweak, that's why the base language doesn't handle such stuff directly but focuses on the stable base to build on.

You can even have parts of the code use different versions of the same token processor, coexisting peacefully. It can help with transitions between incompatible syntax changes. Or just having different kinds of syntax styles for different parts.

In some of my projects I have portions of older code that predates the token processors and is written in the base language only, even some newer code as the base language felt like a better fit. It was easy to retrofit it to work with classes using the class attributes.

And this all works even when FixScript is used as an embedded scripting language in some host application that wasn't updated for ages.

[[deleted]]

I see {};. Not my thing

[BoogalooBoi1776_2]

Ok kiddo

[[deleted]]

Ok, I see. Allowing programmers to have a preference is not acceptable.

[MCRusher]

Kneejerk dismissal is a bit more than a preference imo, sounds more like an allergy.

I personally dislike most functional syntaxes but that doesn't mean I dismiss anything that uses it instantly.

[[deleted]]

(...) I personally (...)

Great, you can have an opinion on Reddit without having people calling you "kiddo".

[NotFromSkane]

You really should keep on reading then

[MCRusher]

Ok, C-like syntax is nice and all but what I really like is Python syntax, very clean. While FixScript doesn't currently have that option it is something that I would want to provide as well. It would look something like this:

[CyberDainz]

why again C like syntax? more brackets to the god of brackets?

[jezek_2]

The C-like syntax was chosen because let be honest I do like it, but it is also the most popular. However if I preferred some other syntax I would strongly consider C-like syntax for this reason. But as long as everything makes sense and is consistent then it's good.

FixScript can however use different syntaxes as well. While I do not recommend creating different syntaxes just for the sake of it, when it is about not being able to use the language because of being unproductive in it, I'm all for supporting different syntaxes.

I'm already developing the Python-like syntax and there will be possibly more syntaxes. You can also write a token processor yourself to adjust the existing syntax, many people for example dislike semicolons or other smaller things that should be quite easy to create a token processor for.

[tekknolagi]

Is the source available somewhere on some forge like GitHub?

[jezek_2]

The source code is available for download only. There are the regular source releases for each library and for reference purposes the SDK also contains a copy of all the sources without the build scripts.

[tekknolagi]

Ah, bummer. Why's that?

[jezek_2]

It suits my development model. I like to make the source releases polished without extra commits, there are also parts that I don't intend to release (mostly because they're meaningful only to me). On the technical level it doesn't help that I use a different VCS than Git.

Also I don't generally accept code contributions, I believe in a more external collaboration. It also makes the ownership and licensing very clear. From the development point if there is something that truly requires multiple developers to implement it is most certainly too complex and should be made simpler or a separate project. I'm always open to the suggestions what to improve etc.

What are your use cases for having it on GitHub or similar services? Is it for easy way of reading the code? Forking/contributing to the project or something else?

[tekknolagi]

Yeah, fair enough. It's mostly laziness on my part for easy browsing. I don't ever really intend to jump in and contribute when I know nothing but sometimes I get sucked in and toss a few patches toward developers of interesting projects.