Whatishisname_ 2017-02-09 18:45:26
all this history is lost here
Whatishisname_ 2017-02-09 18:45:36
we only see the present
Whatishisname_ 2017-02-09 18:45:40
:D
Whatishisname_ 2017-02-09 18:45:54
and noone agrees on one way of doing stuff
Whatishisname_ 2017-02-09 18:45:58
anyways thanks guys
Whatishisname_ 2017-02-09 18:46:01
am done
EvanR 2017-02-09 18:46:11
history of haskell from the 80s to 2011: http://haskell.cs.yale.edu/wp-content/uploads/2011/02/history.pdf
dhalgren_ 2017-02-09 18:53:16
Whatishisname_: maybe more relevant than its matemathical roots to practical matters was how the abstract, conceptual turing machine inspired very real practical computer architectures, and how lambda calc inspired programming language design - or at least the Lisp family, and by now you have the key elements, like first class functions, closures in quite a number of languages.
Whatishisname_ 2017-02-09 18:53:43
What is a boilerplate? monochrom
Whatishisname_ 2017-02-09 18:55:13
dhalgren
Axman6 2017-02-09 18:55:26
it's repetitious code that you have to write every time you do X
Whatishisname_ 2017-02-09 18:56:02
I know long time back it was a different time. Things we assume to be normal now might have been new and unique
Whatishisname_ 2017-02-09 18:56:10
but good point.
Whatishisname_ 2017-02-09 18:59:14
difference between high class functions and objects, isn't it just that objects got more functions in them by default?
Whatishisname_ 2017-02-09 18:59:37
and by funtion and objects I mean a block of code
Whatishisname_ 2017-02-09 18:59:50
with their address location
dhalgren_ 2017-02-09 19:00:26
Whatishisname_: think you can look at it almost like that: http://www.c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent
ertes 2017-02-09 19:00:28
if you insist on identifying things with their address and/or block of code, you will not learn anything interesting about them
Whatishisname_ 2017-02-09 19:00:56
but that is how it is
Whatishisname_ 2017-02-09 19:01:07
everything else is imainary and not real
ertes 2017-02-09 19:01:11
nope… try to get the address of a function in haskell
Whatishisname_ 2017-02-09 19:01:27
it is there deep down in the implementation
Whatishisname_ 2017-02-09 19:01:29
just hidden
ertes 2017-02-09 19:01:41
that's not a function… that's machine code
ertes 2017-02-09 19:01:54
machine code is not very interesting in terms of what functions are
Whatishisname_ 2017-02-09 19:02:04
a function is a block of machine code, with its starting address known
ertes 2017-02-09 19:02:15
wrong… that's what a C function is
Whatishisname_ 2017-02-09 19:02:18
Maybe you can substitude some variables it refers to
Whatishisname_ 2017-02-09 19:02:36
yeah C is the closes to machine language
ertes 2017-02-09 19:02:39
if you translate C/assembly concepts to haskell, again, you will not learn anything interesting about functions
Whatishisname_ 2017-02-09 19:02:40
clsest*
Whatishisname_ 2017-02-09 19:02:44
closest*
Whatishisname_ 2017-02-09 19:02:56
There is nothing interesting
Lokathor 2017-02-09 19:03:03
Whatishisname_, I think the trouble here is that you're still using the C-language version of the word "function", but here in the land of Haskell we used the math form of the word
Whatishisname_ 2017-02-09 19:03:09
maybe the way its handled slightly differs
Lokathor 2017-02-09 19:03:25
in other words, a funciton is an operation that takes one input and gives one output and that's all
ertes 2017-02-09 19:03:34
it's only when you let go of this particular insistence that functions become an abstract concept that we can reason about
Whatishisname_ 2017-02-09 19:03:41
Am interested in new lower level abstactions.
gdfgdfh 2017-02-09 19:03:45
exit
Whatishisname_ 2017-02-09 19:03:50
Higher level abstactions are boring
Lokathor 2017-02-09 19:04:02
Whatishisname_, higher level abstractions are the only ones worth having
ertes 2017-02-09 19:04:06
then you may be in the wrong channel
Whatishisname_ 2017-02-09 19:04:25
ertes i thought functional programming was it
Whatishisname_ 2017-02-09 19:04:31
but I should leave
ertes 2017-02-09 19:04:41
also i'd argue that "lower level" by definition means less abstraction, so i'm not even sure what you're asking for
ertes 2017-02-09 19:05:06
functional programming and in particular haskell are not low level… quite the opposite
Whatishisname_ 2017-02-09 19:05:13
I am talking about machine language techniques
Whatishisname_ 2017-02-09 19:05:32
not sure if that would be an abstaction
Lokathor 2017-02-09 19:05:33
ah, this is very much not the channel to help with machine language techniques
Whatishisname_ 2017-02-09 19:05:42
yes cya
Lokathor 2017-02-09 19:06:02
what an odd fellow
dhalgren_ 2017-02-09 19:06:18
I'm confused. I took it you simply wanted to understand what's actually going on, "behind the screen" when some haskell prog is executed?
Whatishisname_ 2017-02-09 19:06:30
yes
Whatishisname_ 2017-02-09 19:06:40
dhalgren
Whatishisname_ 2017-02-09 19:06:44
and you explained it to me
Whatishisname_ 2017-02-09 19:07:15
It was vry helpful
ertes 2017-02-09 19:07:20
now if you're interested in new ways to solve engineering problems, this channel is probably the best place =)
Whatishisname_ 2017-02-09 19:07:24
Lets talk about haskell now
Whatishisname_ 2017-02-09 19:07:27
am good
dhalgren_ 2017-02-09 19:07:53
You could take a look at the compiler's architecture then: there's a couple of languages progressively closer to the machine that haskell is translated into, and you can make the compiler spit out the results of these transformations if you want
Whatishisname_ 2017-02-09 19:08:23
dhalgren I want to do that :D
Whatishisname_ 2017-02-09 19:08:34
Just before that I wanted to confirm that I wasn't missing anything
ertes 2017-02-09 19:08:36
you should also know that GHC-produced machine code looks *very* different from something like compiled C
ertes 2017-02-09 19:09:19
example: there is no call stack
Whatishisname_ 2017-02-09 19:09:32
okay
ertes 2017-02-09 19:10:01
well, there is a call stack, but it's only used when calling foreign functions
dhalgren_ 2017-02-09 19:11:25
Whatishisname_: i think it goes something like this haskell -> FC -> STG -> Cmm -> machine or LLVM
Whatishisname_ 2017-02-09 19:12:06
looks interesting. will definitely look into int
Whatishisname_ 2017-02-09 19:12:09
it*
Whatishisname_ 2017-02-09 19:14:00
btw dhalgren you put things into perspective for me
Whatishisname_ 2017-02-09 19:14:12
it was very helpful to know other point of views
Whatishisname_ 2017-02-09 19:15:28
Mainly why we had the LC
dhalgren_ 2017-02-09 19:15:34
thx, glad to be of help
Whatishisname_ 2017-02-09 19:16:08
before i read it i thought it is something new I need to learn and use
Whatishisname_ 2017-02-09 19:16:15
after i read it i was kind of bummed out
dhalgren_ 2017-02-09 19:16:57
:D
eacameron 2017-02-09 19:18:52
I'm reading some stuff from a few years ago and people complain that WriterT has bad space leaks.
eacameron 2017-02-09 19:19:00
Have those been fixed in more recent base?
ertes 2017-02-09 19:19:20
eacameron: they can't be fully fixed… use StateT
monochrom 2017-02-09 19:19:44
StateT has the same leak.
dhalgren_ 2017-02-09 19:19:56
monochrom: prob you meant Scott Aaronson , not anderson :) has a great blog.
ertes 2017-02-09 19:19:57
the fix you're asking for is also unlikely to happen, because there are really three different semantics for WriterT
eacameron 2017-02-09 19:19:59
ertes: As in...they are necessary for abiding by the laws?
monochrom 2017-02-09 19:20:11
Oh! Yes, Aaronson.
eacameron 2017-02-09 19:20:50
ertes: Ah. Hmm...
monochrom 2017-02-09 19:21:15
What I read from someone else right here is that WriterT doesn't have leaks, it's the careless use that causes the leak.
ertes 2017-02-09 19:21:37
eacameron: lazy WriterT is completely lazy, strict WriterT as in transformers is strict on the result tuple, not the value you 'tell'
monochrom 2017-02-09 19:22:17
And the grand conclusion of that discussion (contains a series of examples) is that "it depends". And there were like 5 factors named.
eacameron 2017-02-09 19:23:03
ertes: Oh I see. Yes that makes sense. There are many places to be strict
eacameron 2017-02-09 19:23:14
Which one you want is...up to you.
ertes 2017-02-09 19:23:29
eacameron: in general when you think you need strict WriterT you probably need strict StateT
eacameron 2017-02-09 19:23:31
Probably leading to monochrom's point
ertes 2017-02-09 19:23:39
when you don't you should use lazy WriterT
ertes 2017-02-09 19:25:11
> snd (runWriter (forever (tell "abc")))
lambdabot 2017-02-09 19:25:15
"abcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabcabc...
jle` 2017-02-09 19:25:58
> fst (runWriter (forever (tell "abc")))
lambdabot 2017-02-09 19:26:04
mueval-core: Time limit exceeded
ertes 2017-02-09 19:26:06
the lazy variant is useful when you care more about the log than the actual result, or when you only ever ask for the result after you've consumed the whole log
nshepperd 2017-02-09 19:26:42
monochrom: source on 'StateT has the same leak'? I remember the lack of the 's ->' in StateT's 's -> m (s, a)' being one of the factors that made fixing the leak in WriterT 'impossible'
monochrom 2017-02-09 19:28:56
StateT f >>= k = StateT (\s -> do ~(a, s') <- f s ... The ~ there.
nshepperd 2017-02-09 19:28:56
because 'foo >> bar' in StateT lets bar decide to evaluate the state given by foo first, whereas WriterT gives you no such choice
ertes 2017-02-09 19:30:01
lazy StateT is useful in the same way
EvanR 2017-02-09 19:31:06
seems ironic that a desirable property of a lazy data structure is productivity
ertes 2017-02-09 19:32:15
but this time you'd want to consume the *result* first
ertes 2017-02-09 19:32:27
> fst (runState (traverse (\x -> modify (x:) >> pure x) [1..]) [])
lambdabot 2017-02-09 19:32:30
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,...
ertes 2017-02-09 19:32:42
and the log will diverge
nshepperd 2017-02-09 19:32:47
monochrom: what about strict StateT?
monochrom 2017-02-09 19:33:03
delete the ~, you get strict StateT.
jle` 2017-02-09 19:33:11
EvanR: isn't productivity the main benefit of laziness?
jle` 2017-02-09 19:33:40
or are you talking about irony with the typical usage of the word 'lazy' heh
nshepperd 2017-02-09 19:33:43
EvanR: the first hacker virtue is productive laziness
EvanR 2017-02-09 19:33:45
this joke just diverged
c_wraith 2017-02-09 19:34:20
jle`: I'd put the fact that programming with combinators results in efficient code as the main benefit of laziness.
monochrom 2017-02-09 19:34:42
But I agree that you can always use "get" and then you have something to bang on.
ertes 2017-02-09 19:34:50
the strict variant of StateT (unlike strict WriterT) lets you force the current state
ertes 2017-02-09 19:36:01
modify' f = f <$> get >>= (put $!)
ertes 2017-02-09 19:36:11
:t \f -> f <$> get >>= (put $!)
lambdabot 2017-02-09 19:36:13
MonadState s m => (s -> s) -> m ()
EvanR 2017-02-09 19:36:32
i want this: someone is trying to learn haskell and is lost when issues like what youre talking about come up, strict vs lazy vs diverging vs efficient vs inefficient, and you give them one exercise to do involving laziness, or a repl expression to evaluate, and it all becomes clear
monochrom 2017-02-09 19:36:40
But I disagree with the cognitive dissonance in asserting "WriteT leaks, StateT doesn't".
EvanR 2017-02-09 19:36:50
or you just need to go back to that one exercise if you need a review
monochrom 2017-02-09 19:37:02
Unfair comparison if you say "after I add more bangs it doesn't leak".
monochrom 2017-02-09 19:37:14
Fair comparison is when you don't add bangs to either.
c_wraith 2017-02-09 19:37:33
EvanR: write https://hackage.haskell.org/package/base-4.9.1.0/docs/Data-List.html#v:dropWhileEnd using foldr.
ertes 2017-02-09 19:37:38
both WriterTs leak with strict mappend
ertes 2017-02-09 19:37:56
StateT gives you the option not to leak (but doesn't do it on its own)
c_wraith 2017-02-09 19:38:03
EvanR: and make sure that it works on infinite inputs as long as there are more characters it won't drop.
c_wraith 2017-02-09 19:38:10
:t dropWhileEnd
lambdabot 2017-02-09 19:38:12
(a -> Bool) -> [a] -> [a]
monochrom 2017-02-09 19:38:22
But who is going to believe me. The whole etymology of "space leak" is founded on the same cognitive dissonance.
c_wraith 2017-02-09 19:38:28
> dropWhileEnd isSpace $ cycle "hello! "
lambdabot 2017-02-09 19:38:30
"hello! hello! hello! hello! hello! hello! hello! hello! hello! hello! hello...
ertes 2017-02-09 19:38:56
the problem with "space leak" is that it needs a lot more context than "WriterT"
c_wraith 2017-02-09 19:38:57
EvanR: if you can do that, you probably have a pretty solid idea how laziness works.
nshepperd 2017-02-09 19:38:59
that's not what cognitive dissonance means >_<
EvanR 2017-02-09 19:39:20
oh wow
stephaner 2017-02-09 19:40:00
hi everyone, by default if I have a value that changes over time ( a mutable state), should I first think about State monad or STRef ? without performance insight... just the default de-facto standard thing to do. I tend to think it is to use State, just want to be sure.
monochrom 2017-02-09 19:40:00
Would "hypocrisy" work better?
EvanR 2017-02-09 19:40:27
State, probably not
EvanR 2017-02-09 19:40:47
STRef would not be able to remember after the ST action ends
monochrom 2017-02-09 19:40:56
You should think about both simultaneously, concurrently, and in parallel.
EvanR 2017-02-09 19:41:09
so you might want a TVar or IORef
nshepperd 2017-02-09 19:41:16
StateT avoidably leaks. WriterT unavoidably leaks
monochrom 2017-02-09 19:41:18
Actually throw in IORef too. Think all three in parallel and concurrently and whatnot.
nshepperd 2017-02-09 19:41:46
meh. foldr leaks too if you use it on integers
EvanR 2017-02-09 19:42:15
c_wraith: i was also hoping the exercise or repl command was simple and easy ;)
c_wraith 2017-02-09 19:42:49
EvanR: laziness ends up not being simple. It's useful, but it's not really simple. :)
stephaner 2017-02-09 19:43:17
what do you mean by "leaks", you mean it keeps everything in memory until end of program ? and that's the problem with StateT and WriterT ?
c_wraith 2017-02-09 19:43:35
not until the end of the program - just longer than needed
stephaner 2017-02-09 19:43:42
okay, good to know
c_wraith 2017-02-09 19:44:21
At least, longer than ideal.
EvanR 2017-02-09 19:44:28
the same issue happens in java, and ruby for that matter
c_wraith 2017-02-09 19:44:36
foldl (+) vs foldl' (+) is a common example.
nshepperd 2017-02-09 19:44:58
yeah, 'space leaks' aren't really memory leaks. it's just inefficient use of memory, caused by doing things in the wrong order
EvanR 2017-02-09 19:45:06
you generate data willy nilly and references to stuff remain because youre holding on to them somehow, despite being logically "done" with them
