00:05:58 Hello! 00:07:52 Hell no. 00:20:21 http://www.space-invaders.com/rubikdown.html 00:20:22 O_o 00:23:43 that's pretty easy once you know how to solve a rubik's cube 00:34:57 except not all color combinations are legal 00:38:38 once you know how to solve it, you pretty much know what's legal 00:39:27 ah ;) 00:39:29 :P 00:39:36 so what usually goes on here? 00:40:36 discussion about languages, usually 00:40:49 excellent. :D 00:40:58 Speaking of languages... 00:41:10 continuations: 00:41:20 Good, bad, or what? 00:41:33 (and continuated exception handling... whatever that's called) 00:42:45 never used 00:42:56 but i find it a useful concept 00:43:03 and a great toy used excessively 00:43:47 I've never really gotten into most functional languages, so I never use them, and in fact, never even heard of them `till I started doing language design research 00:45:05 i learned about functional programming here, pretty much :P 00:45:08 (iirc) 00:45:43 :P 00:47:23 hmmm... 00:47:32 well, coroutines are simply awesome... and they use a form of continuation. 00:47:52 coroutines? 00:47:55 continuations are pretty obligatory in order to actually implement threading 00:48:01 here's what I've got on Sophia so far, for those interested : http://deadbeefbabe.org/paste/4111 00:48:31 coroutines are procedures that can return multiple outputs and receive multiple inputs. 00:48:37 -!- sebbu has quit ("@+"). 00:49:02 a basic example would be processes running in an OS... 00:50:42 well, I've had a few language ideas about returning multiple values, but I think you're talking about something a little bit different :P 00:50:55 heh, most likely,. 00:51:10 Figs you mean returning multiple values simultaneously? 00:51:16 ...let me write up an example in Python. Familiar with it? 00:51:23 yeah 00:51:26 no 00:51:35 (yeah@oklopol, no@SIB) 00:51:45 with coroutines you return something and leave the function in a state where it expects more arguments 00:51:56 heh... if you've ever dealt with any kind of programming language... basic Python won't take but a few seconds to figure out. 00:52:11 I do most of my programming in C++ 00:52:19 I can probably take a guess at it :P 00:52:40 so... you have a statement in a funtion that is kinda like next_arg=return_and_wait(5); 00:52:41 it basically looks like pseudocode 00:53:06 so, it returns from the function normally, but the next given argument is given to next arg 00:53:26 so, it returns the continuation implicitly 00:53:35 O.o 00:53:36 ok 00:53:39 s/next arg/next_arg 00:53:43 I'd think of that as returning a function 00:54:06 (which I've done things similar to, but not exactly that) 00:54:18 I can see how that'd be useful 00:54:24 kinda like that, though it's usually not returned, but the function itself changes into the new function, that now is the continuation waiting for more parameters 00:54:45 hmm 00:55:00 (correct me if i'm wrong, i've never used yield, which i believe is return_and_wait) 00:55:07 If I was picking a syntax for it based on the way you guys've just described it, I'd do something like 00:55:08 (yield being python) 00:56:06 f=f(x); 00:56:13 f(y); 00:56:29 where f is a function returning a function type :P 00:57:00 ...it's probably the same thing I'd imagine. 00:57:28 Figs the problem with that is f(x) will actually return a value, not just the continuation 00:57:59 I come from C++ remember? :P 00:58:13 reference arguments as return path :P 00:58:23 but eh 00:58:28 ? 00:58:35 return path? 00:58:52 void triple(int& x) {x=3*x;} 00:59:05 well, for lack of a better term 00:59:28 if you have ever done C/C++ programming 00:59:39 i've done mostly c/c++ programming 00:59:43 ok :) 01:00:01 but, returning is a better way, usually 01:00:13 in a fair number of cases, yeah. 01:00:28 but you can do it that way, if you have to 01:00:41 one of the things I thought about for Creole (my language) was to do this: 01:00:49 struct Z = f(x); 01:01:18 if(Z.foo) {bar();} 01:01:41 now what's that mean? 01:01:44 with f returning multiple values 01:01:57 ah 01:01:58 i see 01:02:09 I haven't tried to impliment that yet 01:02:15 so I don't know if it is a good idea or not :P 01:02:28 I have returned 01:02:30 it's quite clever 01:02:42 ...I like it... and I've actually found practical uses for it. 01:02:42 though i'd not do it exactly like that 01:02:50 ..in a text-based game :) 01:03:16 well, using names for returning makes sense in that you usually have names for the args 01:03:18 how could you do it, oklopol? 01:03:21 *would 01:03:54 Here's a coroutine in Python : http://deadbeefbabe.org/paste/4112 01:04:22 "bullet" supports multiple named return values from a function: http://www.nonlogic.org/dump/text/1174856252.html 01:04:25 i would do it exactly like that. 01:04:52 ... 01:05:16 do subdiv[val1:a val2:b] to [subresult:sub divresult:div] 01:05:24 in def main 01:05:27 right? 01:05:47 * SevenInchBread tries his best to stomach the type declarations to figure out what we're talking about. 01:06:18 heh, you'd hate the stuff I'm working on then, 7" 01:06:25 oklopol: that is how they work 01:07:05 ...I probably would. 01:07:19 personally, I find [ ] for blocking to be hard to read, but that's just because I've grown up on {}'s and () 01:07:49 RodgerTheGreat i assume you'll do 'struct lambdas' as i call them like Figs just showed... i mean that struct is just a hash table 01:08:03 in bullet, parameters are given in the form type:name and returned values are extracted in the form storeValueName:ReturnedValueName 01:08:03 I think []'s are easier to follow without "losing them"... it is a little weird though. 01:08:24 with Sophia, I just made everything lazy... so all ()'s are essentially blocks. 01:08:36 mm 01:08:53 i don't know why i assume that. 01:09:06 even non-()'d expressions are blocks. 01:09:08 oklopol: it is one approach that might work 01:09:22 heh, my whole language is blocks @_@ 01:09:32 and interfaces 01:09:52 I still have to figure out a lot of the syntax though 01:10:06 bullet doesn't really need interfaces, because it's non-OO 01:10:18 Figs, if everything is blocks... you could probably afford to get rid of a block syntax. 01:10:21 no, it has interfaces :P 01:10:39 heh 01:10:40 def subdiv[double:a double:b] returns [double:sub double:div] 01:10:43 that is an interface 01:10:54 two inputs (a,b) 01:11:04 and two outputs 01:11:07 (sub,div) 01:11:10 it's a function 01:11:12 unless I am misreading? 01:11:12 though 01:11:18 io is a good example of a language that doesn't eagerly evaluate function arguments - http://iota.flowsnake.org/ 01:11:18 yes. Functions have interfaces :P 01:11:20 ok, If that's how you define interfaces. I think of them how Java uses interfaces 01:11:24 Common Lisp macros are very similar. 01:11:40 abstract base classes (ABCs) in C++ then 01:11:47 ok 01:11:51 gotcha 01:12:21 the thing I've found while I've been working on Creole is that at some point, everything breaks down to actions. 01:12:29 it doesn't matter what language you're in. 01:12:36 be it Lisp or Fortran 01:12:45 or something in-between 01:12:47 define action 01:12:56 statement; statement; statement; 01:13:20 -nod- in all my experience with language designing... everything breaks down to the primitives. 01:13:28 ...my limited experience, mind you 01:13:31 well, that is one way to abstract any language 01:13:41 but many languages do not have statements 01:13:48 like that 01:13:50 Lisp, for example. :) 01:13:57 well, yeah :) 01:14:00 Lisp has statements :P 01:14:09 though not the "blah;" 01:14:11 form 01:14:15 well... it has macros... which can sometimes look an awful lot like statements. 01:14:16 the main reason I designed functions in a name [params][unloads] style rather than unloads=name[params] style is that rather than getting really long lines of nested functions for some operations, you just get a series of code blocks one after another 01:14:51 not sure I follow that 01:14:54 Figs it's all about abstraction, you can think of everything as functional as well, it's just not every language is inherently the "action" kind 01:14:55 explain? 01:15:03 Smalltalk, from what I can tell... has no statements. and currently Sophia executes as one huge expression. 01:15:44 unless you're doing something like prolog 01:15:51 then you're doing statements... essentially. 01:15:57 prolog is more like declarations 01:16:01 RodgerTheGreat: i thought that might have something to do with it 01:16:05 well 01:16:05 bullet will never have something like Length[Mid[Input[0],5,8]] 01:16:23 there's probably a better way of explaining 01:16:28 because that looks nasty and matching brackets is hard to read 01:16:50 actually that's one thing i thought you might've not thought through :P because... well i like the nested chaos 01:16:57 so, how do you do Length(mid(input(0),5,8)? 01:17:12 int rtn 01:17:28 do input[0] to [rtn] 01:17:35 mmm 01:17:39 interesting 01:18:04 do mid[rtn,5,8] to [rtn] 01:18:18 hmm 01:18:20 now, maybe my problem is I really don't see that big a difference between functional programming and proceedural programming... 01:18:21 do length[rtn] to rtn[] 01:18:31 that's really loose, though 01:19:01 I'm ignoring var types and proper return names because I just made those functions up and this is an example 01:19:07 do mid[rtn,5,8] to [rtn] -> do mid[input,5,8] to [rtn] i suppose 01:19:37 hmm 01:19:46 how are you combining input[0] with 5 and 8 for mid? 01:20:05 is oklotalk 'Length(mid(input(0),5,8)' is written '3' PLUS it never fails! 01:20:08 *in 01:20:18 hmmm... what does mid do? 01:20:22 substr 01:20:26 ah. 01:20:36 well, remember, in bullet "do foo[arg:x] to [y:val]" is equivalent to the C-style "y=foo[arg];" 01:20:37 let's see.... 01:21:03 I gave a bad initial example... 01:21:07 and what's input[0] ...like stdin? 01:21:13 does it matter? 01:21:14 :P 01:21:16 input[0] is input's length 01:21:19 in bullet 01:21:23 ah. 01:21:28 since arrays and strings are 1-indexed 01:21:29 it doesn't. It's just a random function 01:22:18 so... how exactly are you combining input[0], 5, and 8? 01:22:23 for mid? 01:22:31 or can you not do that as a single statement? 01:22:32 I JUST MADE THAT FUNCTION UP 01:22:42 you're overanalyzing a poor example 01:22:43 ... :) 01:22:50 eep :P 01:22:53 I don't care what it does 01:22:59 just how your interfaces connect 01:23:14 let's go back to this better explanation: 01:23:15 in bullet "do foo[arg:x] to [y:val]" is equivalent to the C-style "y=foo[arg]; 01:23:22 ok... 01:23:23 so 01:23:33 first_input=input[1]; do mid[first_input,5,8] to [sub:ret]; Length(sub); i guess 01:23:47 wouldn't it be 01:24:02 input[1] to [first_input:notsureonthis]; 01:24:08 no 01:24:11 no? 01:24:17 Maybe. 01:24:23 do* 01:24:26 do to 01:24:29 assuming foo is "def foo[int:x] returns [int:val][val = x+x] 01:24:29 do input[1] to [first_input] 01:24:46 BUT var = value, if value needs no function call 01:24:49 this is how i see it 01:24:56 I thought input[1] was a function O.o 01:25:09 oh 01:25:14 then it'd been how you said 01:25:34 something I read a while ago about making languages easy to teach 01:25:45 is to make visually distinct syntax for each concept 01:25:53 what was input[1] supposed to be then? 01:25:55 array? 01:26:03 inputs in an array :P 01:26:08 whatever they are... 01:26:09 this was the problem with the example: I wasn't specifying return types and input types, so it's impossible to tell if foo[x] is supposed to be an array index or a function 01:26:11 ...hmmm, if that were true... Perl would make a great educational language. 01:26:16 input(0) in the first example 01:26:17 that's why they work how they do 01:26:41 and why my example, I will say again, sucked 01:26:48 Rodger, no offense meant, but you should either (a) combine functions and arrays or (b) make the syntax distinct ;) 01:27:02 they *ARE* distinct. 01:27:08 then I'm confused :P 01:27:33 the syntax is distinct... function: do <> to <>, array var=array[index] 01:27:42 s/array/array: 01:27:42 when I actually write code, they're distinct. They aren't when I give pseudocode to try to explain how something works and you interpret it as real code 01:28:02 (i'm not sure about the syntax though :)) 01:28:12 this is kind of fun :D 01:28:25 whee. I'm not used to talking to people who find this stuff interesting :) 01:28:31 just look at the example code in the spec so far- it is all correct 01:28:35 hmmm... I'm not sure visually distinct concepts makes for good educational languages. 01:28:50 Scheme is really good for learning... and it's completely and utterly uniform 01:29:06 Figs my thoughts exactly when i first came here 01:29:14 Scheme ownz0rz. 01:29:15 Perl makes sure that every concept is visually distinct... but it's consider a complete mess to start off on. 01:29:22 yeah, I'm glad I found this channel 01:29:32 hi, Sukoshi! Long time no see. 01:29:44 you are wrong there... [03:21:12] Maybe. 01:29:44 Who in their right mind thinks that making each different programming concept visually distinct helps? 01:30:00 That's the very *antithesis* of abstraction! 01:30:27 Sukoshi: have you seen the language I'm working on? 01:30:37 http://www.nonlogic.org/dump/text/1174856252.html 01:30:37 RodgerTheGreat: Nopes. 01:30:38 no 01:30:46 sukoshi: link. 01:30:48 thanks, oklopol 01:30:50 making syntax for different operations visually distinct 01:30:50 :P 01:30:51 I've been cramming (and am, and will be) AP test stuff, mostly Physics. 01:31:19 I plan on trying to build a magnetic engine after the AP test based on an idea I got. 01:31:49 neato 01:31:59 our own Tesla 01:32:06 let me see if I can find the examples from before... 01:32:15 Did Tesla make a magnetic engine? 01:32:46 ...I actually like some of Perls ideas... and I like a good deal of Schemes ideas too... but are very different. 01:32:59 s/but/both 01:33:11 I haven't gotten far in learning perl 01:33:17 but that's because I haven't spent much time at it 01:33:21 (about 15 minutes?) 01:33:27 what I've seen so far, I've liked 01:33:44 I had a hard time working with message-passing OOP after having fun with CLOS for so long. 01:34:57 ok, here was the example I found that made me think distince syntax was a fairly good idea 01:35:05 note, I haven't programmed in the language 01:35:27 A(B) supposedly has 5 possible meanings in Turing 01:35:40 [1] call function A and pass parameter B 01:35:57 [2] dereference pointer B to access an object in collection A 01:35:57 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht"). 01:36:06 [3] access the Bth element of array A 01:36:20 [4] construct a set of type A with a single element having the value of B 01:36:37 [5] create a one-letter substring of the string A consisint of its Bth character 01:36:52 *consisting 01:36:55 ...I think a lot of languages get a little too caught up in their ideology... like Scheme. Lisp and Smalltalk create religious fanatics. 01:37:04 lol 01:37:09 Paul Graham? 01:37:21 ...something like that. 01:37:28 Python and its readability creates fanatics too. 01:38:13 ...while I like all of their ideas... I don't like how forceful they are about their philosophy. 01:38:25 I think there are fanatics of every language. 01:38:30 that's part of what's driving my development of Creole 01:38:36 Although the ASM fanatics get sparer every generation. 01:38:39 the fact that "There are many ways to do things" 01:38:59 Languages like Perl are nice because it doesn't force you to succumb To The Grand and Absoltute Plan. 01:39:10 I think it's already been done though 01:39:15 I can't remember what 01:39:18 Tcl? 01:39:26 That's Perl's motto 01:39:30 There's more than one way to do it. 01:39:54 One of Python's mottos is "There should be one obvious way to do it". 01:39:57 well, bullet's design philosophy is the creation of failsafe code... I'm not sure that's really an ideology that'll incite fanaticism, just fanaticism for the compiler-writers. :) 01:40:10 hehe 01:41:05 it's just a feature of the language... 01:41:17 I like languages that are fun to play around with... and let you do what you want. The first language I learnt was Python - and I loved it until I discovered other languages. Now Python seems kind of conservative and bland... but I still use it the most because I know it really well. 01:41:30 some of the things that I'm trying to do with my language (dunno how well I'll succeed) are: (1) flexibility for extension, (2) good error handling and debugging, (3) documentation after I finish designing the syntax 01:42:14 I think error handling is one of the keys to building a really good language. 01:42:26 Few languages focus on error handling as well as they should. 01:42:27 i've made one language while we've been talking :) 01:42:33 lol 01:42:35 ;) 01:42:36 well.... not thoroughly 01:42:48 Sophia's Grand Principle of Construction is: (1) THE AWAKENING OF THE ABSOLUTE MODE OF THOUGHT (2) A LANGUAGE THAT CREATES ORGASMS WHILE DOING THINGS VERY VERY WELL UNDER A SINGLE AND ALL CONSISTENT IDEAL 01:43:06 wow 01:43:08 lol 01:43:11 now THAT's a language. 01:43:21 :P 01:43:32 * RodgerTheGreat tries to remember his last coding-induced orgasm... 01:43:38 ... 01:43:54 am I in #esoteric or #ecstacy ? :P 01:43:58 I'm kinda drawing a blank here, SevenInchBread 01:44:10 ...Homespring is an excellent language - which has already done this: http://web.archive.org/web/20041011092543/http://www.rpi.edu/~bindej/hs.html 01:46:11 ROFL! 01:46:13 ;) 01:46:51 homespring is indeed fun 01:47:05 "Because programming isn't like a river, but it damn well ought to be!" 01:47:35 Well, CLers are said to most proficient when under acid. 01:47:58 Because even though the underlying brain pattern changes, they can abstract the language to work with their new brain patterns. 01:48:11 lol 01:48:21 eh, makes sense :P 01:48:26 that sounds frighteningly accurate 01:48:57 ...but now Sophia is the best language to use for anything ever... even though it's incomplete and kind of completely unspecified. 01:48:59 talking about orgasms, http://www.vjn.fi/pb/p115251624.txt i'm pretty sure i had a boner when i finished this 01:49:05 not sure about the rest of the night 01:49:39 that's pretty scary, dude 01:49:54 have fun at the international obfuscated C coding contest :) 01:49:57 :P 01:50:00 but as they say, "enjoy what you do"... 01:50:31 i just bruteforced the seeds for the functions and obfuscated manually for 3 hours 01:50:31 ...I once tried to obfuscated Python... 01:50:36 it didn't work well. 01:50:42 oh yeah it does 01:50:46 well... yeah. 01:50:47 python loves to be obfuscated 01:50:50 but not as well as like... Perl 01:51:12 most of Python obfuscation comes in the form of syntatic substitutions for very very simple things. 01:51:48 http://www0.us.ioccc.org/1985/lycklama.c 01:52:08 haha 01:52:11 nice 01:52:21 found that on ioccc 01:52:27 couldn't find the ball program :\ 01:52:32 I figured from the URL 01:52:43 well, in python you can redefine variable types... so you can have type and value separate... and that gets really kinky 01:53:05 http://www0.us.ioccc.org/1985/lycklama.c 01:53:08 what's that do? 01:53:18 I don't know. 01:53:30 mine was hello world 01:53:35 in case i didn't mention 01:53:54 it has a non obfuscated version in the comment 01:54:33 I think it scrolls text to the right? 01:54:39 ? 01:54:47 what 01:54:48 ? 01:54:51 compile it and see :P 01:55:06 hmm 01:55:07 based purely on the defines, it could do a lot of things... 01:55:10 that's a define thingie 01:55:26 i once had the trouble of manually demacroing such a program 01:55:33 it usually gets quite simple 01:55:43 i mean the lycklama is a define thingie 01:56:01 goto 01:56:07 doesn't compile for me :P 01:56:07 <3 01:56:26 but I know what's wrong... I think 01:56:26 i'll try 01:57:17 nope... 01:57:18 doesn't work 01:57:22 gcc dies 01:57:30 invalid preprocessing directive #o 01:58:27 http://www.vjn.fi/pb/p514653524.txt 01:58:27 and now 01:58:36 read(a,b,c,d), what's that? 01:59:32 it defines a part of the rest of the defines, something c++ seems to deny 02:00:07 yeah 02:00:14 I thought C supported it 02:00:21 but @_@ 02:00:49 http://www0.us.ioccc.org/1985/Makefile 02:00:51 makefile for it 02:01:56 I assume it's part of a set of these 02:03:57 I tried manually translating all the defines for that program, and I just get a mess 02:04:18 hmm 02:04:19 :\ 02:04:31 *shrug* 02:04:44 have you guys read the Crenshaw "Lets make a compiler!" series? 02:04:49 those last two lines #o garbage.... 02:04:53 just don't make sense to me 02:05:02 unless I don't understand what define does 02:05:03 -!- ShadowHntr has quit ("End of line."). 02:05:52 nope 02:05:57 sounds interesting 02:06:23