Search Haskell Channel Logs

Thursday, March 2, 2017

#haskell channel featuring monochrom, mniip, ski, Clint, Fairy, psilo2,

monochrom 2017-03-02 14:45:07
Oh tonight everyone is going to anal nitpick on everything I said, right?
Clint 2017-03-02 14:45:13
could be
psilo2 2017-03-02 14:45:19
That's fair, I did learnyouahaskell probably literally a decade ago and then dropped it. If I want to try haskell again, is that still a decent place to start?
monochrom 2017-03-02 14:45:46
If you have an erratum to my sentences, just say the erratum, don't bother questioning me, I won't answer.
psilo2 2017-03-02 14:45:51
monochrom: it's a day of the week on an IRC programming channel, isn't that traditional? ;)
monochrom 2017-03-02 14:46:03
Not traditional on #haskell.
psilo2 2017-03-02 14:46:47
Sounds lovely, maybe I'll hang around for once
Fairy 2017-03-02 14:48:00
I'm trying to implement "notFollowedBy" function, using "lookahead" @ http://lpaste.net/4639017352053129216 but I can't seem to figure out a way to do it, I would have thought that "lookahead p <|> return ()" would work, but it doesn't :S
Fairy 2017-03-02 14:52:20
am I being stupid? :S
monochrom 2017-03-02 14:52:59
No, but you're confusing. The code on the webpage is not the code you just said.
monochrom 2017-03-02 14:53:39
I don't see "lookahead p <|> return ()" in the paste. I only see another version.
Fairy 2017-03-02 14:54:45
oh, sorry, that was the only version of "notFollowedBy" that I could get to work properly :S
monochrom 2017-03-02 14:56:33
OK, first a fixable technicality. "lookahead p <|> return ()" is a type error. But can be fixed by "(lookahead p >> return ()) <|> return ()"
monochrom 2017-03-02 14:57:03
But the real, semantic problem is that this attempt always succeeds.
monochrom 2017-03-02 14:57:34
If "lookahead p" succeeds, then the whole thing succeeds. This is not what you want for notFollowedBy.
Fairy 2017-03-02 14:58:24
yeah :S notFollowedBy is basically supposed to be the opposite of lookahead :S
Fairy 2017-03-02 14:58:58
I've spent around 3hrs thinking about a solution, and I can't come up with one
monochrom 2017-03-02 15:00:00
Suppose I give you && and ||, and ask you to implement "not", and I ask you to only use && and || to do it, no lowering yourself into the actual True's and False's. You will not be able to do it.
mniip 2017-03-02 15:00:35
ooh ooh that's a consequence of the post theorem isn't it
mniip 2017-03-02 15:00:42
&& and || are monotonic but 'not' isn't :p
monochrom 2017-03-02 15:00:43
notFollowedBy is a similar story. It is a negation. You can't combine a lot of positive things to implement negation.
Fairy 2017-03-02 15:03:54
so there's no way to do it?
monochrom 2017-03-02 15:08:46
You have to first implement (by going low level) one kind of negation operator or another. Because it cannot be derived from the positive ones.
monochrom 2017-03-02 15:09:11
And the first negation operator you implement may as well be notFollowedBy itself.
monochrom 2017-03-02 15:09:53
Just like when doing booleans, you have to have a "not" as a basic operator, or "nor", or "nand", or "xor".
Fairy 2017-03-02 15:10:07
interesting
mniip 2017-03-02 15:11:46
yeah
mniip 2017-03-02 15:12:57
you need a function that is non-monotonic, one that is nonlinear, one that is non-1-preserving, one that is non-0-preserving, and one that is non-selfconjugate
mniip 2017-03-02 15:13:27
nand is all of those things simultaneously and hence you can implement all of boolean algebra with just that
Fairy 2017-03-02 15:14:14
and here I was sitting confident that the <|> would be sufficient
monochrom 2017-03-02 15:14:30
That is a cunning plan. We need a "nor" or "nand" parser combinator!
ski 2017-03-02 15:16:14
i'm very sorry, but your negation won't be involutive
mniip 2017-03-02 15:28:59
what languages even are closed under nand?
mniip 2017-03-02 15:29:24
regular and recursively enumerable only I think