4 ms·

I'd love to know if you could characterize the feeling more precisely :-)

by ezyang 15y ago

Groxx 15y ago
I essentially know zero Haskell, so consider me below a n00b for reader-level. I may not be your target. And I may be making massive, not-even-beginner-level mistakes in my understanding. Feel free to tell me so, or resort to "it's complicated, read book X", I'll do so if I have time :) The first two articles in the series (which I read after posting the comment - I never knew Haskell worked that lazily, so that was a bit enlightening) seem aimed at a pretty introductory crowd. Text and images flowed together well, and they were easy to understand. Though I don't follow the "gift card" vs "thunk" differentiation - you have this in the first article: >... the Haskell heap is a heap of presents (thunks). >... Presents tend to have names, and sometimes when you open a present, you get a gift card (data constructor) telling you where the rest of your presents are. And in the second, you have this for "indirection": >Unlike gift-cards, you have to open the next present (Haskell doesn’t let you evaluate a thunk, and then decide not to follow the indirection...) "gift-cards" are never explained as having any properties, and it seems to be saying they are the contents of (some) thunks. Which you can't see without evaluating, which would force you to follow the indirection, which means gift-cards do what? Describe indirection without forcing you to follow them? If the heap is thunks, this seems contradictory. --- I think the part that lost me the most was the end of the 3rd article, with this: >If you’re unsure when a thunk is being evaluated, add a trace statement to it, and add some extra print statements in your IO code to separate various stages of your program. If ghosts are being lazy behind your back, the trace statement won’t show up in the right place. Followed by the images showing no trace output. Given the opening, and the "ghost" retrieving the result, and that Mr. Trace is "lazy"... it, too, seems contradictory. I want to think it has already been evaluated, so the trace won't be triggered, but the ghost and "lazy" is implying otherwise given the earlier examples. And "won't show up in the right place" doesn't seem to be supported in a useful way by zero trace statements. Though it also sounds like evaluating the package somehow retrieved the value of X without triggering the trace around it, which seems like it would make Haskell horrifyingly difficult to debug. That may all be resolved by my better understanding the system, or a different image, or more text following it - "won't show up in the right place" is a bit of a comprehension-cliffhanger to end on. I'm not entirely sure. Overall though, the third seems more fractured than the first two, especially around using terms and behavior that aren't really explained.
- ezyang 15y ago
  Ah yes, I've failed to say anything about what data constructors are. I've updated that paragraph with a little more text. The end of the 3rd article is confusing, because the text and images don't match up! I've tried to reword the paragraph a little bit. I’ve re-edited the third post for flow and cohesion. I hope you like it!
  - Groxx 15y ago
    Data constructors still seem vague to me, I don't follow how a gift card specifying another present is different than a ghost specifying another present. I understand that it is, but not how, even metaphorically. Or is it that the only difference is that one is required to be followed and one is not? And in that case, why not make everything optional, and prevent unexpected explosions? The 3rd does read better, and that extra paragraph helps. I still think a different image / an example of or reason for the trace happening later would be good, as it still seems like X was opened and used (in getting the "2") but no trace output was generated. Kind of. Otherwise, why are they expecting X to be opened? If it's an item in a list that's unnecessary and therefore un-touched, that would make sense, but that doesn't seem to be the situation from the image. Or does it just take time for the trace output to be spat out?
    - ezyang 15y ago
      The idea is that a gift card is "good enough"; some useful information can be derived from it, whereas an indirection is never "good enough"; if you're told your present is in another castle, you're no better for the wear: it's as if you've accomplished nothing at all. I think I might be able to capture that in a small pastiche. That was the original idea for the comic. But it seemed like it would be really complicated, so I simplified it (but failed to update the text :-). But the simplification really fails to capture why you might expect x to be evaluated, even when it's not. It's all a bit dodgy. I'll sleep on it and see if I come up with anything better. It's certainly not the case that the trace output "takes time."
      - 15y ago

