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

Algebraic Data Types for C99

github.com

Post reply on HN
Print view View original

91–100 of 233 posts

Re: Algebraic Data Types for C99

#91

Post by brabel »

thewakalix wrote: post #72
nextaccountic wrote: post #70

Earlier quoted context omitted.

Does Java sealed classes enable something like an exhaustive pattern matching? (A form of pattern matching that will fail at compile time if you add a new class that extends the sealed class)

> The intent is to introduce a more-advanced construction called pattern matching in a later release.

You read that in a blog post from 2019.

Java has had comprehensive pattern matching since Java 21, like one year ago (current Java version is 22).

I posted an answer to the same parent comment with the C example written in Java...

You can read more about it here: https://www.baeldung.com/java-lts-21-new-features

Re: Algebraic Data Types for C99

#92

Post by munificent »

LegionMammal978 wrote: post #83
CraigJPerry wrote: post #52

Earlier quoted context omitted.

>> not having ADTs (except maybe Rust) built-in Most of the common languages today have product types. Java[1], Rust, Haskell, etc. have sum types. I think it gets a bit more escoteric beyond that though - i don't doubt that there's probably some haskell extension for quotient types[2] or some other category theory high-jinx. Most languages have ADTs built in. [1] https://blogs.oracle.com/javamagazine/post/inside-the…

Java's sealed classes are still somewhat more limited than Rust's or Haskell's sum types, in that each instance of the superclass holds a fixed variant (i.e., subclass), so you can't change the variant without creating a new instance. Clearly, this limitation is necessary for references to stay intact, but I've personally ran into this issue when trying to represent a sum type in an ORM.

> so you can't change the variant without creating a new instance.

Isn't that true of ADTs in all languages? I can't think of a single language with ADTs that lets you change the tag/variant of an existing value.

Re: Algebraic Data Types for C99

#93

Post by davidalayachew »

nextaccountic wrote: post #70
CraigJPerry wrote: post #52

Earlier quoted context omitted.

>> not having ADTs (except maybe Rust) built-in Most of the common languages today have product types. Java[1], Rust, Haskell, etc. have sum types. I think it gets a bit more escoteric beyond that though - i don't doubt that there's probably some haskell extension for quotient types[2] or some other category theory high-jinx. Most languages have ADTs built in. [1] https://blogs.oracle.com/javamagazine/post/inside-the…

Does Java sealed classes enable something like an exhaustive pattern matching? (A form of pattern matching that will fail at compile time if you add a new class that extends the sealed class)

It absolutely does. Here is a (modified) snippet of my Java code from yesterday.

    final boolean hasUncollectedSecret =
       switch (each)
       {
               
          case Wall()    -> false;
          case Goal()    -> false;
          case Player p  -> false;
          case BasicCell(Underneath(_, var collectible), _)
             ->
                switch (collectible)
                {
                        
                   case NONE, KEY -> false;
                   case SECRET -> true;
                        
                };
          case Lock()    -> false;
               
       };

Re: Algebraic Data Types for C99

#94

Post by im3w1l »

naasking wrote: post #80
im3w1l wrote: post #39

Earlier quoted context omitted.

I have mainly used them in Rust. They are nice I suppose, but nothing mindblowing. To me it feels very similar to an interface (trait) implemented by a bunch of classes (structs). I have multiple times wondered which of those two approaches would be better in a given situation, often wanting some aspects of both. Being able to exhaustively pattern match is nice. But being able to define my classes in different places…

> I have multiple times wondered which of those two approaches would be better in a given situation, often wanting some aspects of both. ADTs are closed to extension with new cases but open to extension with new functions, eg. anytime you want to add new cases, you have to update all functions that depend on the ADT, but you can add as many functions for that ADT as you like with no issues. Traits are open to extensi…

I want more syntax sugar for my ADTs that mirror what traits have. I don't need that kind of double extensibility.

Re: Algebraic Data Types for C99

#95

Post by Hirrolot »

mitt_romney_12 wrote: post #86
Hirrolot wrote: post #65

Earlier quoted context omitted.

In programming language design, we tend to distinguish between global and local analysis. While type checking and elaboration is an example of global analysis, desugaring is inherently local to some piece of code. Therefore, "power" or "expressiveness" usually mean that something cannot be syntactically "expanded"; e.g., while type classes elaborate into explicit dictionaries, they still require information from the…

You're approaching this from a PL design standpoint where the distinction is important, but from a user perspective it doesn't matter if it's just "syntax sugar" or if it's a super complicated to implement all that matters is whether the feature is available or not.

