What are the plans for the language?

[spydr06]

What are the plans for the language?

[Spydr06]

I've spent the last 2 years writing this language, so no, this won't be 'thrown away' anytime soon :)
In fact, I've used this language to solve some of the Advent of Code 2022 problems.
But yea, as you already guessed I'm currently busy developing other projects so this one is put back a bit.
Since the feature-set of this language is pretty much complete (yes, you could always add stuff), most of the future development this project is going to see will be bugfixes and compatibility improvements (Windows and BSD support would be awesome).

Nevertheless, feel free to improve/work on this language if you want to, I'd be happy to merge some pull requests :)

[Its-Kenta]

Sadly I’m not experienced enough to do any PR that would improve this language (apart from bindings 😏)

Are there plans to perhaps expand the documentations e.g on manual memory management and overall?

And ofc Window support anytime?

[Spydr06]

yea, you're right, the documentation is not complete at all, I'll have to expand it eventually, I plan to cover all language features and stdlib functions, but won't go in depth about memory management, etc. since that's a thing not specific to this language.

I already tried porting CSpydr to Windows a couple of times in the past, but never even got the compiler to work (Visual CXX being the main problem). The standard library basically needs to be rewritten to support Windows aswell.
Provided the scale of this and my lack of experience developing for windows platforms, I can't really say if/when this is going to be achieved...

When I get back to this project, my main target will be finishing off all of the semi-implemented features (e.g. libcspydr API/Headers), adding unit tests etc.

[Its-Kenta]

Unfortunately I’m not that experience to help out, but I hope someone will do or one day you find that pesky reason why it doesn’t work.

Personally as a user I do have to say that Windows & Linux or least Linux & WASM is probably the minimal of what people might need, especially if planning to use a language for game dev (which is what I’m into)

Luckily CSpydr source code is quite easy to read so it also reads a little bit like documentation, but most certainly more documentation would make people be interested in using the language.

Hope you will revisit this project and continue developing it at some point. I might play with it a little bit more, although last time I tried using it with the SDL2 and GLFW bindings provided it seemed to give errors. I will try again and continues I will post an issue

[Its-Kenta]

Would there be any guidelines on interoperability with C somewhere as well? If not I will study the bindings a little and try to glue something together

[Spydr06]

Would there be any guidelines on interoperability with C somewhere as well?

CSpydr is fully compatible with C. Stuff like the call ABI, struct padding, pointers, etc. is exactly like in C

Defining a C function is done like this:

extern "C" fn c_function_name(arguments: types): ReturnType;

linking with a C library can be done like this

• for .so libs: [link("yourlibrary")]
• for .o libs: [link_obj("your_o_file.o")]

Calling CSpydr functions from C is possible, although not officially supported right no (no explicit name-conversion...)

[Spydr06]

with the SDL2 and GLFW bindings provided it seemed to give errors. I will try again and continues I will post an issue

Yes! Please do that! :)
The glfw examples work on my machine, the sdl2 one too, but they're not really tested, so I don't know about those

[Its-Kenta]

Would there be any guidelines on interoperability with C somewhere as well?

CSpydr is fully compatible with C. Stuff like the call ABI, struct padding, pointers, etc. is exactly like in C

Defining a C function is done like this:

extern "C" fn c_function_name(arguments: types): ReturnType;

linking with a C library can be done like this

* for .so libs: `[link("yourlibrary")]`

* for .o libs: `[link_obj("your_o_file.o")]`

Calling CSpydr functions from C is possible, although not officially supported right no (no explicit name-conversion...)

Is it possible to link with a static lib? Or would it be the same as dynamic ones?