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]