--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/paste/paste.28703	Thu Jul 18 07:03:43 2013 +0000
@@ -0,0 +1,301 @@
+2006-05-24.txt:17:36:15: <SimonRC> no, I mean there would be a bit to say wether a word was an actual value or a thunk telling you how to calculate it.
+2006-08-23.txt:00:05:09: <ihope> Uh... thunks. The eager kind.
+2006-08-26.txt:21:18:48: <ihope> oerjanj: thunks.
+2006-08-26.txt:21:19:13: <oerjanj> but the thunk would be evaluated every time
+2006-08-26.txt:21:20:16: <ihope> oerjanj: thunks. Like output functions are thunks.
+2006-08-26.txt:21:20:37: <ihope> .H is a thunk. r is a thunk. Continuations are thunks, I think.
+2006-08-26.txt:21:22:24: <oerjanj> i have no problem understanding thunks. but for call-on-need you need to replace a thunk by its result.
+2006-08-26.txt:21:23:16: <ihope> oerjanj: I don't get what you're saying. Thunks wouldn't be evaluated until you call them.
+2007-01-07.txt:21:46:24: <ihope_> Thunk, then?
+2007-01-07.txt:21:54:05: <ihope_> ~pexec self.apply_thunk = lambda *x: lambda: x[0](x[1:])
+2007-01-07.txt:21:55:58: <ihope_> ~pexec self.esoteric(self.apply_thunk(lambda x,y: x+y, 3, 5))
+2007-01-07.txt:21:57:12: <bsmntbombdood> ~exec print self.apply_thunk(lambda x,y: x+y, 3, 5)
+2007-01-07.txt:21:57:59: <bsmntbombdood> apply_thunk is returning a function
+2007-01-07.txt:21:58:13: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
+2007-01-07.txt:21:58:17: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)(1,2)
+2007-01-07.txt:21:58:25: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
+2007-01-07.txt:21:59:12: <CakeProphet> called the function returned by apply_thunk... I'd imagine.
+2007-01-07.txt:22:00:31: <bsmntbombdood> ~pexec self.apply_thunk = lambda *x: lambda: x[0](*x[1:])
+2007-01-07.txt:22:00:42: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)
+2007-01-07.txt:22:00:55: <ihope_> ~pexec self.esoteric(self.apply_thunk(lambda x,y: x+y, 3, 5))
+2007-01-07.txt:22:01:11: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
+2007-01-07.txt:22:02:32: <ihope_> apply_thunk creates a thunk, and esoteric forces it.
+2007-01-07.txt:22:02:39: <bsmntbombdood> what's a thunk?
+2007-01-07.txt:22:03:44: <ihope_> Now to combine esoteric with apply_thunk, because there's really no reason to have both.
+2007-01-07.txt:22:04:47: <CakeProphet> a thunk is a lambda then.
+2007-01-07.txt:22:05:01: <ihope_> And there's really no reason to keep the thunk stuff.
+2007-01-07.txt:22:05:36: * CakeProphet considered a thunk-like thing for a language.
+2007-01-30.txt:01:36:16: <ihope_> Thunk monad, anyone?
+2007-02-02.txt:03:24:31: <SevenInchBread> for evaluating a symbol, the thunk for the get hash value function cab be the symbol itself
+2007-02-02.txt:03:24:54: <bsmntbombdood> thunk?
+2007-02-08.txt:01:40:29: * ihope_ ponders thunks
+2007-02-25.txt:21:32:27: <bsmntbombdood> thunks are ugly :/
+2007-03-22.txt:01:31:55: <oerjan> representing files as lazy thunks allows infinite files without loops.
+2007-06-21.txt:05:05:56: <oerjan> In the monad of (IO) actions, the values would be thunks that did possibly some I/O and then returned an a.
+2007-06-21.txt:05:06:30: <oerjan> thunk = closure without arguments
+2007-06-26.txt:20:59:53: <SimonRC> Oh, wait, you can do it with thunks.
+2007-07-03.txt:13:56:59: <ihope_> Thunks!
+2007-07-03.txt:14:32:51: * ihope_ ponders thunks
+2007-07-03.txt:14:33:45: <ihope_> In the Haskell definition "x = x + 1", calling the x thunk calls the + thunk with x and 1, right?
+2007-07-03.txt:14:35:03: <ihope_> Calling the x thunk... returns something representing (x +), I guess.
+2007-07-03.txt:14:38:26: <ihope_> I was pondering thunks for functions.
+2007-07-03.txt:14:40:01: <oerjan> well, an evaluated function thunk can be thought of as a lambda expression in head normal form
+2007-07-03.txt:14:40:44: <ihope__> Really, their thunks don't need to do anything at all--they can just return.
+2007-07-03.txt:14:43:12: <oerjan> so just because a thunk is of a function type doesn't mean it does no evaluation
+2007-09-22.txt:01:33:36: <edwardk> currently i'm using an 'optimistic with lazy semantics' rule which says it can waste work on things eagerly but it has to bound the amount of speculation and if it encounters an error while speculating it has to pretend it didn't happen and turn that speculation into a lazy thunk to be forced on demand.
+2007-09-22.txt:01:34:11: <edwardk> so that you can encounter bottoms and not 'bottom' out, but you don't have to build as many thunks
+2007-09-22.txt:01:34:47: <oklokok> "build thunks"?
+2007-09-22.txt:01:35:31: <edwardk> a thunk is the unevaluated computation that when forced will give you the answer and overwrite it self with the answer, so that call-by-name evaluation works
+2007-09-22.txt:01:36:26: <edwardk> call-by-name has thunks, call-by-need makes the thunk remember the answer it gave by self-modifying
+2007-09-22.txt:01:36:34: <edwardk> so called 'memothunks' =)
+2007-09-22.txt:01:37:21: <edwardk> pattern matching just checks to see if what you have is a thunk if so it tells the thunk to evaluate which makes sure the outermost constructor is a value, then you can inspect it
+2007-09-22.txt:01:37:51: <edwardk> in the ghc haskell compiler it does so by making everything into a 'thunk' with a function for the constructed values that just returns itself
+2007-09-22.txt:01:39:46: <edwardk> so basically a list 'cons' cell is a [Cons, x, xs]  where cons is a pointer to a function that happens to just return the 'thunk' [Cons, x, xs] that it was given, so to force it you call the function at the start of the thunk and you inspect the value of the tag that it returns in the first position.
+2007-09-22.txt:01:40:20: <edwardk> then you'd encounter a thunk like
+2007-09-22.txt:01:44:01: <oklokok> i mean, it doesn' have to know the object it's matching is actually a thunk
+2007-09-22.txt:01:46:14: <edwardk> adding speculation muddies the waters a bit, you track a speculation depth cap, and rather than generate a thunk in the first place you try to run through it eagerly, but if you hit the cap you abort and return the thunk.
+2008-01-10.txt:23:48:21: <ehird`> CakeProphet_: the term is 'thunk'
+2008-01-15.txt:00:13:10: <ehird`> 0-args can be replaced with thunks, va-arg is more problematic
+2008-01-21.txt:16:09:54: <ehird> every argument to EVERYTHING is a thunk
+2008-01-21.txt:16:10:19: <ehird> CALLIFY(thunky_thunk);
+2008-01-21.txt:16:10:21: <ehird> thunky_thunk:
+2008-01-21.txt:16:10:37: <ehird> so, d works just by wrapping that thunk in a structure
+2008-01-23.txt:18:10:32: <olsner> the name 'blimp' reminds me of haskell's thunks
+2008-02-18.txt:20:14:08: <ehird`> think it's worth making that use a thunk?
+2008-02-18.txt:20:19:32: <ehird`> ais523: http://pastebin.ca/908906 weird bug with thunks
+2008-02-18.txt:20:19:45: <ehird`>     Thunk.new {@block.call.__send__(*args, &blk)}
+2008-02-18.txt:20:19:49: <ehird`> thus making it return a Thunk
+2008-02-18.txt:20:47:16: <ehird`>     blk[head, (magic thunkify: tail.inject(base, &blk))]; end
+2008-02-18.txt:20:47:23: <ehird`> but the magic thunkify is basically impossible
+2008-03-09.txt:17:39:58: <olsner> laziness got the best of you, eh? someone needs to have his thunks forced...
+2008-03-09.txt:21:25:41: <ehird> oerjan: some things cannot be unthunked
+2008-03-09.txt:21:26:22: <oerjan> ITYM "unthunk"
+2008-03-09.txt:21:27:27: <oerjan> i am merely correcting your grammar.  think, thank, thunk.
+2008-03-31.txt:16:10:25: <ehird> closures and thunks and all that mean it's pretty hack
+2008-05-06.txt:18:04:29: <ehird> ais523: they could be thunks
+2008-06-06.txt:01:06:21: <augur> anyone know what a thunk is?
+2008-06-06.txt:01:11:01: <oklofok> cool thunk
+2008-06-08.txt:20:13:29: <augur> i thunk, therefore noone ever disputes me.
+2008-06-18.txt:22:56:20: <augur> sure, you could write a thunk lambda and call it with conditional reactions, but that tells you nothing more than anything else does
+2008-06-19.txt:19:04:12: <tusho> Cool. Thunks were invented in 1961 for ALGOL 60.
+2008-06-19.txt:19:11:13: <Slereah_> Thunks?*
+2008-06-19.txt:19:11:20: <tusho> Thunks
+2008-06-19.txt:19:12:47: <Slereah_> "The word thunk has at least three related meanings in computer science."
+2008-07-08.txt:20:00:58: <AnMaster> pikhq, you can thunk yes
+2008-08-24.txt:23:15:20: <lament> AnMaster: http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/
+2008-08-30.txt:20:02:01: <fungot> AnMaster: any actionscript object could be wrapped in a dynamic-wind exit thunk?
+2008-09-03.txt:13:32:52: <tusho> Deewiant: quick, explain to him the asm that powers thunks
+2008-09-03.txt:13:33:17: <tusho> Deewiant: evidently, thunks don't exist
+2008-09-29.txt:15:53:08: <tusho> it uses thunks
+2008-10-11.txt:05:23:48: <edwardk> the problem is basically i wound up building up these free magmas of structures 1 + (2 + 3) didn't build a thunk chain it built a data structure.
+2008-10-11.txt:05:29:32: <edwardk> so instead i store the fwding pointer xored with the view instead. then to see if a view has already been applied to a thunk i check to see if fwd ^ fwd ^ the-view-i-read = the-view-i-want if so then fwd points to the answer, if not either the wrong view was stored or someone is racing me and its inconsistent
+2008-10-22.txt:18:17:40: <optbot> asiekierka: every argument to EVERYTHING is a thunk
+2008-11-19.txt:12:28:55: <ehird> 1. make it lazy and have no 0-arg functions, they're just thunks, like haskell. <-- Best option, obviously
+2008-12-20.txt:09:13:41: <oerjan> i wioll haven thunk so, but not yet
+2008-12-26.txt:19:41:02: <oklopol> the perfect is changing to thunk, but thank i haven't heard yet
+2009-01-14.txt:17:53:29: <ehird> can't you just track d tags and pass thunks to d-tainted functions?
+2009-01-16.txt:23:22:27: <ehird> who'dathunkit?
+2009-01-18.txt:14:22:40: <ehird> i.e., if we call/cc out of the thunk thing, we call the after thing first
+2009-01-18.txt:14:24:09: <oklopol> oh i remember. weird ordering shit and thunk stuff.
+2009-02-04.txt:18:24:38: <ehird> i.e., no thunks (0-argument functions, used for laziness)
+2009-02-04.txt:18:35:06: <ehird> think think closure thunk _ghczmprim_GHCziTypes_Czh_static_info
+2009-02-04.txt:18:35:13: <ehird> *thunk thunk
+2009-02-16.txt:17:46:02: <ehird> *thunk
+2009-02-16.txt:17:46:51: <ski__> no, code is not thunks
+2009-02-16.txt:17:47:12: <ski__> `eval' in lisps doesn't operate on thunks
+2009-03-27.txt:00:50:06: <ehird> pass the thunk
+2009-03-27.txt:00:59:08: <oerjan> (1) when you evaluate `dd you get not d, but a (d <d>) thunk like you mentioned
+2009-04-21.txt:20:06:17: <ehird> http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ ← now how do I do this with ext3...
+2009-04-21.txt:20:19:09: <ehird> AnMaster: the intel X25-M (best one): http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
+2009-04-21.txt:20:22:43: <ehird> AnMaster: any idea about http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/; it tells you how to do an alignment thing with ext4, can ext3 do that?
+2009-04-21.txt:20:31:43: <ehird> AnMaster: 'cuz of how ssds' blocks work, see http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
+2009-04-21.txt:20:35:16: <ehird> AnMaster: see http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
+2009-04-21.txt:22:20:14: <ehird> just trying to figure out how to do http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ without LVM or ext4
+2009-04-28.txt:19:42:02: <AnMaster> ehird, "<MyCatVerbs> ehird: I would guess that they're fairly lazy, so you end up with enormous thunks." wth did that mean
+2009-04-28.txt:19:42:13: <ehird> 19:41 MyCatVerbs: ehird: I would guess that they're fairly lazy, so you end up with enormous thunks.
+2009-04-28.txt:19:42:46: <AnMaster> not the details, just what a thunk is
+2009-04-28.txt:19:42:56: <ehird> AnMaster: A thunk is a function that evaluates the lazy code.
+2009-04-28.txt:19:43:04: <ehird> So (2+2) is a thunk that calculates 2+2 then replaces it with that value
+2009-04-28.txt:19:43:08: <ehird> Where 2, 2, and (+) are also thunks
+2009-04-29.txt:17:44:24: <Deewiant> ehird: My guess is you're building up a thunkpile of Map.inserts which is what overflows your stack
+2009-04-29.txt:17:45:36: <Deewiant> ehird: Don't build up a thunkpile like that?
+2009-04-29.txt:17:46:12: <Deewiant> ehird: Given that you're using crap like {-# UNPACK #-} I figured you'd know how to force a thunk
+2009-05-08.txt:20:11:29: <ehird> pikhq: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
+2009-05-10.txt:22:40:40: <ehird> optional procedure:  (with-input-from-file string thunk)
+2009-05-10.txt:22:40:40: <ehird> optional procedure:  (with-output-to-file string thunk)
+2009-05-21.txt:20:00:17: <GregorR-L> *ka-THUNK*
+2009-05-30.txt:00:49:25: <ehird> GregorR-L: I'm thunkin'
+2009-06-21.txt:20:31:08: <ehird> bsmntbombdood_: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
+2009-06-22.txt:22:37:20: <ehird> SimonRC: Methunk you mean "Methunk you mean"
+2009-06-24.txt:20:17:02: <pikhq> DOS thunk, I'd imagine.
+2009-07-12.txt:00:03:52: <ehird> isSigned f = thunk (waitForInput f)
+2009-07-12.txt:00:03:58: <ehird> isSigned f = analyze (thunk (waitForInput f))
+2009-07-21.txt:01:39:20: * pikhq returns a vomit thunk
+2009-07-21.txt:01:40:00: <ehird> pikhq: a vomit thunk?
+2009-07-21.txt:01:40:07: <ehird> maybe a thunk of type IO Vomit?
+2009-07-21.txt:01:40:17: <pikhq> ehird: It's a thunk that, when evaluated, results in vomit.
+2009-08-07.txt:23:54:34: <ehird> human communication being subjective and imprecise. who'da thunk it!
+2009-08-09.txt:00:19:17: <pikhq> It takes less code to talk to the VGA card manually then it does to thunk to the BIOS...
+2009-08-09.txt:00:20:01: <AnMaster> pikhq, well iirc the first few lines are traditionally done by thunk to BIOS. Like when grub is printing "Loading stage 1.5"
+2009-08-10.txt:16:36:40: <ehird> QEMU can launch Linux or Darwin/Mac OS X processes compiled for one CPU on another CPU. Target OS system calls are thunked for endianness and 32/64 bit mismatches.]]
+2009-09-22.txt:03:47:43: <augur> all haskell function arguments are effectively thunks
+2009-10-02.txt:12:10:39: <fungot> ehird95: you should have called it ++c c-- --c) and ( compose-event-monitor thunk2 em), when a context of an interpreter
+2009-10-02.txt:12:11:34: <ehird95> ++cc c-- --c) and ( compose-event-monitor thunk2 em)?
+2009-11-23.txt:01:14:21: <coppro> ehird: A conditional jump to a thunk
+2009-12-15.txt:22:12:06: <AnMaster> ehirdiphone, well, non-trivial to do on the fly, probably easier to put a thunking layer in between
+2009-12-22.txt:19:27:53: <ehird> but it looks like <thunk> to haskell, which if you examine the head becomes 1:<thunk>
+2009-12-22.txt:19:28:01: <ehird> if you examine the head of the tail it becomes 1:(1:<thunk>)
+2009-12-24.txt:01:04:37: <ehird_> pikhq: I tried evaluating that, but the thunk diverged.
+2010-01-08.txt:15:21:37: <ehird> Think thunks.
+2010-01-16.txt:13:25:18: <ehird> oklopol: stfu, i'm musing about thoughts that were not thunk in this quantum stream but were thunk in some other quantum stream, that is unthunk thoughts, affecting the (I postulate for no particular reason commutative) p-therefore-q-as-a-thought-process operation so that you think a thought, and then you think (because of the unthinking) a thought by which you derive the previous thought, but this turns out to be a contradiction that you couldn't check
+2010-01-16.txt:13:28:44: <ehird> hmm so if you can communicate across many-worlds branches, then you could cause unthunk thoughts to mingle with this thought stream and become thunk thoughts, thus removing the permutations they performed on your thoughts and instead becoming first-class citizens (albeit being q-thought-before-p in (p therefore q)) of thought
+2010-01-16.txt:13:29:05: <ehird> therefore, achieving "enlightenment" could be modelled as having no unthunk thoughts; having every thought be thunk by quantum methods
+2010-01-16.txt:13:33:33: <ehird> oklopol: maybe you unthunk something in the far, far future about trees that is bad
+2010-01-16.txt:13:34:52: <oklopol> we could model thinking as a process that takes unthunk thoughts, unprocessed data, and outputs thunk thoughts, some sort of results. if there were multiple worlds with the same entity existing multiple times, living almost exactly the same lives, he could skip ahead in his thoughts by accessing the thunk thoughts of a fellow him.
+2010-01-16.txt:13:36:22: <ehird> oklopol: let's mutually thunk the other's unthunk thoughts so as to expand both our repertoire of thoughts (← this is what sex is like post-singularity)
+2010-01-16.txt:13:37:58: <ehird> post-singularity thunk sex.
+2010-01-16.txt:13:44:18: <ehird> you have been acting to cause the recession since before it began, and the p in p-therefore-q that lead you to doing this was only thunk then
+2010-01-18.txt:01:01:07: <uorygl>   some stuff that makes it return a thunk
+2010-01-18.txt:17:39:04: <pikhq> The only way I could make this uglier is to do thunks.
+2010-01-26.txt:19:28:24: <pikhq> Now if I could just figure out why the crap this darned thing is only dethunking once.
+2010-01-26.txt:23:45:11: <pikhq> And thunks confuse it greatly.
+2010-01-27.txt:21:00:54: <pikhq> main.c:112:1: error: pasting ""S"" and "_thunk" does not give a valid preprocessing token
+2010-01-27.txt:21:01:38: <pikhq> AnMaster: name##_thunk
+2010-01-27.txt:21:03:03: <pikhq> static void *__LAMBDA__I_thunk (void*c) { { { return ({ void* __LAMBDA__ (void *_, closure x) { { printf("I thunk (%p)!\n", x); return x; }; }; closure _x = ({ closure _x = xgc_malloc; _x->func(_x->close, sizeof(struct closure)); }); *_x = (struct closure){ __LAMBDA__, ((void *)0) }; _x; }); }; }; } static struct closure __LAMBDA__I_thunk_ = { __LAMBDA__I_thunk, ((void *)0) }; static closure I_thunk = &__LAMBDA__I_thunk_;; static struct th
+2010-01-27.txt:21:07:03: <pikhq> So many thunks...
+2010-01-29.txt:17:39:31: <pikhq> PITA, but less of a PITA than figuring out where in the world the thunks are going.
+2010-01-29.txt:17:49:28: <pikhq>   dethunk(callerT(toChurch(2), 2, tmp, I));
+2010-01-29.txt:18:39:35: <pikhq> Anyways. Now I just make my churchSucc thunk compile that, and voila.
+2010-01-29.txt:18:42:26: <pikhq> global_thunk(static, churchSucc, NULL, {return dethunk(eval(genList("(S(KS)K)(S((S(KS)K)(S(KS)K)I))((S(S(K(S(KS)K))S)(KK))((S(KS)K)(S(S(K(S(KS)K))S)(KK))((S(KS)K)((S(KS)K)(S(KS)K))((S(S(K(S(KS)K))S)(KK))((S(KS)K)(S(KS)K)I)I)))I)")));});
+2010-01-29.txt:22:12:37: <pikhq> Well, that explains at least *some* things. church1's thunks are the only ones being called.
+2010-01-29.txt:22:13:02: <pikhq> Somehow, it never ends up dethunking its arguments.
+2010-01-29.txt:22:13:08: <pikhq> Even the one that it dethunks and calls.
+2010-01-30.txt:05:51:25: <pikhq> So if you're doing a lot of arithmetic, it won't be thunking to and from an integer.
+2010-01-30.txt:05:52:09: <pikhq> Sorry, I've been writing the word "thunk" a lot today. :P
+2010-01-30.txt:05:52:23: <Gregor> Thunks thunking thunks thunk thunk thunk.
+2010-01-30.txt:05:52:48: <pikhq> It tends to thunk.
+2010-01-31.txt:02:11:23: <pikhq> Instead of a thunk.
+2010-01-31.txt:02:15:16: <pikhq> Thunk 0x6382a0 is not a valid thunk. 0x6382a0 = {tag = 4198720, union {func = 0x638300, data = 0x638300}
+2010-01-31.txt:02:15:47: <pikhq> Note: enum {THUNK_UNEVAL, THUNK_EVAL} tag;
+2010-01-31.txt:02:28:15: <pikhq> The issue is that somehow, someone is trying to dethunk a closure.
+2010-01-31.txt:02:28:23: <Sgeo> What's a thunk?
+2010-01-31.txt:02:28:33: * AnMaster thunks Sgeo on the head
+2010-01-31.txt:02:29:06: <pikhq> struct thunk {enum {THUNK_UNEVAL, THUNK_EVAL} tag;union {closure func;void *data;};}
+2010-01-31.txt:02:30:42: <pikhq> enum {THUNK_UNEVAL, THUNK_EVAL} is the enum declaration...
+2010-01-31.txt:02:32:38: <pikhq> The thing is, 0x6382a0 is a pointer to a *closure*, not a thunk.
+2010-01-31.txt:02:33:25: <pikhq> dethunk results in a void*.
+2010-01-31.txt:02:35:48: <pikhq> I have a couple. They are closure and thunk.
+2010-01-31.txt:02:38:26: * pikhq looks for anything that *doesn't* return a thunk
+2010-01-31.txt:02:38:45: <pikhq> (aside from my thunks, which absolutely should not return a thunk)
+2010-01-31.txt:02:51:33: <Sgeo> I still don't know what thunk is supposed to mean >.>
+2010-01-31.txt:03:03:47: <pikhq> main.c:360:1: error: unterminated argument list invoking macro "global_thunk"
+2010-01-31.txt:03:47:01: * pikhq is still amused by the lambdas with thunks that compile them from S and K.
+2010-01-31.txt:19:57:21: <pikhq> From the looks of things, its the fact that S and K get dethunked for everything.
+2010-01-31.txt:23:29:27: <pikhq> It would seem that all my thunks retained values in their closure even after being allocated.
+2010-02-01.txt:01:34:57: <pikhq> In this case, I was holding on to references before dethunking something.
+2010-02-01.txt:01:35:10: <pikhq> And a dethunk can take, well, any amount of time.
+2010-02-01.txt:01:39:07: <pikhq> The biggest gain I got was making the dethunk function actually remove its closure... That's such a ridiculous source of memory leaks.
+2010-02-13.txt:00:52:51: <alise> x; y = x (thunk y)
+2010-02-13.txt:00:53:34: <alise> print "hi" (thunk (print "yo" (thunk (getLine (lambda x (print x))))))
+2010-02-13.txt:00:53:46: <alise> x; = x (thunk nil)
+2010-03-02.txt:20:06:11: <alise> Who'da thunk it
+2010-03-15.txt:05:54:01: <myndzi> sure! one of the reasons lojban was thunk up was to have a language that could be unambiguously machine-processed
+2010-04-09.txt:19:07:54: <Deewiant> I assume that parametrizable languages can be thunk of as one language
+2010-04-24.txt:02:08:44: <oklopod> i would've thunk p v ~p just says in any model of the system one is true, if we can't prove either then it depends on the model which one is true
+2010-04-29.txt:16:03:02: <Rugxulo> who'd thunk it?   ^_^
+2010-06-07.txt:17:54:33: <ais523> AnMaster: no, think of it more like thunks
+2010-06-07.txt:17:55:28: <AnMaster> ais523, um? was ages ago I heard about "thunks" last, and it was something related to windows 3.1 iirc
+2010-06-21.txt:05:07:15: <coppro> don't they usually have a dynamic thunk?
+2010-06-28.txt:19:31:58: <pikhq> Gregor-W: Basically: we try to offer native libraries as much as possible. However, allow for access to host libraries by writing thunks to transfer between the ABIs. My opinion on this may well change if writing thunks is going to be more difficult than a few lines of assembly or C per function.
+2010-06-28.txt:19:32:28: <Gregor-W> pikhq: I get the feeling that thunks will basically be lunacy. Just my own fears manifesting themselves though ^^
+2010-06-28.txt:19:32:52: <pikhq> Gregor-W: On Linux, thunks would probably be trivial. On OS X, not much work.
+2010-06-28.txt:19:33:50: <Gregor-W> pikhq: No use making thunks that only work on one platform ;)
+2010-06-28.txt:19:38:28: <zzo38> I think you should just have a file gelfload.conf with commands such as DYNLINK, STUB, SYSCALL, THUNKCODE, TRANSLATE, and so on.
+2010-06-28.txt:19:40:33: <zzo38> Doing it this way I specified can mean that you can change the system call gates and thunk codes and so on, for different systems and for different libraries you might use
+2010-06-28.txt:19:44:48: <pikhq> The only thick thing here is thunking through to the host ABI.
+2010-07-16.txt:15:08:23: <alise> CakeProphet: Yeah, turns out Genie is a language. Who'da thunk it?
+2010-07-25.txt:22:10:04: <pikhq> Alternately, you will have absurdly large *thunks*.
+2010-08-05.txt:21:59:44: <oerjan> however this has the _practical_ consequence of evaluating the thunk for the first argument, with all usual caching results and plugging of memory leaks
+2010-08-11.txt:23:20:48: <augur> but in the context of the metaphor i decided that i must be a thunk, not a proper function or else i wasnt going to fall asleep any time soon
+2010-08-11.txt:23:21:49: <Phantom_Hoover> augur, no such things as thunks in the pure lambda calculus, though.
+2010-10-07.txt:20:59:10: <pikhq> Especially where I copy a thunk before it's evaluated so that I can do an infinite list of input.
+2010-11-09.txt:19:43:02: <elliott> olsner: (so apparently sizeof("abc"+1) = 2, who'da thunk it? I guess?)
+2010-12-18.txt:21:12:43: <elliott> Who'da thunk it.
+2010-12-27.txt:18:45:10: <elliott> Ilari: Switch statements being slow, who'da thunk it.
+2011-01-03.txt:23:44:23: <olsner> elliott: continuing from before, what I have in mind is not really "macros" in the typical code-that-makes-code macros... rather something like type classes, let's say it'd let you define a category of "boxed values" and describe that they are thunks that get forced when looked at
+2011-02-01.txt:06:36:08: <oerjan> in haskell boxed also implies the possibility of a lazy thunk to be evaluated
+2011-02-09.txt:01:56:08: <quintopia> who'dathunk that'd work so well
+2011-02-09.txt:01:56:18: <myndzi> i woulda thunk :)
+2011-02-11.txt:17:59:14: <elliott> apparently the programs . and [-] draw, whodathunkit?
+2011-02-15.txt:01:45:56: <quintopia> who'dathunk?
+2011-02-20.txt:00:13:20: <quintopia> usually it's because they involve some sort of unusual control flow that requires funky ways of thunking
+2011-02-22.txt:03:32:28: <oerjan> *thunk
+2011-02-22.txt:03:33:26: <elliott> oerjan: not sure how to avoid building a large thunk there, anyway
+2011-02-22.txt:19:39:30: <olsner> and I think you can see when thunks get allocated instead of plain values getting returned
+2011-02-22.txt:22:37:37: <elliott_> maybe it's thunked
+2011-02-27.txt:00:58:56: <elliott> good triumphs over evil, who'da thunk it?!
+2011-03-03.txt:16:56:52: <ais523> it's full of thunks and that sort of thing
+2011-03-12.txt:17:49:37: <elliott> I guess something that lets you write haskell.run_io(haskell.eval("putStrLn").call(Thunk(lambda: haskell.make_string("Hello, world!"))))
+2011-03-14.txt:07:44:27: <elliott> from now on I will talk only in Has<THUNK>
+2011-03-14.txt:07:48:55: <coppro> 03:28 < elliott> from now on I will talk only in Has<THUNK>
+2011-04-03.txt:08:31:58: <elliott> I've been thunkin'.
+2011-04-05.txt:22:08:08: <tswett> Who'dathunk?
+2011-05-13.txt:01:10:44: <elliott> Remember that the blocks execute /every/ time the thunk is left, including multiple times thanks to CALL-WITH-CURRENT-CONTINUATION.
+2011-05-13.txt:01:17:32: <elliott> (Thunk passed is the same as (lambda () (values)).)
+2011-05-13.txt:17:18:06: <ais523> so long as you have some other way to not call a function argument immediately (say, call-by-name, thunking by hand, etc)
+2011-05-17.txt:15:17:33: <elliott_> It just means it'll be evaluated before the thunk is.
+2011-05-20.txt:19:36:11: <Deewiant> Who'da thunk it
+2011-05-21.txt:20:29:06: <elliott> you'd still do all the thunks
+2011-05-21.txt:20:31:56: <elliott> oerjan: Ideally the thunks would become explicit too...
+2011-05-22.txt:04:45:49: <elliott_> I was thinking that you could do CPS if you just returned /immediately/ with a thunk
+2011-05-22.txt:04:45:57: <elliott_> and that thunk would then do one CPS-step when called, and return another thunk, etc.
+2011-05-27.txt:06:08:56: <elliott_> i think it's building up EVERY SINGLE THUNK
+2011-05-27.txt:19:31:56: <pikhq> And it doesn't seem to be because of thunks...
+2011-06-02.txt:12:21:30: <elliott> hmm, you basically have to thunk everything in an unlambda compiler, right?
+2011-06-02.txt:12:25:13: <elliott> if the whole program is a thunk like this
+2011-06-02.txt:12:29:10: <elliott> oerjan: it even made the whole thunk thing transparent :(
+2011-06-02.txt:12:39:39: <elliott> oerjan: basically i was trying to unify thunks and functions...
+2011-06-02.txt:12:39:54: <elliott> oerjan: by just making thunks pretend they're the function they evaluate to, by forcing themselves and then passing that argument on
+2011-06-02.txt:12:49:57: <elliott> oerjan: thunks are ugly :(
+2011-06-02.txt:13:05:08: <elliott> oerjan: so I don't have to do the Haskellian "thunks stub themselves out with {return value;} upon evaluation"?
+2011-06-02.txt:19:44:37: <elliott_> THUNK(a, APPLY(&prim_out_x, &prim_i))
+2011-06-02.txt:19:44:37: <elliott_> THUNK(b, APPLY(&prim_d, &thk_a))
+2011-06-02.txt:19:44:37: <elliott_> THUNK(c, APPLY(&prim_i, &thk_b))
+2011-06-02.txt:19:44:37: <elliott_> THUNK(d, APPLY(&thk_c, &prim_i))
+2011-06-02.txt:19:44:54: <elliott_> and so fold a bunch of thunks into one
+2011-06-02.txt:20:18:31: <elliott_> THUNK(a, APPLY(&prim_s, &prim_d))
+2011-06-02.txt:20:18:32: <elliott_> THUNK(b, APPLY(&prim_k, &prim_out_x))
+2011-06-02.txt:20:18:34: <elliott_> THUNK(c, APPLY(&thk_a, &thk_b))
+2011-06-02.txt:20:18:36: <elliott_> THUNK(d, APPLY(&thk_c, &prim_out_y))
+2011-06-02.txt:20:20:36: <elliott_> pikhq_: its not similar really, the thunks are pretty different
+2011-06-07.txt:23:10:06: <CakeProphet> massive thunk registers.
+2011-06-08.txt:18:50:23: <ais523> elliott: well, you could take an unapplied or thunked continuation, and give it as an argument to a continuation, without any real issues
+2011-06-08.txt:21:55:32: <elliott> > thanks "thunks"
+2011-06-08.txt:21:55:34: <lambdabot>   Thanks, thunks. Thunks.
+2011-06-09.txt:00:45:51: <oerjan> it is possible there's some huge thunk building because of this...
+2011-06-21.txt:13:06:59: <elliott_> Deewiant: Int thunks :-)
+2011-06-21.txt:19:32:11: <pikhq_> Probably building up a thunk.
+2011-06-21.txt:19:39:53: <oerjan> elliott_: perhaps that fmap is also building thunks of what to apply
+2011-06-23.txt:03:59:35: <elliott_> in a misguided attempt to reduce a thunk leak that isn't there
+2011-06-23.txt:04:00:42: <elliott_> CakeProphet: btw, if countBytes wasn't strict in n, it would blow up a huge thunk.
+2011-06-24.txt:21:50:54: <elliott> oerjan: "You cannot use atomically inside an unsafePerformIO or unsafeInterleaveIO. Any attempt to do so will result in a runtime error. (Reason: allowing this would effectively allow a transaction inside a transaction, depending on exactly when the thunk is evaluated.)"
+2011-06-25.txt:11:13:51: <elliott> oerjan: i'm thinking you could pass a thunk to the folding function instead
+2011-06-25.txt:11:15:12: <elliott> may want the thunk first
+2011-06-25.txt:11:22:12: <oerjan> well you need your thunk to self-duplicate so you can use it at the next step
+2011-06-25.txt:11:22:27: <elliott> oerjan: the idea is that the list itself handles the thunk... i think
+2011-06-25.txt:11:28:07: <oerjan> elliott: if the list handles the thunk, then that means the list automatically folds, which means you must always iterate through all of it...
+2011-06-26.txt:20:47:08: <oerjan> foldl can build up a thunk if ghc cannot detect that the folding operation is strict
+2011-06-29.txt:19:20:23: <elliott> Vorpal: ok see http://web.archive.org/web/20090224074532/http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
+2011-06-30.txt:02:58:10: <oerjan> i have a hunch that that would have overflowed the stack if it actually got to finish building the thunks...
+2011-07-01.txt:20:05:25: <elliott> It's just reducing a thunk
+2011-07-01.txt:20:05:47: <newsham> elliott: yah, replacing the thunk with its result.. memoization.
+2011-07-01.txt:20:06:14: <elliott> newsham: it's more like memoisation is ak ind of thunk reduction.
+2011-07-01.txt:20:09:11: <elliott> oerjan: I'm just saying that any implementation that _didn't_ reduce thunks in such a way would be completely braindead
+2011-07-01.txt:20:11:17: <elliott> newsham: Anyway, there is no sharing or thunks as such in my model
+2011-07-01.txt:20:13:18: <newsham> [10:08] < elliott> newsham: Anyway, there is no sharing or thunks as such in my model
+2011-07-06.txt:08:38:41: <elliott> Vorpal: because everything is in a thunk
+2011-07-08.txt:08:39:07: <elliott> when x is bound to an exception-raising thunk.
+2011-07-23.txt:02:37:26: <elliott_> Think thunks
+2011-07-23.txt:02:37:48: <elliott_> You're deleting the thunk that represents that running code
+2011-08-05.txt:20:24:32: <elliott> Cheery: Thunk.
+[too many lines; stopping]