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

141–150 of 270 posts

Re: The C3 Programming Language

#141

Post by bluecalm »

Zambyte wrote: post #126
sph wrote: post #116

Earlier quoted context omitted.

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 it…

Why not just use compile warnings and configure CI with -WError (same like your release build).

It seems like trying to fix the world of undisciplined developers at the cost of a common use case (experimenting and temporary accepting warnings).

Re: The C3 Programming Language

#142

Post by loeg »

turtletontine wrote: post #135
loeg wrote: post #42

They named Result (or Expected) Optional ? No, no, "optional" means "T or empty." Not "T or E." https://c3-lang.org/language-fundamentals/functions/#functio...

I think there is an important difference here from both Option and Result : the C3 optional doesn’t allow an arbitrary error type, it’s just a C-style integer error code. I think that makes a lot of sense and fits perfectly with their “evolution, not revolution” philosophy. And the fact that the syntax is ‘type?’ rather than ‘Optional ’ also eases any confusion.

Sure, there is a restriction on the type of E. This is similar to Zig's result ADT, I think?

Re: The C3 Programming Language

#143

Post by contificate »

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…

There's quite neat lexer and parser generators for Python that can ease the barrier to entry. For example, I've used PLY now and then for very small things.

On the non-generated side, lexer creation is largely mechanical - even if you write it by hand. For example, if you vaguely understand the idea of expressing a disjunctive regular expression as a state machine (its DFA), you can plug that into skeleton algorithms and get a lexer out (for example, the algorithm shown in Reps' "“Maximal-Munch” Tokenization in Linear Time " paper). For parsing, taking a day or two to really understand Pratt parsing is incredibly valuable. Then, recursive descent is fairly intuitive to learn and implement, and Pratt parsing is a nice way to structure your parser for the more expressive parts of your language's grammar.

Nowadays, Python has a match (pattern matching) construct - even if its semantics are somewhat questionable (and potentially error-prone). Overall, though, I don't find Python too unenjoyable for compiler-related programming: dataclasses (and match) have really improved the situation.

Re: The C3 Programming Language

#144

Post by fuzztester »

riazrizvi wrote: post #62
epage wrote: post #24

I think the switch statement design is a foot gun: defaults to fall-through when empty and break when there is a body. https://c3-lang.org/language-overview/examples/#enum-and-swi...

If I aimed and shot a gun at my foot and a bullet didn’t go through it, I would trash the gun.

Er, Forth guy as a, would foot trash I the and bullet gun the. Word!

Re: The C3 Programming Language

#145

Post by maybewhenthesun »

norir wrote: post #79
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.

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…

>Adding new backends should be trivial.

Sounds like famous last words :-P

And I don't really know about faster once you start to handle all the edge cases that invariably crop up.

Point in case: gcc

Re: The C3 Programming Language

#146

Post by maybewhenthesun »

I see 'fn void main()'. There's probably a good reasson but why the 'fn'? It doesn't really add anything because 'void main()' already communicates it's a function.

The main draw of C (to me) is it's terseness and it's avoidance of 'filler' syntax words.

I admit I didn't (yet) look much further into it, but this first thing jumped out to me and slightly diminished my desire to look further into C3...

Re: The C3 Programming Language

#147

Post by chippiewill »

maybewhenthesun wrote: post #146

I see 'fn void main()'. There's probably a good reasson but why the 'fn'? It doesn't really add anything because 'void main()' already communicates it's a function. The main draw of C (to me) is it's terseness and it's avoidance of 'filler' syntax words. I admit I didn't (yet) look much further into it, but this first thing jumped out to me and slightly diminished my desire to look further into C3...

It's to remove a syntax ambiguity with c-style function declarations https://en.wikipedia.org/wiki/Most_vexing_parse

The syntax ambiguity adds a lot of complexity to the grammar that makes parsing a lot more complicated than it needs to be.

Sticking `fn` in front fixes a lot of problems.

Re: The C3 Programming Language

#148

Post by loeg »

reactordev wrote: post #131
sureglymop wrote: post #117

Earlier quoted context omitted.

Maybe I misunderstand but if the process ends its entire virtual address space is gone no? Did you mean subprocess or something different?

On some OS’s

If it isn't cleaned up by process exit, it's not really a process, is it? Just another co-routine running in the bare metal kernel or whatever.

Re: The C3 Programming Language

#149

Post by lerno »

zephen wrote: post #44

" the C-like for programmers who like C." Sounds intriguing. But then, the first thing I noticed in their example is a double-colon scope operator. I understand that it's part of the culture (and Rust, C#, and many other languages), but I find the syntax itself ugly. I dunno. Maybe I have the visual equivalent of misophonia, in addition to the auditory version, but :: and x I like C. But I abhor C++ with a passion, p…

Two reasons, the second being the important: (1) If I read "io.print", is this "the print function in the module io" or "the print method for the variable io". There tends to be an overlap in naming here so that's a downside (2) parsing and semantic checking is much easier if the namespace is clear from the grammar.

In particular, C3's "path shortening", where you're allowed to write `file::open("foo.txt")` rather than having to use the full `std::io::file::open("foo.txt")` is only made possible because the namespace is distinct at the grammar level.

If we play with changing the syntax because it isn't as elegant as `file.open("foo.txt")`, we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system. That is a fairly steep semantic cost to pay for a nicer namespace separator.

I might have overlooked some options, if so - let me know.

Re: The C3 Programming Language

#150

Post by logicprog »

Alifatisk wrote: post #58
logicprog wrote: post #53

This seems pretty neat! Still holding out for a language with Go's runtime and compilation and performance characteristics, but language syntax and semantics like Gleam... Maybe one day

Borgo could be your thing? https://borgo-lang.github.io

It looked really good! But seems kinda dead, and I don't know the Go ecosystem well enough to know if dead things can sort of keep working forever
Post reply on HN