The big 1.0

[lerno]

I'm collecting small pieces of things needed for 1.0 that aren't really ready to go into issues yet into this single issue.

• [ ] Full BSD-family support in the standard library
• [ ] C-to-C3 tool available
• [ ] C3docs available
• [ ] Full standard library available on the web
• [ ] No known bugs in the compiler
• [ ] A secondary backend for fast compilations
• [ ] Automatic static / dynamic library .c3l generation
• [ ] A completely fleshed out standard library
• [ ] Support for most common embedded targets (when 1.0 is released!)
• [ ] Full Android / iOS support
• [ ] Downloadable binaries for all Linux distros, MacOS, Windows, all BSD variants.
• [ ] A good experience cross compiling to Linux
• [ ] Cross compiling to MacOS & Windows with automatic download of required supporting libraries
• [ ] High quality LSP
• [ ] Easily available editor plugins
• [ ] High quality IntelliJ plugin

Nice to haves:

• [ ] A C output backend

Stdlib features

• [ ] Zip compression
• [ ] Regex library

[Caleb-o]

Very exciting!

[lerno]

ZIP compression? yoinks C# ZIP library implementation

If you want to. There are a lot of them out there.

[rodgomesc]

What is still needed to complete Android support? Is there a to-do list available anywhere?

[lerno]

Something like this @rodgomesc

1. Make sure linking links the proper libraries
2. Decide what Android platforms to support (32 bit ARM for example?)
3. Add CI for Android compilation
4. Fix whatever special ABI changes Android has compared to Linux
5. Linking should work off the bat, so there should be a way to pull in the needed libraries for linking, initially perhaps as an external script, but later as something in the compiler itself which downloads needed dependencies.
6. Add some bindings to essential Android libraries.

[radekm]

Zip compression

This also means ZIP decompression? If that is so, I wonder how to deal with different kinds of ZIP archives produced by different implementations. Recently I watched Josh Wolfe's talk about yauzl library and invalid ZIP archives produced by Mac Archive Utility (you can see the GitHub issue https://github.com/thejoshwolfe/yauzl/issues/69). It seemed that creating a reliable ZIP decompressor which works with most ZIP archives is a really hard task.

[lerno]

I think a best effort thing would be reasonable @radekm. Something on par with Java's built in zip library code.

[rodgomesc]

Hey! I started to poke around and I start thinking about something - is it possible to use CMake to turn .c3 code into a shared library without the prebuilt c3c compiler? Ideally, I don't want users to need a c3c compiler already installed on their computer. Maybe I could go from .c3 files to LLVM IR, then to object files, and finally into a .so library? Or am I just making this way more complicated than it needs to be?

[lerno]

Well, turning a .c3 file into a IR or a library is exactly what you need a compiler for. So I'm not sure how that could work @rodgomesc

[alexveden]

c3fmt now is released https://github.com/alexveden/c3tools/tree/main/src/c3fmt

[LukeGary462]

using C3 for embedded systems development on arm cortex mcus is extremely exciting to me. Is there an option to compile c3 without linking libc or specifying a different libc implementation? I cant wait to see how support for embedded targets progresses!

[LowByteFox]

Unsure if someone mentioned it, but for BSD binary releases, be aware that each release, the respective BSD may not be ABI compatible

let's say between OpenBSD 7.6 to 7.7

one thing that could be done is to add c3c port to their ports trees

it is also why each release, every single package is recompiled

[lerno]

You're talking about the compiler or something else?

[LowByteFox]

You're talking about the compiler or something else?

yes, the compiler binary releases, the standard library should be fine

[lerno]

A good point. Ideally it compiles to a wide range of targets out of the box, but also is available from different package managers.

[kryzet]

Are there plans to eliminate the intermediate language stage from compilation?

[lerno]

What intermediate language @kryzet

[kryzet]

I mean eliminating LLVM and going directly from C3 to assembly (maybe machine code?)

[lerno]

@kryzet That's the "secondary backend" point.

[kryzet]

Ah, I see. Thanks. For the point "No known bugs in the compiler", is there an amount of time for which it has to remain true before it is considered done?

[lerno]

Typically a few months. @kryzet

[kryzet]

The compiler should utilize the Sea of Nodes algorithm; that would make it competitively performant without relying on GCC/LLVM/QBE.

[LowByteFox]

The compiler should utilize the Sea of Nodes algorithm; that would make it competitively performant without relying on GCC/LLVM/QBE.

Yes, but wouldn't say that's always the case

Look at V8 https://v8.dev/blog/leaving-the-sea-of-nodes

I know I'm comparing apples and pears but I don't think there always is one solution that's the fastest

[kryzet]

Since a number of the issues noted in that article are caused by the design of JavaScript, it is likely that this won't be an issue for C3 as it is not trying to be similar to JavaScript (though I'm not familiar with the language so I can't say for sure that there aren't any deal breakers). Do you have any other suggestions for the IR that the C3 compiler should use?