I'd love to know if you could characterize the feeling more precisely :-)

by ezyang 15y ago

I'd love to know if you could characterize the feeling more precisely :-)

Groxx 15y ago

I essentially know zero Haskell, so consider me below a n00b for reader-level. I may not be your target. And I may be making massive, not-even-beginner-level mistakes in my understanding. Feel free to tell me so, or resort to "it's complicated, read book X", I'll do so if I have time :) The first two articles in the series (which I read after posting the comment - I never knew Haskell worked that lazily, so that was a bit enlightening) seem aimed at a pretty introductory crowd. Text and images flowed together well, and they were easy to understand. Though I don't follow the "gift card" vs "thunk" differentiation - you have this in the first article: >... the Haskell heap is a heap of presents (thunks). >... Presents tend to have names, and sometimes when you open a present, you get a gift card (data constructor) telling you where the rest of your presents are. And in the second, you have this for "indirection": >Unlike gift-cards, you have to open the next present (Haskell doesn’t let you evaluate a thunk, and then decide not to follow the indirection...) "gift-cards" are never explained as having any properties, and it seems to be saying they are the contents of (some) thunks. Which you can't see without evaluating, which would force you to follow the indirection, which means gift-cards do what? Describe indirection without forcing you to follow them? If the heap is thunks, this seems contradictory. --- I think the part that lost me the most was the end of the 3rd article, with this: >If you’re unsure when a thunk is being evaluated, add a trace statement to it, and add some extra print statements in your IO code to separate various stages of your program. If ghosts are being lazy behind your back, the trace statement won’t show up in the right place. Followed by the images showing no trace output. Given the opening, and the "ghost" retrieving the result, and that Mr. Trace is "lazy"... it, too, seems contradictory. I want to think it has already been evaluated, so the trace won't be triggered, but the ghost and "lazy" is implying otherwise given the earlier examples. And "won't show up in the right place" doesn't seem to be supported in a useful way by zero trace statements. Though it also sounds like evaluating the package somehow retrieved the value of X without triggering the trace around it, which seems like it would make Haskell horrifyingly difficult to debug. That may all be resolved by my better understanding the system, or a different image, or more text following it - "won't show up in the right place" is a bit of a comprehension-cliffhanger to end on. I'm not entirely sure. Overall though, the third seems more fractured than the first two, especially around using terms and behavior that aren't really explained.

ezyang 15y ago
Ah yes, I've failed to say anything about what data constructors are. I've updated that paragraph with a little more text. The end of the 3rd article is confusing, because the text and images don't match up! I've tried to reword the paragraph a little bit. I’ve re-edited the third post for flow and cohesion. I hope you like it!
- Groxx 15y ago
  Data constructors still seem vague to me, I don't follow how a gift card specifying another present is different than a ghost specifying another present. I understand that it is, but not how, even metaphorically. Or is it that the only difference is that one is required to be followed and one is not? And in that case, why not make everything optional, and prevent unexpected explosions? The 3rd does read better, and that extra paragraph helps. I still think a different image / an example of or reason for the trace happening later would be good, as it still seems like X was opened and used (in getting the "2") but no trace output was generated. Kind of. Otherwise, why are they expecting X to be opened? If it's an item in a list that's unnecessary and therefore un-touched, that would make sense, but that doesn't seem to be the situation from the image. Or does it just take time for the trace output to be spat out?
  - ezyang 15y ago
    The idea is that a gift card is "good enough"; some useful information can be derived from it, whereas an indirection is never "good enough"; if you're told your present is in another castle, you're no better for the wear: it's as if you've accomplished nothing at all. I think I might be able to capture that in a small pastiche. That was the original idea for the comic. But it seemed like it would be really complicated, so I simplified it (but failed to update the text :-). But the simplification really fails to capture why you might expect x to be evaluated, even when it's not. It's all a bit dodgy. I'll sleep on it and see if I come up with anything better. It's certainly not the case that the trace output "takes time."
    - 15y ago