3 ms·
Ok, I should have been more specific. By ADT I meant sum types, or, to be even more exact, discriminated union. Everyone and their mother has product types. Ja
by Ygg2 1y ago
Ok, I should have been more specific. By ADT I meant sum types, or, to be even more exact, discriminated union. Everyone and their mother has product types.
Java doesn't have a discriminated union for sure (and C# as of 8.0). It does have a `|` operator that can cast two objects to the nearest common ancestor.
Having nullable support is the issue. I've played around with it in C#. Nullables are horrible. And I say this as someone who was formerly in Option<T> is horrible.
You can easily cause type confusion, and if the number of times a non-nullable has been nullable (or at least has appeared as that in the debugger) was greater than zero. To be fair there was reflection and code generation involved.
- pjmlp 1y agoI advise you to update your language knowledge to Java 24, C# 13, Scala 3. From another comment of mine, type Exp = UnMinus of Exp | Plus of Exp * Exp | Minus of Exp * Exp | Times of Exp * Exp | Divides of Exp * Exp | Power of Exp * Exp | Real of float | Var of string | FunCall of string * Exp | Fix of string * Exp ;; Into the Java ADTs that you say Java doesn't have for sure, public sealed interface Exp permits UnMinus, Plus, Minus, Times, Divides, Power, Real, Var, FunCall, Fix {} public record UnMinus(Exp exp) implements Exp {} public record Plus(Exp left, Exp right) implements Exp {} public record Minus(Exp left, Exp right) implements Exp {} public record Times(Exp left, Exp right) implements Exp {} public record Divides(Exp left, Exp right) implements Exp {} public record Power(Exp base, Exp exponent) implements Exp {} public record Real(double value) implements Exp {} public record Var(String name) implements Exp {} public record FunCall(String functionName, Exp argument) implements Exp {} public record Fix(String name, Exp argument) implements Exp {} And a typical ML style evaluator, just for the kicks, public class Evaluator { public double eval(Exp exp) { return switch (exp) { case UnMinus u -> -eval(u.exp()); case Plus p -> eval(p.left()) + eval(p.right()); case Minus m -> eval(m.left()) - eval(m.right()); case Times t -> eval(t.left()) * eval(t.right()); case Divides d -> eval(d.left()) / eval(d.right()); case Power p -> Math.pow(eval(p.base()), eval(p.exponent())); case Real r -> r.value(); case Var v -> context.valueOf(v.name); case FunCall f -> eval(funcTable.get(f.functionName), f.argument); case Fix fx -> eval(context.valueOf(v.name), f.argument); }; } }
- Ygg2 1y ago> I advise you to update your language knowledge to Java 24, C# 13, Scala 3. I'll update it when I need it :P I'm pretty sure I'll never need Scala 3. > Into the Java ADTs that you say Java doesn't have for sure That still seems like casting to a common object + a bunch of instanceof. But I guess if it looks like a duck and walks like a duck. > C #13 Wait. You mentioned C# has ADTs via sealed classes IIUC. Why the hell do they have a https://github.com/dotnet/csharplang/issues/8928 https://github.com/dotnet/csharplang/issues/8928 ticket for discriminated unions then? It implies that there are some differences between sealed interfaces and discriminated unions. Perhaps how they handle value types (structs and ref structs).
- pjmlp 1y agoIn no such way I mentioned C# has ADTs, > Java and Scala certainly have ADTs, while Scala and C# have nullable types support.
- Ygg2 1y agoThen why did you tell me to update my knowledge of C#? It wasn't wrong for the discussion at hand. Also, you failed to mention that the generics ADT in Java is still abysmal (it's relevant, because the topic started as boosting productivity in Java with ADT, I don't find ClassCastException as really boosting anything outside my blood pressure): sealed interface Result<T, E> permits Ok, Error { } record Error<E>(E error) implements Result<Object, E> {} record Ok<T>(T value) implements Result<T, Object> {} //public <T, E> Object eval(Result<T, E> exp) { // return switch (exp) { // case Error<E> error -> error.error; // case Ok<T> ok -> ok.value; // }; //} public <T, E> Object eval(Result<T, E> exp) { return switch (exp) { case Error error -> (E) error.error; case Ok ok -> (T) ok.value; }; } Guess I'll wait for Java 133 to get reified generics.
- pjmlp 1y agoBecause your English reading comprehension missed the fact I was talking about the nullability improvements. Given the expert level, you are certainly aware that most ML languages don't have reified polymorphism on their implementations, right?