00:04:50 -!- puzzlet has quit (Read error: 104 (Connection reset by peer)). 00:05:02 -!- puzzlet has joined. 00:07:18 -!- Corun_ has quit ("This computer has gone to sleep"). 00:08:18 -!- pgimeno has left (?). 00:09:33 -!- Corun has joined. 00:22:36 -!- RockerMONO[enfr] has changed nick to RockerMONO. 00:23:11 hi 00:31:40 -!- immibis has joined. 00:44:40 -!- dbc has quit (Client Quit). 01:08:55 -!- ehird_ has joined. 01:09:30 -!- ehird has left (?). 01:09:44 -!- ehird_ has changed nick to ehird. 01:17:35 -!- Corun has quit ("This computer has gone to sleep"). 01:26:28 -!- immibis_ has joined. 01:26:43 -!- immibis_ has quit (Read error: 104 (Connection reset by peer)). 01:37:50 -!- ehird has quit ("This computer has gone to sleep"). 02:19:57 * RockerMONO made an irc bot in brainfuck (using my interpreter that has networking) that can parse brainfuck 02:26:06 -!- immibis has left (?). 02:37:30 -!- RockerMONO has changed nick to Rocker[box]. 03:24:40 You shouldn't need an interpreter with networking, just netcat :P 03:25:00 That being said: Really? An IRC bot written IN BF that INTERPRETS BF? That's pretty cool. 03:26:17 Get it on. 03:27:35 This isn't relevant, but it's insanely awesome: http://www.nongnu.org/sps/ 03:28:07 Well aware. 03:28:31 Oh. 03:28:36 You did more stuff to it. 03:28:39 That's damned awesome. 03:30:21 I didn't just do more to it, I rewrote it from scratch as a FUSE filesystem utilizing Debian packages. 03:32:28 Damn. 03:48:22 -!- Insane has joined. 03:48:39 Somebody do me a favor and randomly link me to a fun language 03:49:04 ERROR: I DON'T WANNA. 03:49:16 Ooooooh 03:49:23 Let's invent ERRORCODE 03:49:37 What, where everything is a Kimian quine? 03:49:37 you program in error messages 03:50:07 What's a kimian quine? 03:50:53 A quine which depends upon the error reporting facilities of a language. 03:51:11 In some BF interpreters, "Mismatched ]." is a Kimian quine. 03:51:12 mk 04:10:42 -!- adu has joined. 04:15:51 could somebody explain a "Kimian quine" to me? I've heard this obscure fact, but I could never find a more detailed explanation 04:16:14 like, in detail? 04:16:35 is the idea that mismatched brackets will output an error message containing "]" somehow? 04:19:14 and Insane- your idea sounds intriguing. Like a language in which you "program" to some extent by purposely producing various types of errors? 04:19:50 You'd probably want a nearly TC base language with some key features missing, and then use bizarre side effects of error messages to fill in the gaps 04:27:26 Hmm 04:27:50 Maybe something like dividing by zero to output memory 04:37:28 could work 04:37:50 if it was interpreted in some fashion you could use nullpointer exceptions and array index out of bounds violations 04:38:44 there are a number of nonfatal things, like conversions that lose precision, that could fail predictably to provide rudimentary math or something 04:43:21 Basically, you create a program whose *error messages* are the program. 04:46:33 Maybe you can simply "emulate" error messages 04:46:50 counter from 1 to 10: i = 1; LOOP { i = i + 1; peek(0); 1/(0-i); }, EXCEPT (DivZero) { BREAK; }, EXCEPT (NullRead) { ErrStr = str(i) + chr(10); COMPLAIN; CONTINUE; }; 04:46:59 eg. instead of really dividing by 0 and catching an error, you could pretend to 04:47:03 actually... 04:47:11 counter from 1 to 10: i = 1; LOOP { i = i + 1; peek(0); 1/(0-i); }, EXCEPT (DivZero) { BREAK; }, EXCEPT (NullRead) { ErrStr[NullRead] = str(i) + chr(10); COMPLAIN; CONTINUE; }; 04:49:14 DO { 1/0; }, EXCEPT (DivZero) { DivZero = "Hello World!" + chr(10); COMPLAIN; CONTINUE; }; 04:49:47 this could tie into the idea we had earlier about a language where all logic, variables and flow control was a twisted mass of exception throwing and catching 04:50:04 exceptions themselves formed the mechanism for storing variables 04:50:22 and the potential for conditionals is obvious 04:50:52 and with some kinda nasty object oriented stuff it was possible to do recursion with them 04:50:58 I forget all the details 04:51:19 but we can call the language "DieHard" or something 04:51:38 heh 04:51:54 I'm still working on writing an irc bot in NetBrainFuck 04:52:08 NetBrainFuck provides 4 more instructions 04:52:09 or name it after the big iron OS "NonStop", legendary for it's reliablility 04:52:18 connecting using data from memory, reading, writing, d 04:52:22 *disconnecting 04:52:31 NetBrainFuck? shouldn't it be "ClusterFuck"? 04:52:42 Heh. Maybe 04:53:41 how about FuckThis? 04:54:43 FuckItAll 05:07:36 Let's make SLOCODE where every instruction takes a while, forcing programmers to write efficient code or wait forever 05:07:46 hm easy 05:08:04 s/*/*sleep(2000);/g 05:11:38 -!- Insane has quit (Remote closed the connection). 05:33:38 no, SLOCODE should turn conventions of cost and speed on their heads 05:33:53 what should be slow will be fast and vice versa 05:34:22 we could essentially accomplish this with a hideously complex "optimizer" routine 05:38:50 -!- adu has left (?). 05:45:01 i read somewhere that any universal lang can simulate any other efficiently, meaning running in polynomic time compared to the original prog in the other language, anyone know if this is true? 05:45:37 was just thinking about ais's O(2^2^n) simulation of a utm, unless i remember that wrong too 05:49:55 well, it at least seems plausible 05:50:34 that is a bit hard to google : D 05:51:54 I now challenge you to write a lisp (or scheme) interpreter for the Z1. 05:54:42 Z1? :) 05:54:56 i didn't read the paper. 05:55:16 *couldn't 05:56:55 e.g. v++ goes to v += 0xFF; for(i=0;i<0xFF;i++) v--; 05:56:59 i was just thinking, in case that polynomic time is *not* true, might be interesting to try and make the slowest language ever 05:58:19 the Z1 was one of the first computers, created by Konrad Zuse. 05:58:24 if there's no polynomic bound, you can probably make a language, in theory, that can actually be parametrized to be infinitely slow 05:58:43 oh, right, i was assuming that had to do with the proof :D 06:01:07 what i meant was a limit of infinite running time 06:01:45 when growing a param of the language 06:02:45 something like 2^2^2^...^n where you can choose the number of 2's by slightly modifying the language 06:04:54 since i don't think you can assume any optimization when calculating that, doesn't seem impossible really 06:33:20 -!- calamari has joined. 06:46:54 -!- calamari has quit ("Leaving"). 07:36:13 -!- puzzlet has quit (Remote closed the connection). 07:36:21 -!- puzzlet has joined. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 09:19:30 -!- GreaseMonkey has quit ("night"). 09:36:06 -!- puzzlet has quit (Remote closed the connection). 09:36:14 -!- puzzlet has joined. 09:47:19 -!- sebbu has quit ("bye"). 12:23:18 -!- ehird has joined. 12:38:37 -!- ehird has set topic: Continuing the tradition of me changing the topic when I get up, the topic is now "Conti. 13:05:03 -!- jix has joined. 13:26:07 hello jix 13:45:45 -!- helios24 has joined. 13:59:44 -!- Tritonio_ has joined. 14:01:25 -!- sebbu has joined. 14:05:25 -!- Hiato has joined. 14:05:48 Wassup 14:18:54 the sky 14:19:11 I hoped as much 14:19:23 I am trying to pervert Hofstadter's "GOD Over Djinn" into an esolang name. 14:20:04 Hrmm... GOD Over Gin ? Naah, nevermind.... 14:20:21 He already made that joke, in the same story. 14:20:38 Oh well.. I tried ;) 14:20:59 The characters (The Tortoise and Achilles) had entered an M.C. Escher painting using pushing & popping tonics (used to explain call stacks). 14:21:26 That was where they met the infinite chain of Djinn (Djii?), collectively referred to as the recursive acronym "GOD Over Djinn". 14:21:35 The dialogue, of course, was called "Djinn and Tonic". 14:22:26 Ah, I see. Wel,, I'm out of suggestions (yes, after but one), but I'll keep thinking about it - if that helps :) 14:22:59 :-P 14:23:01 Thanks, I guess. 14:45:47 -!- jix has quit (Read error: 104 (Connection reset by peer)). 14:46:24 -!- jix has joined. 14:59:57 Someone name my concatentative esolang like Joy :P 15:06:05 -!- Elion has joined. 15:19:31 -!- Elion has quit (Remote closed the connection). 15:19:50 :| 15:31:26 -!- Tritonio_ has quit (Read error: 110 (Connection timed out)). 15:31:54 -!- Tritonio_ has joined. 15:37:14 Hmm 15:37:16 Who is alive right now? 15:41:50 -!- Asztal has quit ("not me"). 15:43:10 -!- Insane has joined. 15:43:12 Nobody? 15:43:25 Internet connectivity? check 15:44:32 check! :)))) 15:44:40 hehe 15:45:03 who wants to talk about a concatentative esolang similar to Joy and Cat? *crickets chirp* oh. nobody? :( 15:45:59 Joy and Cat?.................... 15:46:07 Sounds like a disease 15:54:26 heh 15:54:38 google 'joy programming language' 15:54:39 ditto for cat 15:55:39 -!- Insane_ has joined. 15:55:49 they are both very interesting 15:56:41 -!- Insane has quit (Read error: 104 (Connection reset by peer)). 15:57:20 -!- Insane_ has changed nick to Insane. 15:57:38 IKsn't a cat a pĆ¼rogr 15:57:44 *program that outputs input? 15:57:48 *Isn't 15:57:54 yes, but it's also a programming language... 15:57:56 sheesh! 15:57:57 I'm gonna smack his lappy keyboard... 15:58:03 first and foremost, a cat is an animal 15:58:04 *this 15:58:08 it doens't have to be only one program! 15:58:09 Eh?? 15:58:17 What's an animal? 15:58:45 English isn't your native language, is it. 15:59:01 Yes it is :P 15:59:09 Just joking, I know what an animal is 15:59:14 :P 15:59:44 Insane: You know Forth? 16:00:03 Well, Joy is like a functional (not in the sense of 'works', of course) Forth. 16:00:14 Cat is like a functional, statically-typed (!) Forth, 16:00:16 . 16:01:41 Hmm 16:01:45 What's Forth? ^^ 16:02:14 I don't think you're the best person to talk about this with... 16:02:18 Right 16:02:24 oklofok: You know Forth, don't you :P 16:02:49 The only esoteric languages I know are brainfuck, NetBrainFuck and 1337 16:03:33 Insane: Forth,Joy,Cat aren't esoteric. 16:03:40 Ooh? 16:03:46 interesting 16:03:49 Well. 16:03:52 ehird: i know it's a stack-based language. 16:03:58 You could call them esoteric. But people use Forth for real-world apps, all the time 16:04:01 Mainly in embedded systems. 16:04:02 and that it's old and famous 16:04:07 Cat is a mainly-research-and-teaching language. 16:04:19 Joy is a 'ooh, what would happen if we...' language made by a philosophy professor guy 16:04:26 oklofok: well, you know stack based languages. 16:04:31 yeah 16:04:35 well, concatentative languages, to be precise. 16:04:58 i.e. 16:05:27 for all A,B in P. concat(A,B) == compose(A,B) where P = programs in language L 16:05:32 ==> language L is concatentative 16:05:43 and unless it's a computationally useless language you achive that with a stack. 16:05:47 oklofok: there, have a formal definition 16:06:04 well, thanks for that i guess :) 16:06:24 oklofok: know Joy? 16:06:45 once again i just know some outlines. 16:07:30 http://en.wikipedia.org/wiki/Joy_%28programming_language%29 good primer. 16:07:35 basically, it's a functional, concatentative language, 16:07:56 but instead of formal parameters and function application, it has program quoting and evaluation 16:08:05 kind of like underload, but less crazy 16:08:14 the wikipedia article is all i've read about joy, probably. 16:08:20 haven't used it 16:08:30 give it another read, as a refresher 16:08:51 hmm, [] is a false-like lambda? 16:08:58 a generic grouping thingie 16:09:04 i'llr ead. 16:09:08 *typo 16:09:13 oklofok: 16:09:14 no 16:09:16 -!- Tritonio_ has quit (Read error: 104 (Connection reset by peer)). 16:09:21 [...] is a program 16:09:39 and you can run it, or use e.g. a combinator to do stuff with them 16:09:42 x == [x]i 16:09:50 (i is the 'just run it' combinator) 16:11:50 well, that's what i meant by a grouping thingie 16:11:57 you can use that to get a list 16:12:05 not well, but kinda! :) 16:12:14 anyways, i know what it is. 16:12:27 I'm trying of thinking of some non-lazy evaluation command. How's this? ``>A[B] converts to `A[B], and immediatly afterward, [B] is evaluated. 16:12:55 Slereah: just don't if it's for IO 16:12:56 monads 16:13:01 oklofok: okay 16:13:05 oklofok: my language is kind of like that 16:13:14 I cannot undersandy monads. 16:13:21 Newton was against Monads! 16:13:24 Slereah: Don't write a functional programming language until you do. 16:13:46 oklofok: one distinguishing thing is that it has no special syntax apart from [...] 16:14:02 Is there a better source than Wikipedia on it? 16:14:11 yeah, i don't like that 16:14:17 oklofok: what don't you liek 16:14:25 my prog language has nothing but [..] 16:14:27 but joy has things like 16:14:27 the DEFINE thing 16:14:31 "DEFINE x == y." 16:14:31 yeah 16:14:37 i'm assuming you meant,,.... well, yeah 16:14:50 that's kinda impure. :P 16:14:54 (sadol ftw!) 16:15:25 My prog language has: +-><[].,*~!% 16:16:24 P := '[' P* ']' | (!WS)+ P | 16:16:24 P := '[' P* ']' 16:16:24 | (~S)+ S P* 16:16:24 | S 16:16:24 | P* 16:16:25 S := ' ' | '\t' | '\n' 16:16:27 errrr 16:16:29 wait 16:16:45 http://rafb.net/p/w9QzSK93.txt 16:16:45 there 16:16:48 that's my languages syntax 16:16:55 (if we assume ~X means 'anything but x') 16:17:05 hm wait 16:17:07 you can also do 16:17:08 a[b]c 16:17:11 but whatever. 16:17:12 you get the idea 16:17:25 oh wait 16:17:29 i also have string literals. 16:17:30 heh 16:17:31 :) 16:17:50 looks ambiguous 16:17:58 maybe my BNF is 16:18:00 but the language isn't 16:18:02 honest :-) 16:18:18 well, ofc not 16:18:47 -!- Insane has quit (Remote closed the connection). 16:18:51 anyway 16:19:00 i'm not sure how i'm doing to do assignment in my language 16:19:00 XD 16:19:11 without adding extra syntax, or using something ugly like a string literal 16:19:20 well, the purest way is not to :) 16:19:37 but that's not a *good* way 16:24:58 i mean, fuction definitions 16:25:03 which I need since I hav eno paraemters :P 16:25:15 i guess i could maybe manage one bit of syntax... 16:25:29 WORD = WORD*. 16:25:36 So, just like Joy but without the DEFINE thing 16:28:01 -!- Tritonio_ has joined. 16:32:16 oklofok: is that ok with you? ;) 16:32:26 it just means you can't define = as a word, and the parser needs a lookahead of one word. 16:32:46 hmm 16:32:58 -!- timotiis has joined. 16:33:20 i'd make case putting an atom on the stack and using it as a function 16:33:25 errr 16:33:32 i'd make case differentiate between putting an atom on the stack and using it as a function 16:33:47 oklofok: inconsistent, though - and there's no need for atoms elsewhere :) 16:33:50 So, I think I like this idea. 16:33:54 OK! Time to write some example code.. 16:33:59 atoms are great, though 16:34:13 but, do what you want 16:34:16 inconsistent? 16:34:18 how? 16:34:33 you define as Abc, you use as abc 16:34:54 hmn 16:34:54 i might use ; instead of . 16:35:01 oklofok: what do you think i should use as a terminating mark? 16:35:16 hmm, depends 16:35:20 can you redefine? 16:35:26 not sure yet. 16:35:46 i'd put ";" if you can redefine, otherwise "." 16:36:04 oklofok: hm, why? 16:36:18 no reason, except a feeling. 16:36:26 i'll go buy something pretty -> 16:36:31 (thirsty) 16:40:20 Really -- all my esoteric programming endeavours are just part of the search for the perfect programming language (for me). 16:40:37 I continuously try new abstractions, while removing others. 16:41:32 What's the best so far! 16:44:11 I don't know. 16:44:15 It seems both extremes work equally. 16:44:26 Haskell, Lisp, Joy, Cat... they all seem to be just about the same. 16:44:32 But I'm not sure they're good *enough*. 17:01:26 -!- Corun has joined. 17:06:06 -!- Corun has quit (Client Quit). 17:07:03 oklofok: you bacj yet? 17:07:31 Hmm 17:07:37 Maybe I'm looking in the wrong place. 17:07:54 Maybe my options of: REPL-based, batch compiler, batch interpreter are wrong. 17:08:03 Maybe my options of: unicode text file are wrong 17:13:25 -!- jix has quit ("CommandQ"). 17:15:36 o 17:20:51 :| 17:20:55 oklofok: comments? 17:21:26 -!- oklofok has changed nick to oklopol. 17:21:58 what do you mean by options? 17:23:33 well, like what i aim for when designing 17:23:40 like, maybe programs aren't inherently flat text files 17:23:49 maybe implementations don't have to be one of the things i said. 17:26:13 i don't consider those that important 17:26:23 so... hard to say. 17:57:00 The monads tutorial seems to require some knowledge of Haskell 17:58:25 Slereah: gasp. 17:58:26 ;) 17:58:34 WHAT A SHOCK! 17:58:49 I guess I'll have to learn Haskell after all. 18:02:24 http://sigfpe.blogspot.com/2006/08/you-could-have-invented-monads-and.html http://www.haskell.org/haskellwiki/Monad_%28sans_metaphors%29 18:02:28 the latter is just a 'WHAT is a monad' 18:02:34 the first is 'WHY is a monad' 18:03:50 Apparently, I could have invented them! 18:03:54 I'm flattered. 18:17:47 -!- Tritonio__ has joined. 18:17:51 -!- Tritonio_ has quit (Read error: 110 (Connection timed out)). 18:19:17 -!- Rocker[box] has changed nick to RockerMONO. 18:20:31 hi 18:21:32 Hello sir. 18:23:47 Hello 18:24:02 what's up? 18:24:14 * RockerMONO got a dialect of brainfuck that uses sockets working 18:24:21 as ehird said in reply to my exact question: the sky :P 18:24:50 well... it works until the socket disconnects.... but if you leave an IRC bot made in it up for 14 and a half hours after it disconnects, it will be ugly :< 18:25:13 Imma reading sum monads 18:25:22 In the hope of making some useful input function 18:25:26 mmm 18:25:29 Slereah: and output! 18:25:33 all IO :) 18:25:47 psh why not II or OO? =P 18:25:48 You can even do state with monads, just add a magical monad-creator combinator and you can write a state monad :P 18:25:49 Well, output seems to work okay so far. 18:25:53 btw 18:25:57 what's a monad? 18:26:03 Slereah: yes, but if you do one you have to do the other, otherwise things go weird 18:26:05 RockerMONO: I'm still wondering! 18:26:14 RockerMONO: 1.learn haskell 2.learn monads 18:26:18 But I hope that the mystery will soon be lifted 18:26:42 It's apparently from category theory, that one from which I don't know squat. 18:27:16 Slereah: you don't need to know category theory 18:27:19 I don't! 18:28:41 Well, I also don't know Haskell. 18:28:52 But I guess Haskell is easier to learn! 18:29:11 [Narrator : AND THAT WAS HIS FATAL MISTAKE] 18:30:14 HE DIED 18:30:16 LIKE A TORTOISE 18:30:18 IN A BATH 18:30:54 This was brought to you by the campaign against functional languages. 18:34:10 Slereah: #haskell! 18:34:18 We're Friendly(TM) 18:34:58 MY GOD 18:35:02 IT'S FULL OF STARS! 18:37:49 -!- oerjan has joined. 18:41:11 hello oerjan 18:41:17 make Slereah's #haskell-time fun and fuzzy 18:41:30 -!- jix has joined. 18:44:08 Well, I'll probably read haskell tomorrow. 18:44:13 After a night of sleep. 18:44:21 Don't have many classes tomorrow. 18:45:50 Well, more than I thought. They added some more. 18:46:06 But I still have nothing on fridays. 18:50:33 * oerjan just says "aye" to that. 19:00:53 Hello oerjan 19:01:09 Thanks (once again) for cleaning up the mess I leave on the wiki :D 19:02:47 i think ais523 did the last cleaning up, actually 19:03:14 well, nontheless, thanks for moving my page and what not :) 19:04:16 I wonder 19:04:25 If a minimal combinator can be "i" 19:04:29 that was him. he's not here right now (he just comes for short periods) 19:04:35 to get an entire TC system, 19:04:44 what is it for a stack based language? 19:04:45 well, they 19:04:46 oh, woops, well thanks anywho for the typo thing etc :) 19:04:54 i imagine it requires multiple: dup and all that, for stack manipulation 19:04:55 i'm thinking: 19:05:06 quoted programs + basic stack manipulation words + ??? magic thing ??/ 19:05:28 -> AWESOME LANGUAGE??? 19:05:38 Solve for X. 19:06:05 we just need to figure out magic thing 19:06:05 :P 19:06:28 Well, I just use an electronic wand, personally. 19:06:40 3.5 megathaums. 19:07:13 ehird: have you looked at Joy? 19:07:31 It can be used to solve most undecidable problems. Although cannot force someone to love you, as you can learn in Alladin. 19:08:12 someone did a paper on doing combinators in Joy 19:09:12 * oerjan wonders if ??? magic thing = dip 19:13:08 oerjan: of course! 19:13:15 my neu language is based on joy, kind of. 19:13:21 it's a functional, stack-based language so yeah 19:14:26 it might be dip, yes 19:14:40 oerjan: i've considered a statically typed Joy -- like Cat -- but with type inference 19:14:52 so it's just like a regular concatentative lang, except it yells at you when you write something silly 19:14:55 um Cat is supposed to have type inference 19:14:58 afair 19:15:05 oerjan: its not that good though. 19:15:08 i might even handle variadic functions 19:15:10 like 19:15:21 you could write a printf which took an argument off the stack when it saw a certain formatting directive 19:15:24 and it'd type properly 19:16:33 well you'll have to invent a more clever type system than cdiggins did. 19:16:57 indeed 19:17:01 i think a printf type could be: 19:17:17 and he had some help from lambda-the-ultimate.org 19:17:19 ok, sprintf: 19:17:25 oerjan: this is true, i think it may be undecidable 19:17:44 ( ... STRING -- STRING ) 19:17:49 a bit vague, i guese 19:18:03 but it gets the essentials right: you need a STRING on the stack, and might need other stuff, and you'll get a string back 19:18:32 my understanding is that it essentially boils down to the undecidabilit of word equations 19:18:43 *my intuition, perhaps 19:18:49 i guess 19:19:06 oerjan: the reason i said STRING is because lowercase is reserved for polymorphism 19:19:24 swap ( a b -- b a ) 19:19:44 let's assume forth style definition syntax: 19:19:46 hmm 19:19:48 this is something.. 19:19:57 oerjan: can you write the S combinator in J? 19:20:08 my intuition is that you cannot capture its first argument in the quoted program it should return 19:20:58 -!- RockerMONO has quit ("Firefox using HALF OF MY FUCKING RAM and HALF OF MY FUCKING CPU :<"). 19:21:09 i know very little about J 19:21:42 i guess 19:22:02 you're not just abbreviating Joy, i assume? 19:22:06 oh 19:22:07 i meant joy 19:22:08 xD 19:22:48 as i implied, someone has shown how to rewrite SKI combinators in Joy, so yes 19:22:52 : factorial ( INT -- INT ) [zero?] [1] [1 -] [*] iter-rec ; 19:23:19 : iter-rec ( PROG PROG PROG PROG -- a ) .... ; 19:23:22 but that's not very helpful 19:23:25 so i'll describe iter-rec 19:23:38 ( TERM BASE STEP BINOP ) 19:23:46 TERM is the termination predicate. 19:23:52 BASE is the value to use at termination. 19:23:58 well, the program to execute. 19:24:12 STEP is what we should repeat on, given the previous value. 19:24:29 And BINOP is what we should apply to the next and previous values. 19:24:46 hm 19:24:48 better iter-rec: 19:25:16 : iter-rec ( a ( a -- BOOL ) ( -- a ) ( a -- a ) ( a a -- a ) -- a ) ... ; 19:25:44 -!- RockerMONO has joined. 19:25:45 which is insane, but good :D 19:25:57 oerjan: Do you think that's a general kind of recursion or is it only going to be usful for a factorial? ;) 19:27:17 * RockerMONO wonders why this channel loses topic parts and modes each time he joins.. 19:27:19 =P 19:27:50 modes? 19:28:05 * oerjan hadn't noticed the modes. actually still haven't. 19:28:14 oerjan: any thoughts on iter-rec? 19:28:24 it makes my head hurt? :D 19:28:28 oerjan: nvm it was just lag =P it showed 'no modes' now it shows +nc =P 19:28:38 ah 19:28:39 -!- Slereah has set topic: 10 : Continuing the tradition of me changing the topic when I get up, the topic is now GOTO 10. 19:28:53 oerjan: Well, i'll annoate the type fully 19:28:57 Slereah :DD 19:29:13 Look around you! 19:29:25 one thing, ( -- a ) is just a unless you are doing side effects 19:29:38 no 19:29:41 its a constant 19:29:43 [1] 19:29:51 well 19:29:55 you could do side effects too 19:30:00 maybe i'll pass in a value at some time 19:30:01 but for now.. 19:32:50 i guess it is at least as powerful as a while loop, so can give TC 19:33:10 at least if a can be a tuple type 19:33:29 or some sort of composition 19:33:48 (a stack, probably?) 19:35:02 oerjan: i was asking re: expressivity 19:35:13 here, have annotations: 19:35:40 http://pastebin.ca/raw/880225 19:36:06 * RockerMONO 's making screwbin, binary counterpart for brainfuck :D 19:36:07 oerjan: using that definition, and seeing how it works with the factorial example, would you say iter-rec is an expressive recursive operator, or will it be ugly for things beyond factorial-alikes? 19:38:43 it's a bit primitive recursive, although not exactly 19:38:56 i don't think you can write ackermann with it 19:40:14 (simply) 19:40:36 as in, you can only make one recursive call 19:41:44 oerjan: its not meant to be general 19:41:47 just one in a toolbox 19:41:56 i'm just asking if it's elegant for many other things than a factorial? 19:42:41 it's like a haskell unfoldr + foldr 19:43:01 yes 19:43:09 I guess it's useful then 19:43:48 : bin-rec ( a ( a -- BOOL ) ( -- a ) ( a -- a ) ( a -- a ) ( a a -- a ) -- a ) ... ; 19:44:01 although for the full power of that, you want to distinguish some of the a's 19:44:31 actually it is not a complete unfoldr 19:45:01 though that can be adjusted in the combining function, so not a problem 19:45:22 oerjan: give me a syntax for lists 19:45:24 it's iterate + takeWhile + foldr 19:45:27 and i'll give you a quicksort with bin-rec 19:45:32 and that actually sounds very useful then 19:45:36 ;) 19:45:51 if you look at factorial with a grokking of iter-rec, it's very clear 19:46:13 no stack shuffling or any of that, just the algorithm stated concisely, purely and simply 19:46:30 and bin-rec can trivially be tail-recursive! 19:46:34 or iterative 19:46:37 err 19:46:38 iter-rec 19:46:45 which remidns me. list syntax :P 19:48:07 head tail : ++ 19:48:21 oerjan: heh 19:48:27 i meant a convenient way to say [a,b,c] 19:48:32 not using [] for obvious reason :P 19:49:00 ah yes, i think Joy uses the same for both but that is bad for typing 19:49:41 well there is only one actual bracket left, { } 19:50:37 actually you _could_ use [a,b,c] 19:50:53 saying a b and c are subprograms 19:51:00 er wait 19:51:06 breaks for single element 19:53:43 okay then: 19:53:50 wait no 19:53:53 oerjan: {} is taken 19:53:55 i assume type inference means the initial ( ... ) in a function could be left out, so that spot makes it unsafe to use something with ( ) 19:53:56 for {* comments *} 19:54:09 <, > are used for comparison for now 19:54:12 plus <1 2 3> is ugly :P 19:54:20 bah, i need unicode 19:54:20 ;) 19:54:32 seems you need a multi-char keyword 19:54:39 hm 19:54:40 like what 19:54:42 ok, (, a, b, c) 19:54:59 or [, a, b, c] 19:57:15 for a slightly harder parsing, the initial , could be optional when there is more than one 19:57:16 heh 19:57:20 there's no need for a, b, c 19:57:23 just a b c 19:57:28 oh 19:57:29 since you can have it gobble off the stack 19:57:53 [, a b c] 19:58:13 i don't particularly like that. Maybe: 19:58:18 {{..}} 19:58:22 kinda ugly though 19:58:25 {: ... :} 19:58:32 {: 1 2 3 :} 19:58:34 {: :} 19:58:35 hm another option 19:58:45 eh, let's do {: ... :} for now? 19:58:47 ok: 19:58:49 [a b c]: 19:58:56 i'd prefer 19:58:57 ,[a b c] 19:59:05 yes, i like that, let's use that FOR NOW 19:59:09 because : could be an actual function 19:59:20 no, oerjan. : is define 19:59:30 anyway, bin-rec has gone off my screen. stop talking while i write quicksort :) 19:59:32 well something could be 20:00:43 : quicksort uncons [length 2 <] [{,}] [swap dup peek <] [swap dup peek >] [concat] ; 20:00:47 with syntax: 20:00:49 {,1 2 3} 20:00:54 but, my problem with that 20:00:57 is the stack manipulation 20:01:21 : quicksort ( {,a} -- {,a} ) uncons [length 2 <] [{,}] [swap dup peek <] [swap dup peek >=] [concat] ; 20:01:26 made it work, added a type signature :P 20:01:32 oerjan: but that stuff to get to the pivot is pretty ugly 20:02:33 quicksort needs O(1) mutable arrays to be worthwhile anyhow 20:03:12 mergesort is better for actual linked lists 20:04:07 yeah 20:04:30 * Slereah goes back to work on Mulambda 20:05:37 oerjan: the language is tentatively called LION 20:05:40 or just Lion 20:06:31 the object structure is very simple incidentally: just a pointer, if the rightmost bit is 0 the rest of the object is a pointer to something (where *ptr == the type tag structure, and everything after that the data), otherwise the rest is a small integer 20:07:00 lambda in one ... ? 20:07:19 oerjan: ? 20:07:26 (inspired by Scheme in one defun) 20:07:26 well, the rightmost bit would be 0 20:07:29 oh 20:07:30 haha 20:07:31 :) 20:07:40 Lambda in one .. node? 20:07:42 Really, we want: 20:07:57 Quoted program in one word definition 20:08:03 qpiowd isn't very catchy though. 20:08:08 hmm 20:08:36 #define SMALL_MAX ((~7)>>3) 20:08:41 wait 20:08:43 >>3? 20:08:45 no no no 20:08:45 haha 20:08:49 ((~1)>>1) 20:09:00 oerjan: nifty little definition no? 20:10:06 oerjan: interestingly, ptr-to-int is just -1 ;) 20:10:09 and vise-versa! 20:11:19 how is ((~1)>>1) different from ((-1)>>1) ? 20:11:52 -!- immibis has joined. 20:11:55 or ((~0)>>1), for that matter 20:12:21 oerjan: well, it shouldn't be 20:12:23 i just want 20:12:27 ...111111111111111111111111110 20:12:44 and you're right with ~0 20:12:44 er that 0 the most significant digit? 20:12:45 hm 20:12:47 ((~0)<<1) yoy mean? 20:12:50 *you 20:12:52 immibis: no 20:12:58 i want the maximum value stuffable, if you lose one bit 20:13:11 So currently that's ((~0)>>1) but I think -1 is right 20:13:13 * oerjan would call that 0111...1 20:13:16 or something 20:13:25 oerjan: Welp, I stuff on the rightmost bit. 20:13:31 And so does mzscheme, so I have backing here! 20:13:42 righmost, shmightmost 20:14:02 i'm a mathematician, i expect the least significant bit to be rightmost 20:14:50 and >>1 shifts off the least significant bit afaik 20:15:17 leaving the most significant bit 0, assuming sign bits don't duplicate 20:15:24 oerjan: You are confused. 20:15:32 I am accessing WHAT I CAN HAVE, NOT packing stuff ina value 20:15:37 4>>1 == 2, right? 20:15:42 so, an example packed small integer: 20:15:47 1101 20:15:48 Or pointer: 20:15:50 1100 20:16:00 So: least significant, rightmost. 20:16:14 ok but: 20:16:26 1...1110 is <<1, not >>1 20:16:37 oerjan: your -1 relies on twos complement 20:16:44 true 20:16:52 oerjan: Yes! Exactly! So I get 1...110, shift it to the right, then get 0...111 20:16:52 ehird: it's still <<1 20:16:58 Which is the maximum value a small integer can be! 20:17:00 Damnit!!! 20:17:11 This is when I read in an integer! 20:17:16 To tell if I can stuff it into the pointer directly! 20:17:30 ehird: ok i was confused but you started it :D 20:17:50 so ...1110 is the internal integer format 20:17:59 ...1111 actually 20:18:01 and >>1 turns it into ordinary C format 20:18:01 0 is for the pointers 20:18:02 :P 20:18:05 And yes, that is right 20:18:28 * oerjan assumes it's cleared up now 20:18:30 Cute trick: 20:18:31 #define IS_SMALL(x) ((x)&1) 20:18:58 LION sp; /* JESUS CHRIST IT'S A LION STACK POINTER GET IN THE CAR */ 20:19:01 ^^ i am tempted ... 20:20:44 and later, /* ARGH CLOSE THE WINDOWS */ 20:22:04 oerjan: evidently internet memes never effect you 20:22:05 :P 20:22:07 *affect 20:22:09 *eh whatever 20:22:22 -!- Hiato has left (?). 20:22:47 that's a meme? 20:23:08 indeed i browse relatively few sites 20:23:28 'JESUS CHRIST IT'S A LION GET IN THE CAR' is a meme, yes 20:23:31 it's died down by now 20:23:42 * oerjan get Larson vibes 20:23:46 *gets 20:23:51 i'm not sure though 20:25:00 ah, probably not 20:25:36 or rather, i am reminded of a Larson strip where a lion has a cloth-hanger 20:27:43 *clothes 20:28:05 (#¤%& english) 20:28:25 sp = 195948557; 20:28:31 hilarious! 20:29:07 csp = 195935983; 20:29:08 hahahahhaa 20:29:26 * oerjan is confused. again. 20:29:42 do you just find numbers funny, or what? :D 20:30:24 oerjan: you will figure it out, if you have the fu of not 10. 20:30:29 (yes, i am being deliberately obscure) 20:30:58 oerjan: when you get it, explain it to me in pm 20:31:04 i don't wanna look stupid 20:31:24 hah 20:31:25 it's not that hard 20:31:35 hint: that's in my initialization function. it's for future error checking 20:32:23 whatever 20:33:28 sigh, ok 20:33:49 sp = 0xBADF00D; 20:33:51 csp = 0xBADBEEF; 20:33:56 but i'm changing BADBEEF to DEADBEEF 20:34:04 because that more accurately describes a call stack underflow 20:34:38 you spoiler! i was just starting trying base conversions. 20:34:48 for some reason tried binary first 20:35:02 i thought 'whatever' meant 'i gave up' 20:35:03 :P 20:35:14 "whatever, i'm not gonna play your stupid games" 20:35:26 ("mwahahaha, i'm so gonna crack this") 20:35:44 er, my giving up passed away 20:35:52 could've been "lololol!" 20:36:53 that badf00d actually caused me some confusion, because those 0's _do_ show up prominently in base 2 20:37:14 but my brain was just too slow this evening 20:39:44 oerjan: Should Lion have a call/cc 20:39:46 ? 20:39:46 :D 20:39:52 -!- jix has quit ("CommandQ"). 20:40:21 might be easy if you have a linked-list execution stack 20:40:37 well, even if not 20:40:58 oerjan: Well, I don't :P 20:41:32 what are you writing it in? 20:41:41 C, duh. Didn't you see my #defines? :P 20:41:52 er... 20:42:08 * oerjan de-evolves further to the neanderthal stage 20:42:11 hahah 20:42:20 don't worry, i'm going to write it simply 20:42:21 :P 20:42:26 THAT NOT FLINT 20:42:48 isn't defining like coarsening? 20:46:35 oerjan: Feel free to help me implement it in Haskell. ;) 20:47:02 OH NOW YOU DON'T TALK 20:48:53 TOO LONG WORD, HAS, HAS, THAT ONE 20:50:02 So now you don't like Haskell either? :P 20:50:20 IS GREAT. JUST NOT CAN SAY IT. 20:50:54 oerjan: WILL HELP IMPLEMENT LION HASKELL? 20:51:01 primitive :: Stack -> Stack LIKE MUCH 20:51:52 maybe 20:52:07 yay 20:52:17 C can wait until we've verified the awesomeness of it, I guess :P 20:58:47 oerjan: I have an idea for mutability 20:59:01 instead of doing like 20:59:05 (IORef Value) 20:59:09 in various clauses of Value, 20:59:10 we can do 20:59:12 Location 20:59:20 where Location is an Int index, in a heap array 20:59:27 and we can just modify that array.. 20:59:35 perhaps ugly, perhaps not. oerjan: thoughts? 21:00:11 -!- Hiato has joined. 21:00:31 well i think that's the usual way of simulating mutable structures in pure code 21:00:50 it gets ugly if you have more than one type of value though 21:01:17 also, you don't get the benefit of automatic GC 21:01:31 oerjan: is it? 21:01:32 ok. 21:01:39 oerjan: of course, at any time a function could do some IO 21:01:45 so maybe we'd be best off using IO and IORef 21:01:53 right 21:01:57 But if we do that 21:02:09 should we still have (Stack -> Stack), well, now, (Stack -> IO Stack)? 21:02:13 Or just: 21:02:20 StackMonad () 21:02:27 where StackMonad is IO with a stack in it, heh 21:02:56 well you could have a StackMonad even if you don't keep the Stack in an IORef 21:03:10 * Slereah needs some Garry Gum 21:03:14 (StateT Stack IO for example) 21:03:38 oerjan: Yes. 21:03:49 I propose: 21:03:58 type Stack = StateT [Value] IO 21:04:03 So we can have "primitive :: Stack ()" 21:04:08 Just looks a bit nicer, I guess. heh. 21:04:45 er 21:04:55 so the actual stack is [Value] 21:05:09 that's a bit confusing terminology 21:05:45 oerjan: Well, yeah 21:05:48 top : rest 21:05:52 A stack is just a linked list 21:06:04 er not that 21:06:08 but, 21:06:11 that's perfectly reasonable. 21:06:14 haskell compilers can do optimizations on lists. 21:06:15 ah 21:06:15 ok 21:06:18 i mean calling the monad Stack 21:06:30 yeah i know 21:06:34 it's just... :-) 21:06:37 hmm 21:06:41 let's say its called StackMonad 21:06:45 drop :: StackMonad () 21:06:54 drop = do (_:xs) <- get 21:07:01 put xs 21:07:09 return () 21:07:15 I dunno. :| 21:07:18 As opposed to: 21:07:22 drop :: Stack -> IO Stack 21:07:24 drop = modify tail 21:07:28 drop (_:xs) = return xs 21:07:32 oerjan: I guess. 21:07:40 I just guess I see everything as a stack to stack mapping 21:08:02 although yours has the advantage we can add an error layer easily 21:08:31 both of yours, really 21:08:33 oerjan: Which do you prefer? A stack monad, with IORef for all mutable things, or a stack to stack mapping function that has an IO monad attached to it? 21:09:25 i think perhaps Stack -> IO Stack is better, nearly all the functions will need to look at the stack anyhow 21:10:02 oerjan: One thing 21:10:03 and few will need to return any other value 21:10:06 if we're going to do static type checking 21:10:13 oh 21:10:15 we need to make that pleasant to deal with in our primitives 21:10:31 i.e. specifying a type for them, and all that jazz 21:10:33 * oerjan actually has no experience implementing that 21:10:45 Me neither! 21:10:52 And especially no experience implementing type inferrence. 21:11:09 Still. 21:11:28 oerjan: I'm not sure which of our options -- or a third -- will make specifying the primitive functions and their types easier 21:15:26 oerjan: In fact, how will we specify the types at all? 21:16:34 -!- helios24 has quit ("Leaving"). 21:16:50 afk 21:50:13 -!- ehird has quit ("Leaving"). 21:52:08 -!- ehird has joined. 22:01:34 -!- cherez has quit (Read error: 104 (Connection reset by peer)). 22:10:44 -!- unrepresentative has joined. 22:11:04 oerjan: 22:11:09 any thoughts? 22:11:14 on typability and mutability and taht stuff 22:14:01 i recall faxathisia yesterday was trying to implement type inference for simply typed lambda calculus in haskell 22:15:11 also, that will not be enough for a stack language 22:16:21 i actually didn't look at what Cat ended up with 22:19:59 oerjan: i tell you what 22:20:02 i'll get ghc back up 22:20:09 then let's just see how it goes, when we try and write it 22:22:10 -!- GreaseMonkey has joined. 22:26:15 :) 22:26:23 oerjan: I think, data types: 22:26:55 1. Integer 2. Float 3. Program 4. Primitive 5. List 22:26:58 Maybe 6. Vector 22:27:21 2. Double 22:27:56 oerjan: Bah, ok. But still have a float? 22:28:03 why not 22:29:07 perhaps Tuple 22:29:18 or is that what you mean by Vector? 22:29:48 anyway more of those are easy to add, i think 22:32:21 oerjan: Vector is a numerically-indexed, consecuative in memory O(1) access structure 22:32:24 (aka 1-dimensional array ;)) 22:32:43 oerjan: Tuple, maybe but i'm not sure 22:32:48 mostly you would just use the stack for that 22:33:06 oerjan: I think we should get basic object and stack operations, then write the parser. It often helps enlighten. 22:34:19 oerjan: Should types be first class objects? 22:34:26 no 22:34:28 So you could do INT and get the integer type pushed to the stack 22:34:30 aww, ok 22:34:33 that would be fun though 22:34:39 it'd also make implementing (...) easy 22:34:40 ;) 22:34:41 then we get dependent types 22:34:43 yes 22:34:45 good point 22:34:50 and we are already in deep enough water 22:34:53 TYPE is a TYPE is a TYPE ... 22:35:15 oerjan: I'm naming all the constructors LName 22:35:16 like 22:35:19 LInt Integer 22:35:24 to avoid conflicts. 22:35:27 the actual type is Value, though. 22:35:40 not strictly necessary 22:35:51 oerjan: should i not do it? 22:35:55 data constructors and type constructors are different name spaces 22:35:55 i get confused when i see like 22:35:59 String "abc" 22:36:02 or 22:36:03 Int 2 22:36:14 oerjan: oh, extra type: String 22:36:26 and thus character 22:36:34 hm 22:36:38 strings: immutable, or mutable 22:36:52 but we'll need constructors for types and values, so need to have two sets of some anyhow 22:36:59 immutable 22:37:43 immutable? ok :| 22:37:54 I seem to mutate strings all the time, when not programming in a really functional language 22:38:06 (Lion isn't purely functional. Just you can utilize the functional paradigm to your benefit.) 22:38:41 oerjan: instead of list, maybe we should have stack 22:38:53 when you have a dictionary and the keys can be mutated, you are in deep trouble 22:38:55 but... i can't see you using a 'stack' structure heavily in programming, more than a list.. 22:38:59 oerjan: this is true 22:39:13 oerjan: maybe we should provide 'stack' and 'list' which are equivilent :P 22:39:24 yeah 22:39:41 oerjan: both are (IORef [Value]) 22:39:53 actually 22:39:55 maybe we should do 22:40:16 newtype Stack a = EmptyStack | Stack a Stack 22:40:22 just to emphasise the difference 22:40:28 but that might stop compilers optimizing 22:40:45 newtype Stack a = Stack [a] should work 22:41:02 oerjan: pretty useless, though 22:41:06 oerjan: Wait. 22:41:09 Should lists be immutable? 22:41:19 Schemers seem to like their lists in Diet Immutable flavour.. 22:41:53 oerjan: by the way 22:41:59 type Stack = IORef [Value] 22:42:00 or 22:42:03 type Stack = [Value] 22:42:04 pick one 22:42:28 if the latter, then we get | LStack (IORef Stack) which is different from the stack in Lion programs 22:42:54 what is the stack in Lion programs? 22:43:06 they should definitely be interchangeable 22:43:17 oerjan: the stack in lion programs is just a [Value] 22:43:22 with all the primitives being (Stack -> IO Stack) 22:44:12 we could go the Ref way - having just one type that is mutable, and contains an arbitrary value 22:44:30 oerjan: personally i don't like that 22:44:31 do you? 22:45:25 oerjan: another note: double vs float - i don't want two because it will make the interpreter more complicated 22:45:40 right, so take the best precision 22:45:43 I say Double 22:46:08 oerjan: In: 22:46:09 [a b c] 22:46:13 how do we represent the a, b and c? 22:46:23 i.e. | LProg Type (WHAT?) 22:46:25 err 22:46:25 should be 22:46:29 i.e. | LProg Type Type (WHAT?) 22:46:37 oerjan: speaking of which, what type is a data constructor 22:46:56 hmm 22:46:57 :P 22:46:59 a function of its arguments, in haskell 22:47:05 ah. 22:47:14 so how do we represent 'a type in Lion' 22:47:44 also, values do not need to contain types 22:47:58 oh 22:47:58 true 22:48:04 we can do that all pre-interpretation right? 22:48:10 yep 22:48:14 hmm, we will need a two-pass interpretation :-) 22:48:29 after parsing (which will not be able to parse into values, but some AST): 22:48:36 analyze all imports and that shiznit 22:48:42 gather up our types, do the inferrin' and the checksin' 22:48:53 get all yer AST, munge into values 22:48:55 interpret 22:49:24 oerjan: oll korrect? 22:49:32 afaict 22:49:48 oerjan: and the AST should be in Lion.AST 22:49:48 not Lion 22:49:58 because it's murky and most people would wet their pants upon seeing it 22:50:16 heh 22:50:21 oerjan: So: LProg [AST] or LProg [Value] 22:50:29 * oerjan thinks the same is true for ghc... 22:50:33 [Value] would require that we resolve [a b c] into the programs that a, b and c represent 22:50:40 which is like forth and... you can't recurse with it 22:50:52 So... [AST]? If so, that means we have to do analysis on quoted program call 22:51:00 Which is... kinda lame. 22:51:16 LProg (Stack -> IO Stack) 22:51:27 theoretically enough 22:51:52 oerjan: whoa, we're compiling? 22:51:55 .. when did that happen 22:52:24 we might 22:52:33 oerjan: and if we don't? :P 22:52:48 also, how would we construct the haskell? we can't exactly generate a string and pass it to eval.. 22:52:57 we should use Harpy FOR THE SPEED OF IT! :p 22:53:30 * oerjan has heard the word Harpy but isn't quite clear on it 22:54:24 oerjan: it's a monadic haskell DSL for generating x86 machine code (and getting a function out of it) at runtime 22:54:36 http://uebb.cs.tu-berlin.de/harpy/ 22:54:39 not constructing haskell text, just using combinators to combine programs 22:54:53 ah 22:55:06 so, oerjan 22:55:10 are we compiling or not? 22:55:13 well perhaps we should go via an AST first 22:55:15 and if not, what data type for LProg? :P 22:55:24 oerjan: oh, we will go via an AST 22:55:26 because 22:55:27 oh wait 22:55:32 we have to analyze all the types and all that 22:55:36 and THEN we can compile that 22:55:45 we need LProg's to be available as runtime values 22:56:08 -!- Corun has joined. 22:56:28 oerjan: just to execute them 22:56:45 oerjan: though we do need the types i think? 22:57:12 hm if we do imports 22:57:26 of already compiled modules 22:57:40 then they need to include types somehow 22:57:47 although maybe not in the same file 22:57:49 exactly.. 22:57:55 oerjan: I think interpretation is our best best. 22:58:03 But then, we go back to the problem: What is an LPRog? 22:58:43 the thing is 22:59:23 interpret (LProg prog) :: Stack -> IO Stack 22:59:44 oerjan: what about it 23:00:00 and that is the only way a prog is used 23:00:16 oerjan: and getType :: LProg -> ??? 23:00:25 so the prog could be just that, and interpret (LProg prog) = prog 23:00:32 or it could be a list 23:00:35 oerjan: and getType :: LProg -> ??? 23:00:39 think about, say, a REPL 23:00:44 when you enter an expression 23:00:46 it has to typecheck it 23:00:49 it is merely a question when we do the conversion to Stack -> IO Stack 23:00:49 but all the compiled functions it has 23:00:52 don't have their types! 23:00:57 they're just (Stack -> IO Stack) 23:01:05 so... whoopsy! 23:01:18 i am assuming this is at the time we have already done type inference 23:01:26 oerjan: REPL. 23:01:29 so values don't need to contain types 23:01:29 An interactive mode. 23:01:32 Do you see the problem now? 23:01:44 the dictionary for a repl 23:01:49 watch this 23:01:51 : foo ( INT -- INT ) ; 23:01:53 would contain (Value, Type) pairs 23:02:01 "abc" foo {* foo has lost its type, so we can't check it *} 23:02:07 oerjan: uhm what about the eval function 23:02:08 just saying 23:02:20 i think that the best way is to have some kind of actual interpretation. 23:02:33 LProg Type Type ??? 23:02:40 The thing we need to fill in is ??? 23:02:40 no types needed there 23:02:47 oerjan: can you please read what i'm saying 23:02:50 we need the types at runtime 23:02:54 yes and i disagree 23:03:02 oerjan: so explain. 23:03:09 we don't need them in the values themselves 23:03:13 where do we need them 23:03:23 we just need them in the toplevel REPL dictionary 23:03:46 each identifier comes with a value _and_ a type 23:03:47 oerjan: REPL isn't the only instance of this. 23:04:22 if you have a dynamic language, where ANYTHING could happen at runtime, including loading files in mish-mash order, you NEED to store those types 23:04:31 oerjan: OK then, let's pretend we don't need types 23:04:33 Fill in ??? 23:04:38 if it's dynamic yes 23:04:58 oerjan: Well, yeah. It is a dynamic language 23:05:00 it could still be either [Value] or Stack -> IO Stack 23:05:02 Not in types, but in other cases. 23:05:09 oerjan: [Value] it could not be. 23:05:18 [a b c] -> what Value do you use for a, b and c? 23:05:49 hm 23:06:29 exactly 23:06:33 so the current only option is an AST 23:06:36 which is probably the best bet 23:06:58 oh i am not sure [Value] is impossible 23:07:03 but i still think having types in the value -- even if not neccessary -- will make writing the interpreter trivial 23:07:15 oerjan: basic rule of thumb: everything that's a Value you can put in a ( -- ) declaration 23:08:07 i am still not sure there is a problem 23:08:24 oerjan: what is the value for a b and c then 23:08:37 that depends, obviously, on what a b and c is 23:08:51 if a = 1, probably just that 23:08:55 no, oerjan 23:08:57 i mean literally 23:08:58 [a b c] 23:09:21 if a b and c are primitive functions 23:09:32 oerjan: primitive or maybe defined.. 23:09:36 and here's the main thing 23:09:39 functions can be redefined. 23:09:44 oops 23:10:02 need to keep their types, right? 23:10:05 haha, did i just stomp out our compiler design 23:10:06 oerjan: yes 23:10:18 otherwise you'd have to do major type rechecking 23:10:30 and this would break the system: 23:10:33 : dup ; 23:10:52 oerjan: so, it does have to be an AST doesn't it 23:10:54 realistically 23:11:04 ah wait! we don't EVER have to convert an AST into Values 23:11:13 we just go through the AST and interpret it 23:11:17 just the stuff on the stack are Value-s 23:11:44 -!- timotiis has quit ("leaving"). 23:12:03 well if functions can be redefined they need to be stored with their names/lookup keys 23:12:10 or as IORefs 23:12:30 oerjan: yes, we'll also gain global variables from this 23:12:31 hmm 23:12:38 maybe local variables would make some code clearer too 23:12:49 though lexical vars would be a huge overhead. 23:12:55 -!- oklopol has quit (Read error: 104 (Connection reset by peer)). 23:13:02 oerjan: we have a (M.Map String Value) 23:13:10 eh, wait 23:13:14 oerjan: we have a (M.Map String (Bool,Value)) 23:13:25 Bool? 23:13:29 otherwise assigning a global variable to a program would have odd results (autocommandifies) 23:13:52 (isCommand,value). (True,aProg) or (False,anyValue) 23:14:19 -!- oklopol has joined. 23:14:34 oerjan: that's ugly, of course ;) 23:15:56 hm perhaps 23:16:34 a program executes while a value places itself on the stack 23:16:43 yes 23:17:07 oerjan: actually, i think we should store the type in programs only used by things like the repl 23:17:12 it'd just make the repl a lot easier 23:17:12 :P 23:17:13 no other reason 23:17:34 -!- Insane has joined. 23:17:44 oerjan: hmm, what to call the AST object? 23:17:48 AST or ASTNode or Expr or.. 23:18:37 assuming there is only one type of it, AST is fine? 23:19:31 its just not a tree 23:19:33 its a tree node 23:19:33 :) 23:20:04 * oerjan spontaneously rearranges ASTN and adds a Y 23:21:02 heh 23:21:10 * oklopol adds an "i", because this channel lacks it 23:21:25 oerjan: I think Expr is good 23:22:01 oerjan: hould we duplicate LInt/Char/String etc for the exprs? 23:22:03 or should we have 23:22:06 Constant Value 23:22:35 data constructors cannot be shared between types 23:23:51 oerjan: I meant 23:23:57 data Expr = EInt Integer | ... 23:24:04 i prefer the Constant Value 23:25:45 -> food 23:25:51 oerjan: d'aww 23:25:55 i was just about to paste something 23:26:09 only from the fridge... 23:26:11 http://hpaste.org/5333 23:26:13 ah 23:26:14 :P 23:27:12 i just need the Type type ;P 23:27:19 -!- unrepresentative has left (?). 23:31:53 oerjan: when you're back: what should Type be? 23:32:07 that's the hardest part i guess 23:32:22 it'd mostly be a duplication of Expr. But without the constructor parameters 23:32:30 we need Forall Var Type for polymorphism 23:32:44 oerjan: whut 23:32:57 er, do you know anything about haskell types? 23:33:11 enough to write most stuff! 23:33:16 But not Forall Var Type polymorphisms 23:33:25 I kind of get the "forall a. ..." stuff though. If it's anything related 23:33:37 yes it's for that 23:33:54 hm, perhaps Forall [Var] Type 23:34:10 oh 23:34:22 stacks cannot be the same type as uniform lists 23:34:46 exactly 23:34:48 lists are immutable 23:34:51 stacks are an IORef 23:34:54 no 23:34:59 uh yes, see my paste 23:35:00 that is almost irrelevant 23:35:03 h 23:35:05 okay :P 23:35:14 lists contain only one common type 23:35:27 stacks need to be distinguished according to their contents 23:35:43 Stack Type Type perhaps 23:35:45 -!- cherez has joined. 23:35:47 oerjan: haskell lists or my list 23:35:54 because Lion lists are polymorphic 23:35:58 they're [Value] 23:35:59 the first is the top type, the second the rest of stack 23:38:43 if there is to be any hope of type inference, then there must be a difference between what corresponds to haskell's tuple-like and list-like types 23:38:55 yes, I guess 23:39:06 tuple-like means each position of the tuple (at least those positions we look at) must have a specific type 23:39:12 OK, lists are all of one type... Hm... I don't know how to express that in Value 23:39:30 list-like means all positions have the same type 23:39:40 i don't think you can 23:39:49 without Oleg-level type hackery 23:40:39 hm, or... 23:40:52 maybe that's what they do with those GADTs 23:41:52 that would mean having Lion types be more closely connected to haskell types 23:42:03 oerjan: maybe we should stop using haskell's type system, the way this is going :P 23:42:10 well 23:42:12 for Values 23:42:17 like 23:42:26 right 23:42:28 data Value = Value Type [... but then i wouldn't know what to put here obviously ...] 23:42:55 _either_ we make Value be completely dynamically typed, _or_ we need to be very clever with the haskell 23:43:25 oerjan: i think being clever with haskell might make us bump into limimtations later on 23:43:35 right 23:43:47 oerjan: OK, what zany magic does a Value become now? 23:45:18 :) 23:45:32 oerjan: Since I have no idea to say A BLOCK OF POLYMORPHIC MISHMASH since that is... not haskell's speciality 23:45:38 Do we need to do weird pointer magic or something? :P 23:46:22 um i thought you said we _shouldn't_ be clever with the haskell 23:47:15 oerjan: we shouldn't 23:47:20 but i don't see another way to make Value polymorphic 23:47:41 we make Value polymorphic by ignoring all types in it 23:47:54 writing it as if the language is totally dynamically typed 23:47:56 I think i'm missing something. What is Value's data definition? 23:48:19 -!- Hiat1 has joined. 23:48:42 you might remove the two Type's from it 23:49:00 i am slightly worried about the IORef Stack 23:49:18 exactly how is it supposed to be legal to change a Stack? 23:49:45 oerjan: by pushing to it and popping off it? 23:49:51 or swappign two valus in it? 23:49:53 or dupping it? 23:49:55 JUST A THOUGHT 23:50:20 and that can only be well-typed if all values in it have the same type 23:50:26 well, no. 23:50:30 It's just like the main program stack. 23:50:35 Completely polymorphic 23:50:49 there's only a single stack type, STACK 23:50:53 it holds any value 23:51:21 that's not a single type in any static type system 23:51:36 er 23:51:46 that might be overgeneralizing 23:51:52 oerjan: It is in this case, because otherwise the main stack would be badly typed 23:52:00 no 23:52:03 So we have one magical kitten bunny unicorn polymorphic type. 23:52:16 in a concatenative language the type of the stack depends on time 23:52:23 where you are in the program 23:52:40 1 "abc" 2.3 [x y z] 23:52:47 that is totally polymorphic. 23:52:54 and having the stack as a first-class object is useful 23:52:57 but if it is static like Cat then the type is still fixed at a given point 23:53:07 oerjan: oh, in FUNCTIONS, sure. 23:53:12 that's just verified that the calls are OK 23:53:17 but you can do whatever you want otherwise 23:53:17 also 23:53:24 -!- Corun has changed nick to RockTheDragon. 23:53:26 runInStack :: Stack -> IO Stack 23:53:46 so you want a lot of dynamic checking of stacks before passing them to functions? 23:54:01 runInStack (s : p : xs) = do foo <- readIORef s; return (interpret p s : xs) 23:54:16 oerjan: We determine this before interpretation.. 23:54:49 Since all FUNCTIONS have well defined types, and all PUSHES do, we can determine if a CALL is well-typed, but the STACK itself is totally polymorphic. 23:55:58 hm... 23:56:30 if you dup a mutable stack you are going to get aliasing problems 23:56:49 oerjan: present a program (use any stdlib functions you want to do it) that is a problem with typing or whatever because i'm not seeing it 23:56:56 oerjan: also, we copy objects with dupping, I think 23:57:05 entire stacks? 23:57:10 hm 23:57:29 in that case there is no point in making Stacks be in IORefs 23:57:55 oerjan: yes there is 23:58:36 runInStack (p : s : xs) = do foo <- readIORef s; stk <- interpret p s; writeIORef foo stk; (s : xs)) 23:58:36 hm 23:58:36 i guess you are right 23:58:41 oerjan: but then stacks are just identical to lists 23:58:46 so i don't feel justified including them! ;) 23:58:54 oerjan: oh 23:58:59 you can stuff stacks in something else 23:59:02 - say a structure - 23:59:05 without having them copied 23:59:09 thus, they need to be iorefs 23:59:32 but then you get aliasing problems again