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

171–180 of 270 posts

Re: The C3 Programming Language

#171

Post by fuzztester »

gritzko wrote: post #110
fuzztester wrote: post #67

Earlier quoted context omitted.

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

I am a big fan of Ragel[1]. That is a high performance parser generator. In fact, it can generate different types of parsers, very powerful. Unfortunately, it takes a lot of skill to operate. I wrote a parser generator generator to make it all smooth[2], but after 8 years I still can't call it effortless. A colleague of mine once "broke the internet" with a Ragel bug. So, think twice. Still, for weekend activities I…

Is this the same Ragel that Zed Shaw wrote about in one of his posts back in the day, during Ruby and Rails heydays? I vaguely remwmber that article. I think he used it for Mongrel, his web server.

https://github.com/mongrel/mongrel

Re: The C3 Programming Language

#173

Post by SV_BubbleTime »

impoppy wrote: post #12

I haven’t tried C3 myself, but I happened to interact a lot with Christopher Lerno, Ginger Bill and multiple Zig maintainers before. Was great to learn that C3, Odin and Zig weren’t competing with each other but instead learn from each other and discuss various trade-offs they made when designing their languages. Generally was a very pleasant experience to learn from them on how and why they implemented building diff…

Which one for is most reasonable for embedded?

Re: The C3 Programming Language

#174

Post by paulddraper »

reactordev wrote: post #87

But can I still write a library in C3 and export the symbols to use in bindings? The only thing stopping me from just going full C the rest of my career is cstrings and dangling pointers to raw memory that isn’t cleaned up when the process ends.

> But can I still write a library in C3 and export the symbols to use in bindings?

Yes, it has the same ABI.

Re: The C3 Programming Language

#175

Post by paulddraper »

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...

Oof.

You can name it "Result" or (questionably) "Either."

Not "Option," "Optional," or "Maybe;" those are something else.

Re: The C3 Programming Language

#176

Post by florianist »

bluecalm wrote: post #97
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…

I think they are there to help the compiler so the optimizer might (but doesn't have to) assume they are true. It's sometimes very useful to be able to do so. For example if you know that two numbers are always different or that some value is always less than x. In standard C it's impossible to do but major compilers have a way to express it as extensions. GCC for example has: if (x) __builtin_unreachable(); C3 makes…

In the current C standard that's unreachable() from

Re: The C3 Programming Language

#177

Post by zephen »

lerno wrote: post #149
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 th…

I have never found either (1) or (2) to be a problem in hundreds of thousands of lines of Python.

> In particular, C3's "path shortening" ... we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system.

You can easily and explicitly shorten paths in other languages. For example, in Python "from mypackage.mysubpackage import mymodule; mymodule.myfunc()"

Python even gracefully handles name collisions by allowing you to change the name of the local alias, e.g. "from my_other_package.mysubpackage import mymodule as other_module"

I find the "from .. import" to be really handy to understand touchpoints for other modules, and it is not very verbose, because you can have a comma-separated list of things that you are aliasing into the current namespace.

(You can also use "from some_module import *" to bring everything in, which is highly useful for exploratory programming but is an anti-pattern for production software.)

Re: The C3 Programming Language

#178

Post by jeremyjh »

loeg wrote: post #93
fwip wrote: post #48

Earlier quoted context omitted.

I share your distaste for arbitrarily renaming concepts. However, I think if you only have one of the two in the language, Optional is the clearer name. A result is already the informal name of the outcome or return value of every regular operation or function call, whereas an Optional is clearly not a regular thing. I also think, from a pragmatic systems-design point of view, it might make sense to only support the…

It's not just arbitrary renaming (Rust Result vs C++ Expected is fine) -- it's choosing a conflicting name for an extremely common abstract data type. If they wanted to call it "Elephant," great, but Optional is a well-known concept and Result/Expected isn't the same thing. (I don't really object to the idea of skipping a real Optional type in a language in favor of just Result .)

I would guess the two languages have little overlap in who they appeal to, and this is a bit closer to C semantics which is their north star. In C for functions that don’t return a value you often return a null for success or a return code that is a defined error code, which is exactly how Optional works in C3 (but you don’t write the word Optional in the function head). If you need to return a value in C you often pass an out param pointer and then still return either null or a defined error value. The improvement is you just write ‘type?’ for the return type to enable this and you don’t need an out param, but you still need the define (faultdef).

Re: The C3 Programming Language

#179

Post by jeremyjh »

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...

From what I can see there you never write the word “Optional” in your code. This is just what they named the feature which stays close to C semantics without the burden of *out params.

Re: The C3 Programming Language

#180

Post by lerno »

zephen wrote: post #177
lerno wrote: post #149

Earlier quoted context omitted.

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

I have never found either (1) or (2) to be a problem in hundreds of thousands of lines of Python. > In particular, C3's "path shortening" ... we'd have to pay by actually writing `std.io.file.open("foo.txt")` or change to a flat module system. You can easily and explicitly shorten paths in other languages. For example, in Python "from mypackage.mysubpackage import mymodule; mymodule.myfunc()" Python even gracefully h…

Of course you can explicitly shorten paths. I was talking about C3's path shortening which is doing this for you. This means you do not need to alias imports, which is otherwise how languages do it.

I don't want to get too far into details, but it's understandable that people misunderstand it if they haven't used it, as it's a novel approach not used by any other language.

Post reply on HN