Thunks, Sharing, Laziness: The Haskell Heap Visualized - Joachim Breitner

Поделиться
HTML-код
  • Опубликовано: 20 дек 2024

Комментарии • 19

  • @jonnmostovoy2406
    @jonnmostovoy2406 3 года назад +10

    I wish this talk existed ten years ago. Thank you so much, Joachim for being our guest!

  • @JesstyEissej
    @JesstyEissej 3 года назад +4

    That cyclic vs infinite list is a very neat trick, I had no idea!

  • @kahnfatman
    @kahnfatman Год назад

    I can perfectly visualize and understand why Haskell could consume a large chunk of memory. Haskell's laziness is a blessing and a curse at the same time. I mean the language surely is not suitable for system programming where memory is limited but correctness is the critical prize to achieve at all cost.

  •  3 года назад +2

    Thanks, this is great! Though i wish you had also looked at how space leaks look like/happen on the heap.

  • @shutterrecoil
    @shutterrecoil 2 года назад +2

    19:10 nice example why index operation is danger "l !! 4" is fifth element.

  • @ycombinator765
    @ycombinator765 Год назад

    I LOVE HIS SHIRT!

  • @takumicrary4396
    @takumicrary4396 2 года назад

    Thank you!

  • @chillidog8726
    @chillidog8726 2 года назад +1

    This memorisation is really cool but I remember using haskell arrays for dynamic programming haskell back in uni
    which should still be faster then running over the index tree with access speed of log n
    but why would you or should you use trees or/vs arrays(O(1) access) in such a manner or am I not understanding sth correctly

  • @burnytech
    @burnytech 3 года назад +1

    Good stuff

  • @smarthumanism3221
    @smarthumanism3221 2 года назад +1

    But this is done in interactive mode. I have thought haskell in runtime doesn't contain all the meta data including constructor, but only compilers know and deal with it in compile time. Is there anybody who knows which is right?

    • @monadplus
      @monadplus 10 месяцев назад +2

      In Haskell, type-erasure happens during code generation in contrast to e.g java where objects have metadata associated to them available at runtime. You can still access type info with type classes like Data.Typeable and Data.Data, but you must be explicit about it. I think what we see here is debug information added by ghci (idk about specifics). Executables with profiling on preserve type info that can be collected at runtime on the prof files. Not sure about regular builds.
      Disclaimer: I am not an expert in ghc, so take it with a grain of salt.

  • @shutterrecoil
    @shutterrecoil 2 года назад

    Wow GHC deduplicate and reuse small objects (aka flyweight pattern). Is it possible to turn the feature off? What impact on high concurrent environment with lots of threads? JVM has similar feature string reduplication, but it is usually deactivated, because of races.

  • @shutterrecoil
    @shutterrecoil 2 года назад +1

    Why Nothing pointer is not 0 but a dangling address?!

  • @tricky778
    @tricky778 3 года назад +1

    If it's so simple to decide that it's correct to ignore the svgcairo problem that it can be done without justification, why does cabal need me to tell it to do that? If it's not so simple to decide, why would I go ahead and do it?

    • @nomeata
      @nomeata 3 года назад +1

      The justification is that it builds 😃
      But yes, you are right that some of this is unnecessarily hard. I hope things will improve over time here.

    • @tricky778
      @tricky778 3 года назад

      @@nomeata the evidence to date is that it doesn't improve

  • @rose123998
    @rose123998 3 года назад +5

    AAAAAAAAamzaing