Talk:Monad (functional programming): Difference between revisions

Revision as of 17:26, 3 December 2024

Latest revision as of 16:56, 5 February 2025

(5 intermediate revisions by 2 users not shown)

Line 1:

{{Talk header}}

{{WikiProject banner shell| class=BC |

{{WikiProject Computer science|importance=mid}}

{{WikiProject Computing|class=C|importance=low}}

}}

{{FAQ}}

{{To do|collapsed=yes}}

{{Archives|auto=yes|search=yes}}

== Not useful for non-Haskell programmers ==

Almost any programming language nowadays has some form of monads and thus many people will come here first looking for explanation and find something completely incomprehensible to them. IMHO this page should completely eliminate Haskell from overview and explain terms in plain English and perhaps some JavaScript (or TypeScript since generic types are pretty useful in fully explaining it?) like pseudocode. <!-- Template:Unsigned IP --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/207.96.108.12|207.96.108.12]] ([[User talk:207.96.108.12#top|talk]]) 15:27, 21 June 2021 (UTC)</small>

:Hi there, the page could definitely still use more work so changes are welcome. I did a lot of editing a couple years back here, but mostly worked through my list of ideas; I just watch the talk-page because it's evolving & conceptual discussions still come up (plus I have one table for this page on my to-do list).

:For the code snippets specifically, there is a pretty clear consensus to minimize Haskell on the page (outside of one or two examples, like IO, for flavor). The catch is there's no real guidance on Wikipedia for ''functional'' pseudocode, so when I was doing a lot of editing, I wound up settling on a pseudocode that still looks a lot like Haskell. The thinking there was that it is concise, abstract, de-emphasizes execution order, and often resembles functional math notation, especially if you leave things like lambda calculus implied. But there was also a bit of incrementalism in that decision. I left a long, rambling debriefing for my choices [[Talk:Monad (functional programming)/Archive 2#Style and pseudocode|in the talk archives]].

:If you do have something else in mind though, I'd go for it. I think pseudocode as close as possible to basic math notation (mapping arrows, "f(x)" style functions, etc.) fits this topic well, especially for the (granted, probably very rare) non-programmers that stumble onto the article. So I lean more towards something that looks like Haskell than imperative code in this case, even if it's a popular language, but that's just me. --[[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 21:20, 23 June 2021 (UTC)

:I just rewrote the ''An Example: Maybe'' monad section and the introduction to use less haskell as well as being more clear. I used Rust for the code which is my preferred language and I think has similar syntax to other popular languages like Python & C++. I will try to do the rest if I have time. Any critiques? I'm a little new to Wikipedia editing. [[User:Zyansheep|Zyansheep]] ([[User talk:Zyansheep|talk]]) 05:44, 22 November 2021 (UTC)

::Circled back to Graham Hutton's 2016 book to expand/generalize the Rust examples. They all work together to get beyond any H. syntax. Used Failure/ Success as generic concepts from (Hutton 2016) to show the role of ''bind'' in the languages used (H., Rust, F#, etc.) --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 05:09, 4 January 2022 (UTC)

== We should dehaskelize it ==

There's a big problem with this article. It's all Haskell. That's not good. We have to be more abstract. Maybe write a bunch of paragraphs regarding how a monad looks like in Scala, Java, JavaScript, C++, Rust, C#, etc.

[[User:Vlad Patryshev|Vlad Patryshev]] ([[User talk:Vlad Patryshev|talk]]) 19:27, 4 January 2017 (UTC)

:Haskell is a huge contributor to the use of monads in functional programming, so it's logical that many sections are based on documentation written in it. (Some may say that writing in Haskell ''is'' being "more abstract"). We have examples in Javascript and F#. If you know of references that document the usage of monads in those other languages, by all means bring them here and we'll figure out the best way to include them in the article. [[User:Diego Moya|Diego]] ([[User talk:Diego Moya|talk]]) 09:55, 5 January 2017 (UTC)

:A Haskell-oriented explanation would be OK if it also explained enough Haskell details used so readers needn't already know Haskell to follow along. Grokking monads is difficult so we can't really expect readers to simultaneously make lots of successful inferences about Haskell. This is doubly important since you can't get far in Haskell in turn without understanding monads.

:Please explain the syntax used, also its precedence (or use enough parentheses to avoid that). Are newlines significant? What determines ''which'' monadic type's <code>Just</code>, <code>return</code>, or <code>&gt;&gt;=</code> get called in presented example expressions such as <code>Just 10 // Just 5</code>? Type classes, parameterized types, operator overloading, type inference, <code>()</code>, ... What's the relationship between <code>Just</code>, <code>unit</code>, and <code>return</code>? When the article says “a monadic value: <code>M a</code>”, is that really a variable, a type, or both?

:An alternate way to explain monads would be in a more familiar programming language. Using an object oriented language would answer the question of which <code>Just</code> and <code>bind</code> get called, but it ought to be a language where types are first class values like JavaScript, Ruby, or Smalltalk.

:That said, this page has improved dramatically over the last few years. [[Special:Contributions/73.93.185.77|73.93.185.77]] ([[User talk:73.93.185.77|talk]]) 01:55, 12 January 2017 (UTC)

::::There is a [https://www.haskellforall.com/2014/10/how-to-desugar-haskell-code.html (26 Oct 2014) a 5-line, internally consistent, mental model of Haskell]--[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 00:30, 28 October 2022 (UTC)

::I'm afraid explaining the syntax of Haskell is outside the scope of this article. What it could do is better identify what features of the language are used in each example (enumerated types, pattern matching, etc).

::Adding examples in imperative languages wouldn't be a good idea, methinks; monads and object-orientation don't mix well, as the contrived Javascript example shows. IMHO one should have at least a basic grasp of functional programming before trying to understand monads; this is the scope where they are more useful anyway.

::In imperative languages you can use mutable state, so one of the main selling points of monads for strict functional languages is not needed there. And the other uses, for handling data structures and control threads, would require a syntax in an imperative language too awkward to be useful. [[User:Diego Moya|Diego]] ([[User talk:Diego Moya|talk]]) 13:29, 12 January 2017 (UTC)

::: Maybe this could be a starting point to explain things: What would one do in an imperative language? Why is this not possible (or at least not that easy) in a functional language? In what way does the concept of monads solve this problem? [[Special:Contributions/217.61.234.177|217.61.234.177]] ([[User talk:217.61.234.177|talk]]) 07:37, 15 July 2020 (UTC)

::::Problem solving can take many forms; please see [[reframing]] (in the sense of [[denotational semantics]]) for one approach to [[how to solve it|problem solving]]. --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 13:48, 18 July 2020 (UTC)

:::::How does this relate to the suggested way of introducing monads? [[Special:Contributions/217.61.234.177|217.61.234.177]] ([[User talk:217.61.234.177|talk]]) 08:08, 19 July 2020 (UTC)

::::::{{anchor|letBe}}[[Subjunctive mood]] and [[reframing]] are part of Haskell: as an example, <code>let tmp::b = g x in f tmp</code> can be read ''let <code>tmp</code> be <code>g</code> applied to <code>x in f tmp</code>'' where the compose operator <code>('∘') f g</code> has type (b→c)→(a→b)→a→c <ref name=coresyn.hs>[https://www.youtube.com/watch?v=uR_VzYxvbxg Simon Peyton Jones (Sep 14, 2016) Into the Core - Squeezing Haskell into Nine Constructors]</ref>{{rp|minute 11:45}}

{{talkref}}

::::::''be'' is "Subjunctive ''='' " and part of the Haskell ''let'' syntax, as are ''<code>in f tmp</code>'' (ie, in f applied to tmp) and ''<code>where</code>'', which serve to Reframe the terms of some expression which are used to define a function such as ''[[Composition operator|compose]]'', for example. (The section <code> ('∘') f g</code> means ''f ∘ g'', read as ''f follows g'', and the a,b,c are [[Parametric polymorphism|polymorphic]] type variables, in Haskell. <small>−It may help to mentally separate the concepts [[Lambda_calculus#β-reduction|reduce]], [https://en.wikibooks.org/wiki/Haskell/Pattern_matching#let_expressions_and_where_clauses bind], [[Evaluation strategy#Call by need|eval]], and [[Function application|apply]] in your further readings. The articles sometimes gloss over differences in these separate concepts when discussing them in examples. [[A-normal form]] can be a useful reduction.</small>) [[Evaluation strategy#Call_by_need]] says "Haskell only supports side effects (such as mutation) via the use of monads".

::::::--[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 02:55, 9 August 2020 (UTC)

:::::::{{anchor|haskForGg }}See Gabriel Gonzalez' ''Haskell for all'' [https://www.haskellforall.com/2014/10/how-to-desugar-haskell-code.html (26 Oct 2014) How to desugar Haskell code] for a 5-line, internally consistent, mental model of Haskell, and how to reduce/rewrite its expressions into their equivalents (which depends on how you intend to apply those expressions). --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 05:31, 4 January 2022 (UTC)

== Uncertainty about the term's etymology ==

The clause "due to category-theorist Saunders Mac Lane" suggests that Mac Lane invented the term. This appears to be an exaggeration: Mac Lane may have ''popularized'' it (''Categories for the Working Mathematician, 2nd Ed.'', p.138), but [https://english.stackexchange.com/questions/30654/where-does-the-term-monad-come-from Where does the term “Monad” come from?] documents ambiguity about the original source. [http://math.ucr.edu/home/baez/week200.html This Week's Finds in Mathematical Physics (Week 200)] credits Jean Benabou, whereas [https://www.math.uchicago.edu/~may/PAPERS/mayi.pdf OPERADS, ALGEBRAS AND MODULES] implies that J. P. May either invented the term or advocated it to Mac Lane before the latter published CftWM.

Mac Lane offers no definitive explanation of the name in CftWM, but his book is clearly the most reputable source among those I cited above. Absent an authoritative source, perhaps we should reword the "due to..." clause to highlight the ambiguity and more conservatively describe Mac Lane's role?

[[Monad (category theory)]] is similarly loose regarding attribution and should be clarified. [https://en.wikipedia.org/wiki/Talk:Monad_(category_theory)#Etymology? Etymology?] contains a brief but inconclusive discussion about the term's origin. <!-- Template:Unsigned --><small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Maniaphobic|Maniaphobic]] ([[User talk:Maniaphobic#top|talk]] • [[Special:Contributions/Maniaphobic|contribs]]) 03:07, 27 June 2019 (UTC)</small> <!--Autosigned by SineBot-->

:In the same vein ".. researchers working with Haskell eventually generalized the monad pattern" might be rephrased as ".. in the 2010s researchers working with Haskell eventually recognized that monads are applicative functors". ([https://books.google.com/books?id=MXboNPdTv7QC&pg=PA138&lpg=PA138&dq=%22monoid+in+the+category+of+endofunctors%22+mac+lane&source=bl&ots=feQWTkH2Uw&sig=tv-1JwaMOygKGmFE2vM2FhJVS9o&hl=en&ei=5iWsTJCkBIPSsAPQwJ36Aw&sa=X&oi=book_result&ct=result#v=onepage&q&f=false This leads back to Mac Lane as well.]) page 138 of ''[[Categories for the Working Mathematician]]'' --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 06:05, 27 June 2019 (UTC)

== List example ==

[[Monad (functional programming)#Another example: List|§ Another example: List]] claims • is bind, but then defines it as Kleisli composition, which is quite different. I also have no idea what ° is supposed to mean: is it the Kleisli star? But we don't really need to use it in this pseudocode (it's a trivial embedding of a subset of arrows in one category as arrows in another category - we're not discussing the category-theoretical underpinnings at this point) and "f° := unit•f = f•unit" is nonsense - "unit•f = f•unit" is a law for •, not a definition of °. [[User:Hairy Dude|Hairy Dude]] ([[User talk:Hairy Dude|talk]]) 16:54, 30 June 2019 (UTC)

:Perhaps the editor who contributed it might defend it; otherwise I agree it can go. (Note: the citation to Dan Piponi's discussion motivates the contribution, for me.) --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 23:53, 30 June 2019 (UTC)

::How about now? Just swinging by, but I've done a variation on the diagram similar to one I tried a while back. The original contributor didn't like my changes, and since this is just an occasional hobby / writing practice, I had no interest in an edit war. I don't think they're on Wikipedia anymore though, and they never responded to my points here on the talk-page.{{pb}}As for the old caption, I think that was a misinterpretation of Dan Piponi's post. Since the ° is appended to the individual "sqrt" & "cbrt" functions, I think it was supposed to correspond to the ' in the blogpost. But that's just to distinguish the multivalued, complex functions from the simpler real ones; it can't be the monadic lift for List because you have to consider the individual function semantics to apply it.{{pb}}And the • as bind was only correct in the 1st & 4th identity. Besides not matching up with the article text, I'm pretty sure the old caption was mixing up bind with Haskell function composition (f . g) when reading the 2nd & 3rd identity from the blogpost. --[[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 06:13, 10 February 2021 (UTC)

:::The image has lost the parallelogram/rectangle syntax: parallelograms denote input/output (complex numbers or lists); rectangles denoted functions; input can only be fed into one function (can't feed one input into [cbrt] and [>>=cbrt]); [cbrt] should not accepts a list because it is not lifted.

:::The diagram should look something like this (rotated here for easier typing):

[cbrt°] ↘ ↗ < 8> → [cbrt°] → < 2, 2e..., 2e...> ↘

<64> → [sqrt°] → <8, -8> → [map] [concat] → < 2, 2e..., 2e..., -2, -2e..., -2e...>

↘ <-8> → [cbrt°] → <-2, -2e..., -2e...> ↗

:::...which represents this far less comprehensible equasion:

sxrt(64) = (cbrt°•sqrt°)(64) = concat(map(cbrt°,sqrt°(64))) = concat(map(cbrt°,concat(map(sqrt,unit(64))))) = concat(map(cbrt°,[8,-8])) = concat(cbrt°(8),cbrt°(-8)) = concat(concat(map(cbrt,unit(8)),map(cbrt,unit(-8))) = concat([2,2e...,2e...],[-2,-2e...,-2e...]) = [2,2e...,2e...,-2,-2e...,-2e...]

:::Using concat ([[append]]), map, lift (°), unit, and bind (•) as defined in the cited source. I hope I got that right. [[User:CrossCriss|CrossCriss]] ([[User talk:CrossCriss|talk]]) 17:11, 19 April 2021 (UTC)

{{out|4}} Hi there, so I think you make some good points about the flowchart, such as the boxes. My intent was actually for them to make a slightly more general distinction: rectangles for (first- or higher-order) functions that allow evaluating the expression further, parallelograms for the expression itself, including self-contained rewrites. That's not immediately clear though, and perhaps a couple more style variations would be good (for example, to point out that '''map''' is a higher-order function).{{pb}}

You're also right that '''cbrt''' (without >>=) only accepts a simple input, not the list. Putting '''cbrt''' with the list in that 1st parallelogram on the left, without further reduction, was meant to show the expression can't be evaluated until '''map''' is applied. That's not particularly clear though, so if you can think of a clearer way to put it, that would be great.{{pb}}

That said, like I wrote above, I think the ° (' in the original blog-post) should only be considered as a shorthand to distinguish monadic functions (like the use of x' variables in physics), not an official, valid lift. A few of his examples ''are'' derived by lifting, but if you notice in the multivalued <s>trig</s> example, he never formally defines how to go from the real-valued cube root to the multi-valued complex one. To do so requires facts about the underlying function (how to do complex roots), but the lift should be a property of the monad, which is only a generic list.{{pb}}

Or another way to look at it: in his first example with the writer monad (what he calls "debuggable functions"), when he does explicitly describe lifting a function ''f'', he doesn't specify anything particular for a debug message. He only tags the function with the empty string because anything more implies knowledge of the function's specifics, but the lift has to be generic to the monad, which only specifies ''that'' comments will be appended. To specify ''what'' comment a monadic function should output, that needs to be defined along with the monadic function itself.{{pb}}

I'm still not sure it's correct to consider the • a bind either. One immediate issue is that it doesn't match a valid infix bind's type signature: one input should be a monadic value, not a 2nd monadic function (funny enough, IIUC in category theory terms, bind is itself a "lift" from (a -> Mb) functions to (Ma -> Mb) ones). Now if it's meant to be like the * from the blog-post, that's actually monadic composition (our articles uses >=> like in Haskell for now); that does have the correct type-signature, but it's not directly equivalent to bind or the composition of join & map. --[[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 07:02, 20 April 2021 (UTC)

== "Non-technical explanation" and the monad tutorial fallacy ==

The "Non-technical explanation" section was awful. I've removed the whole thing as it's actually more confusing than the technical introductory section. Monads are easy to describe once you know how they work using any number of analogies, but is there any reasonable way of describing monads to someone who hasn't already learnt the concept the hard way?

[https://byorgey.wordpress.com/2009/01/12/abstraction-intuition-and-the-monad-tutorial-fallacy/ This blog post] on the "monad tutorial fallacy" is I think insightful; there's really no substitute for doing the hard work of understanding, and once you've done it, your insight is still hard (impossible?) to communicate with others, because the hard work simply cannot be avoided. -- [[User:The Anome|The Anome]] ([[User talk:The Anome|talk]]) 13:25, 8 June 2020 (UTC)

:Except that's only true in a limited way. Mathematics pedagogy has known for a long time that often the best way to get someone to understand something is to begin by describing concrete instances and only once the intuition has been developed for the concrete do we generalize and abstract. Think about how you learned about the real numbers. Did you start by sayings its the unique Dedekind complete ordered field or hand you a definition in terms of equivalence classes of Cauchy sequences? Of course not! You started by learning to manipulate concrete examples of reals, first the rationals and then you started to add some special definable real numbers like pi which you can approximate and then we say ok now it's like that but we generalize even to values which you can't define and give a fully formal definition.

:I think the linked article does have a good point but I'd phrase it as this. When introducing a new abstraction it's important to be clear on whether you are giving a concrete example of a type of thing that falls under the concept or something that can kinda motivate the concept or if you are suggesting that a description captures the complete nature of the concept. [[User:Peter M Gerdes|Peter M. Gerdes]] ([[User talk:Peter M Gerdes|talk]]) 16:25, 2 October 2021 (UTC)

== "f returns a defined value of type Maybe U" ==

One of the comments in >>= operator for Maybe says:

"f returns a defined value of type Maybe U".

Is that "defined" correct?

(It sounds like it's saying that that function call can't return Nothing. However, function f's return type is Maybe U, so can't the function return _either_ "a defined value of type Maybe U" _or_ the Nothing value of type Maybe U?)

[[Special:Contributions/100.36.43.9|100.36.43.9]] ([[User talk:100.36.43.9|talk]]) 18:36, 6 March 2021 (UTC)

:I think the main gist of the comment is correct, since it's placed with the 1st branch of the if statement. You're right though that it does sort of imply that Nothing wouldn't be a valid Maybe value, which isn't correct. I'll tweak the wording to emphasize it wraps a defined ''Just'' value within the Maybe type. --[[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 23:11, 20 April 2021 (UTC)

== Consistency in notation ==

The first section of the article seems to be using `:` for type declarations, e.g.

<code>unit : T → M T</code>

while the Analysis section is using it to indicate the definition of the function, e.g.

<code>map φ : (a → b) → (ma → mb)</code>

This is confusing - it would be good to rewrite the Analysis section to be more consistent with the intro. We could potentially write both the type and the definition:

<code>map : (T → U) → M T → M U

map φ ma = ?</code>

Also, in the Analysis section, I think we should explicitly state the types of <code>ma</code>, <code>mmma</code>, etc, to avoid confusion (I found it hard to work out). --[[User:Jordan Mitchell Barrett|Jordan Mitchell Barrett]] ([[User talk:Jordan Mitchell Barrett|talk]]) 21:11, 16 September 2021 (UTC)

:::The part that has been left unsaid in the article is that '[[whitespace characters|whitespace]] is an [[operator (mathematics)|operator]]' .<ref name=so >Daniel Wagner [https://stackoverflow.com/questions/57032261/is-whitespace-either-used-as-a-function-application-operator-or-a-word-separator (15 Jul 2019 at 1:10) Is whitespace either used as a function application operator or a word separator] in answer to bradm</ref> Thus in the pseudocode in the article, whitespace can mean [[function application]], or [[Indentation style#Haskell style|even more, depending on the language]]. The pseudocode is written in mathematical style, or in [[functional programming]] style (which dates back to [[Miranda (programming language)]]). --[[User:Ancheta Wis|Ancheta Wis]] [[User talk:Ancheta Wis| &nbsp; (talk]] [[Special:Contributions/Ancheta Wis| &#124; contribs)]] 11:30, 28 October 2022 (UTC)

:Hi there, first off, the : symbol is actually one bit I really didn't think through much. IIRC Haskell uses it for type signatures, and it's not that different from its use in plain English or function signatures in math. So I just ran with it without thinking too much about it; if some inconsistency jumps out at you, I don't see a reason not to change it.

:As for the the use of <code>ma</code> in the Analysis section, I'm not sure I follow about making the types explicit. Do you mean include the signatures in an expanded form? I tried to stay concise, but if you think adding some details clarifies things, that's always an improvement.

:It is a little tricky because the laws are pretty generic, as long as <code>m</code> is monadic and the same variable means the same thing on both sides of an expression. Repeating the variable for the monad type was the simplest way I could think of to express the nesting you see in the laws (and like in the List example, when you're in that transition state after mapping the monadic function but before reducing again with join). [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 21:24, 25 October 2021 (UTC)

{{talkref}}

== IFF or equality? ==

Maybe I'm just being dumb bc I'm just a mathematician who doesn't do category theory and may be unfamiliar with some of the programming/category theory specific notation but shouldn't the statement of the Monad laws use an equals symbol not a double arrow (as it appears in iPhone Wikipedia app)? If it is correct as written it might help to add a note explaining that it's not meant to be read as the usual logical connective. [[User:Peter M Gerdes|Peter M. Gerdes]] ([[User talk:Peter M Gerdes|talk]]) 16:06, 2 October 2021 (UTC)

:No, you're definitely not being dumb or missing some deep secret; while the choice was intentional, it was mainly a compromise for the pseudocode. I thought it could act as a (metalanguage?) hint that the monad laws aren't necessarily programmed, but ultimately logical propositions about a potential monad. They may or may not be true, based on whether the object is actually verified to be a monad.

:If anyone wants to change it, I'm definitely not opposed. I'd just stay away from the single = sign since that's used for assignment in so many programming contexts, but a == or === is pretty common for equality in several languages. Ideally though, we'd still want to emphasize the laws (typically) aren't checked within the program, but outside of it logically. [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 21:24, 25 October 2021 (UTC)

== Informal style ==

Line 198 ⟶ 86:

::::Regarding the whole table, I would see this table as a commutative diagram of "list → multiset → set", "list → permutation → set". The combinatoric interpretation is interesting. For the permutations, choosing universal left-bias might correspond to enforcing causality (the items selected earlier is removed from the pool and forbidden).

::::I don't think full permutation allowing duplicates is a standard terminology. Also, I stand by just permutation instead of partial permutation, as there is nothing to disambiguate in the context, and [[Partial permutation#Restricted partial permutations|being partial can mean many things]]! [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 15:18, 29 November 2024 (UTC)

:::::{{outdent|4}} Ahhh, you're right, I totally forgot about the closure there. I also think you're exactly right about biasing the operator so that it's well-defined.

{{outdent|4}} Ahhh, you're right, I totally forgot about the closure there. I also think you're exactly right about biasing the operator so that it's well-defined.

:::::Because the join is a natural transformation, that would probably still remain naive, and the + would need to implement the bias. I would think either direction could work though; the append would just need to directly compare the items, then drop duplicates from either the left or the right. And like you said, you could interpret the left-bias causally like selection without replacement (and the right-bias is... anti-causal?)

:::::''That said'', I also think you're right that we're getting into the weeds about the permutation bit. There's actually not even a citation either so while I think technical articles (especially hard topics) need some flexibility to work out the math / logic oneself, we're probably veering into [[WP:SYNTHESIS]] at this point.

Because the join is a natural transformation, that would probably still remain naive, and the + would need to implement the bias. I would think either direction could work though; the append would just need to directly compare the items, then drop duplicates from either the left or the right. And like you said, you could interpret the left-bias causally like selection without replacement (and the right-bias is... anti-causal?)

:::::So I just cut any mention of the permutations from the table for now. I also consolidated the table layout a bit, but noted the combinatoric properties (so the potential symmetry I mentioned is still implied). If you think it needs more work though or that it should be cut, you should probably go for it. This article definitely needs more attention to the technical details. -- [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 17:26, 3 December 2024 (UTC)

''That said'', I also think you're right that we're getting into the weeds about the permutation bit. There's actually not even a citation either so while I think technical articles (especially hard topics) need some flexibility to work out the math / logic oneself, we're probably veering into [[WP:SYNTHESIS]] at this point.

So I just cut any mention of the permutations from the table for now. I also consolidated the table layout a bit, but noted the combinatoric properties (so the potential symmetry I mentioned is still implied). If you think it needs more work though or that it should be cut, you should probably go for it. This article definitely needs more attention to the technical details. -- [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 17:26, 3 December 2024 (UTC)

:Leaving only the relatively obvious varieties makes sense. About the additional columns, I personally see them redundant but having both perhaps helps readers less familiar with algebraic terms. We should defer a potential improvement on this part to a separate discussion. Thanks for the discussion! [[User:J824h|Junghyeon Park]] ([[User talk:J824h|talk]]) 16:09, 4 December 2024 (UTC)

::You're right, the new columns are redundant for anyone that knows the mathematical definitions or can understand the linked articles. But that can be a good thing for new readers.

::Thank you too for talking through it with me; it was kind of fun. Maybe I should get over my bad feelings from university and go back to grad school someday. -- [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 02:39, 5 December 2024 (UTC)

== Rust example ==

Line 218 ⟶ 114:

:* Referring to the Haskell wiki pages is definitely less than ideal, but the talk page already saw a lot of back-and-forth on moving away from Haskell more. I think the core issue is that while we can do examples in other languages, we don't have a better idiom than Haskell-ish terms and pseudocode for explaining the actual concepts. A lot of the historical record out there on using monads is based in Haskell too. Even if it's still Haskell-centric, another harder reference (like a book) might be a good first step. At least that gets us away from citing Haskell's community wiki.

:Like I said, I can't dedicate much time to this article going forward, but if you think I can help somehow, feel free to ping me. -- [[User:Zar2gar1|Zar2gar1]] ([[User talk:Zar2gar1|talk]]) 18:05, 21 November 2024 (UTC)

== Confusing Introduction ==

The first paragraph refers to two ''operations'': "return : <A>(a : A) -> M(A)" and "bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)". The notation is not explained nor is there a link to a resource to understand them. There is a slight attempt to explain them with "which lifts a value into the monadic context" and "which chains monadic computations", but in introducing the idea of monads &mdash; which I'm still trying to understand &mdash; such things only serve to confuse. For example, what's a ''monadic context'' and why must a value be ''lifted'' into that context?

That same paragraph purports to provide a simpler explanation via, "In simpler terms, monads can be thought of as interfaces implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad." However, I have no idea what a type constructor is, how functions can ''abstract over various type constructor variants'', or what it means for such type constructors to "implement monad", so how does any of that jargon help me figure out what a monad is?

[[Special:Contributions/141.162.102.57|141.162.102.57]] ([[User talk:141.162.102.57|talk]]) 16:56, 5 February 2025 (UTC)