279 reputation
15
bio website smokingkangaroo.com
location Melbourne, Australia
age 30
visits member for 1 year, 11 months
seen Jun 1 at 23:58
stats profile views 21

Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
Is anyone surprised that a nonterminating program is equivalent to undefined in the pure semantics of Haskell? Different ⊥s are supposed to be indistinguishable in Haskell's pure semantics! But when we think operationally about our programs we want to distinguish different kinds of ⊥ too, even when IO is not involved; I care whether my program is throwing an exception or entering an infinite loop, even if you can prove that those are equal by proving that they're both ⊥. That's not actually a contradiction though.
Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
But the interface WorldState -> (a, WorldState) is deliberately abstract, because the whole point is to model something that can't actually be directly expressed in Haskell, and it never breaks its contract. Mercury also uses explicit world-passing. The monad bit of Haskell's IO interface is only needed to ensure you don't reuse the world; understanding it as a State-monad-like abstraction for world-passing does work, because world-passing does work directly.
Jan
24
comment Critique of the IO monad being viewed as a state monad operating on the world
That's not a problem at all. The type WorldState -> (a, WorldState) only claims to accept a WorldState and give you back another one. It "does something" to the world. In the pure model of IO, that includes clocks advancing, stars decaying, network packets arriving, etc. Operationally of course it implements that by just observing how the real world actually changes.
Sep
7
comment Why is the concept of lazy evaluation useful?
This is why only languages with "enforced purity" like Haskell support laziness everywhere by default. "Encouraged purity" languages like Scala need the programmer to explicitly say where they want laziness, and it's up to the programmer to ensure that the laziness won't cause problems. A language that had laziness by default and had untracked side-effects would indeed be difficult to program predictably.
Jul
24
awarded  Yearling
Jan
5
comment Are there any “enterprise ready” functional programming languages?
@JörgWMittag I'm pretty sure the OP is interested in non-JVM non-CLR "enterprise-ready" functional languages. i.e. A functional language is not to be considered "enterprise-ready" solely on the basis of having been ported to JVM or CLR. It would be very strange to exclude a language from this discussion solely because there is another implementation of it on the JVM!
Oct
15
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@BenVoigt I don't know that that's inherently true. I can imagine schemes where you run all the finalizers before deallocating any of the objects and only afterwards free anything that's still unreachable. I have gotten the impression that some modern languages are moving away from finalizers being a good idea because of complications with GC though, so your point has a measure of truth. I'd though it was impossible to do the GC/finalizers combo efficiently rather than impossible to do it though.
Oct
12
comment Is garbage collection necessary?
I would say automatic use of reference counting is a form of garbage collection. It's also known as a particularly inefficient way to implement garbage collection.
Oct
10
awarded  Nice Answer
Oct
9
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@kylben Also, as others have said, reference counting is hugely inefficient compared to sophisticated modern GCs, and even hand-tuned manual free can be sub-par for some workloads. The advantage of C/C++ isn't that they're always more efficient than more managed environments, it's that they make it possible to write more efficient code when the managed environment is sub-par for your use-case.
Oct
9
comment Why do languages such as C and C++ not have garbage collection, while Java does?
@kylben You explicitly drew a distinction between reference counting schemes in C/C++ and GC, and then wrote a comment stating that GC has the risk of masking zombie object bugs. This is severely misleading; it's only true if you're using a library based GC such as Boehm and you circumvent it. GC was specifically invented to make bugs such as zombie objects impossible.
Oct
9
comment Could it be more efficient for systems in general to do away with Stacks and just use Heap for memory management?
@Ingo Not really in any meaningful sense. Sure, the OS will initialise a section of memory traditionally called "the stack", and there'll be a register pointing to it. But functions in the source language don't wind up represented as stack frames in call order. Function execution is entirely represented by manipulation of data structures in the heap. Even without using last-call optimization it's not possible to "overflow the stack". That's what I mean when I say there's nothing fundamental about "the call stack".
Oct
9
comment Is garbage collection necessary?
@acidzombie24 There, I've updated my example of "undecidable garbage" to be a lot clearer, I hope.
Oct
9
awarded  Editor
Oct
9
revised Is garbage collection necessary?
Changed example
Oct
9
comment Is garbage collection necessary?
@acidzombie24 And 3) my point was that it is not possible for the compiler to figure out statically when every object needs to be deallocated. There's always cases that require information from runtime to do properly, so if the compiler were doing it statically it would have to use conservative safe assumptions. And that means there'll always be cases where those rules aren't good enough, and the program uses too much memory, while a GC would let it run fine.
Oct
9
comment Is garbage collection necessary?
@acidzombie24 2) The essential difference is that by reacting to objects dropping out of scope then you need at least some operations for every object you free even if that's just flipping a few flags and then the amortized cost of the bulk deallocate (although you probably can't bulk deallocate in C; the objects will be non-contiguous). A fully managed GC scans the live objects, and can compact the heap as it goes. So the final deallocate is just a single pointer subtraction, and the scan only considers live objects, and only on each GC cycle. For some workloads this can be less work.
Oct
9
comment Is garbage collection necessary?
@acidzombie24 1) I think I framed that example very badly. What I was trying to do was make you think of a case where a heuristic static memory manager would get it wrong and have to keep excess memory around, where a dynamic garbage collector would prevent unbounded memory growth. Such cases exist; I just failed to demonstrate one.
Oct
9
awarded  Teacher
Oct
9
awarded  Supporter