@Lady @wallhackio your therapist: monads aren’t a real concept, they can’t hurt you

haskell:

@aescling @wallhackio haskell is a language of delusion and fraud

@Lady @wallhackio it was fun getting scammed though, i’ll give it that

@Lady @aescling but it looks fun :)

@Lady @aescling I forgot to report you for this

@wallhackio @Lady i’m going to furcibly change your display name to include “serial reporter” or some shit

@wallhackio monads were hard enough for me to understand that an ex once got mad at me because they explained monads and then a few weeks later i happened to mention in conversation that i didn't understand monads. they thought i didn't listen to them

@monorail expecting someone to get what a monad is from a single conversation is insane behavior

It took me a couple days to feel like I understood what a monad was

@wallhackio it took me years of, not really trying but occaisonally stumbling into people talking about them

i heard so many people talk say "monads are simple, people just overcomplicate them. all they are is [simple explanation]" and every time they'd describe something entirely different

there was a really good youtube video i saw that finally made me understand it though. i don't remember the specifics very well, i'd have to watch it again, but i understand the general idea of "putting a value into an environment that abstracts out an idea about that value, and then performing actions in that environment in a way that preserves that idea"

which is obviously a horrible description, i never claimed i could teach monads to someone haha. but i understand that like, Maybe is a monad that puts a value into an environment and extracts out the idea of "the value might not actually be there", in such a way that you can perform actions on it even though it might not be there

@monorail monads are hard to learn but they are even harder to teach

@wallhackio real and true

@wallhackio monads are like a burrito

@monorail reported.

@wallhackio we take reports very seriously here and i will make sure this is investigated fully

@wallhackio i'm back fuk u

@monorail @wallhackio smh at then fur not understanding you won’t understand a monad by just listening to somebody talk about it

@aescling @wallhackio yeah that was not the worst part about that relationship lmao

@monorail @wallhackio btw, he should have said “rvalue in C++ specifically”, because that’s what he really means by this poll

@aescling @monorail C++11 and beyond, specifically

@vaporeon_ in C++ the left value/right value definition used to be mostly correct (it's not exactly right) but the 2011 update to the specification fucked everything

@wallhackio Can you tell me about that new definition?

(Also, what did I get wrong? You say it's not exactly right...)

@vaporeon_ I'll get back to you later this evening 🫡

@vaporeon_ Before the 2011 update to the C++ specification, lvalues and rvalues could have been thought of as "addressable expressions" and "temporary expressions", respectively. Any expression whose value was stored in an address in memory that was made available to the programmer was an lvalue ("addressable expressions") while expressions that cannot be accessible in subsequent lines of code (say, a + b = 3 in an if statement; the result of a + b can't be used again in any context other than the if statement) were referred to as rvalues ("temporary expressions").

Note that when we say that a value is addressable we mean that it is addressable from the programmer's point of view. Many rvalue expressions have results that must be stored somewhere (a function call which returns an object is an rvalue, for example) but if the programmer cannot access that address with the & operator then it is is not an lvalue in the pre-2011 C++ standard.

But the introduction of the rvalue reference cast in C++11, used to enable move semantics, created an expression that does not fit neatly into the old lvalue/rvalue dichotomy. Casting an object into an rvalue reference is a temporary value (if I don't store it in a variable the result of the cast won't be accessible in subsequent lines of code) but since it is a reference it is an explicit address in memory that is made available to the programmer. The C++ standards committee resolved this problem by introducing a third value category and changing the meaning of the word "rvalue":

• most of what we used to call rvalues are now called "prvalues" ("pure rvalues"),
• what we used to call lvalues are still called lvalues,
• an rvalue reference cast expression is of a new value category called "xvalue", which is like a prvalue in that it is a temporary expression but it is also like an lvalue because it is essentially a memory address made available to the programmer,
• rvalue is now an umbrella term; xvalues and prvalues are specific types of rvalues.

There also exists the less useful umbrella term glvalue, short for "general lvalue", which refers to either xvalues or lvalues. The new term xvalue was originally introduced without any meaning and has been retroactively defined in the standard as being short for "eXpiring value". I prefer to think of xvalue as being short for "cross value" since an xvalue contains a cross of some characteristics from lvalues and some characteristics from prvalues.

There are many details I'm leaving out, here is a "pastebin" containing additional notes I left out of what I wrote here: https://hastebin.com/share/feqoyilaqo.vbnet

@vaporeon_ I forgot to mention that, to access the hastebin, you need to enter The Truth as a password (clodsireisawhale)