taktoa 2017-01-26 12:45:17
err, not GC
uiop 2017-01-26 12:45:18
askhask: it cannot be planned
uiop 2017-01-26 12:45:26
askhask: in the general case
uiop 2017-01-26 12:45:43
taktoa: thx
askhask 2017-01-26 12:45:51
so GC is inevitable?
uiop 2017-01-26 12:46:00
what does that mean askhask
uiop 2017-01-26 12:46:03
"inevitable"
orzo 2017-01-26 12:46:11
glguy: I don't know what the cause is, but I'm now living with a superstitious fear of using 'forever' in any code.
askhask 2017-01-26 12:46:33
inevitable means that as we progress towards "better" programming languages
taktoa 2017-01-26 12:46:44
askhask: choose two from the set {completely automatic, turing complete, no runtime cost}
askhask 2017-01-26 12:46:59
which are faster, more succinct, provide stronger guarantees on code properties, etc
lordcirth_ 2017-01-26 12:47:10
AFAIK, If you allocate memory during runtime differently as a result of input, then the compiler can't predict that completely, thus GC ?
askhask 2017-01-26 12:47:12
will we have GC systems on these better languages 100 or 500 years from now?
glguy 2017-01-26 12:47:33
orzo: what type do those computations have? I'm guessing IO based on your use of threadDelay, but then I'm confused by your use of liftIO (is that redundant?)
taktoa 2017-01-26 12:47:51
GC = turing complete + completely automatic
taktoa 2017-01-26 12:47:51
rust = no runtime cost + turing complete
taktoa 2017-01-26 12:47:51
idris (uniqueness types) = no runtime cost + completely automatic
lordcirth 2017-01-26 12:47:54
askhask, I would think so. Probably way different abstractions around them, though.
uiop 2017-01-26 12:48:39
askhask: GC is more a function of the level at which a language is designed to operate. you'll always need a language to write the GC's in.
uiop 2017-01-26 12:48:48
s/GC/similar code/
Tuplanolla 2017-01-26 12:48:54
The divide between predictable-allocation and general-purpose languages is theoretically motivated and will stay with us, askhask.
orzo 2017-01-26 12:49:00
i can't relate to the desire for GC, it's one of those things I kept an open mind on when adventuring learning functional programming. Memory management in C++ seems fine and reference-counting is all i've ever really needed.
uiop 2017-01-26 12:49:08
exactly what Tuplanolla said
orzo 2017-01-26 12:49:38
i'm not sure the ideal computer language will use GC
askhask 2017-01-26 12:50:03
the problem is that GC latency can be fatal or undesirable for a number of applications
uiop 2017-01-26 12:50:13
orzo: reference counting is slow compared to copying GC for many many things. C++ reference counting is the trade-off it accepts for not being able to copy stuff around
askhask 2017-01-26 12:50:13
and it's quite a serious proble
askhask 2017-01-26 12:51:49
is it possible to pay a fixed penalty (like 2x to 3x memory usage) and get pauseless GC?
orzo 2017-01-26 12:52:07
uiop: That may be so, but I suspect that most GC-enthusiasts are actually novice coders bitten by pointer bugs and the like.
orzo 2017-01-26 12:53:01
uiop: which means, it's overrated.
taktoa 2017-01-26 12:53:41
askhask: just don't ever collect :)
taktoa 2017-01-26 12:53:46
totally pauseless
f-a 2017-01-26 12:54:15
is there a way to make ghc show the unsugared version of a rec block (arrowloop)?
taktoa 2017-01-26 12:54:15
but yes, I think you've correctly identified a tradeoff
geekosaur 2017-01-26 12:55:04
f-a, possibly -ddump-ds
taktoa 2017-01-26 12:55:34
askhask: https://www.artima.com/lejava/articles/azul_pauseless_gc.html
taktoa 2017-01-26 12:56:01
though I've read that that technique ^ actually has very very short pauses
plakband 2017-01-26 12:56:20
I'm using http://lpaste.net/351682 to convert a type-level list into a term. Is there a reason there is nothing like this in Data.Singletons.Prelude.List? This seems like a common operation, but I feel I might be misunderstanding something
orzo 2017-01-26 12:57:09
uiop: If there's some easy accessible examples that show the power of GC from an efficiency stand-point, i'm interested. The GC as a panacea for solving memory management issues is very obviously wrong, considering how hard it is to debug memory leaks in haskell.
uiop 2017-01-26 12:57:12
orzo: i think the point is that, it's only if we're restricting ourselves to having a *single* language that the question even comes up "is GC better than full manual control (and thus the impossibility of a fully automatic precise GC)"
askhask 2017-01-26 12:57:21
ok so can we get a haskell feature request for a pauseless GC option? ;)
uiop 2017-01-26 12:57:51
orzo: it's better to have at least two languages, one fully manual and one fully auto
uiop 2017-01-26 12:57:55
wrt mem
Jophish__ 2017-01-26 12:58:16
foo f = pure (f x); foo :: (A -> b) -> IO b; bar f = f x; bar :: (A -> IO b) -> IO b; -- Is it right to consider foo more general than bar here or are they incomparable?
Cale 2017-01-26 12:58:16
askhask: there was a concurrent GC which was implemented that didn't stop the world, but it has significantly worse throughput than the current stop-the-world approach
f-a 2017-01-26 12:58:31
thanks geekosaur , I'll try this
Tuplanolla 2017-01-26 12:58:31
Pass in `-fcrap-throughput` to enable pauseless gc.
Cale 2017-01-26 12:58:37
(current GC is stop-the-world, but concurrent)
askhask 2017-01-26 12:58:46
Cale: how much lower?
Cale 2017-01-26 12:59:16
askhask: I don't remember, it was years ago that I read a paper about the concurrent GC in GHC.
orzo 2017-01-26 12:59:36
Tuplanolla: is that really the name of the option?
orzo 2017-01-26 12:59:40
heh
Tuplanolla 2017-01-26 12:59:44
No.
Tuplanolla 2017-01-26 13:00:25
Should be though.
askhask 2017-01-26 13:04:41
https://simonmar.github.io/bib/parallel-gc-08_abstract.html this?
geekosaur 2017-01-26 13:07:13
no, I think that's the current (parallel but not concurrent) gc
Cale 2017-01-26 13:09:58
Yeah, I don't remember exactly, can't seem to find it
Cale 2017-01-26 13:10:26
There are some newer papers than that one on the existing GC though
Cale 2017-01-26 13:10:53
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/local-gc.pdf -- is from 2011
Jophish__ 2017-01-26 13:12:59
I suppose it depends on how one defines "more general". Neither type subsumes the ither
Jophish__ 2017-01-26 13:13:07
Other*
Jophish__ 2017-01-26 13:13:28
However the set of values which inhabit them is equal in size
orzo 2017-01-26 13:26:31
does 'seq' do anything to values of type (IO a) ?
Koterpillar 2017-01-26 13:27:22
orzo: same thing as it does to any other values
orzo 2017-01-26 13:27:27
I guess an unevaluated (IO a) might be bottom, but an evaluated one is a thunk?
Koterpillar 2017-01-26 13:27:38
orzo: evaluated != executed
orzo 2017-01-26 13:27:54
what's the distinction
Koterpillar 2017-01-26 13:28:08
in particular, observe that the signature of seq is the same as flip const
Koterpillar 2017-01-26 13:28:24
the _value_ of putStrLn "hello" is an action that would print hello
Koterpillar 2017-01-26 13:28:56
when you execute it, hello appears
orzo 2017-01-26 13:29:00
oh, i don't expect 'seq' to run side-effecting code. But i'm wondering if there is a memory-use point to running seq on a (IO a)
Koterpillar 2017-01-26 13:29:22
there's nothing specific about IO in here
Koterpillar 2017-01-26 13:29:53
f = if (isPrime 45678901) then putStrLn "hello" else return ()
Koterpillar 2017-01-26 13:30:01
this will benefit from seq, I suppose
orzo 2017-01-26 13:30:55
would it ever make sense to say: return $! putStrLn "hello"
orzo 2017-01-26 13:31:20
as opposed to the non-strict $ version
orzo 2017-01-26 13:33:49
i mean, my intention is to return a thunk, but maybe it's better to avoid some pointless indirection with the lazy version?
Koterpillar 2017-01-26 13:35:16
orzo: did you do any IO actions before this?
Koterpillar 2017-01-26 13:35:37
orzo: putStrLn "one" >> putStrLn "two" will not be affected by seq, because it needs to evaluate (>>) first
Koterpillar 2017-01-26 13:36:19
(my understanding is a bit vague; I suggest you put some trace in there to check)
orzo 2017-01-26 13:37:31
i'm not sure a trace could tell me anything
orzo 2017-01-26 13:38:00
a trace on the putStrLn "hello" will be emitted with the $! but not with the $, I expect
askhask 2017-01-26 13:38:11
so is writing software ultimately an empirical process?
orzo 2017-01-26 13:38:24
but that doesn't actually mean that enevaluated putStrLn is represented differently than evaluated
Koterpillar 2017-01-26 13:38:44
orzo: you can have a negative result
askhask 2017-01-26 13:38:49
that is to say, in many or most "real world" situations, can you only tell that software works by using it a lot?
ggVGc 2017-01-26 13:39:02
define works
orzo 2017-01-26 13:39:12
askhask: in short, yes
Koterpillar 2017-01-26 13:39:24
orzo: what would it tell you if trace didn't fire?
ggVGc 2017-01-26 13:39:34
all software does exactly what the code in it says, so in that sense all software works
askhask 2017-01-26 13:40:27
and furthermore that "works" can only be qualified as a statistical phenomenon?
orzo 2017-01-26 13:40:31
i suppose it'd tell me 2 things, one: that seq was indeed a no-op, and two, trace is a magical compiler primitive rather than what i thought it was
monochrom 2017-01-26 13:40:33
seq is unlikely to cause effects to happen
askhask 2017-01-26 13:40:41
that is to say, i fly my airplane control software on thousands of airplanes
Koterpillar 2017-01-26 13:40:50
orzo: (putStrLn "one" >> trace "trace" (putStrLn "two")) `seq` return ()
askhask 2017-01-26 13:41:10
and then on the one or two occasions when the airplane decides to dive, i go into the code and find why that happened
Koterpillar 2017-01-26 13:41:13
orzo: (trace "trace" (putStrLn "two")) `seq` return ()
monochrom 2017-01-26 13:42:35
askhask: You can only tell that my brain works by watching me a lot.
Koterpillar 2017-01-26 13:42:35
orzo: in the first case, seq is happy enough to see (>>) at the top level
askhask 2017-01-26 13:42:58
and then if i dont have any airplane dives for the next ten years,... i can have confidence that the airplanes won't dive,... but only confidence?
askhask 2017-01-26 13:43:29
monochrom: that's kind of excessive
Koterpillar 2017-01-26 13:43:29
askhask: people used to think that Newton physics "works"
geekosaur 2017-01-26 13:43:59
it works fine as long as you're not moving at the speed of light or smaller than a grain of dust >.>
geekosaur 2017-01-26 13:44:10
s/at/almost at/
askhask 2017-01-26 13:44:35
newtonian physics works for a huge range of phenomena,... but more importantly
askhask 2017-01-26 13:44:42
if newtonian physics works for a given phenomenon today,
askhask 2017-01-26 13:44:45
it will also work tomorrow
monochrom 2017-01-26 13:44:50
It is not excessive. You started with general "software". Airplane control is a very simplistic case where people can actually prove things.
askhask 2017-01-26 13:44:53
if a program works today, it may not work tomorrow
