00:20:44 -!- lament has joined.
03:33:10 -!- lament has quit ("Leaving").
03:54:24 -!- int-e has quit ("Client exiting").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
13:34:49 -!- edwinb has joined.
19:13:36 -!- lament has joined.
21:04:33 -!- heatsink has joined.
21:07:01 * heatsink was thinking about compiling unlambda
21:08:11 <heatsink> I think it's possible, though its creator thinks the d operator makes it impossible
21:11:56 <heatsink> I've got a solution for d, which is to identify all compile-time instances of d and reorder execution appropriately
21:13:09 <heatsink> The only other times 'd' might affect execution order is in an ```sXYZ evaluation, but that's easy enough to check at runtime
21:15:09 <heatsink> There seems to be a lot of brainfuck in the archives
21:39:29 <mtve> compile-time?   shouldn't it appear as a result of evaluation?
21:46:57 <heatsink> mtve: yes, it can
21:48:32 <heatsink> But when d is applied to an already-evaluated expression, it acts no different from i
21:49:12 <mtve> sorry for get into discussion, i'm far from expert on functional programming :)   i even don't understand your compiling concept, compiling to what?
21:49:16 <heatsink> The only time d is applied to an expression that hasn't been evaluated at run-time is when s is being evaluated
21:49:53 <heatsink> mtve: compiling to another programming language, I'm going for scheme because it should be the simplest
21:51:09 <heatsink> The idea is to make functions that have the behavior of the unlambda operators,
21:52:31 <heatsink> Rather than an "interpreter" function that evaluates by reading some unlambda code and performing its behavior
21:53:03 <mtve> i see.
23:11:23 -!- kosmikus has joined.
23:35:15 -!- heatsink has quit ("Leaving").