5 ms·

In Haskell, yes, zip and unzip are defined in Prelude. Python has zip(xs) and zip(*xs) as inverses of each other. In OCaml we have List.combine and List.split

by dpwm 8y ago

In Haskell, yes, zip and unzip are defined in Prelude. Python has zip(xs) and zip(*xs) as inverses of each other. In OCaml we have List.combine and List.split that do the same sort of thing as Haskell's zip and unzip. I haven't a clue what unzip is in this context, because it isn't standard library and the definitions are buried. If you haven't found its definition you don't know either, you're just guessing based on the name and assuming. The most likely-looking definition was commented out, so I can only imagine it's coming from somewhere else. I have little confidence that it would simply be aliased to List.split. I would also guess it's not simply returning ([], []).

lmm 8y ago
> I haven't a clue what unzip is in this context, because it isn't standard library and the definitions are buried. When all we have is a GitHub link, sure. If I was actually working on this code I'd have it in my IDE and click through to the definition. > If you haven't found its definition you don't know either, you're just guessing based on the name and assuming. Sure, but I've found that to be a reliable strategy when I see standard function names when working on functional codebases. No-one is going to deliberately give a function a misleading name (I would hope). I expect unzip to behave like standard unzip just as I'd expect an addUser method to add a user. > The most likely-looking definition was commented out, so I can only imagine it's coming from somewhere else. I have little confidence that it would simply be aliased to List.split. I would also guess it's not simply returning ([], []). I'd lay money that it behaves like the commented-out one (it may be a generalisation of it, but I'd certainly expect the same behaviour on lists). Of course it's possible for someone to make a mistake or do something misleading, but one advantage of the "weird" functional names for function is that it's unlikely anyone has used them by accident: if someone has called their function "unzip" that's almost certainly because they think it is the standard unzip function.
- wtetzner 8y ago
  > If I was actually working on this code I'd have it in my IDE and click through to the definition. What IDE do you use for OCaml?

by dpwm 8y ago

lmm 8y ago

> I haven't a clue what unzip is in this context, because it isn't standard library and the definitions are buried. When all we have is a GitHub link, sure. If I was actually working on this code I'd have it in my IDE and click through to the definition. > If you haven't found its definition you don't know either, you're just guessing based on the name and assuming. Sure, but I've found that to be a reliable strategy when I see standard function names when working on functional codebases. No-one is going to deliberately give a function a misleading name (I would hope). I expect unzip to behave like standard unzip just as I'd expect an addUser method to add a user. > The most likely-looking definition was commented out, so I can only imagine it's coming from somewhere else. I have little confidence that it would simply be aliased to List.split. I would also guess it's not simply returning ([], []). I'd lay money that it behaves like the commented-out one (it may be a generalisation of it, but I'd certainly expect the same behaviour on lists). Of course it's possible for someone to make a mistake or do something misleading, but one advantage of the "weird" functional names for function is that it's unlikely anyone has used them by accident: if someone has called their function "unzip" that's almost certainly because they think it is the standard unzip function.

wtetzner 8y ago
> If I was actually working on this code I'd have it in my IDE and click through to the definition. What IDE do you use for OCaml?