I have no problems with the names you have chosen.
When I say emit is not the same as join, what I mean is that emit (as you have defined it) is not equivalent to join (as Haskell defines it — if you wish to use that as a point of reference).
Emit is in fact equivalent to extract, which is part of Comonad but not part of Monad. There is no way to do what emit does with a Monad.
You can define join from Monad, or join can be used in the definition of Monad — there are different equivalent ways to formulate Monad.
This is not a naming problem. This is a problem with the definition of Monad.
Well, at this point I'd have to say you'll need to also take it up with various other existing monad implementations that have been created in Javascript. These are all from folks who know way more than me and could answer better your concerns.
It's done in Professor Frisby's guide here and in his videos:
(He also points out rightly that one can just omit join altogether and use a chained identity for this kind of thing. That might actually be easier from an educational perspective, I'm not sure.)
As does the monet.js monad library which aliases join to be like .chain(a => a) which might as well be () => x in the end, it's just a semantic difference.
And this last one on Maybe by James Sinclair is another, just using a class-style monad.
For Monad to make sense, types cannot be ignored. That is why join is being misunderstood.
I have not watched Professor Frisby's explanation so I have no comment there.
Eric Elliot misunderstands join in his article you linked. I'll try and get in touch.
monet.js does it right. Read carefully what the type of join is.
James Sinclair describes join accurately and then, following that, explains why emit cannot be defined for Maybe. I recommend rereading his work carefully.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have no problems with the names you have chosen.
When I say emit is not the same as join, what I mean is that emit (as you have defined it) is not equivalent to join (as Haskell defines it — if you wish to use that as a point of reference).
Emit is in fact equivalent to extract, which is part of Comonad but not part of Monad. There is no way to do what emit does with a Monad.
You can define join from Monad, or join can be used in the definition of Monad — there are different equivalent ways to formulate Monad.
This is not a naming problem. This is a problem with the definition of Monad.
Well, at this point I'd have to say you'll need to also take it up with various other existing monad implementations that have been created in Javascript. These are all from folks who know way more than me and could answer better your concerns.
It's done in Professor Frisby's guide here and in his videos:
mostly-adequate.gitbooks.io/mostly...
And in the Composing Software book (this is a part of it):
medium.com/javascript-scene/javasc...
(He also points out rightly that one can just omit
joinaltogether and use a chained identity for this kind of thing. That might actually be easier from an educational perspective, I'm not sure.)As does the monet.js monad library which aliases
jointo be like.chain(a => a)which might as well be() => xin the end, it's just a semantic difference.And this last one on Maybe by James Sinclair is another, just using a class-style monad.
jrsinclair.com/articles/2016/marve...
For Monad to make sense, types cannot be ignored. That is why join is being misunderstood.
I have not watched Professor Frisby's explanation so I have no comment there.
Eric Elliot misunderstands join in his article you linked. I'll try and get in touch.
monet.js does it right. Read carefully what the type of join is.
James Sinclair describes join accurately and then, following that, explains why emit cannot be defined for Maybe. I recommend rereading his work carefully.