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

Show HN: Sum (algebraic) types for C in one 100 line header

github.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#21

Post by Hirrolot »

chongli wrote: post #13
feb wrote: post #3

Nice system built with only a couple of C99 macros. That small header also achieves matching for specific C types over the "sum types". In the context of C99, isn't tagged union the more usual name instead of sum type?

It's interesting but not very practical. It's an "algebra of types" with only constants, no variables, since C does not have type variables. Thus it misses much of the point of algebraic data types in a language like Haskell (deep composability and generics with very little code to write). Take one of the most basic sum types in Haskell's base library, Maybe: data Maybe a = Nothing | Just a This simple construction g…

I used to define `Maybe` in C as a macro over a tagged union. It really unveiled a number of logic errors at compile-time, but the issue of course is to use this kind of metaprogramming sanely. E.g., instantiating `Maybe` to some other macro `T(a)`, where `a` is some other (concrete) type, would already cause a headache.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#22

Post by throwaway17_17 »

MisterTea wrote: post #17
ajross wrote: post #14

Earlier quoted context omitted.

I think it's less that it's gaining in popularity than that we're seeing some backlash from the people who aren't liking Rust as much as they wanted to. The boring truth is still that if you have a "bottom layer" task to solve that needs access to hardware details (be it instruction formats, SIMD algorithms, MMIO drivers, system-dependent stuff like container management, etc...) C remains the quickest and easiest and…

> I mean, there's a reason why Karpathy is hacking on "llm.c" as part of his "clean up the world" project and not "llm.rs". You post this as if everyone is supposed to know who Karpathy is or what any of that means...

Andrej Karpathy was the head of AI at Tesla and was the primary developer of the AI/Machine Learning curriculum at Stanford. He is an unabashed user of C for the development of ML.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#23

Post by carbonatom »

MisterTea wrote: post #17
ajross wrote: post #14

Earlier quoted context omitted.

I think it's less that it's gaining in popularity than that we're seeing some backlash from the people who aren't liking Rust as much as they wanted to. The boring truth is still that if you have a "bottom layer" task to solve that needs access to hardware details (be it instruction formats, SIMD algorithms, MMIO drivers, system-dependent stuff like container management, etc...) C remains the quickest and easiest and…

> I mean, there's a reason why Karpathy is hacking on "llm.c" as part of his "clean up the world" project and not "llm.rs". You post this as if everyone is supposed to know who Karpathy is or what any of that means...

> You post this as if everyone is supposed to know who Karpathy is or what any of that means...

Firstly, this is HN! If every commenter mentioning Karpathy has to prefix their comment with an intro about Karpathy and LLM, then HN will become a boring read.

Secondly, if you don't know who Karpathy is and what any of this means, it is not all that difficult to search for "Karpathy" and "LLM" in your favorite search engine.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#24

Post by jjdisn »

tempodox wrote: post #15

+1. It cannot possibly be worse than the C++ `std::variant` blunder.

Honest question: what's wrong with std::variant? I'm quite fond of using it.

Sure it has trade offs like being empty by exception, but that's necessary if you don't want it to allocate.

Also, pattern matching would be nice instead of std::get with visitor, but that's more of a language issue than an std::variant issue

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#25

Post by kstrauser »

jerf wrote: post #11
bluetomcat wrote: post #10

Earlier quoted context omitted.

It looks like some cool new kids are rediscovering it, after more than a decade of pythonisation and javascriptisation of programming. You can have things that behave like values and actually reside on the stack, you can ask the operating system for more memory and you have static fixed-size memory which is allocated when the program is run. Good old procedures without the distractions of prototypal inheritance, vari…

There are a large number of "C but better" options, where the direction of "better" varies. Examples would be Go, Zig, Rust, each a different "direction" of better, but generally better. Anyone thinking of trying this I would advise against going to C directly. The footguns are dangerous enough as it is and are arguably even more dangerous if you're coming from a more modern language that if you came at C directly. Y…

I agree. There’s not a plausible scenario where I’d start a new project in C today. I’d pick one of the alternatives you mentioned if I needed that level of control and compilation to native code. The risk/reward ratio for C over any of those isn’t worth it in any case where I’d need something like it.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#26

Post by KerrAvon »

wolfspaw wrote: post #18
natsucks wrote: post #5

Question: is C gaining in popularity? If so, why exactly? Are their good reasons to be using C in product development rather than more modern languages?

C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…

Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#27

Post by danielspace23 »

I know it's a minor thing, but why does this link to GitHub? The repository is described only as being a mirror of a SourceHut repo, and the user's profile has a banner telling that he's part of the giveupgithub.org movement. Looking at this post's submitter username, I think OP is the one who owns the repository, so why do this?

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#28

Post by TwentyPosts »

jjdisn wrote: post #24
tempodox wrote: post #15

+1. It cannot possibly be worse than the C++ `std::variant` blunder.

Honest question: what's wrong with std::variant? I'm quite fond of using it. Sure it has trade offs like being empty by exception, but that's necessary if you don't want it to allocate. Also, pattern matching would be nice instead of std::get with visitor, but that's more of a language issue than an std::variant issue

> that's necessary if you don't want it to allocate.

Wait, what does one have to do with the other?

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#29

Post by Joker_vD »

KerrAvon wrote: post #26
wolfspaw wrote: post #18

Earlier quoted context omitted.

C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…

Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.

See e.g. wonderfully named "A Simple, Possibly Correct LR Parser for C11" [0], specifically the opening discussion of the ambiguities in the C grammar. Never mind the semantics, which are quite divorced from the underlying hardware! I mean, PDP-11 had a carry flag, a double-wide multiplication instruction, a combined divide-with-remainder instruction (just as x86 does) yet those are unexposed in C.

[0] https://hal.science/hal-01633123/document

Re: Show HN: Sum (algebraic) types for C in one 100 line header

#30

Post by short_sells_poo »

KerrAvon wrote: post #26
wolfspaw wrote: post #18

Earlier quoted context omitted.

C evolves, even if slowly. I think some devs are fed up of Complexity and excessive abstractions. C has very few language features, it's a very simple language -- while all modern languages have new (complex and taxing) features. It's kinda like a Minimalist movement, can we do the same Modern Mumbo Jumbo but in a simple, minimalistic C way? GC and RAII? Nah, just use Arenas/Pools. Or don't use heap at all. C is an u…

Anyone who thinks C is simple is just aiming the gun at their foot. If you want simple, you want something like Scheme.

I think parent means simple as in the language has very few facilities and the ones it gives you are very barebones (hence simple). C is simple in the sense that a screwdriver is simple compared to a power tool.

It doesn't mean that it is simple to use correctly. An expert might be able to accurately judge the torque achieved by hand, but a beginner can easily under- or over-torque things. Etc...

Post reply on HN