00:01:32 <ehird`> void ul_call(ul_obj o) { top: o->fp(); if (o->cdr) { o = o->cdr; goto top; } }
00:01:35 <ehird`> poor man's tail recursion
00:01:51 <ehird`> actually, i should make that pop
00:01:55 <ehird`> instead of take an arg
00:04:01 <ehird`> oerjan: this should actually be pretty fast shouldn't it?
00:04:17 <ehird`> how do i represent that with my struct?
00:04:22 <pikhq> In Agora, I am Champion and Minister Without Portfolio.
00:04:27 <pikhq> But, I never won the game.
00:04:39 <ehird`> i thought you meant my unlambda compilation efforts!
00:04:42 <pikhq> ehird`: That, too, is quite interesting.
00:04:50 <ehird`> oerjan: i think i just need another entry in ul_obj
00:04:59 <pikhq> No, pure stupidity.
00:05:23 <pikhq> Champion was changed so that it was granted by the announcement of the Herald to someone who has won.
00:05:33 <pikhq> Minister Without Portfolio was changed similarly later. . .
00:05:41 <pikhq> But in that proposal, I was granted the patent title.
00:06:44 <oerjan> the obvious solution is to now request the patent title
00:07:16 <oerjan> Champion Not Created By Winning
00:07:17 <ehird`> i think my compiler architechture is pretty unique :P
00:09:23 <oerjan> ehird`: i don't see how your struct would deal well with (a)(b)*(c)*(d)*
00:10:33 <oerjan> assuming your (*fp)() always is first, that is still essentially a linked list, so needs linked list concatenation
00:11:28 <ehird`> * with stack=[a,b] is a->cdr = pop()
00:11:58 <ehird`> a with stack=[x] is a push with ... wait, i need to rethink this
00:12:09 <ehird`> there's no fp i could reasonably assign a run on 'x'
00:12:26 <oerjan> then you have to do deep copying when duplicating things
00:12:35 <ehird`> i just have to check for ->inner
00:12:42 <ehird`> if it's there, push that.
00:13:01 <oerjan> i.e. you are doing hideously mutation there, which _will_ trip you up
00:13:57 <oerjan> i.e. how would you do :*:*:* ?
00:14:49 <oerjan> ehird`> * with stack=[a,b] is a->cdr = pop()
00:15:04 <oerjan> actually my point is, what do you do if a _already_ has a cdr?
00:15:38 <oerjan> (well one point. : may still make things even worse later)
00:16:07 <ehird`> oerjan: that's a good point...
00:16:15 <ehird`> oerjan: So! Suggest another way.
00:16:36 <oerjan> construct a new struct, with car a and cdr b
00:17:07 <ehird`> so typedef void ul_obj;
00:17:27 <ehird`> with a char tag at the front 0=ul_obj 1=ul_pair
00:17:32 <ehird`> and distinguish them both?
00:18:12 <ehird`> oerjan: ul_atom still has a ul_obj *inner, right?
00:19:19 <oerjan> of course i am really thinking functionally, so i envision all the structs as immutable
00:19:34 <ehird`> car a, cdr b is immutable
00:19:52 <ehird`> but mostly, yeah, i just cons a lot
00:20:08 <oerjan> the point is, if you don't make things immutable then : will require deep copying sometimes
00:20:41 <oerjan> for example, consider ::*::*::*
00:21:04 <oerjan> or anything which leaves a copy of the old version on the stack
00:21:26 <ehird`> so it's ALWAYS one cons.
00:21:45 <ehird`> oerjan: it's worth noting you should have thought of the consequences: now ul_call must be recursive.
00:21:56 <ehird`> so i have an arbitary restriction i didn't before.
00:22:06 <ehird`> remember: recursion in C barely ever works well
00:22:13 <ehird`> probably worse than the linked-list slowness.
00:22:20 -!- Jontte has quit ("Konversation terminated!").
00:22:44 <oerjan> you can make your own execution stack
00:23:06 <oerjan> push the cdr there before going to the car
00:23:20 <ehird`> you do know that all flow control involves lots of lots of ^ right?
00:23:28 <ehird`> normally with hundreds of appends
00:23:31 <ehird`> before my call was tail-recursive
00:23:36 <ehird`> but now i'm going to have Real Big Problems
00:23:49 <ehird`> 's a pain and will probably run out soon
00:24:06 <ehird`> oerjan: do you accept now that my linnked list was better :P
00:24:33 <oerjan> i now accept that there are trade-offs
00:24:38 <ehird`> might be slower but 1. 34583475x faster than any of the interpreters out there anyway (most use O(n) concats anyway) 2. who will notice
00:24:53 <ehird`> mine will at least run all ul programs perfectly
00:24:57 <oerjan> also, that i shouldn't be considered as having the final word on anything involving C or similar low-level languages
00:25:53 <ehird`> so for now i'm going to use a linked list
00:26:27 <oerjan> but anyway, you should think carefully about what is immutable and what requires deep restructuring
00:26:49 <ehird`> the js interp and my scheme interp do the same O(n) concats.
00:27:05 <ehird`> mine is in /C/ fer gods sake, and the code itself is compiled 100%, it's gonna be blazing fast for underload
00:37:38 <ehird`> ok i have my whole prelude/postlude! :D
00:37:49 <ehird`> that's most of the work done, actually
00:38:22 <ehird`> i defined all of the operations
00:38:50 <ehird`> oerjan: my compiler output will be weird :)
00:39:03 <ehird`> ul_push(ul_func_4, "...code for that...");
00:39:16 <ehird`> and it'll come out in ul_func_1,ul_func_2,... order
00:39:32 <ehird`> so you'll get a ref to the functions and the complete code of the following functions before they come :)
00:39:47 <oerjan> i have sort of assumed that compiler outputs _are_ weird.
00:39:50 <ehird`> if anything this proves you can probably compile unlambda ok
00:40:09 <ehird`> my ul2c function will be VERY imperative...
00:40:11 <oerjan> unless the languages compiled from/to are particularly close
00:40:25 <ehird`> mostly define/sets/etc
00:40:35 <ehird`> because i cba to do it another way because my compiler arch is crazy
00:43:13 <ehird`> oerjan: shit, compiling literal nested ()s will be a pain :)
00:44:20 <ehird`> ((abc)def(ghi)) -> ul_push(ul_func_1, "abc"); ul_wrap(); ul_push(ul_func_2, "def"); ul_concat(); ul_push(ul_func_3, "ghi"); ul_wrap(); ul_concat();
00:44:50 <ehird`> to put it another way, ((abc)def(ghi)) -> (abc)a(def)*(ghi)a*
00:45:11 <ehird`> oerjan: but i don't think that will have a big effect on performance.
00:45:45 <ehird`> oerjan: i mean, your original source code isn't used much - mostly you're doing the operations themsevles :)
00:47:54 <oerjan> i don't recall, i guess you cannot declare struct constants involving function pointers?
00:50:15 <oerjan> i mean you are not actually compiling the structures themselves, you are compiling how to build them
00:50:32 <ehird`> i can't compile the structures themselves
00:50:38 -!- calamari has joined.
00:50:45 <oerjan> i suppose C does not support it
00:50:54 <ehird`> it would if ul_push didn't push to a stack
00:50:58 <ehird`> it's just simpler this way anyway
00:52:54 <oerjan> ((abc)def(ghi)) -> ul_push(ul_func_0, "(abc)def(ghi)");
00:53:10 <ehird`> because what if ul_func_0 wants to execute (abc)
00:54:01 <oerjan> you would define ul_func_0 as what actually executes (abc)def(ghi)
00:54:22 <oerjan> no need for the ul_concats though
00:55:11 <ehird`> anyway with your ul_func_0
00:55:27 <ehird`> like if ul_func_0 did loadsa funky ~ stuff
00:55:47 <oerjan> i.e. ul_func_0 () { ul_push(ul_func_1, "abc"); ul_func_2(); ul_push(ul_func_3, "ghi"); }
00:56:16 <ehird`> ul_push(ul_func_1, "abc"); ul_push(ul_func_3, "ghi");
00:56:25 <ehird`> where both 1 and 2 are {}
00:57:10 <oerjan> ul_func_2() would be something which called a,b,c in order
00:57:28 <ehird`> that would be inline, in ul_func_0
00:57:30 <oerjan> or perhaps just include those directly
00:58:10 <oerjan> i assumed they stood in for something arbitrary
00:58:10 <ehird`> a b and c have no meaning in underload
00:58:38 <oerjan> because you still want such things for printing
00:59:02 <oerjan> but if they had been :*: instead you would just inline that
00:59:07 <ehird`> i could actually add a debugger to this
00:59:14 <ehird`> since i have the current program at every step of the way...
01:00:12 <oerjan> debugger macros, that you could turn off/on with a flag
01:09:22 <ehird`> if this works first time
01:12:25 <oerjan> you'll have to borrow one from GregorR then.
01:14:12 <Slereah> We don't want him choking.
01:16:36 <Slereah> Is there a Rube interpreter somewhere?
01:16:57 <Slereah> The Cat's eye page isn't even in archives.org
01:17:17 <Slereah> (Well, except the java interpreter)
01:17:54 <oerjan> Slereah: um catseye.webhop.something has been acting up, try catseye.tc i think it is
01:19:23 * oerjan wonders if you can put templates in wiki urls
01:19:46 <oerjan> cpressey's webpage moves so often it could need one... :D
01:20:12 <ehird`> i have errorrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrs, oerjan!!!!!!!!!!!!!!!!!!!!!!!!!
01:20:22 <ehird`> I use ul_func_N without predeclaring them
01:20:50 <oerjan> as eating hats can be harmful to your health, i think
01:21:02 <Slereah> Well, depends if it's an edible hat
01:21:09 <Slereah> Like edible panties, but less erotic.
01:23:41 <ehird`> (:aSS):aSS doesn't work
01:23:45 <ehird`> ERROR -- popped from empty stack
01:24:51 <ehird`> time to add debug code
01:26:15 <ehird`> oerjan: can you check my primitives to see if they have obvious errors?
01:26:24 <ehird`> i think i have a basic logical error in one but i just cant see it
01:26:49 <ehird`> http://rafb.net/p/XEGp7F68.html
01:26:56 -!- sebbu has quit (Success).
01:28:39 <ehird`> ul_wrap doesn't actually push
01:28:40 <oerjan> ouch i cannot read this
01:28:47 <ehird`> sorry for the lack of indentation, oerjan
01:28:53 <ehird`> it's inlined as a string in my scheme program
01:29:02 <oerjan> um i'm not talking about formatting
01:29:02 <ehird`> it's object code, anyway
01:29:10 <ehird`> the low-levelness of C ;)
01:29:46 <oerjan> i was going to suggest some tests though
01:30:01 <oerjan> (test):SS for : for example
01:31:21 <ehird`> I COMPILED FUCKING >UNDERLOAD<
01:32:06 <ehird`> (()(*))(~:^:S*a~^a~!~*~:(/)S^):^ does not compile
01:32:45 <ehird`> void (*ul_func_1)(); ul_push(ul_func_1, "()(*)"); void (*ul_func_2)(); ul_push(ul_func_2, "()(*)");
01:33:19 <oerjan> compile-time infinite loop?
01:33:48 <ehird`> "(~:^:S*a~^a~!~*~:(/)S^):^"
01:33:54 <ehird`> and continues outputting that ()(*)
01:34:09 <ehird`> i pass prog to find-matching-paren
01:34:35 <ehird`> void ul_func_2(void) {
01:34:36 <ehird`> void ul_func_2(void) {
01:45:15 <ehird`> this makes me angry >:(
01:45:45 <Slereah> "You wouldn't like me when I'm angry!"
01:57:11 <ehird`> zsh: segmentation fault ./out
02:01:29 <ehird`> ((Hello, world!))(S)*^ ; equivilent to (Hello, world!)S
02:14:56 <ehird`> my fp is being set to NULL somewhere.
02:17:27 -!- Slereah- has joined.
02:17:39 <Slereah-> NEVER HAVE I BEEN MORE ANGRY OR ORANGE
02:18:05 -!- Slereah has quit (Nick collision from services.).
02:18:10 -!- Slereah- has changed nick to Slereah.
02:18:20 <ehird`> BUT NEVER, EVER ASSIGN TO THEM
02:18:33 <Slereah> Pointers are for squares dude.
02:30:25 <ehird`> my compiler output is slow or: it's broken
02:30:52 <ehird`> the bottles of beer works
02:31:02 <ehird`> ill post the source tomorrow
02:32:42 -!- ehird` has changed nick to ehirdsleep.
02:47:22 -!- puzzlet has quit (Remote closed the connection).
02:47:25 -!- puzzlet has joined.
02:53:22 <Slereah> Hm. Wonder if I could make a RUBE-like, but based on Lemmings.
03:03:24 * Slereah slaps Slereah around a bit with a large trout
03:03:42 <Slereah> I should play some Lemmings, for further reflexion.
03:04:13 * oerjan sidles carefully away from the lambdabot possessed one
03:04:34 <oerjan> or perhaps that quote is even older, hm
03:05:02 <oerjan> * Slereah slaps Slereah around a bit with a large trout
03:05:23 <Slereah> Apparently, there's a button that will cause the action!
03:05:24 <oerjan> last i saw it was with lambdabot's @slap command
03:05:46 <Slereah> Well, when used on a nick, that is.
03:08:36 -!- puzzlet has quit (Remote closed the connection).
03:08:47 -!- puzzlet has joined.
03:08:48 <Slereah> Hm. Lemmings 95 won't run.
03:09:00 <Slereah> I'd better find the original CD and use it on my old laptop
04:11:21 <Slereah> Hm. Hello world! would be something like this : http://membres.lycos.fr/bewulf/Russell/Hello%20Lemming.txt
04:13:19 <Slereah> Although, the A should be on the floor.
04:13:38 <Slereah> (Incidentally, this is exactly the first level of the first Lemming game)
04:21:31 <pikhq> Would I be correct in assuming that you are going to design the spec so that that is true?
04:27:43 <Slereah> Well, the O is the gate that drops the little lemmings (waiting in the brackets), and the A is the exit (to the output)
04:28:47 <Slereah> Although the skills for the little buggers are going to be hard to implement.
04:31:53 <Slereah> I'll probably have to make some sort of command for a lemming to destroy or create a new instruction on the path.
05:29:24 -!- Slereah has quit (Read error: 110 (Connection timed out)).
05:41:14 -!- Slereah- has joined.
05:45:52 -!- Sgeo has quit (Read error: 110 (Connection timed out)).
05:51:30 -!- immibis has joined.
05:56:10 -!- oerjan has quit ("Cheap Freudian slips here").
05:57:02 -!- immibis has quit (Read error: 104 (Connection reset by peer)).
06:53:21 -!- calamari has quit ("Leaving").
07:06:52 -!- Jontte has joined.
07:07:40 <oklopol> just popping by to say nothing
07:56:34 -!- tesseracter has quit (Read error: 110 (Connection timed out)).
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:15:04 -!- tesseracter has joined.
08:51:04 -!- helios24_ has quit (Read error: 101 (Network is unreachable)).
09:00:42 -!- helios24 has joined.
09:14:25 -!- helios24_ has joined.
09:15:18 -!- helios24 has quit (Read error: 104 (Connection reset by peer)).
09:25:03 -!- helios24_ has quit (Remote closed the connection).
09:28:46 -!- sebbu has joined.
09:33:17 -!- helios24 has joined.
10:01:24 -!- Slereah- has changed nick to Slereah.
10:53:42 -!- JontteG has joined.
10:55:13 -!- JontteG has quit (Remote closed the connection).
13:18:36 -!- jix has joined.
13:24:31 -!- puzzlet_ has joined.
13:24:36 -!- puzzlet has quit (Remote closed the connection).
15:13:02 -!- calamari has joined.
15:29:45 -!- jix has quit (Nick collision from services.).
15:29:56 -!- jix has joined.
15:30:49 -!- calamari has quit ("Leaving").
15:34:28 -!- johnl has joined.
15:58:45 -!- tesseracter has quit (Remote closed the connection).
15:59:33 -!- ehirdsleep has changed nick to ehird`.
16:01:07 <ehird`> ais523 doesn't come here any more, after proving that the world is upside down and becoming filthy rich because of it :(
16:01:11 <ehird`> SO I CAN'T ASK HIM ABOUT UNDERLOAD.
16:02:37 <ehird`> ok i'll just ask people who know about underload. oklopol? maybe? pikhq?
16:02:46 <ehird`> which is the most common operation: * or ^
16:03:12 <ehird`> i can either have ^ potentially die if you use * a few hundred thousand times before using it, and have it relatively inefficient
16:03:34 <ehird`> where n = the amount of times you've used * before
16:03:45 <ehird`> because it uses a linked list, so it has to follow ->cdr
16:03:48 -!- sebbu2 has joined.
16:11:22 <ehird`> oooh, I hsould write a malbolge compiler
16:18:48 -!- sebbu has quit (Connection timed out).
16:25:37 <ehird`> is that even possible?
16:30:03 -!- timotiis has joined.
17:09:26 <ehird`> unlambda terminaology question:
17:09:32 <ehird`> in `xy, what is 'x' called and what is 'y'?
17:09:38 <ehird`> applicator and applicant?
17:31:26 <oklopol> ehird`: are you just using the underload compiler for compiling unlambda->underload programs?
17:31:52 <oklopol> no haha, just a question :\
17:32:00 <ehird`> that doesn't have c etc
17:32:21 <ehird`> http://www.esolangs.org/wiki/Underload look at the translations
17:32:25 <ehird`> it isn't full unlambda
17:32:35 <ehird`> oklopol: (unlambda->underload) is missing.
17:32:36 <oklopol> just answer my question :\
17:33:32 <oklopol> i mean, if you're just doing unlambda->underload programs -> C, then optimizations will be very different from if you want to compile any underload program fast.
17:33:44 <oklopol> i mean, into efficient code
17:34:50 <oklopol> i haven't coded much underload, but i don't think the best way to use it is to do unlambda->underload, and unlambda->underload programs converted using the instructions on the page probably are slower than programs written in 100% underload
17:35:32 <ehird`> what are you talking about.
17:36:05 <oklopol> "which is the most common operation: * or ^"
17:37:47 <oklopol> in case you aren't using your compiler for underload programs as such, but instead translating unlambda to underload to be able to compile unlambda to C
17:38:07 <ehird`> i'm compiling underload to C.
17:38:40 <ehird`> I can either make * very fast and ^ not guaranteed to always work if the program does an awful, awful lot, or i can make * very slow and ^ guaranteed to work
17:40:04 <oklopol> so unlambda wasn't involved at all?
17:40:14 <oklopol> i thought underload was just an intermediary step.
17:40:44 <oklopol> anyway, i'd say just use a tree structure and have both ^ and * be fast
17:42:02 <ehird`> unl->c and ul->c are two entirely different programs
17:42:11 <ehird`> ul->c, underload->c, is the only non-vaporware one right now
17:42:23 <ehird`> and, oklopol, that's the first option. but ^ then must be recursive.
17:42:34 <ehird`> and recursion in C = lawl, thus what i say about it in my first option
17:43:42 <oklopol> i don't see why you'd need to use recursion.
17:43:57 <oklopol> you mean when flattening the tree?
17:48:49 <ehird`> if you have a cons-pair of the tree
17:48:54 <ehird`> where both the car and cdr were once cons'd
17:48:59 <ehird`> then you have to recurse to call them both.
17:50:39 <ehird`> oklopol: and in C, recursion is very shaky
17:51:27 <oklopol> i have no idea what you mean by shake, and i don't see why you'd need recursion.
17:52:05 <oklopol> i do know that's easiest to do via recursion, but it's not hard without it...
17:53:12 <ehird`> if i don't have recursion, then i need to manually keep a stack
17:53:22 <ehird`> also, by shaky, i mean recursion in C /is a bad idea/
17:53:26 <ehird`> you never know when it might fuck up
17:56:53 <ehird`> oklopol: question - does your filesystem support > in filenames
17:57:34 <oklopol> i don't see why it might fuck up, but... err... i guess it does?
17:58:49 <oklopol> hmm, so basically what you are saying is you don't wanna use a tree-structure for efficiency because a tree-structure cannot be traversed efficiently?
17:59:16 <ehird`> but if ^ wasn't nearly as common as *, then ...
17:59:24 <ehird`> also, if i recurse in C then the call stack will run out *QUICKLY*
17:59:35 <ehird`> which is why most people avoid recursion in c
17:59:46 <oklopol> really? in my experience you can recurse as much as you like
18:01:00 <ehird`> try writing a recursive factorial in C
18:01:19 <oklopol> but you'll never get a tree that high
18:01:39 <ehird`> all unlambda programs cons like crazy
18:02:18 <oklopol> OK, tell me more about these programs doing over 10^300 catenations :-)
18:02:40 <oklopol> (assuming perfect balancing, which of course isn't realistic.)
18:03:15 <oklopol> height grows logarithmically, recursiong depth will *not* be a problem, ever.
18:03:45 <ehird`> http://esoteric.voxelperfect.net/wiki/Underload
18:03:49 <ehird`> (()(*))(~:^:S*a~^a~!~*~:(/)S^):^
18:03:53 <ehird`> that one does infinite conses.
18:05:15 <oklopol> technicality hats are the best ones
18:08:58 <ehird`> oklopol: do you think i should have my fancy error messages?
18:09:01 <ehird`> that tell you what went wrong
18:09:09 <ehird`> i could remove all error checking and get super-fast-pwnage programs
18:09:55 <oklopol> error checking is for kids and women!
18:10:24 <oklopol> you could perhaps have both, and like a #define to switch it on/off
18:10:31 <oklopol> in case #define is still cool.
18:10:44 <ehird`> i'd make it a compile-time option
18:10:56 <ehird`> time to rewrite my compiler, I think
18:11:21 <oklopol> HEY, that isn't incremental coding!!
18:12:52 <ehird`> my compiler arch is a bit broken
18:13:29 <ehird`> the problem is: inside a compile, we may need to save some code for later compilation and have the function generated match a name that we can get at the first compile
18:13:32 <ehird`> but they also may depend on others...
18:13:42 <ehird`> right now, it's written in an imperative, global-using type of scheme. :-)
18:16:10 <ehird`> oklopol: and i'm not sure what else i should do
18:18:43 <oklopol> well, currently you are more or less have a c interpreter for underload, and you are just injecting the code
18:19:11 <oklopol> ul_push(ul_func_0, "(:aSS):aSS");
18:19:33 <oklopol> sorry, i didn't look carefully enough.
18:19:42 <ehird`> it's pretty clever :-)
18:19:45 <ehird`> that's an old version of the output though
18:19:58 <ehird`> but yeah i most certainly do compile
18:20:23 <ehird`> oklopol: the thing is ul_func_0 may suddenly need to make a ul_func_1
18:20:27 <ehird`> i have an easy solution to this problem:
18:21:54 <ehird`> ul_concat is perhaps a little bit cheating, but not really
18:22:10 <ehird`> i still take all the instructions and compile them down to c code that performs those operations natively
18:27:29 -!- pikhq has quit (Read error: 104 (Connection reset by peer)).
18:27:55 <ehird`> my architechture is fucked :P
18:30:09 <oklopol> well, to do * properly, you'd basically need to be able to make machine code at runtime.
18:30:57 <ehird`> so i think mine is a nice trade-off
18:31:10 <ehird`> just add a pointer to 'end'
18:31:49 <ehird`> oklopol: now my compiler is truly awesome
18:31:58 -!- pikhq has joined.
18:34:28 <ehird`> pikhq: MY COMPILER CAN HAVE O(1) *.
18:34:35 <ehird`> AS WELL AS TAIL-RECURSIVE ^.
18:34:44 <ehird`> = best underload implementation yet
18:34:54 <ehird`> the JS one is O(n) *, iirc
18:35:04 <ehird`> it's compiled, too, so yay
18:35:58 <ehird`> now i just have to make the code functional.
18:36:04 <ehird`> functional = non-imperative fubnctional
18:49:48 <ehird`> an underload parser parsing to a list is actually pretty non-trivial
18:50:19 <ehird`> ((1 ghi) (2 def) (abc))
18:53:00 -!- ais523 has joined.
18:53:11 <ais523> I saw you were discussing Underload from the logs. How could I not join?
18:54:06 <ais523> <ehird`> ais523 doesn't come here any more, after proving that the world is upside down and becoming filthy rich because of it :(
18:54:27 * ais523 doesn't come here any more, due to being busy from the fallout...
18:54:42 <ehird`> ais523: I wrote an underload compiler!
18:54:55 <ehird`> And it runs all underload programs, and doesn't embed an interpreter.
18:55:04 <ehird`> I'm now rewriting it so it isn't such a mess of hideous code!
18:55:05 <ais523> Impressive. I just finished posting my bf (without input) to Underload compiler
18:55:39 <ais523> http://pastebin.ca/847012
18:56:10 * ais523 continues to read the logs
18:57:42 <ehird`> ais523: the main thing is that nested parens have to be unrolled
18:57:49 <ehird`> ((abc)def)ghi -> three functions
18:57:59 <ehird`> with the 'ghi' containing a push of the (abc)def
18:58:03 <ehird`> (abc)def pushing (abc)
18:58:10 <ehird`> and that's ugly in my current compiler
18:58:16 <ehird`> i'm writing a parser that does most of that for me, so.
18:58:18 <ais523> to answer your question about ^ and *, * is more common, but ^ absolutely has to be tail-recursive so that infinite loops are possible
18:58:20 <ehird`> (it's written in Scheme)
18:58:36 <ehird`> ais523: yep, i KO'd oklopol with that beforehand
18:58:42 <ehird`> and i found a way to make * fast
18:58:46 <ehird`> just keep a ptr to 'end'
18:59:01 <ehird`> i know, ridiculously simple, why didn't i think of it before
18:59:31 <ais523> How do you deal with memory allocation?
18:59:46 <ais523> presumably by reallocing the original string if it's too small before copying onto it?
19:00:13 <ais523> and doesn't that leave * as O(n) anyway due to the need to copy each byte of the string that's being copied over
19:00:19 <ais523> or are you representing strings as linked lists?
19:01:32 <ehird`> ais523: ul_print handles that
19:01:56 <ais523> are you just referring to bits of the code I can't see or is the source online somewhere?
19:02:33 <ehird`> it cats them and wraps in parens at print-time
19:02:51 <ais523> so are you using linked lists as strings?
19:03:06 <ais523> I wrote an interpreter for some language that did that at one point. Can't remember which language, though
19:03:41 <ehird`> when you concat it appends to the linked list
19:03:44 <ehird`> an object is a linked list.
19:03:52 <ehird`> each has a 'str' which is as big as possible at compile time
19:03:55 <ehird`> print prints these out sequentially
19:04:01 <ais523> linked list of strings is the best of both worlds, I suppose
19:05:21 <ais523> Underload really needs proper I/O extensions, I reckon, so that it's actually possible to do things like self-interpreters and to make it BF-complete
19:05:32 <ehird`> if you can do input then ^
19:05:35 <ehird`> then my compiler can't work
19:05:55 <ehird`> it relies on having all the code that can ever possibly be reached at compile-time
19:06:02 <ehird`> that's why it's so efficient
19:06:16 <ais523> if you're inputting as Church numerals, then all you need is zero and Church-increment
19:06:17 <ehird`> if you can do input but that makes it un-^able though i guess that's ok :P
19:06:31 <ais523> which are (!()) and (:)~*(*)*
19:06:38 <ehird`> "if you can do input but that makes it un-^able though i guess that's ok :P"
19:06:54 <ais523> but how else could you determine what it was?
19:07:16 <ais523> OTOH, if input is church numerals, then its behaviour on ^ing is defined; it just repeats the TOS the correct number of times
19:07:25 <ais523> that's sort of the definition of Church numerals
19:07:32 <ehird`> then ^ on it -> BLEEEEP
19:07:52 <ais523> what operations would be available on it other than cat, then?
19:08:17 <ais523> the problem with Underload is that everything has to be evaluated to be able to tell what it actually is...
19:08:35 <ais523> and there's no point allowing input to a program if all you could do is output it again
19:08:47 <ehird`> church numeral for ascii of a
19:08:57 <ehird`> if so, that's good, i can do that without having an interpreter
19:09:06 <ais523> that's what I'd just realised
19:09:15 <ehird`> But. Yeah. I want my new compiler done first :|
19:09:18 <ais523> because you can just have a church-numeral function in the code
19:09:41 <ais523> that's fine, any input extension would probably be a new language
19:09:52 <ais523> because it would spoil the beautiful tarpitness
19:11:27 <ehird`> ais523! write my parser for me
19:11:43 <ais523> I'd better get clear on the spec first, then
19:11:55 <ais523> and you just know I'll write it in some completely unacceptable language
19:11:58 <ehird`> i understand the spec fine
19:12:12 <ehird`> because my compiler's in scheme! :P
19:12:19 <ehird`> naw i'm sure i can figure it out ;)
19:12:21 <ais523> I'm not sure if I have a scheme interpreter just here
19:12:35 <ais523> maybe I should write it in elisp, that shouldn't be too hard to translate from...
19:13:20 <ais523> now, as for implementing the rest of the Unlambda operations in Underload...
19:13:39 <ehird`> -> simple translations,say bye bye
19:13:43 * ais523 has forgotten what x does
19:14:15 <ais523> but as for c, all you need to write is something that can save and restore the current stack
19:14:55 <ais523> so if you have some way to recognise the bottom of the stack, say by inserting a dummy entry between every stack entry, it shouldn't be too hard
19:15:09 <ehird`> ais523: re: scheme interpreter, I reccomend Chicken Scheme
19:15:14 <ais523> d may be harder, though, as I find it a bit hard to get my head round
19:15:15 <ehird`> well, it's a compiler. But it includes an interpreter.
19:15:28 <ehird`> http://www.call-with-current-continuation.org/ There are windows binaries, too.
19:15:32 * ais523 is currently using a computer on which they can't install software
19:15:42 <ais523> why else do you think I'd be using this aeons-old IRC client?
19:15:47 <ehird`> I should write a scheme in javascript
19:17:14 <ais523> d is actually very hard to translate into reverse-Polish
19:17:27 <ais523> because you have to know the second argument to ` before determining whether to evaluate the first one...
19:17:53 <ehird`> ais523: parse unlambda program, THEN do conversion
19:18:06 <ais523> ignore everything I just said, I was confused
19:18:23 <ais523> what you have to do is not to do evaluation while there's a d on top of the stack
19:19:56 <ais523> not just on top of the stack, what you have to do is not to do evaluating while there's a d anywhere in the stack
19:20:26 <ais523> but a `promise' is fine to have in the stack, and evaluating it should lazily evaluate the original code
19:22:17 <ais523> of course, v is easy, it's ((a(:^)*):^)
19:22:43 <ais523> sorry, that needs a pop... (!(a(:^)*):^)
19:23:22 <ais523> !ul (is this still working?)S
19:27:20 * ais523 is trying to figure out what happens when a construct like ```kdi`.xi is run through an Unlambda interpreter
19:27:43 <ais523> the ``kdi translates to d, thus preventing the `.xi being run
19:31:36 <ais523> OK, when there's a d anywhere in the stack, ~^ should instead do *(~^)*a rather than what it normally does, to preserve the semantics of d
19:31:42 <ais523> and d itself should be a no-op
19:31:57 <ais523> correction: when there's a d anywhere in the stack below the top element
19:37:50 <ehird`> ais523: Maybe I should pre-parse some programs first.
19:38:46 <ais523> the problem is to change subnodes into pointers, by the look of it
19:39:02 <ais523> that would likely be pretty easy with a parser-generator like yacc
19:40:37 <oklopol> parser-generators are for wimps
19:41:26 <ehird`> ais523: yacc for... scheme.
19:41:28 <ehird`> i seeeeeeeeeeeeeeeeeeeeeeee.
19:41:41 <ais523> there's probably some version knocking around somewhere
19:48:27 <ehird`> ais523: i should write a scheme->underload
19:48:42 <ais523> possibly easier than unlambda->underload, I suppose...
19:48:57 <ais523> and easier still than scheme->malbolge
19:55:22 <ehird`> ais523: I mean full scheme
19:55:35 <ais523> probably harder, in that case
19:55:41 <ehird`> that includes dynamic-wind
20:01:33 -!- ais523 has quit.
20:24:16 -!- timotiis_ has joined.
20:28:14 -!- bsmntbombdood_ has changed nick to bsmntbombdood.
20:38:56 -!- timotiis has quit (Read error: 110 (Connection timed out)).
20:42:57 -!- Jontte has quit (Remote closed the connection).
21:01:15 -!- Hiato has joined.
21:01:21 <Hiato> Gues who's back :P
21:03:36 <tejeez> i've got a crystall ball that tells me everything!
21:04:02 <Hiato> can it solve the halting problem, I've got some code here... :P
21:04:21 <tejeez> at least some very obvious things.. well.. it actually doesn't work with buggy code very well :(
21:05:56 -!- timotiis_ has changed nick to timotiis.
21:08:38 <Hiato> I wonder if GregorR is even still alive....
21:11:16 <oklopol> i bet he's been playing hydra for 2 weeks straight and is soon the world champuon
21:11:53 <oklopol> when did you first join this channel?
21:12:01 <Hiato> isn't it the IRC thingy
21:12:35 <oklopol> but i don't like telling people things they *should've* read from the logs!
21:12:36 <Hiato> it is also an IRC client (or was)
21:13:01 <oklopol> it's not fair just me and oerjan waste our time doing that :)
21:13:21 <oklopol> or then oerjan just checks for highlights.
21:13:39 <Hiato> haha, no don't worry, I bothered reading yesterday and the day beofre's logs (kinda) beofre I came ;)
21:14:17 <oklopol> i kinda wish i was less addicted to irc
21:14:45 <Hiato> heh, join the club, or should I say IRC channel :P
21:18:59 <Hiato> I wish I could use Ogre3D ... :(
21:23:52 <ehird`> i joined here sometime in 2006
21:24:15 <ehird`> wow, have i really been here a year?
21:24:20 <ehird`> that can't be right...
21:25:54 -!- GreaseMonkey has joined.
21:26:33 <Hiato> http://it.youtube.com/watch?v=Jd3-eiid-Uw
21:26:44 <Hiato> this guy is a genius :D :D :D
21:26:58 <Hiato> can't wait till games turn like this :D
21:30:56 <Hiato> so that you also go wow
21:31:11 <Hiato> don't know why it's italian
21:31:17 <Hiato> but hey, who cares :D
21:31:26 <Hiato> (PS: It's in english)
21:32:36 <oklopol> Hiato: that's actually not that hard to do
21:33:02 <Hiato> Awesome, but anyway, it is COOL to do ;)
21:33:18 <Hiato> can't wait until Crytek incorporates this ) or valve or whoever :P
21:33:26 <oklopol> if you have a way to do 3d graphics, you will have a virtual camera direction vector and position anyway
21:33:48 <oklopol> so you basically just have to set the virtual cam to move as the real cam moves
21:33:52 <Hiato> yes, but the idea of tracking a players head makes it that much more interesting
21:34:02 <Hiato> yes, I understand how it works
21:34:11 <Hiato> I would just like to see it in commercial games
21:34:48 <oklopol> i wouldn't like seeing it in commercial games, since it'd just suck like every other game.
21:35:07 <oklopol> i'd like to see it in a game i've made myself
21:35:11 <Hiato> say waa? I like my games :)
21:35:15 <oklopol> have i mentioned my games are awesome
21:35:32 <Hiato> that would be nice, but the camera code in Irrlicht is so screwy, It would never work...
21:35:50 <Hiato> My game is pretty much grouned
21:36:12 <Hiato> until I re-write the camera object, which will probably never happen...
21:37:53 <Hiato> Yes, I do. Making 2D ones in delphi, I have done a lot. But 3D ones, with Irrlicht
21:38:03 <Hiato> because my C group sucks
21:38:15 <Hiato> and I also don't like the C group of languages
21:38:20 <Hiato> in terms of playing
21:38:28 <Hiato> I'm a serious gamer :D
21:56:44 -!- Hiato has left (?).
22:12:25 -!- jix has quit ("CommandQ").
23:02:40 <ehird`> stack-based lambda calculus:
23:06:50 <ehird`> with currying, it's hard
23:07:03 <ehird`> essentially the stack becomes useless.
23:08:02 <ehird`> pikhq: since you're alive:
23:08:08 <ehird`> can you name a few languages that people haven't compiled yet?
23:08:28 <ehird`> e.g. when i compiled underload, most people would give it a cursory glance and say that a compiler would be impossible
23:08:30 <ehird`> because of ^ and * and a
23:08:38 <ehird`> i want something like that so i can prove them wrong :D
23:14:29 <ehird`> ooh i know what i should do
23:14:35 <ehird`> write a Brainhype interpreter in Scheme-omega!
23:15:43 -!- timotiis has quit ("leaving").
23:23:41 <ehird`> hm pikhq that makes no sense
23:38:06 <ehird`> there should be an esolang X which has a 'wimpmode' X-1. X reads a program, constructs a number from how 'line-noise/random-typing' the program looks, then uses that as a godel number for an X-1 program, which is then run.
23:40:28 <ehird`> pikhq: Comment, alive person!
23:40:47 <pikhq> Um, that's fuckin' *evil*?
23:40:49 <ehird`> Good, go write a spec.
23:41:08 <ehird`> Yes, I know it's evil that I'm making you do my labours.
23:41:19 <ehird`> But I didn't ask for your opinion, spec-writing slave!
23:42:24 <ehird`> pikhq: I am writing a Glass->C compiler.
23:42:36 <ehird`> Now Glass can run faster than ever!
23:42:54 <pikhq> Try a Glass->C++ compiler. Might be easier.
23:45:10 <ehird`> pikhq: But even better, of course, since it optimizes away the base classes.
23:45:10 <ehird`> pikhq: Think it'd be worth writing it in Glass? Might be a bit painful :P
23:45:43 <pikhq> Glass is actually not that painful.
23:45:53 <pikhq> It's *remarkably* terse, but fairly feature-filled.
23:46:20 <ehird`> C is far cooler to compile to, also :D
23:46:28 <ehird`> pikhq: I guess, but for the parser...
23:47:07 <ehird`> pikhq: Are there any glass programs apart from beer/bf/fibonacci/hello_world/rand?
23:47:55 <ehird`> There is an upside to writing the compiler in glass: metacircularness
23:49:26 <ehird`> pikhq: Even so, parsing Glass isn't like your typical trivial esolang...
23:49:42 <ehird`> Plus I'd have to write parsetree objects..
23:50:27 <ehird`> pikhq: OK, you decide for me. :P Should I write the compiler in Glass or something else?
23:50:50 <pikhq> The term is "self-hosting".
23:52:12 <ehird`> pikhq: Actually I object to the term 'self-hosting'
23:52:20 <ehird`> it implies that you 'stack up' compilers
23:52:22 <ehird`> whereas it's more like tail recursion.
23:52:30 <pikhq> Then you object to computer science.
23:52:31 <ehird`> pikhq: Got a glass-mode.el? :P
23:52:40 <pikhq> If you have one, please let me know.
23:53:04 <pikhq> Hell, a plof-mode.el would be damned spiffy.
23:53:07 <ehird`> pikhq: Yeah, so maybe I do.
23:53:22 <ehird`> pikhq: Oh, I still have to write Calculus/pebble.bfm don't I?
23:53:39 <pikhq> If you're insane, yes.
23:53:45 <pikhq> (you sure may. ;))
23:54:14 <ehird`> pikhq: When I write pebble.bfm, should I write the C backend or the BF backend first?
23:54:47 <pikhq> Either one; your choice.
23:54:57 <pikhq> Although the BF backend is certainly amusing.
23:55:09 <ehird`> 'amusing'? More like 'the main use'
23:55:24 <ehird`> You can see it seeping through every part of PEBBLE, from the tempvars to everything else
23:55:43 <pikhq> The C backend is basically just a really fancy Brainfuck optimiser. ;)
23:57:25 <ehird`> you can use PFUCK for that if you desire
23:57:32 <ehird`> actually I might make an ultra-PFUCK sometime
23:57:47 <ehird`> that has many backends (i guess: C, machine code, and for laughs PEBBLE) and optimizes to hell :P
23:57:58 <ehird`> just for the novelty of having it be brainfuck
23:58:12 <ehird`> and also for compiling itself to brainfuck, then uncompiling that to PEBBLE with itself
23:59:46 <ehird`> Oh by the way, pikhq, does the reference Glass interpreter gc?