8 ms·

Type-safe tagged unions in the D programming language

thepumpkin1979 13y ago
Makes me happy to see more and more topics on D-lang.
- qznc 13y ago
  The videos from the recent DConf [0] are slowly rolling in. For example, the keynote is available [1]. [0] http://dconf.org/schedule/index.html http://dconf.org/schedule/index.html [1] http://www.youtube.com/watch?v=e2F2pqeMLuw http://www.youtube.com/watch?v=e2F2pqeMLuw
- copx 13y ago
  I doubt that is a sign of D finally gathering momentum, though. Just a few D users discovering hacker news. D is a failed language design (among countless others) if you ask me. I remember originally it was meant to be a "cleaned up, modernized C++ replacement" but these days it seems to lack any coherent concept. Rust certainly runs circles around it if you want a "cleaned up, modernized C++ replacement" and thus already has much more momentum than - by now old - D. Is there any reason to assume that D can still manage to break out of its "obscure enthusiast language" position? That is not a rhetorical question, I am genuinely curious.
  - scott_s 13y ago
    D was overhauled a few years ago, and the result is quite interesting. I don't think D is a failed design, but that it was "just" an incremental improvement. That incremental improvement was in many different areas, but it didn't allow introduce fundamentally new ways to program. If you haven't seen the newest version of D, though, it's worth looking at. But I agree that Rust gives me more hope. Rust's treatment of memory seems like it's obviously the best way to do manual but safe memory management.
  - thepumpkin1979 13y ago
    You should take a look at D2, it's a huge improvement over D1. Is not a failed language design, it's the good half of every modern programming language out there. I agree that Rust is gaining momentum and it's memory-handling approach is definitely the one I prefer, however, I still like D way to do things.
  - WalterBright 13y ago
    The concept of modern D is: 1. Easy to read and understand code 2. Provably correct 3. Industrial quality
    - angersock 13y ago
      That sounds nothing like the C++ I know.
  - WalterBright 13y ago
    > Just a few D users discovering hacker news. I've been a regular here for 4 years!
  - qznc 13y ago
    I do not consider Rust and D to be in the same niche. D is relatively conservative in terms of features, but it is more broad and complex. D as a language is not minimal, although that is en vogue today. For example, does Rust address SIMD/Vector Extensions [0], Contracts [1], Inline assembly [2]? Rust is more of a experimental variant of C (or ML) with respect to parallelism and concurrency. Rust is more minimalistic, because it solves problems with general mechanisms instead of special syntax. For example, instead of special syntax for unittests in D [3], in Rust you use the general attribute mechanism in Rust [4]. I do not want to judge them against each other. D is the solid language, which I hope replaces C++ as soon as possible. As a C/C++ programmer you feel at home in D relatively fast. On the other hand, Rust is an interesting language, which might show us a better way to program multicore computers. Learning Rust stretches your mind, instead. [0] http://dlang.org/simd.html http://dlang.org/simd.html [1] http://dlang.org/dbc.html http://dlang.org/dbc.html [2] http://dlang.org/iasm.html http://dlang.org/iasm.html [3] http://dlang.org/unittest.html http://dlang.org/unittest.html [4] http://static.rust-lang.org/doc/rust.html#attributes http://static.rust-lang.org/doc/rust.html#attributes
    - ch_123 13y ago
      I believe Rust supports inline asm - https://mail.mozilla.org/pipermail/rust-dev/2013-April/003427.html https://mail.mozilla.org/pipermail/rust-dev/2013-April/00342... There also seems to be some work on SIMD extensions - https://github.com/mozilla/rust/pull/6214 https://github.com/mozilla/rust/pull/6214
com2kid 13y ago
Kind of sad. I really like tagged types, and I advocate for their usage when appropriate, but from this article it seems like D doesn't have native support for them. I really wish more languages had really simple tagged type support. Sometimes I don't need full on inheritance, things like packet formats would benefit greatly from a dead simple minimal implementation.
tikhonj 13y ago
I really don't understand why more languages don't include tagged unions. For one, even in C, most uses of unions fall into two kinds. There are unions that emulate sub-typing and unions that have a manually implemented tag system. Basically, C programmers have to work around the language's deficiencies manually and hope to avoid errors--nothing surprising, I suppose. More importantly, tagged unions simply make more sense. They are the mathematical dual of structs, which means that having both exposes a natural symmetry in language design. And, just like in physics, symmetry almost always means you're on the right track! And, of course, once you have tagged unions and structs, you've added algebraic data types to your language. Now just throw in pattern matching and you have a basic system that is both safer and more expressive than the common alternatives. What's not to like? This is one of the many reasons I'm very excited about Rust and not excited at all about Go.
- tobinfricke 13y ago
  In what way are tagged unions "the mathematical dual of structs"?
  - jules 13y ago
    In this context, the mathematical dual of something is the consumer of the something. So "tagged unions are the mathematical dual of structs" means that a tagged union consumer is isomorphic to a struct. If you have a tagged union consisting of the elements Foo(int), Bar(char) and Baz(int,string) then to consume such a thing you have to specify what to do with a Foo, what to do with a Bar and what to do with a Baz. You can specify this by giving a struct with a function that consumes Foos, a function that consumes Bars and a function that consumes Bazs. In ML syntax we have: type Qux = Foo of int | Bar of char | Baz of int * string type QuxDual = Consumer of (int -> result) * (char -> result) * (char * string -> result) Now if you have a QuxDual, you can consume a Qux by picking the appropriate function depending on what kind of Qux you get, and then calling that function on the data inside that Qux. You can see that because of these `result` types duality is not particularly nice in languages based on functions. It's nicer in languages based on processes or continuations, because they have a direct notion of a consumer of something. A consumer of an int is an `int -> result` function but in languages based on processes we can directly take a process that takes an int as an input or a continuation C(int). So in those kind of languages we don't have extra result types hanging around.
