dramforever 2017-01-27 02:45:23
I keep saying if you make your own *tree* it would work
dramforever 2017-01-27 02:45:46
but it's going to take forever to draw tree
tabaqui1 2017-01-27 02:45:57
dramforever: well, my ghost wisphers that it's really possible
tabaqui1 2017-01-27 02:46:20
so I trust ghc for now
tabaqui1 2017-01-27 02:46:23
thank you
dramforever 2017-01-27 02:46:35
tabaqui1: How would you 'normally' make a persistent structure?
tabaqui1 2017-01-27 02:46:38
*whispers
tabaqui1 2017-01-27 02:47:17
dramforever: after each change put some "tag" in each node
dramforever 2017-01-27 02:47:49
Hmm looks like Haskell isn't that normal
merijn 2017-01-27 02:47:53
mniip: I literally can't even get a hole with a type signature to typecheck :\
tabaqui1 2017-01-27 02:48:04
so new versions could recover whole structure starting from the end
tabaqui1 2017-01-27 02:48:21
and read tags placed for it and it's parents
dramforever 2017-01-27 02:50:13
I don't think that's what Haskell does
dramforever 2017-01-27 02:50:32
Does that image make sense to you?
ertes 2017-01-27 02:50:52
merijn: sorry, i have no idea
dramforever 2017-01-27 02:50:55
a b c are the three variables
dramforever 2017-01-27 02:51:07
and we've got a linked list from each variable down
ertes 2017-01-27 02:51:10
merijn: the only thing that made sense to me was the toConsumer thing
dramforever 2017-01-27 02:51:15
but they really share a nice part of it
merijn 2017-01-27 02:51:48
ertes: Well, looks like GHC is fucking up in a spectacular fashion
jophish 2017-01-27 02:52:12
merijn: what's up?
merijn 2017-01-27 02:52:24
I moved part into a where clause with explicit signature and now it compiles just fine...
dramforever 2017-01-27 02:52:35
Oh wait, someone's already drawn a tree here: https://en.wikipedia.org/wiki/Persistent_data_structure#Trees
merijn 2017-01-27 02:52:56
I knew that code was trivially correct...
dramforever 2017-01-27 02:52:58
tabaqui1: *This* is how sharing in Haskell works, basically
dramforever 2017-01-27 02:53:23
https://en.wikipedia.org/wiki/Persistent_data_structure#Trees
merijn 2017-01-27 02:54:19
ertes, jophish: Looks like I've fallen victim to annoying RankN type aliases in conduit
merijn 2017-01-27 02:54:46
If I change "foo . skipMany $ item" to "foo $ skipMany item" it compiles just fine
athan 2017-01-27 02:54:57
What are the "key field" and "id field" in ghc-pkg? Are those something to do with semvars?
dramforever 2017-01-27 02:55:39
merijn: GHC can't instantiate a type variable with a 'forall' type
dramforever 2017-01-27 02:55:56
So... I suppose that's what happening with (.) there
tabaqui1 2017-01-27 02:56:03
dramforever: O(log n) additional memory
dramforever 2017-01-27 02:56:34
Yeah
merijn 2017-01-27 02:57:00
Welp...
merijn 2017-01-27 02:57:07
That's 2 hours of my life I will never get back
tabaqui1 2017-01-27 02:57:46
btw
tabaqui1 2017-01-27 02:58:17
if I have "infixl 5 @" and "infixr 5 $"
tabaqui1 2017-01-27 02:58:28
in which order will evaluated
dramforever 2017-01-27 02:58:30
btw, were you talking about this fat node thing? https://en.wikipedia.org/wiki/Persistent_data_structure#Fat_node
tabaqui1 2017-01-27 02:58:34
1 @ 2 $ 3
tabaqui1 2017-01-27 02:58:37
?
merijn 2017-01-27 02:58:37
tabaqui1: You can't mix those
merijn 2017-01-27 02:58:41
tabaqui1: Parse error
dramforever 2017-01-27 02:58:47
tabaqui: that's a parse error
dramforever 2017-01-27 02:58:53
How about we try that?
tabaqui1 2017-01-27 02:59:28
dramforever: I hope, that someone knows exactly :)
dramforever 2017-01-27 02:59:40
How exactly?
quchen 2017-01-27 02:59:56
?let infixA = undefined
lambdabot 2017-01-27 02:59:58
Defined.
quchen 2017-01-27 03:00:01
?let infixB = undefined
lambdabot 2017-01-27 03:00:06
Defined.
tabaqui1 2017-01-27 03:00:07
without starting ghci
quchen 2017-01-27 03:00:12
?let infixl 5 infixA
lambdabot 2017-01-27 03:00:12
Parse failed: Parse error: infixA
dramforever 2017-01-27 03:00:16
Yes, I know it's a parse error
quchen 2017-01-27 03:00:16
Aww. :-(
tabaqui1 2017-01-27 03:00:23
that's it
tabaqui1 2017-01-27 03:00:29
thx)
quchen 2017-01-27 03:00:31
?undef
lambdabot 2017-01-27 03:00:31
Undefined.
dramforever 2017-01-27 03:00:37
quchen's wasn't it
quchen 2017-01-27 03:00:59
Lambdabot can't define fixities it seems
dramforever 2017-01-27 03:01:02
It would be (literally) 'can't mix' infixl 5 @ and infixr 5 $
jophish 2017-01-27 03:01:21
merijn: what was the warning GHC gave. It's often pretty good at saying "Ahhh! ImpredictiveTypes"
merijn 2017-01-27 03:02:34
jophish: This one: Couldn't match type 'ConduitM Event o0 SqlM (Maybe ())'
merijn 2017-01-27 03:02:34
with 'forall o. ConduitM Event o SqlM (Maybe a0)'
merijn 2017-01-27 03:02:34
Expected type: Consumer Event SqlM (Maybe a0)
merijn 2017-01-27 03:02:34
Actual type: ConduitM Event o0 SqlM (Maybe ())
dramforever 2017-01-27 03:02:34
tabaqui1: ^ That's an example
dramforever 2017-01-27 03:03:01
GHC usually gives pretty long error messages
dramforever 2017-01-27 03:03:22
I don't really remember them exactly...
dramforever 2017-01-27 03:03:39
But I'm not sure you'll be happy with
merijn 2017-01-27 03:03:45
dramforever: "pretty long errors" <- wut?
merijn 2017-01-27 03:03:56
dramforever: Clearly you've not programmed C++ if you consider GHC errors long
dramforever 2017-01-27 03:04:06
with 'it's a parse error' or 'Ahhh! ImpredicativeTypes'
dramforever 2017-01-27 03:04:19
merijn: Uh, that's a whole different thing
dramforever 2017-01-27 03:04:31
C++ template error messages are not for mortals to read
merijn 2017-01-27 03:04:39
I've had errors longer than my terminal scroll history >.<
dramforever 2017-01-27 03:05:48
I set up my gnome-terminal so that it has infinite history
dramforever 2017-01-27 03:05:54
(FSVO infinite)
jophish 2017-01-27 03:05:57
Ooh, that's annoying merijn. Is it worth filing a ghc bug?
ertes 2017-01-27 03:06:23
merijn: consider it an exchange: you paid two hours to save hundreds of hours in the future =)
quchen_ 2017-01-27 03:06:24
Hah, got it. Forgot the backticks for infix fixities.
quchen_ 2017-01-27 03:06:28
?let infixA = undefined
quchen_ 2017-01-27 03:06:28
?let infixl 5 `infixA`
lambdabot 2017-01-27 03:06:29
Defined.
quchen_ 2017-01-27 03:06:30
?let infixB = undefined
lambdabot 2017-01-27 03:06:31
Defined.
quchen_ 2017-01-27 03:06:32
?let infixr 5 `infixB`
lambdabot 2017-01-27 03:06:33
Defined.
quchen_ 2017-01-27 03:06:34
:t \x y z -> x `infixA` y `infixB` z
lambdabot 2017-01-27 03:06:34
Defined.
lambdabot 2017-01-27 03:06:36
t -> t2 -> t3 -> t1
dramforever 2017-01-27 03:06:43
huh?
quchen_ 2017-01-27 03:06:44
Wat.
dramforever 2017-01-27 03:06:48
Wat
quchen_ 2017-01-27 03:06:50
That gave me an error in the private session.
quchen_ 2017-01-27 03:07:06
15 seconds ago.
quchen_ 2017-01-27 03:07:11
!??!
dramforever 2017-01-27 03:07:15
Let's do it again
quchen_ 2017-01-27 03:07:36
:t \x y z -> x `infixA` y `infixB` z
lambdabot 2017-01-27 03:07:39
error:
lambdabot 2017-01-27 03:07:39
Precedence parsing error
lambdabot 2017-01-27 03:07:39
cannot mix 'infixA' [infixl 5] and 'infixB' [infixr 5] in the same infix expression
quchen_ 2017-01-27 03:07:43
Uhmmmm
quchen_ 2017-01-27 03:07:54
:t \x y z -> x `infixA` y `infixB` z
lambdabot 2017-01-27 03:07:56
error:
lambdabot 2017-01-27 03:07:56
Precedence parsing error
lambdabot 2017-01-27 03:07:56
cannot mix 'infixA' [infixl 5] and 'infixB' [infixr 5] in the same infix expression
dramforever 2017-01-27 03:08:00
Could be a race condition or something
quchen_ 2017-01-27 03:08:00
OOkkaaay.
quchen_ 2017-01-27 03:08:04
Yeah maybe.
quchen_ 2017-01-27 03:08:11
Anyway, that's the error I wanted.
dramforever 2017-01-27 03:08:22
tabaqui1: I can't really recite *that*, you see...
tabaqui1 2017-01-27 03:08:39
yep
dramforever 2017-01-27 03:08:43
But GHCi *always* knows the exact error message
merijn 2017-01-27 03:12:32
And now on to simpler Haskell issues, like: How do you guys deal with linewrapping of long pipelines of function composition
jophish 2017-01-27 03:12:59
merijn: break before the operators, line up the .'s and $'s vertically
dramforever 2017-01-27 03:14:06
Basically like how you write multi-line {;;;;;;;} lists
dramforever 2017-01-27 03:14:46
Arguments for that: lining operators on the left side allows one to scan through the left edge and see the outmost structure
merijn 2017-01-27 03:16:33
jophish: That wastes so many lines, though :\
jophish 2017-01-27 03:18:41
merijn: break your pipeline up into two or three smaller pipelines in a let or where?
jophish 2017-01-27 03:18:52
that's sometimes easier said than done
merijn 2017-01-27 03:19:30
Basically this is what I have: http://lpaste.net/5818896029914759168
Profpatsch 2017-01-27 03:21:03
:exf a -> b -> c -> a
exferenceBot 2017-01-27 03:21:03
parse error: more than one input
Profpatsch 2017-01-27 03:21:14
:exf test :: a -> b -> c -> a
exferenceBot 2017-01-27 03:21:15
could not parse input type: ParseFailed (SrcLoc "inputtype.hs" 1 6) "Parse error: ::"
Profpatsch 2017-01-27 03:21:32
:exf a -> b -> a
exferenceBot 2017-01-27 03:21:33
parse error: more than one input
Profpatsch 2017-01-27 03:21:37
:exf a
Profpatsch 2017-01-27 03:21:48
hm
exferenceBot 2017-01-27 03:22:24
could not find expression
bwe 2017-01-27 03:22:44
> fromIntegral $ 3/1 :: Rational -- how can I make a Rational into an Integer?
lambdabot 2017-01-27 03:22:46
error:
lambdabot 2017-01-27 03:22:46
• Ambiguous type variable 'a0' arising from a use of 'fromIntegral'
lambdabot 2017-01-27 03:22:46
prevents the constraint '(Integral a0)' from being solved.
merijn 2017-01-27 03:23:09
:t round -- ?
dramforever 2017-01-27 03:23:11
round floor ceil
lambdabot 2017-01-27 03:23:11
(RealFrac a, Integral b) => a -> b
dramforever 2017-01-27 03:23:12
chose one
dramforever 2017-01-27 03:23:14
*choose
dramforever 2017-01-27 03:23:40
> floor $ (3/1 :: Rational) -- Let's hope for the best
lambdabot 2017-01-27 03:23:43
3
merijn 2017-01-27 03:23:53
dramforever: FYI
merijn 2017-01-27 03:23:55
:t (%)
lambdabot 2017-01-27 03:23:57
Integral a => a -> a -> Ratio a
merijn 2017-01-27 03:24:09
> floor $ (3%1)
lambdabot 2017-01-27 03:24:11
3
dramforever 2017-01-27 03:24:14
I 'like' (/)
dramforever 2017-01-27 03:24:24
And it's not like it's inexact or anything...
merijn 2017-01-27 03:24:48
dramforever: Naah, but I hate having to type Rational as annotation :p
dramforever 2017-01-27 03:25:05
Uh, you know, I was just trying to imitate the original coee
dramforever 2017-01-27 03:25:07
*code
dramforever 2017-01-27 03:25:15
where original =def= bwe's
bwe 2017-01-27 03:26:02
dramforever: Thanks, have it working now.
saurabhnanda 2017-01-27 03:31:14
anyone know how to use PackageImports properly? http://stackoverflow.com/questions/41896211/how-to-use-packageimports-extension-to-shadow-a-module
merijn 2017-01-27 03:32:02
saurabhnanda: Why do you need it?
merijn 2017-01-27 03:32:46
Doing that will force every user of your library to use packageimports
saurabhnanda 2017-01-27 03:35:33
is it?
saurabhnanda 2017-01-27 03:36:13
merijn: if my library's user simply puts "instrumentedscotty" in the cabal file, and imports the same old `Web.Scotty.Trans` it'll work, right?
saurabhnanda 2017-01-27 03:36:37
that's the idea -- minimal amount of code change to use instrumented versions of certain libraries
merijn 2017-01-27 03:37:16
saurabhnanda: No
merijn 2017-01-27 03:37:36
saurabhnanda: They will have to change their imports to use packageimports to use your package if the module name clashes
dramforever 2017-01-27 03:37:40
Snoyman said no: http://www.snoyman.com/blog/2017/01/conflicting-module-names
saurabhnanda 2017-01-27 03:38:33
merijn: but they'll change `scotty` to `instrumentedscotty` -- not depend on BOTH in the cabal file.
saurabhnanda 2017-01-27 03:39:26
dramforever: Snoyman has not thought of my sexy use-case
dramforever 2017-01-27 03:39:44
More like 'he has other concerns'
saurabhnanda 2017-01-27 03:40:01
Use case: For someone using a library X make instrumentedX available. So, simply by changing X to instrumentedX in their cabal file, they can use the instrumented version of the library -- without any other change in code.
saurabhnanda 2017-01-27 03:40:53
merijn: if only instrumentedX is present in cabal file, even then will library users need to depend on PackageImports?
merijn 2017-01-27 03:41:04
I don't know for sure
saurabhnanda 2017-01-27 03:42:31
is there a way to find out who authored the PackageImports extension?
saurabhnanda 2017-01-27 03:44:18
a-ha : https://ghc.haskell.org/trac/ghc/ticket/13168
