Una monada è solo un monoide nella categoria degli endofunttori, qual è l'illuminazione?

Question

Perdonare la parola gioca. Sono un po 'confuso per l'implicazione del reclamo e quindi la domanda.

Sfondo: Mi sono azzardò nella teoria della categoria per comprendere le basi teoriche di vari costrutti categorici e la loro rilevanza per la programmazione funzionale (FP). Sembra (a me) che una delle "gemme del coronamento" all'incrocio di cat e fp è questa affermazione:

A monad is just a monoid in the category of endofunctors

Qual è il Big Deal su questa osservazione e quali sono le sue implicazioni programmatiche / progettuali? Fonti come sigffpe e molti testi su FP sembrano Implica Mindblowness di questo concetto, ma forse non riesco a vedere la sottigliezza che viene alusa.

Ecco come lo capisco:

Sapere qualcosa è un Monoid ci consente di estrapolare il fatto che possiamo lavorare all'interno di Mappa-Riduci Impostazione in cui l'associatività delle operazioni ci consente di dividere / combinare il calcolo in ordine arbitrario cioè, (a1+a2)+a3 == a1+(a2+a3). Può anche consentire a uno di distribuirlo attraverso le macchine e ottenere un'elevata parallelizzazione. (Pertanto, potrei andare mentalmente da un theoretical construct -> computer science understanding -> practical problem solving.)

Per me era ovvio (come risultato dello studio del gatto) per vedere che le monade hanno una struttura monoidale nella categoria degli endofunttori. Tuttavia, qual è l'implicazione che si può disegnare da questo e qual è il suo impatto programmatico / design / ingegneria quando stiamo codificando con un modello così mentale?

Ecco la mia interpretazione:

.
• Implicazione teorica: Tutti i problemi calcolabili al loro cuore sono monoidal in un senso.
  .
  • è corretto? Se è così, posso capire illuminazione . È una prospettiva diversa sulla comprensione della nozione / struttura dei problemi calcolabili che non sarebbero ovvi se provenienti da solo un modello di calcolo di Turing / Lambda e posso essere in pace.
  • C'è più ad esso?
• implicazione pratica: è semplicemente quello di fornire un caso per lo stile della programmazione di do-notation? Cioè, se le cose sono monoidali possiamo apprezzare meglio l'esistenza dei costrutti do/for a Haskell / Scala. È questo? Anche se non sapevamo delle basandose monoidali, non abbiamo bisogno di invochiamo monoidalness per effettuare questa rivendicazione poiché le cacciatori >>= e i costrutti flatMap sono definiti per essere associativi. Quindi cosa dà? O è più a che fare con la pieghevole dei costrutti monadi e che è l'illuminazione indiretta a cui viene alluso?

Domanda (s): Cosa mi manca qui? È semplicemente il riconoscimento del fatto che le monade sono monoidi generalizzati e che possono essere combinati in qualsiasi ordine simile alla mappa, ridurre le operazioni come monoidi? Come sapeva della proprietà monoidale help migliorare il codice / design in qualsiasi modo? Qual è un buon esempio di prima / dopo per mostrare questa differenza (prima di sapere su monadi / monoidalità e dopo)?

Answer 1

Questa risposta potrebbe non essere esattamente ciò che stai cercando. Cioè, penso che forse l'importanza di questa caratterizzazione sia esaurita qui. La citazione

.

A monad in x è solo un monoide nella categoria di endofintori di x

è originaria delle categorie di Mac Lane per il matematico funzionante , dove appare come un'intuizione utile per la definizione di monade, che, da sola, può sembrare piuttosto sconosciuta. Caratterizzandolo come monoide in una particolare categoria monoidale, il lettore viene assegnato una prospettiva alternativa. Si noti che il capitolo sulle monade viene effettivamente prima del capitolo sulle categorie monoidali: l'osservazione è destinata a essere utile, piuttosto che precisa (è prese preciso solo in seguito).

La citazione è stata quindi riformulata nel famigerato articolo di James Iry Storia breve, incompleta e per lo più sbagliata dei linguaggi di programmazione .

.

A Monad è solo un monoide nella categoria degli endofunttori, qual è il problema?

presentato dal contesto, come è nell'articolo, è pensato per divertirsi. La citazione è diventata un meme nella comunità di programmazione funzionale, principalmente perché è divertente, piuttosto che una visione chiave per la programmazione funzionale (anche se serva anche a piquet la curiosità dei programmatori funzionali, disegnandoli nel meraviglioso mondo della teoria della categoria ). La mia opinione è che questa caratterizzazione, mentre è disponibile e interessante, non è importante quanto si possa immaginare dalla sua popolarità.

Tuttavia, questo non vuol dire che non vi è alcuna intuizione da guadagnare da questa caratterizzazione. Per prima cosa, fammi sottolineare che, mentre la presentazione di una monada con una moltiplicazione e unità è chiaramente suggestiva di un monoide, mentre sottolinea, la presentazione di Kleisli, con un'operazione di collegamento e di ritorno, non lo è. È la presentazione di Kleisli che è comune nella programmazione funzionale, quindi certamente la caratterizzazione come monoide è più interessante da questa prospettiva.

Da una prospettiva teorica, una delle intuizioni è in effetti che molte strutture naturali in informatica (e matematica) sono monoidal. Dal punto di vista delle monade (in particolare con la loro relazione con operate cartesiane e Lawvere Teorie ), la struttura monoidale corrisponde alla struttura sostitutiva (equivalentemente, struttura della composizione). La sostituzione è onnipresente in informatica (ad esempio, evitando la sostituzione in una teoria del tipo o in un innesto degli alberi). I monadi sono solo un altro esempio.

Mentre la comprensione formalmente la dichiarazione in questione potrebbe non illuminare, suggerisco che si illuminisca comprendere le diverse prospettive sulle monade, in quanto ti permette di vedere i diversi modi in cui potrebbero essere utilizzate monade (ad es. come contenitori, descrivendo Struttura algebrica, che descrive sistemi multi-compositivi, ecc.). Può essere difficile apprezzare quanto spesso si aprono senza aver visto le diverse luci in cui possono essere visti. In questo senso, le monade come monoidi sono solo una prospettiva (e probabilmente non è il più illuminante).

Infine, mentre i monadi stessi sono indubbiamente molto utili in pura programmazione funzionale in generale, non sono sicuro della prospettiva come monade come monoidi è utile per sé. Penso che la prospettiva di Kleisli, che accade essere equivalente, è la prospettiva più illuminante qui.

In sintesi, questa risposta potrebbe essere un po 'deludente: non penso che la comprensione di questa relazione sia tutto utile o di illuminazione praticamente (cioè per la programmazione). Tuttavia, è una prospettiva utile da tenere a mente, insieme agli altri, quando considera le monade teoricamente.