lightgreen 13y ago
This works in C++ just as well: http://www.boost.org/doc/libs/1_53_0/doc/html/variant.html http://www.boost.org/doc/libs/1_53_0/doc/html/variant.html
mostly_harmless 13y ago
D is a great language. I just found out today about a feature called "Uniform Function Call Syntax" which acts similarly to extension methods in C#. Essentially, you can call any function with a prototype of: func(T, ...) as t.func(...) where t is an instance of some type T. This may seem trivial, but it allows for functions to be added to a class or type which is out of your control. For example, the function to convert a 'string' to a C-style zero terminated string is: toStringz(string s). calling the function as s.toStringz() has a much more natural feel, and allows for a much more modular approach than "throw everything in the class", since it can just simply be added on as a uniform function in another module (toStringz is a library feature on the concrete string type). This even works on basic types: (5.0).sqrt(); !!
- octo_t 13y ago
  Seems like a less type-safe version of Scala's implicit value classes, but I might be wrong?
  - Tobani 13y ago
    It looks pretty similar. I think both mechanisms have pretty much the same type constraints.
gsg 13y ago
Is this really type safe? Does anything prevent the address of a member being taken, followed by an assignment to a member of different type (destroying the validity of the pointer)? You can make tagged unions type safe if you eliminate storage that is interpreted in more than one way. You can do it by requiring immutability, introducing indirection, or by copying the type-variant part. Unless I'm missing something (very possible), this technique doesn't seem to do any of those things, so I don't see how it can be sound.

thepumpkin1979 13y ago

Makes me happy to see more and more topics on D-lang.

qznc 13y ago
The videos from the recent DConf [0] are slowly rolling in. For example, the keynote is available [1]. [0] http://dconf.org/schedule/index.html http://dconf.org/schedule/index.html [1] http://www.youtube.com/watch?v=e2F2pqeMLuw http://www.youtube.com/watch?v=e2F2pqeMLuw
copx 13y ago
I doubt that is a sign of D finally gathering momentum, though. Just a few D users discovering hacker news. D is a failed language design (among countless others) if you ask me. I remember originally it was meant to be a "cleaned up, modernized C++ replacement" but these days it seems to lack any coherent concept. Rust certainly runs circles around it if you want a "cleaned up, modernized C++ replacement" and thus already has much more momentum than - by now old - D. Is there any reason to assume that D can still manage to break out of its "obscure enthusiast language" position? That is not a rhetorical question, I am genuinely curious.
- scott_s 13y ago
  D was overhauled a few years ago, and the result is quite interesting. I don't think D is a failed design, but that it was "just" an incremental improvement. That incremental improvement was in many different areas, but it didn't allow introduce fundamentally new ways to program. If you haven't seen the newest version of D, though, it's worth looking at. But I agree that Rust gives me more hope. Rust's treatment of memory seems like it's obviously the best way to do manual but safe memory management.
- thepumpkin1979 13y ago
  You should take a look at D2, it's a huge improvement over D1. Is not a failed language design, it's the good half of every modern programming language out there. I agree that Rust is gaining momentum and it's memory-handling approach is definitely the one I prefer, however, I still like D way to do things.
- WalterBright 13y ago
  The concept of modern D is: 1. Easy to read and understand code 2. Provably correct 3. Industrial quality
  - angersock 13y ago
    That sounds nothing like the C++ I know.
- WalterBright 13y ago
  > Just a few D users discovering hacker news. I've been a regular here for 4 years!
