Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C3 Programming Language

c3-lang.org

Post reply on HN
Print view View original

121–130 of 270 posts

Re: The C3 Programming Language

#121

Post by mananaysiempre »

esrauch wrote: post #105
ajuc wrote: post #98

Earlier quoted context omitted.

So the compiler could have debug mode where it checks the invariants and release mode where it assumes they are true and optimizes around that without checking?

Yes, and that same pattern already does exist in C and C++. Asserts that are checked in debug builds but presumed true for optimization in release builds.

Not unless you write your own assert macro using C23 unreachable(), GNU C __builtin_unreachable(), MSVC __assume(0), or the like. The standard one is defined[1] to either explicitly check or completely ignore its argument.

[1] https://port70.net/~nsz/c/c11/n1570.html#7.2

Re: The C3 Programming Language

#123

Post by Fraterkes »

tialaramex wrote: post #90
Fraterkes wrote: post #52

Dumb question about contracts: I was reading the docs ( https://c3-lang.org/language-common/contracts/ ) and this jumped out "Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all. However, violating either pre- or post-conditions is unspecified behav…

Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…

I guess the reason I found it surprising is that I would only use 3 (ie risk introducing UB) for invariants that I was very certain were true, whereas I would mostly use 2 for invariants that I had reason to believe might not always be true. It struck me as odd that you'd use the same tool for scenario's that feel like opposites, especially when you can just switch between these modes with a compiler flag

Re: The C3 Programming Language

#124

Post by christophilus »

cardanome wrote: post #101
norir wrote: post #79

Earlier quoted context omitted.

Yes, this is fine for basic exploration but, in the long run, I think LLVM taketh at least as much as it giveth. The proliferation of LLVM has created the perception that writing machine code is an extremely difficult endeavor that should not be pursued by mere mortals. In truth, you can get going writing x86_64 assembly in a day. With a few weeks of effort, it is possible to emit all of the basic x86_64 instructions…

That is why the Hare languages uses QBE instead: https://c9x.me/compile/ Sure it can't do all the optimizations LLVM can but it is radically simpler and easier to use.

Hare is a very pleasant language to use, and I like the way the code looks vs something like Zig. I also like that it uses QBE for the reasons they explained.

That said, I suspect it’ll never be more than a small niche if it doesn’t target Mac and Windows.

Re: The C3 Programming Language

#125

Post by lerno »

tialaramex wrote: post #90
Fraterkes wrote: post #52

Dumb question about contracts: I was reading the docs ( https://c3-lang.org/language-common/contracts/ ) and this jumped out "Contracts are optional pre- and post-condition checks that the compiler may use for static analysis, runtime checks and optimization. Note that conforming C3 compilers are not obliged to use pre- and post-conditions at all. However, violating either pre- or post-conditions is unspecified behav…

Contracts are a way to express invariants, "This shall always be true". There are three main things you could do with these invariants, the exact details of how to do them, and whether people should be allowed to specify which of these things to do, and if so whether they can pick only for a whole program, per-file, per-function, or whatever, is separate. 1. Ignore the invariants. You wrote them down, a human can rea…

Maybe also worth mentioning is that some static analysis is done using these contracts as well. With more coming.

Re: The C3 Programming Language

#126

Post by Zambyte »

sph wrote: post #116
jadbox wrote: post #69

Does anyone who has actually used C3, Odin, and Zig talk about how to think of these three?

Zig feels too much in flux, has some incredible ideas, but I really don't like it syntactically wise, and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors which I believe it's the worst thing to ever have been invented and drives me up the wall. Documentation was still pretty bad last I checked, and that's the bare minimum before I can seriously adopt a new language. C3 feel…

> and I really don't like how the author is so stubbornly in favour of unused-variables-as-errors

FWIW, they also have a goal to emit as much output as possible, even in the face of compilation errors. They have stated that even syntax errors should have the compiler exit with a non-zero exit code, but still produce an executable that will give you a syntax error at runtime. The point of this being to allow you to iterate quickly, but force things like CI to fail.

Re: The C3 Programming Language

#127

Post by fuzztester »

fuzztester wrote: post #67
contificate wrote: post #41

Earlier quoted context omitted.

> Meanwhile, a compiler is an enormously complicated story. I don't intend to downplay the effort involved in creating a large project, but it's evident to me that there's a class of "better C" languages for which LLVM is very well suited. On purely recreational grounds, one can get something small off the ground in an afternoon with LLVM. It's very enjoyable and has a low barrier to entry, really.

>On purely recreational grounds, one can get something small off the ground in an afternoon with LLVM. It's very enjoyable and has a low barrier to entry, really. Is there something analogous for those wanting to create language interpreters, not compilers? And preferably for interpreters one wants to develop in Python? Doesn't have to literally just an afternoon, it could be even a few weeks, but something that will…

Thanks to those who replied.

Re: The C3 Programming Language

#128

Post by lerno »

coldtea wrote: post #111
Windeycastle wrote: post #64

Earlier quoted context omitted.

The way I reason about it is that the contracts are more soft conditions that you expect to not really reach. If something always has to be true, even on not-safe mode, you use "actual" code inside the function/macro to check that condition and fail in the desired way.

> The way I reason about it is that the contracts are more soft conditions that you expect to not really reach What's the difference from an assert then?

The difference from an assert is that for "require" they are compiled into the caller frame, so things like stack traces (which is available in safe mode) will point exactly to where the violation happened.

Because of inlining them at the call site happens, static analysis will already pick up some obvious violations.

Finally, these contracts may be used to compile time check otherwise untyped arguments to macros.

Re: The C3 Programming Language

#130

Post by lerno »

lalitmaganti wrote: post #63

Was an interesting ready but sad to see that there is nothing special for matching or restructuring tagged unions (beyond the special cased optional type). That's one of the things from Rust I miss the most in my day to day work with C/C++.

Still looking for a good design: https://github.com/c3lang/c3c/issues/829
Post reply on HN