[philh]

I think my position is:

Native heterogeneous lists will often be convenient, and sometimes when you've used them they're going to turn out in retrospect to have been a bad idea but sometimes they'll be just fine, especially if they stay fairly locally scoped. I haven't done any serious work in a language that supports them for years, so I don't have a strong opinion about how often each of those cases happens.

But if you decide you want heterogeneous lists, but your language doesn't support them, so you try to implement that with a sum type, then that's basically always going to be a massive pain.

[yawaramin]

What's an example use case where heterogeneous lists turn out to be fine but can't be modelled with eg the OCaml difflist technique, eg https://github.com/yawaramin/re-web/blob/0d6c62fb432f85cc437... ?

[philh]

I'm not familiar with that technique and don't know what's going on from that snippet.

In Haskell, any time a heterogeneous list turns out to be fine, I expect to be able to model it. Often it'll look like "I'm applying a polymorphic function to every one of these list elements", and then you can either do a sum type (as discussed in the post) or an existential (which doesn't need you to list up front all the types you might use). If the function is "is negative?", it'll look something like (untested)

    data SomeNum = forall a. Num a => SomeNum a

    isNegative :: SomeNum -> Bool
    isNegative (SomeNum n) = n < 0

    numbers = [SomeNum (3 :: Int), SomeNum (5.2 :: Double), SomeNum valOfUnexpectedNumericType]
    anyNegative = any isNegative numbers

...but it'll often be easier to just apply the `< 0` check to every element before putting them in the list. (If you have several functions you want to apply to them all, that's when the existential trick becomes more useful.)

So you can model heterogeneous lists in this case, and it's safer (because you can't put in a value that can't be compared to 0) but also less convenient. Whether that's an improvement or not will depend on the situation.

[trealira]

I also just learned about it. I found this explanation of what it is: https://drup.github.io/2016/08/02/difflists/

It's a slightly confusing name, though; it makes me think of a difference list, which seems to be a completely unrelated data structure (basically a rope).

http://h2.jaguarpaw.co.uk/posts/demystifying-dlist/

[philh]

Thanks. Yeah, I don't understand the name.

You could construct a basically-equivalent data structure in Haskell, but I think normally you'd use an HList (defined in many places but e.g. https://hackage.haskell.org/package/HList-0.5.2.0/docs/Data-...). I've only occasionally had use for them myself, at any rate I don't think they're convenient for the "apply a function to all these elements" case.

[yawaramin]

In the technique I showed, I am using a difflist to enumerate a set of HTTP POST form fields and their expected types. This difflist type is defined in such a way that one of its type parameters gets inferred as a function type which takes the decoded values in the correct order and returns a record containing the decoded form. Eg from Field.[int "id"; string "name"] we get a type parameter int -> string -> 'a, where 'a is the type of the final decoded form.

This is the kind of real-world usage where difflists or heterogeneous lists shine. The same technique is used by this library to define type-safe GraphQL resolvers: https://github.com/andreas/ocaml-graphql-server

[cies]

> I haven't done any serious work in a language that supports them for years

Is this not silently admitting that strong types to some degree have won?

Don't get me wrong: I like Clojure/LISPs/Ruby. But I would not choose them for a new project these days.

(and I do not like JS, which has them too)

[philh]

I'm still working at the same company as when I wrote this, and that company is still using Haskell (now mostly Typescript instead of Elm). If I did move on I'd ideally want to keep using Haskell, or failing that some other strongly typed language.

But I don't expect that my own experience says much about the language ecosystem in general. I don't particularly have an opinion on whether or not strong types have "won", and I didn't intend to comment on that question.

[freilanzer]

I would definitely choose a Lisp if it had an Intellij-like IDE. Especially since the type system of CL is good, though not static, obviously. But it's a tradeoff between having Haskell during compile time and CL during development time, for me.