< 1082852444 0 :lament!~lament@S0106000d3a705704.vc.shawcable.net JOIN :#esoteric < 1082863990 0 :lament!unknown@unknown.invalid QUIT :"Leaving" < 1082865264 0 :int-e!unknown@unknown.invalid QUIT :"Client exiting" < 1082879999 0 :clog!unknown@unknown.invalid QUIT :ended < 1082880000 0 :clog!unknown@unknown.invalid JOIN :#esoteric < 1082900089 0 :edwinb!dcs3ecb@cs-186.dur.ac.uk JOIN :#esoteric < 1082920416 0 :lament!~lament@S0106000d3a705704.vc.shawcable.net JOIN :#esoteric < 1082927073 0 :heatsink!~heatsink@dan0612.urh.uiuc.edu JOIN :#esoteric < 1082927221 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :ACTION was thinking about compiling unlambda < 1082927291 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I think it's possible, though its creator thinks the d operator makes it impossible < 1082927516 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :I've got a solution for d, which is to identify all compile-time instances of d and reorder execution appropriately < 1082927589 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :The only other times 'd' might affect execution order is in an ```sXYZ evaluation, but that's easy enough to check at runtime < 1082927709 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :There seems to be a lot of brainfuck in the archives < 1082929169 0 :mtve!unknown@unknown.invalid PRIVMSG #esoteric :compile-time? shouldn't it appear as a result of evaluation? < 1082929617 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :mtve: yes, it can < 1082929712 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :But when d is applied to an already-evaluated expression, it acts no different from i < 1082929752 0 :mtve!unknown@unknown.invalid PRIVMSG #esoteric :sorry for get into discussion, i'm far from expert on functional programming :) i even don't understand your compiling concept, compiling to what? < 1082929756 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :The only time d is applied to an expression that hasn't been evaluated at run-time is when s is being evaluated < 1082929793 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :mtve: compiling to another programming language, I'm going for scheme because it should be the simplest < 1082929869 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :The idea is to make functions that have the behavior of the unlambda operators, < 1082929951 0 :heatsink!unknown@unknown.invalid PRIVMSG #esoteric :Rather than an "interpreter" function that evaluates by reading some unlambda code and performing its behavior < 1082929983 0 :mtve!unknown@unknown.invalid PRIVMSG #esoteric :i see. < 1082934683 0 :kosmikus!~andres@kosmikus.developer.gentoo JOIN :#esoteric < 1082936115 0 :heatsink!unknown@unknown.invalid QUIT :"Leaving"