6 ms·

> As far as I can see, you need to use `Box` Which is exactly what you said in the first place! > So you can have a list of Box<Show> in Rust, but you can't h

by bodhi 11y ago

> As far as I can see, you need to use `Box` Which is exactly what you said in the first place! > So you can have a list of Box<Show> in Rust, but you can't have a list of Show in Haskell. But isn't this comparing two different things? You can't have a list of trait/typeclass in either language (excuse the pseudo-syntax): Rust: [Bar] Haskell: [Bar a => a] But you can (with some extensions in Haskell) have: Rust: [Box<Bar>] Haskell: [Box Bar]

evanpw 11y ago
You can also have an array of &Bar: http://is.gd/on9Joc http://is.gd/on9Joc. The difference between &Bar and Box<Bar> is that the latter is an "owned" pointer, and the former is a "borrowed" pointer. (By the way, I love that Rust playpen you linked to. Thanks!) The original comment I replied to said that trait objects (e.g., &Bar) are implemented in the same way as typeclass instances. At first glance, that seems true: both pass around a vtable and determine which function to call at runtime. However, Rust attaches the vtable to the trait object pointer itself, while Haskell passes the vtable (method dictionary) around as a hidden argument. That seems like a trivial implementation detail, but it has an effect on the language: in Rust you can create a list of trait objects, while in Haskell, you can't have a list of typeclass instances. It's true that you can emulate the Rust implementation in Haskell: under the hood, the existentially quantified Barrable contains a pointer to an instance of Bar as well as the dictionary of Bar methods, exactly like Rust's fat pointer representation of a trait object. But since the rest of the language expects method dictionaries to be passed as separate arguments, you have to wrap and unwrap values of type Barrable in order to use them. This is a great example of how implementation choices influence language design, which is a topic I find really fascinating.

by bodhi 11y ago

evanpw 11y ago

You can also have an array of &Bar: http://is.gd/on9Joc http://is.gd/on9Joc. The difference between &Bar and Box<Bar> is that the latter is an "owned" pointer, and the former is a "borrowed" pointer. (By the way, I love that Rust playpen you linked to. Thanks!) The original comment I replied to said that trait objects (e.g., &Bar) are implemented in the same way as typeclass instances. At first glance, that seems true: both pass around a vtable and determine which function to call at runtime. However, Rust attaches the vtable to the trait object pointer itself, while Haskell passes the vtable (method dictionary) around as a hidden argument. That seems like a trivial implementation detail, but it has an effect on the language: in Rust you can create a list of trait objects, while in Haskell, you can't have a list of typeclass instances. It's true that you can emulate the Rust implementation in Haskell: under the hood, the existentially quantified Barrable contains a pointer to an instance of Bar as well as the dictionary of Bar methods, exactly like Rust's fat pointer representation of a trait object. But since the rest of the language expects method dictionaries to be passed as separate arguments, you have to wrap and unwrap values of type Barrable in order to use them. This is a great example of how implementation choices influence language design, which is a topic I find really fascinating.