jle` 2017-03-01 14:46:01
michalrus: are you familiar with how pattern matching works?
jle` 2017-03-01 14:46:35
michalrus: you can match on numeric literals
Forkk 2017-03-01 14:46:52
yeah but shouldn't let 1 = 2 in 1 cause a match failure
Forkk 2017-03-01 14:46:57
since 1 isn't 2
pikajude 2017-03-01 14:47:10
no
pikajude 2017-03-01 14:47:12
because 1 matches 1
jle` 2017-03-01 14:47:18
> let Nothing = Just 10 in "hello"
lambdabot 2017-03-01 14:47:22
"hello"
Forkk 2017-03-01 14:47:24
what
Forkk 2017-03-01 14:47:28
why does that happen
jle` 2017-03-01 14:47:29
match failures are only checked if you use what is inside
jle` 2017-03-01 14:47:37
> let Just x = Nothing in "hello"
lambdabot 2017-03-01 14:47:39
"hello"
jle` 2017-03-01 14:47:46
> let Just x = Nothing in x
lambdabot 2017-03-01 14:47:48
*Exception: :3:5-20: Irrefutable pattern failed for pattern Just x
jle` 2017-03-01 14:47:50
^ Forkk, michalrus
Forkk 2017-03-01 14:47:53
interesting
jle` 2017-03-01 14:47:58
pattern matching is lazy
jle` 2017-03-01 14:48:07
the match is only resolved if any bindings inside are needed
jle` 2017-03-01 14:48:25
so let Just x = Nothing in "hello" doesn't actually do the pattern matching unless x is needed
jle` 2017-03-01 14:48:54
in let 1 = 2 in 3, there are no bindings generated in the pattern match '1 = 2', so nothing really can happen
jle` 2017-03-01 14:49:12
if '1 = 2' created a binding like 'Just x = Nothing' does, then if you evaluated it, you'd get problems
jle` 2017-03-01 14:49:22
but no bindings, no way to really cause any problems
nshepperd_ 2017-03-01 14:49:47
let bindings are lazy. Pattern matching in a case is strict
jle` 2017-03-01 14:50:07
1 = 2 is a bit of a silly pattern match but there's no reason to explicitly disallow it, since it's consistent with haskell pattern matching/let binding syntax
Forkk 2017-03-01 14:50:11
> case Just 1 of Nothing -> 0
lambdabot 2017-03-01 14:50:14
*Exception: :(3,1)-(4,22): Non-exhaustive patterns in case
jle` 2017-03-01 14:50:44
yes, sorry, should have clarified
sveit 2017-03-01 14:51:58
is there an "idiomatic" (i have a solution using explicit recursion) way to produce the list [0 (a0 times), 1, 0 (a1 - a0 - 1 times), 1, 0 (a2 - a1 - 1 times),...] given the list [a0, a1, a2, ...] of ascending integers? Preferably something that fuses well
jle` 2017-03-01 14:52:37
can you give example inputs/outputs?
sveit 2017-03-01 14:52:47
so for example the list [1,3,4] should produce [0,1,0,1,1]
angerman 2017-03-01 14:53:06
can someone recommend some th heavy library? I'd like to try some th compilation.
angerman 2017-03-01 14:53:19
E.g. some library that uses a lot of th.
hpc 2017-03-01 14:53:42
uses, or would just providing definitions work?
sveit 2017-03-01 14:54:20
what i really want to do is, for some N, take N (repeat 0) and for each index in some input list (i.e. [1,3,4]) replace 0 with 1
sveit 2017-03-01 14:55:15
this seems like a "fusable" operation, so i'd like something that is likely to fuse if possible (i.e. efficient)
kadoban 2017-03-01 14:58:38
sveit: What are you using it for after that? That seems like a fairly questionable operation on its own, adding a lot of ... stuff around not much data
angerman 2017-03-01 15:01:01
hpc: uses, or e.g. makes ghc have to compile th.
sveit 2017-03-01 15:01:01
kadoban: this is actually a minimal example. in my particular application the objects are more complicated than integers and the list gets folded at the end. i can give a less trivial example if that would somehow help. the conceptual idea is to, without explicit recursion, emulate a sequence of while loops
kadoban 2017-03-01 15:08:32
sveit: Hmm, I'm not sure I'm following you. I just know that when I notice myself doing that type of thing, I'm often better off just ... not doing that transformation unless I'm really forced to by subsequent needs.
kadoban 2017-03-01 15:10:00
Possibly not a helpful comment, since it sounds like you have a solid goal in mind that I don't quite understand.
sveit 2017-03-01 15:12:24
kadoban: here is a less minimal example. suppose i want to create a path on a square lattice by moving up and right (so a list of data Steps = Up | Right) to process later. This is a list like [Up, Right, Up, Up, ...]. A compact way to represent such a path is by a list of ascending integers, where each integer tells you where to take a "Right" step. So [1,3,4] represents the path [Up, Right, Up, Right, Right, Up, ...]. I want to run a
sveit 2017-03-01 15:12:24
fold over the latter list. The question is how to efficiently convert [1,3,4] to the list of steps.
Squarism 2017-03-01 15:15:12
it seems my hunit test suite cannot access parts of my lib that isnt in "exposed-modules" in my cabal file. Is that how its supposed to work?
Squarism 2017-03-01 15:15:28
(i hoped test suite had special priviliges)
kadoban 2017-03-01 15:26:23
sveit: concat . concatMap ((\x -> [x, [Right]]) . (flip replicate Up) . max 0 . pred) $ zipWith (-) xs (0:xs) -- or explicitly recursive is the best I can come up with, but neither looks particularly great
sveit 2017-03-01 15:30:08
hmm. thanks. do you think i should just prefer explicit recursion to a stack of functions like that?
sveit 2017-03-01 15:32:08
i mean specifically for efficiency. it looks like lots of concatenations on lists will be happening
kadoban 2017-03-01 15:35:21
Not sure, the explicit recursive one is probably a bit faster when it matters. But if the lists are going to be long enough for it to matter, maybe there's a better way to do this than explicitly building the list?