00:09:57 hmm 00:11:48 oerjan: if smetana+1 compacts the infinite smetana program to finite size, then it's obviously turing-complete 00:12:43 oerjan: the question is whether we can consider smetana to be turing-complete, despite infinitely large programs 00:14:11 and "smetana+1 is just a notation" would be a good argument for that. 00:15:15 if it is turing complete 00:15:19 it can hardly be said to be just a notation 00:15:59 ehird`: that doesn't make any sense. 00:20:49 ehird`: Any more pebble.bfm insanity? 00:20:55 pikhq: damnit!!! i forgot 00:21:02 pikhq: =( 00:21:18 pikhq: it'll also be harder than i thought due to lack of strings in pebble 00:21:37 Meaning that you'd have to do string functions first. 00:21:44 yes 00:21:56 the hardest part would be coming up with an efficient representation 00:22:16 i mean, H1e1l1l1o1w1o1r1l1d is... bigger than neccessary 00:24:30 Only by a constant factor. 00:24:38 i mean linear. 00:24:43 And "Hello world\0x00" is. . . Not useful for string insertion in Brainfuck. ;) 00:25:38 lament: yeah well :( 00:25:51 i guess, i'll do the swapping-algorithm 00:25:55 -!- jix has quit ("This computer has gone to sleep"). 00:25:55 Helloworld0 00:25:58 to insert to string 00:26:15 make 0 the index of the string from the end you want to access 00:26:19 swap and -1 repeatedly 00:26:37 of course, to iterate 00:26:43 just go from H until you find 0 00:27:51 good algorithm? 00:27:57 though the swapping could be inefficient 00:29:18 pikhq: lament: comments? 00:29:41 i bought sheet music paper! 00:30:02 related comments? 00:30:33 10 staves per sheet, 40 sheets (related to my previous comment) 00:31:00 related to my algorithm 00:32:19 :) 00:36:57 i guess the swapping would be slow 00:36:58 no? 00:40:03 -!- RedDak has quit (Read error: 113 (No route to host)). 00:51:15 no/yes? ;) (lament,pikhq) 00:55:59 Are you looking for minimal Turing-complete systems? 00:56:21 and PEBBLE in PEBBLE 00:59:25 * ihope creates a parser called convertNewZealand 00:59:35 haha, what 00:59:39 oh -- welcome back 00:59:43 hm 00:59:45 Ello. :-) 00:59:55 It converts from unary to decimal with New Zealand. 00:59:57 is the unary->anything converter actually possible/easy in your subst lang? 01:00:03 It's certainly possible. 01:00:04 hahahaha 01:00:04 one second difference 01:00:18 so how does it utilize new zealand 01:00:40 By New including a Zealand if the string is "". 01:00:57 ...including New Zealand, I mean. 01:01:23 so what is a New Zealand 01:01:25 apart from a country 01:01:40 A backronym for "no zero". 01:01:57 And now for another regex mnemonic: "Look up there! It's money!" 01:02:10 I'm dumb. explain 01:02:22 (By the way, what regexps do you use? Custom?) 01:02:24 "" is converted to "" instead of "0". 01:02:30 Undefined, really. 01:02:39 ah 01:02:43 Though $ is a pretty important part of it. 01:04:21 Does your language have a way of putting anything to the screen? 01:04:35 A primitive or something, that does no substitutions, but has a side effect of output 01:04:44 It could easily be extended to include one. 01:05:03 Input as well. 01:05:32 Because you could make a program basically identical to fibonacci.b 01:05:41 bleach(): {/[ab]/; "w" + bleach()} 01:05:42 Writes out fibonacci numbers in decimal, one per line, until halted. 01:05:51 (With an invisible period on the end.) 01:05:58 ihope: what does that do? 01:06:07 It replaces a and b with w. 01:06:15 And... why. 01:06:22 ...and gives an error when it reaches the end of the string. 01:06:46 It was going to make input more friendly for convertNoZero, but I just realized it's actually completely unnecessary. 01:07:08 Just match . instead of w :-) 01:07:31 Well, I was thinking [ab]. 01:07:34 But yeah. 01:07:39 * ihope ponders 01:07:47 You want it to be generalized 01:07:53 I guess so. 01:08:05 since unary is just a way of encoding a string as its length, the actual contents is arbitary 01:08:27 * ihope nods 01:10:06 * ihope decides to go for little-endian increment 01:10:29 So what is your language called? 01:10:32 is it implemented? 01:11:11 No implementation. I think I'll call it Redivider. 01:11:26 It's really interesting, I might implement it :) 01:11:44 Should I finish the program or the spec first? 01:11:45 Does it have a spec or similar? I mean, defining regexps beyond the basics could be hard... 01:11:49 hahah 01:11:53 :-) 01:11:54 <1 second difference 01:12:01 and program! :) 01:12:10 Will do! 01:16:13 Is it okay if I use the word "guts" in the spec? :-P 01:16:28 Sure 01:16:29 :P 01:16:31 As in ::= "/" "/" 01:16:35 But I want to see the program first! 01:16:37 oh 01:16:40 as long as you define regexguts 01:16:41 ;) 01:16:42 Yes, I'm still doing that. 01:16:49 Pff, why would I do that? :-) 01:17:01 because otherwise i won't implement it, having no spec :P 01:17:08 i'm not going to use a third-party regexp spec 01:17:11 Okay. 01:17:14 that'd be inconsistant with other implementations! 01:17:19 I'll write my own minimalistic one, then. 01:17:22 think of all the regexp libs... you gotta define your own for portability ;) 01:17:28 just give it enough to be comfy for use 01:17:33 * ihope nods 01:17:41 Ranges, exclusion... 01:17:51 Plus /[]/, the regex that doesn't match. 01:17:53 there's not much to regexps 01:18:11 So is Redivide TC? 01:18:21 i doubt it, personally, but.. 01:18:34 I might try and write a bf interp in it. :) 01:18:46 Redivider is almost certainly TC. 01:18:48 hm, i think that would be possible 01:18:50 even simple 01:18:52 that would be cool :) 01:18:55 If http://pastebin.ca/679421 has no bugs, it is. 01:19:09 Of course. 01:19:11 But brainfuck = far more fun 01:19:12 ;) 01:19:46 very crazy suggestion for regexps 01:20:08 means "anything function x matches" 01:20:20 this would make, e.g. parsing brainfuck braces trivial 01:20:24 That sounds rather complicating. 01:20:25 though perhaps it's too bloated in your mind ;) 01:20:35 i don't know, it'd just make a lot of stuff you could think of easier 01:20:49 This language is inspired by Parsec, which is a completely ordinary combinator parser as far as I can tell :-) 01:21:28 Well, yeah, but with parsec you could insert random haskell in the middle 01:21:33 Something like (i don't know haskell) 01:21:44 match "abc" ++ callParser ++ match "def" 01:21:48 with these regexps, you can't 01:22:02 I think you can still do that here. 01:22:20 Hmm 01:22:20 how? 01:22:32 /abc/ + parser() + /def/ will work and return "abcwhatevertheparserreturneddef". 01:23:04 oh, cool 01:23:04 so 01:23:11 /[/ + bf() + /]/ 01:23:11 First it runs /abc/, which consumes the abc and returns "abc", then it runs parser(), which consumes something and returns something, then it runs /def/, which consumes the def and returns "def". 01:23:14 should parse braces? 01:23:18 right? 01:23:22 Yup. 01:23:46 If bf() parses "foo" into "bar", that'll parse "[foo]" into "[bar]". 01:24:23 If you don't like the brackets around it, then there's {/[/; x <- bf(); /]/; x} 01:24:29 hmm 01:24:35 what is a function that parses nested parens with anything in 01:24:36 i.e. 01:24:36 That parses "[foo]" into "bar". 01:24:53 (abc) ((ab)c) (a(b)(c((d)))) parses, (a etc don't 01:25:05 More importantly: some way to get the inner contents 01:25:09 (abc) returns abc 01:25:14 ((ab)c) returns (ab)c 01:25:22 but, of course, ONLY if the whole thing has well-formed braces 01:25:25 Is it possible? 01:25:26 What does (ab)c return? 01:25:32 Possible, yes. Probably easy, too. 01:25:33 ihope: ab 01:25:35 well 01:25:37 i guess that's undefined 01:25:45 but yeah ab 01:25:52 i just mean, if you can do that, then you can parse brainfuck 01:26:13 check(): /(/ + check() + /)/ + check() | /[^()]/ + check() 01:26:16 if you have "code[SENTINEL]tape", then you can run a brainfuck program trivially, iirc 01:26:19 ...with that invisible period. 01:26:28 That just checks for well-formedness. 01:27:08 grab(): {/(/; x <- check(); /)/; x} 01:27:13 Cool. 01:27:17 ...period again, gah. 01:27:21 So what are these "x"s etc? 01:27:28 Just arbitary variables that are "" by default? 01:27:36 By default, they're errors. 01:27:40 Otherwise, yes. 01:27:46 So how does grab(): {/(/; x <- check(); /)/; x} work 01:27:48 They always hold strings, never parsers. 01:28:23 It runs /(/ and throws away the result, then runs check() and stores the result in x, then runs /)/ and throws away the result, then runs x and returns the result. 01:28:31 A string is the same thing as a parser that does nothing and returns that string. 01:28:35 But what is x 01:28:40 It should be an error 01:28:43 x is a local variable, I guess. 01:28:43 You did not define it 01:28:55 x <- check() is what introduces it. 01:28:56 <- is append right? 01:29:09 No, it stores. 01:29:12 Ah 01:29:14 How do you append? 01:29:15 Or creates or some such. 01:29:17 x <- x + y? 01:29:21 <- is obviously borrowed from haskell's do notation 01:29:32 I guess you can do it that way. You might as well do z <- x + y, though. 01:29:49 These behave pretty much exactly the same way as in Haskell's do notation, yeah. 01:29:56 Why, ihope? Why have unneeded vars? 01:30:20 Less confusion, I guess, if you find that sort of thing confusing. 01:31:53 I think this is right, apart from the fact that it outputs the numbers all smooshed together if output doesn't automatically add a newline: http://pastebin.ca/755940 01:32:25 a few questions 01:32:43 is main a special name? or is it just what you called it as a convention? and, what's []? 01:33:03 There's not necessarily anything special about it. 01:33:24 foo()[blah] makes foo parse blah; otherwise, it parses from whatever it's called in. 01:33:32 Could you like put it in the spec? "If there is a main function, it is called at runtime, otherwise you are dropped in to a REPL?" 01:33:39 The "current string", I guess. 01:33:44 Sure. 01:33:48 foo()[blah]... why not just foo(blah)? 01:33:53 I can't see the ()s being used for anything else there 01:34:13 Plus it would look nicer. 01:34:41 They're for when you want parsers to take parameters other than the current string. 01:35:07 so foo(extra)[str]? 01:35:13 If so, may I humbly suggest just foo(str, extra)? 01:35:25 Good idea, yes. 01:35:30 :) 01:35:37 Though I rather feel foo(extra, str) would be better. 01:35:46 Although... What if you want extra args, but default string? 01:35:54 Maybe some kind of seperator 01:35:57 foo(str | extra) 01:36:05 no, no... that won't work nicely 01:36:06 hmm 01:36:13 how to resolve that? 01:36:22 Extra arguments but the default string would just be foo(extra). 01:36:37 How can it tell the difference between foo(str) and foo(extra)? 01:37:04 Each parser has a parameter number. If it's given that many parameters, then they're all actually parameters; if it's given one more, the last one is the input string. 01:37:28 Parser with 1 parameter number: 01:37:30 foo(str) 01:37:34 I just want to pass it a special string. 01:38:03 If foo's parameter number is 1, then str is the parameter. 01:38:16 Right! BUt I don't want it to be. 01:38:21 If foo's parameter number is 0, then str is the input string. 01:38:24 I just want to pass it an extra string, with no extra parameters. 01:38:29 Foo's parameter number is 1. 01:38:31 Tell me how. 01:38:41 If foo's parameter number is 1, then use foo(parameter, inputstring). 01:38:49 I don't want to give it an extra parameter 01:39:03 If foo's parameter number is 1, it must take a parameter. 01:39:09 Ah, ok. 01:39:12 No optional parameters 01:39:14 Right. 01:39:46 If you like those optional parameters, go the Haskell Way and use foo("J" + parameter) or foo("N") :-) 01:39:47 I suggest making inputstring the first 01:40:02 It feels like it's what the parser is being called /with/ 01:40:06 Everything else is just additional info 01:40:15 Also, it makes sense. 01:40:25 I sort of have the opposite opinion for the same reason. 01:40:28 For increasing parameter num: foo(str), foo(str,1), foo(str,1,2) etc 01:40:41 str - the main part of the parser, it's what its actually parsing - moves, in your smantics 01:40:43 which is not nice 01:41:19 Well, if parameter numbers can vary, you need some way of differentiating a parameter from an input string. 01:41:32 First parameter: string 01:41:38 Rest: parameters, function dependena 01:42:01 Function what? 01:42:13 dependant 01:42:21 The string is there regardless of the function 01:42:25 The rest is stuff added on "after the tail" 01:42:36 The input string's being optional is sort of necessary. 01:42:36 It makes so much more sense for the string to be first. 01:43:27 You need some way of making reference to the current string... or maybe this could be done without the current string stuff? Hmm. 01:43:42 look: 01:43:47 func() # current string 01:43:54 oh 01:43:55 wait 01:43:59 i get you 01:44:04 you can call a function with a parameter 01:44:06 but with the current string 01:44:10 OK, you're right, yours is better 01:44:19 Hmm. 01:44:22 Some way to mark it 01:44:23 How about 01:44:32 [abc] means "abc as string argument" 01:44:38 and can be anywhere, but is generally at the start 01:44:46 for a function with parameter value 2: 01:44:49 func(1,2) # normal 01:44:53 func([str], 1, 2) # using str 01:45:07 How would varying numbers of parameters work, anyway? 01:45:12 They wouldn't 01:45:15 I'm not talkng about that 01:45:18 But, 01:45:22 func(1,2) and func(1,[str],2) would work 01:45:28 i.e. [] just mean "string argument" 01:45:34 Seems a little pointless. 01:45:34 func2(str) # I guess, for parameter value 0, the []s would be optional, for nicety 01:45:52 so, progression: func(str) func([str],1) func([str],1,2)... 01:46:09 ihope: Well, it's nicer than allowing one additional argument. Think of the bugs - it's just not obvious at a glance 01:46:28 * ihope ponders 01:46:41 I think it's nicer, IMO 01:46:42 Just cleaner. 01:46:44 More free-form 01:46:45 Well, the input string is quite a bit like just another parameter. 01:47:02 Yes, but: 01:47:06 func(1,2,oops-an-additional-arg) 01:47:11 That could so easily be a bug. 01:47:15 And explicitness is better, I'd say 01:47:18 Indeed, it could. 01:47:29 func(1,2,oops) would be an error - "too many arguments, perhaps you need []?" 01:47:38 func(1,2,[oops]) would do what you intend 01:47:43 Though I like the look of semicolons better. 01:47:51 (Probably [] would by convention go at the start, though - func([oops], 1, 2)) 01:47:56 func(1, 2, oops;) and func(1; 2, oops) and such. 01:47:57 So, I think that'd be good. 01:48:03 but [oops] at the start or end by convention? 01:48:11 ihope: Well, it just seems not noticable enough to me 01:48:25 Hmm... 01:48:40 "It's an esoteric language; get over it"? :-P 01:48:51 Esoteric language != unplanned language 01:49:02 I think that [] here makes more sense 01:49:13 OK, How about this 01:49:20 How about func(1, 2; oops] and func[oops; 1, 2)? 01:49:23 Instead of func()[blah] 01:49:29 func[blah]() 01:49:32 or just func[blah] 01:49:33 yeah 01:49:34 so: 01:49:36 func[blah] 01:49:37 func() 01:49:41 func[blah](1,2) 01:49:47 Ah, I like that. 01:49:55 func[blah] would be sugar for func[blah](), since the former looks nicer 01:50:01 * ihope nods 01:50:09 Though maybe func[blah]() would be nicer, as its more consistant - func[blah] is the parser that matches on blah 01:50:31 Hmm 01:50:42 Well, there are no first-class parsers here. 01:50:46 output[reverse[unary()]] output[reverse[unary()]()]() 01:50:49 The former is definately nicer 01:50:50 OK 01:50:52 Yeah. 01:51:00 a[b] is a[b]() 01:51:05 a() is a[current_str]() 01:51:07 Hey, maybe we could get rid of () entirely. 01:51:12 I mean, make it optional. 01:51:14 a[b](c,d) is what you expect 01:51:21 a(b,c)[d] is an error 01:51:22 And how? 01:51:28 a[b],c,d? Ugly. 01:51:36 I think the above is probably the best 01:51:40 I mean just (), not (stuff). 01:51:49 No foo(); just foo. 01:51:49 run(): {x <- step(); output()[reverse()[unary()]]; run()[x]}. 01:51:49 -> 01:51:56 output[reverse[unary]] 01:51:57 run(): {x <- step(); output[reverse[unary()]]; run[x]}. 01:52:01 Hmm 01:52:08 ihope: I think in that case () provides more information 01:52:13 Because, otherwise 01:52:17 You could mistake it for a variable. 01:52:25 Yes, that's true. 01:52:36 I'll rewrite your paste using that proposed syntax 01:53:04 http://pastebin.ca/755956 01:53:10 IMO, it looks really clean and easy to understand. Very nice. 01:53:36 Likewise, func[a](b,c) follows naturally from that syntax. 01:53:38 Yes, you're right. 01:53:40 * ihope nods 01:53:41 OK. 01:53:49 So, can I expect a spec tomorrow maybe? ;) 01:53:50 I'm going now 01:53:57 Yup. Bye. 01:53:59 Very interesting langugae 01:54:05 It's esoteric but looks really easy to program in too 01:54:09 * ihope nods 01:54:16 OK. Leave me a memo with MemoServ if you get it done :) 01:54:20 Will do. 01:55:20 -!- ehird` has quit (Read error: 104 (Connection reset by peer)). 04:25:58 -!- tokigun has joined. 04:51:12 THIN FUNCTIONS WILL BE THE DEATH OF ME 04:52:52 GAUNT ZOMBIE FUNCTIONS, LOOKING FOR BRAINS... 04:56:22 Unfortunately, I believe that the solution is to abandon my dictum that all blocks are functions :( 04:56:50 You *could* do it as Tcl does. . . 04:57:08 Provide an "uplevel" command, which executes something up a level in the stack. 04:57:21 -!- ihope has quit (Read error: 110 (Connection timed out)). 04:57:40 Wow that's gross >_> 04:58:19 that's not very higher-order. a function should not necessarily know where it was called. 04:58:23 I guess it's not Plofy, though. 04:58:28 Mind you, it's better than thick and thin :P 04:59:52 But not much better. 05:01:51 hm... isn't a thick function essentially one that binds its escape continuation to return? 05:19:05 That's a truly bizarre way of looking at it :P 05:19:46 A thick function is the point in the call stack that a return will drop do. 05:33:48 alternately, a thick function is one which catches the return exception. you could generalize that. 05:33:57 and good night. 05:34:03 -!- oerjan has quit ("leaving"). 05:34:38 Oooh, that's a good way to think about it. 05:34:43 Returns become throws with special syntax. 05:35:01 Thick functions are just functions with implicit try/catch blocks. 05:35:18 Now, how can I use that to get rid of thick functions :P 06:58:56 -!- staplegun_ has joined. 06:59:47 -!- staplegun_ has changed nick to i4nic8. 07:00:55 howzit 07:03:24 -!- i4nic8 has quit (Client Quit). 07:03:44 -!- i4nic8 has joined. 07:05:10 piss 07:17:54 -!- i4nic8 has quit ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]"). 07:26:42 -!- puzzlet has quit (Remote closed the connection). 07:26:50 -!- puzzlet has joined. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 10:20:10 Hm. 10:26:33 -!- puzzlet has quit (Remote closed the connection). 10:26:37 -!- puzzlet has joined. 10:32:34 -!- puzzlet has quit (Remote closed the connection). 10:32:40 -!- puzzlet has joined. 11:09:34 -!- bsmntbom1dood has joined. 11:21:20 -!- bsmntbombdood has quit (Read error: 110 (Connection timed out)). 11:49:14 -!- jix has joined. 11:49:24 -!- jix has quit (Remote closed the connection). 11:49:51 -!- jix has joined. 12:15:15 o 12:37:45 -!- Tritonio has joined. 13:56:49 -!- puzzlet has quit (Read error: 104 (Connection reset by peer)). 13:58:26 -!- puzzlet has joined. 15:08:29 -!- ehird` has joined. 15:12:55 GregorR: that try/catch idea for thick functions is good but it doesn't help you vanquish thick/thin functions 15:13:25 Hence, " Now, how can I use that to get rid of thick functions :P" 15:13:52 :P 15:13:59 in fact it probably complicates it 15:14:07 because you introduce syntactic sugar etc and even more thick/thin semantics 15:14:28 ok, show me a recursive factorial again so i can see thick vs thin and i'll try and figure out a way to resolve it 15:16:23 :) 15:16:24 http://www.pastebin.ca/756432 15:23:32 GregorR: make it always run the program with every single combination of thick and thin functions at the same time, and introduce another, declarative, language, you have to use with the actual plof code to tell the interpreter what the correct behavior is; it can then resolve the right combination of thick/thin functions automatically 15:23:38 you're welcome. 15:23:50 wow 15:24:25 so 15:24:27 {} = thin 15:24:32 :{} = thick 15:34:32 right? GregorR? 15:34:55 -!- Tritonio has quit (Read error: 110 (Connection timed out)). 15:36:16 pikhq: pebble.bfm will be called Calculus ;) I'm working on it no 15:36:17 w 15:36:20 -!- Tritonio has joined. 15:48:44 -!- bsmntbombdood has joined. 15:48:55 -!- oerjan has joined. 15:57:39 pikhq: how does eval work? does it run at compile-time? 16:00:02 -!- bsmntbom1dood has quit (Read error: 110 (Connection timed out)). 16:24:18 * GregorR reappears. 16:24:20 ehird`: Yes. 16:24:21 oklopol: No. 16:24:32