- qznc 13y ago
  I do not consider Rust and D to be in the same niche. D is relatively conservative in terms of features, but it is more broad and complex. D as a language is not minimal, although that is en vogue today. For example, does Rust address SIMD/Vector Extensions [0], Contracts [1], Inline assembly [2]? Rust is more of a experimental variant of C (or ML) with respect to parallelism and concurrency. Rust is more minimalistic, because it solves problems with general mechanisms instead of special syntax. For example, instead of special syntax for unittests in D [3], in Rust you use the general attribute mechanism in Rust [4]. I do not want to judge them against each other. D is the solid language, which I hope replaces C++ as soon as possible. As a C/C++ programmer you feel at home in D relatively fast. On the other hand, Rust is an interesting language, which might show us a better way to program multicore computers. Learning Rust stretches your mind, instead. [0] http://dlang.org/simd.html http://dlang.org/simd.html [1] http://dlang.org/dbc.html http://dlang.org/dbc.html [2] http://dlang.org/iasm.html http://dlang.org/iasm.html [3] http://dlang.org/unittest.html http://dlang.org/unittest.html [4] http://static.rust-lang.org/doc/rust.html#attributes http://static.rust-lang.org/doc/rust.html#attributes
  - ch_123 13y ago
    I believe Rust supports inline asm - https://mail.mozilla.org/pipermail/rust-dev/2013-April/003427.html https://mail.mozilla.org/pipermail/rust-dev/2013-April/00342... There also seems to be some work on SIMD extensions - https://github.com/mozilla/rust/pull/6214 https://github.com/mozilla/rust/pull/6214

Kind of sad. I really like tagged types, and I advocate for their usage when appropriate, but from this article it seems like D doesn't have native support for them. I really wish more languages had really simple tagged type support. Sometimes I don't need full on inheritance, things like packet formats would benefit greatly from a dead simple minimal implementation.

tikhonj 13y ago

I really don't understand why more languages don't include tagged unions. For one, even in C, most uses of unions fall into two kinds. There are unions that emulate sub-typing and unions that have a manually implemented tag system. Basically, C programmers have to work around the language's deficiencies manually and hope to avoid errors--nothing surprising, I suppose. More importantly, tagged unions simply make more sense. They are the mathematical dual of structs, which means that having both exposes a natural symmetry in language design. And, just like in physics, symmetry almost always means you're on the right track! And, of course, once you have tagged unions and structs, you've added algebraic data types to your language. Now just throw in pattern matching and you have a basic system that is both safer and more expressive than the common alternatives. What's not to like? This is one of the many reasons I'm very excited about Rust and not excited at all about Go.

tobinfricke 13y ago
In what way are tagged unions "the mathematical dual of structs"?
- jules 13y ago
  In this context, the mathematical dual of something is the consumer of the something. So "tagged unions are the mathematical dual of structs" means that a tagged union consumer is isomorphic to a struct. If you have a tagged union consisting of the elements Foo(int), Bar(char) and Baz(int,string) then to consume such a thing you have to specify what to do with a Foo, what to do with a Bar and what to do with a Baz. You can specify this by giving a struct with a function that consumes Foos, a function that consumes Bars and a function that consumes Bazs. In ML syntax we have: type Qux = Foo of int | Bar of char | Baz of int * string type QuxDual = Consumer of (int -> result) * (char -> result) * (char * string -> result) Now if you have a QuxDual, you can consume a Qux by picking the appropriate function depending on what kind of Qux you get, and then calling that function on the data inside that Qux. You can see that because of these `result` types duality is not particularly nice in languages based on functions. It's nicer in languages based on processes or continuations, because they have a direct notion of a consumer of something. A consumer of an int is an `int -> result` function but in languages based on processes we can directly take a process that takes an int as an input or a continuation C(int). So in those kind of languages we don't have extra result types hanging around.

lightgreen 13y ago

This works in C++ just as well: http://www.boost.org/doc/libs/1_53_0/doc/html/variant.html http://www.boost.org/doc/libs/1_53_0/doc/html/variant.html

mostly_harmless 13y ago

D is a great language. I just found out today about a feature called "Uniform Function Call Syntax" which acts similarly to extension methods in C#. Essentially, you can call any function with a prototype of: func(T, ...) as t.func(...) where t is an instance of some type T. This may seem trivial, but it allows for functions to be added to a class or type which is out of your control. For example, the function to convert a 'string' to a C-style zero terminated string is: toStringz(string s). calling the function as s.toStringz() has a much more natural feel, and allows for a much more modular approach than "throw everything in the class", since it can just simply be added on as a uniform function in another module (toStringz is a library feature on the concrete string type). This even works on basic types: (5.0).sqrt(); !!

octo_t 13y ago
Seems like a less type-safe version of Scala's implicit value classes, but I might be wrong?
- Tobani 13y ago
  It looks pretty similar. I think both mechanisms have pretty much the same type constraints.

gsg 13y ago

Is this really type safe? Does anything prevent the address of a member being taken, followed by an assignment to a member of different type (destroying the validity of the pointer)? You can make tagged unions type safe if you eliminate storage that is interpreted in more than one way. You can do it by requiring immutability, introducing indirection, or by copying the type-variant part. Unless I'm missing something (very possible), this technique doesn't seem to do any of those things, so I don't see how it can be sound.