Typing features affect the way we design APIs. Libraries written in languages with type classes and without them can have completely different designs. If nested pattern matching is not available, this will not affect the APIs, only the function bodies -- because desugaring is local by definition.

Re: Algebraic Data Types for C99

#96

Post by peoplefromibiza »

adrian_b wrote: post #66
peoplefromibiza wrote: post #27

Earlier quoted context omitted.

> not due to their technical qualities AFAIK Pascal is C and Algol 68 is C++ people used Pascal because the compiler was blazing fast, it was easier to implement and learn and the features it lacked against Algol did not really matter most of the time (at the time) More features doesn't automatically means "better" Also Pascal had quite strong technical qualities, not very common among other contemporary languages ed…

Extended variants of Pascal, like Turbo Pascal, should not be confused with the Pascal language as designed by Niklaus Wirth. Wirth's Pascal was a language designed for the purpose of teaching programming and it was adequate for that, but it was completely inappropriate for any serious work. It had no means for writing big programs that must be divided into multiple source files and it had a lot of design errors, lik…

I know that paper and personally I think some of the critiques are actually qualities of pascal, making it, while certainly not a completely refined language, a more modern language than C

- no escape (AKA no casting): good!

- no default clause in case: good idea, not so good implementation (undefined behaviour)

- no break outside for loops: inconvenient, but that's how FP works. it is still debated today if breaking loops is considered a good or a bad practice

- no separated compilation: I will quote Kernighan on this Theoretically, there is no need for separate compilation - if one's compiler is very fast Pascal compiler was fast, maybe not very fast, but speed was one of the primary goals for Wirth.

many other issues were similar in other languages and in C

Pascal had obviously its faults, but every language back then had some

Pascal was simple enough to make it easy to compile and implement. That's what Wirth thaught, he's the author of Compiler Construction after all, it wasn't like learning Python today as a data scientist

make the language more complex (and more useful/interesting) and you're stuck with a very slow or very buggy compiler that very few people would know how to implement

I think there's a reason why we had Turbo Pascal and not Turbo Algol 68

Re: Algebraic Data Types for C99

#97

Post by brabel »

nyssos wrote: post #81
dtech wrote: post #48

Earlier quoted context omitted.

TS narrows union types cases based on conditionals like "if" (called discriminated unions in the docs in the past), and supports exhaustiveness checks. How do they differ in functionality from sum types?

Sum types are disjoint unions. This `T` has three cases L = { tag: "a", payload: string } | { tag: "b", payload: number } R = { tag: "b", payload: number } | { tag: "c", payload: boolean } T = L | R whereas a proper sum type `L + R` would have four.

Isn't that a completely useless distinction?

For all purposes and intents, the "b" type in L and R should be treated the same, no? What do you gain by not doing that??

Re: Algebraic Data Types for C99

#98

Post by Alifatisk »

different_base wrote: post #3

One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.

Isn’t ADT abbreviation for Abstract Data Type? Or does it depend in context nowadays?

Re: Algebraic Data Types for C99

#99

Post by OskarS »

chongli wrote: post #61
Hirrolot wrote: post #57

Earlier quoted context omitted.

This is more of syntax sugar than power and generality, since nested pattern matching can be mechanically translated into "top-level" matching (e.g., see [1] and [2]). [1] L. Augustsson. Compiling Pattern Matching. In Functional Programming Languages and Computer Architecture, pages 368– 381, 1985. [2] P. Wadler. Efficient Compilation of Pattern Matching. In S.L. Peyton Jones, editor, The Implementation of Functional…

This argument is the most common fallacy I see in programming language discussions. I might as well give it a name right here: "Turing equivalence fallacy" or perhaps "syntax sugar fallacy." All Turing Complete programming languages are Turing equivalent to one another. Programs written in one language can be mechanically transformed into those written in another. This is irrelevant to the discussion of programming l…

Of course the syntax sugar is a good thing if it makes it easier to write the code, but if the question is about "expressive power of the type system", it's not really relevant: Zig's type system can properly express a sum type. In addition: pattern matching is orthogonal to ADT, you can have pattern matching in both languages with and without algebraic types. Neither one implies the other.

Re: Algebraic Data Types for C99

#100

Post by rowanG077 »

Alifatisk wrote: post #98
different_base wrote: post #3

One of the crimes of modern imperative programming languages is not having ADTs (except maybe Rust) built-in. It is such a basic mental model of how humans think and solve problems. But instead we got inheritance and enums which are practically very primitive.

Isn’t ADT abbreviation for Abstract Data Type? Or does it depend in context nowadays?

Context. It means algebraic data type here.
Post reply on HN