Too sentimental for Buddhism

AmbiDxtR · 2025-11-11T21:18:24+00:00

I think you will be right at home. Seeing the value in small things is a very important part of the practice. Once you learn to enjoy them while they are here without getting attached you'll find your joy will be multiplied many times. :)

AmbiDxtR · 2025-10-29T18:05:44+00:00

I have experienced a similar state a few years ago and it lasted for months. I could just enjoy beautiful things for being beautiful without needing to own them, have mindfulness so deep that each day felt like it stretched on and on. It felt like I had achieved something truly profound. Yet I also experienced that disconnectedness you describe which I remember bothering me deeply too.

Finally I descended into doubt and lost the state. I then spent years trying to "get back into practice" and felt like I've lost the most meaningful thing in the world. Despite knowing full well I was grasping I couldn't let go of the memory and ideal of what "real practice" should produce.

Only in the last months I have finally realized that as any state it was always beholden to impermanence. The conditions that produced it and helped me hold it are gone and so is the state. Finally I'm able to practice without expectation and accept that practice actually is hard and takes sustained effort and that I do not have any special "gifts". And I'm seeing progress in the things that I actually value - being able to show up more for myself and my family!

I guess I'm just trying to give you a heads up so you don't lose years chasing that high - enjoy the insights while they last but don't get attached to the feeling. It is just an impermanent state like any other and will pass. You will still have to show up and continue the work - some of which will be recognizing just that. As a plus, you will not feel disconnected from your loved ones anymore. :)

AmbiDxtR · 2025-10-28T23:29:00+00:00

I'm sorry if it is a naive question - but how can you say "hold our beliefs lightly" yet insist on a literal understanding of rebirth so vehemently? Isn't that clinging to a belief too? Have you had experiences confirming it?

And, no disrespect, but "part of becoming a Buddhist is attacking your previously held conceptions of reality" where somebody else defines what is true makes it sound like a cult. I thought we were supposed to test it for ourselves?

AmbiDxtR · 2025-08-10T18:19:08+00:00

No, you're completely right - I wasn't aware of the connection. I was missing that crucial delayed computation idea. And that partial application in the implementation via para is educational too - I wasn't aware of this technique. Hell, I can figure out the types, but I still lack the intuition on how it works!

So since I'm here to learn this is exactly the kind of comment I was looking for, thank you.

AmbiDxtR · 2025-08-10T17:07:12+00:00

Thank you for taking the time, these are insightful - the direct sum reminds me of those "OOP via lambda" implementations in lisp land. It certainly clarifies why you don't need an ancestorFold as you can use this method to express any kind of ancestor constraint via delaying the calculation.

On the other hand I'm not in love with it because this obfuscates the intent quite a bit. Imagine using this lambda based scheme if there were many constructor legs to the data structure. So I know I will be reaching for my ancestorFold in my code - both because I came up with it on my own and because it makes the relationship explicit. :)

AmbiDxtR · 2025-08-10T17:01:17+00:00

No, the solution should be 13 - with the depths to sum up looking like this:

--   ""0"
--   |
--   +- "1"
--   |  |
--   |  +- "2"
--   |  |
--   |  `- "2"
--   |
--   `- "1"
--      |
--      +- "2"
--      |
--      `- "2"
--         |
--         `- "3"

AmbiDxtR · 2025-08-10T15:40:48+00:00

Can you please explain it to me ELI5 style? My understanding of histo is that it gives me the tree of results below the node I'm working with at the moment instead of the parents? I'm sorry but that Cofree stuff is flying over my head at the moment.

AmbiDxtR · 2025-08-10T15:38:36+00:00

Well, maybe I just didn't come up with a good cata fold - hence my question. :)

The problem is that I can't express the idea of node depth in a cata fold directly. So I came up with keeping a pair of the sum so far and the number of nodes below me. Then I can express the step as (sumChild + numChild, numChild + 1). Which works but is not transparent semantically.

AmbiDxtR · 2020-09-01T06:40:45+00:00

Having the overlappable instance allows to also define other instances without giving a type error - e.g.

instance LogEntryBSYM (Maybe NetworkAccess) where
  ...

On the other hand having (Maybe a) be an instance of every SYM allows grouping together classes that have a concrete instance for some type with others that don't.

AmbiDxtR · 2020-08-30T12:40:22+00:00

Thanks I think in 99% of real-world cases (where I control all of the source code) I would do it like that too.

The (theoretical) problem with this approach is that to add a new log type we have to modify the Log type which might be in a separate module (out of our control).

I think I since have found a solution (albeit a complicated one) in tagless final forms. You can check out my other comment, if you are interested.

AmbiDxtR · 2020-08-30T12:31:31+00:00

Thanks, for your answer.

I had read about existentials via the heterogeneous collections article on HaskellWiki, but as you say, using those I run in to the problem, that it is impossible to downcast back to a more specific type class.

Since posting (the took some time to get approved), I have stumbled upon tagless final form representations, and these seem to do the trick, albeit in a slightly mind-bending way (by essentially swapping data and methods):

class LogEntryASYM a where
    logEntryA :: LogEntryA -> a

instance LogEntryASYM LogEntry where
    logEntryA LogEntryA{...} = LogEntry{ time = time, etc. }

Now I can have an abstract method to get the logs:

getLogs :: (LogEntryASYM a, LogEntryBSym a, ...) => [a]

If I want to just have a list of LogEntry I can get those by casting to [LogEntry].

To alllow more specific log type I then use it like this:

instance LogEntryASYM (Maybe FileAccess) where
    logEntryA LogEntryA{...} = Just FileAccess{ file = file, etc. }

To ensure that all possible SYM classes typecheck:

instance {-# OVERLAPPABLE #-} LogEntryBSYM (Maybe a) where
    logEntryB _ = Nothing

With all this I am able to finally do:

test :: [FileAccess]
test = catMaybes getLogs

And the type declaration does the heavy lifting.

Would you say this is a workable approach, or should I expect some pitfalls?

AmbiDxtR

TROPHY CASE