00:02:56 -!- ehird` has quit.
00:04:32 -!- RodgerTheGreat has joined.
00:14:42 <SimonRC> maybe it is funnier on bash
00:32:34 -!- sebbu has quit ("@+").
01:09:48 -!- oerjan has quit ("Good night").
01:27:45 <bsmntbombdood> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/sed/TEST/math.sed
01:29:05 * SimonRC wonders where th sokoban in sed got to
01:29:51 <SimonRC> and there is a nearly-full dc written in sed
01:33:56 <pikhq> Removes an item from the stack and outputs it without a newline.
01:34:04 <pikhq> (why no newline is beyond me)
01:34:21 <ihope> So that you can have no newline?
01:36:00 <ihope> Ooh! Maybe I'll slightly revamp my parser language and call it "Cetacea".
01:39:41 <bsmntbombdood> oooh, i think sed could actually be implemented in dc
01:39:55 <bsmntbombdood> by storing strings as lists of numbers instead of the builtin strings
01:41:02 <pikhq> Of *course* sed could be implemented in dc.
01:41:12 <pikhq> At least, GNU dc is Turing complete. . .
01:43:07 <bsmntbombdood> dc even has 128 tapes and an extra stack, so it's 128.5 times more powerful than a turing machine!!
01:43:29 <pikhq> A simple dc is merely a push-down automaton.
01:46:42 <pikhq> Could you find said man page?
02:02:53 <GregorR> Clearly SimonRC is BORED by dc.
02:37:52 <lament> i always got confused about why there's both dc and bc
02:37:56 <lament> and as a result, learned neither.
02:43:42 -!- puzzlet has quit (Client Quit).
02:51:38 -!- puzzlet has joined.
02:52:08 -!- puzzlet has quit (Client Quit).
02:58:32 -!- puzzlet has joined.
03:02:44 -!- puzzlet has quit (Client Quit).
03:04:09 -!- puzzlet has joined.
03:17:37 <pikhq> lament: Traditionally, dc was an RPN calculator, and bc was an infix frontend for the same.
03:17:55 <pikhq> In GNU, they're just different programs in coreutils.
03:18:17 <pikhq> bsmntbombdood: GNU's implementation doesn't.
03:18:39 <bsmntbombdood> bc also has silly things like functions, variables, and structured loops
03:19:07 <pikhq> "It is not implemented in the traditional way using 'dc'." -- bc.info
03:19:28 <pikhq> . . . It has a bytecode compiler?!?
03:19:41 <pikhq> Seems a bit overdone for a comparatively simple program.
03:20:31 <pikhq> A whole compiler can't be done in Yacc.
03:21:15 <pikhq> Although it may *use* Yacc to parse, as I imagine GNU bc does. . .
03:21:23 <pikhq> The moment you start using stuff in Flex. ;)
03:23:16 <bsmntbombdood> and yacc can't be used without writing the actions in C, so nothing can be strictly completely written in yacc
03:24:09 <pikhq> And since Yacc is a *parser generator*, even if you could, it'd not actually get any compilation done.
03:25:25 <pikhq> Yacc only generates a parser. . .
03:25:52 <pikhq> That's not all that's in a compiler.
03:26:10 <pikhq> You neglect this funny thing called "code generation".
03:26:10 <bsmntbombdood> the parser doesn't need to be sepperate from the code generator
03:26:17 <pikhq> It is with yacc. . .
03:39:22 * pikhq decides to learn Yacc
03:39:44 <RodgerTheGreat> I don't understand the advantage to yacc at all in comparison with writing the parser by hand- parsing isn't one of the difficult aspects of writing a compiler at all
03:40:29 <RodgerTheGreat> I suppose it could *become* useful with arbitrarily complex grammars, but you'd have something hideous by the time you hit the break even point, I think.
03:45:49 <RodgerTheGreat> tokenization is straightforward, relying primarily on defining patterns that determine certain types of tokens and scanning forward, with some minor exceptions for nesting. Building parse trees is basically just error-checking and order of operations.
03:50:19 <RodgerTheGreat> there are a lot of aspects of compiler design and implementation that are really difficult (especially when the language doesn't help), but I really can't find anything in parsing that can hold a candle to the other stuff.
03:53:01 <pikhq> Realise that I wrote a compiler without knowing how to do a parser. ;)
03:54:33 <RodgerTheGreat> pikhq: that's my point exactly- it's more or less trivial
03:55:16 <RodgerTheGreat> if an average hacker can reinvent something without undue difficulty, it's trivial.
03:55:50 <pikhq> RodgerTheGreat: No, I mean "I didn't even do a parser".
03:56:04 <pikhq> My "parser" in PEBBLE is Tcl's source command.
03:56:34 <pikhq> One must admit, it works pretty well.
03:57:45 <pikhq> int c = getchar ();
03:58:00 <pikhq> Out of *immense* curiosity, how could that involve an invalid lvalue?
04:05:21 <bsmntbombdood> pikhq: because your compiler is expressing its displeasure at your use of spaces
04:05:56 <RodgerTheGreat> that is an unusual way to apply whitespace to a function call
04:06:28 <pikhq> Sorry; that's the GNU indentation standard; kinda start thinking in it when I start flipping through GNU manuals.
04:07:17 <pikhq> http://en.wikipedia.org/wiki/GNU_coding_standards
04:07:19 <RodgerTheGreat> I'm gonna have to side with bsmntbombdood with this one
04:07:57 <RodgerTheGreat> christ, that's like a laundry list of all the coding style points I have distaste for
04:08:36 <RodgerTheGreat> spaces-as-tabs, spaces before function parameter blocks, /* oneliner comments like this */
04:09:50 <RodgerTheGreat> // comments should always be used for oneliners, but if I recall, ANSI C lacks those.
04:10:20 <pikhq> *Modern* ANSI C has it; GNU tries to maintain some level of backwards compatibility with older standards and K&R C.
04:18:25 <RodgerTheGreat> different prog, but I think this code represents my coding style pretty well: http://nonlogic.org/dump/text/1189566634.html
04:22:15 <RodgerTheGreat> all curly-bracket languages are equal when it comes to coding style.
04:54:23 * pikhq has done his first program via Yacc & Flex. . .
05:16:42 <lament> ^-- a sample program in a curly-bracket language
05:17:25 -!- poiuy_qwert has quit (Read error: 104 (Connection reset by peer)).
05:35:25 -!- fizzie has quit (Read error: 54 (Connection reset by peer)).
07:09:56 -!- sebbu has joined.
07:22:20 -!- pikhq has quit (Read error: 110 (Connection timed out)).
07:42:34 -!- pikhq has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:21:50 -!- pikhq has quit (Read error: 104 (Connection reset by peer)).
08:22:37 -!- pikhq has joined.
09:01:43 -!- RedDak has joined.
09:31:22 -!- SEO_DUDE has quit (Remote closed the connection).
09:40:33 -!- SEO_DUDE has joined.
11:24:19 -!- ehird` has joined.
11:25:34 -!- ehird` has quit (Client Quit).
11:41:08 -!- RodgerTheGreat has quit (Read error: 110 (Connection timed out)).
11:47:51 -!- RodgerTheGreat has joined.
11:56:39 -!- ehird`_ has joined.
12:05:48 -!- SEO_DUDE has quit ("using sirc version 2.211").
12:07:16 -!- RodgerTheGreat has quit (Read error: 110 (Connection timed out)).
12:07:42 -!- RodgerTheGreat has joined.
12:08:19 -!- ehird`_ has changed nick to ehird`.
12:13:26 -!- Tritonio has quit (Remote closed the connection).
12:35:22 -!- RodgerTheGreat has quit (Read error: 110 (Connection timed out)).
12:41:12 -!- sebbu2 has joined.
12:48:35 -!- RodgerTheGreat has joined.
12:59:50 -!- sebbu has quit (Connection timed out).
13:21:37 -!- pikhq has quit (Read error: 104 (Connection reset by peer)).
13:21:54 -!- pikhq has joined.
13:31:58 -!- oklopol has quit (Read error: 104 (Connection reset by peer)).
13:32:43 -!- oklopol has joined.
13:50:21 <oklopol> http://esolangs.org/wiki/BF_instruction_minimalization <<< @ notes, doesn't "; [<,>]@[<.>@]" loop endlessly @ input?
14:19:14 -!- jix has joined.
14:36:57 -!- RedDak has quit (Remote closed the connection).
14:48:41 <ihope> maybe eat clothespins nooga
14:51:34 -!- jix has quit (Nick collision from services.).
14:51:45 -!- jix has joined.
15:19:12 -!- SEO_DUDE has joined.
15:20:07 <ihope> Rather like calamari.
15:22:55 <bsmntbombdood> My orders say I'm not supposed to know where I'm taking this boat, so I don't. But one look at you, and I know it's gonna be hot.
15:46:13 <sp3tt> I think the formatting language of my mpd client will be turing complete
15:46:24 <sp3tt> You don't need loops to be turing complete, right?
15:54:19 <oklopol> if you run it on something superturing, it can be loopless
15:55:02 <sp3tt> The interpreter is in python.
15:55:24 <sp3tt> It's a stack based language to format playlists, overkill? No
16:07:59 <ihope> I think to be Turing complete, you have to be able to translate any Turing program into that language.
16:09:11 <ihope> I'm not sure just how the resulting program has to act...
16:10:09 <ihope> I think that if the original program halts, you must be able to find that out by running the resulting program, and if the original program halts, you must *not* be able to find that it halts by running the resulting program.
16:10:55 <ihope> I'd like to see a description of this language.
16:29:14 <lament> sp3tt: loops are just something some imperative languages have.
16:29:57 <oklopol> i assumed he meant the concept of looping
16:30:11 <oklopol> and not an actual "while" etc.
16:33:16 <lament> i'm not sure in what sence does lambda calculus have "the concept of looping"
16:34:03 <oklopol> through an abstraction the programmer has created...
16:34:18 <oklopol> but i guess that might be a bad term for it.
16:36:10 <lament> i suppose in any language with side effects, you could define an "infinite loop" as something that performs some sequence of actions over and over again infinitely.
16:36:23 <lament> in that sense, you can have infinite loops in unlambda and haskell.
16:37:28 <lament> if your language can't do that, it's definitely not turing-complete.
16:38:37 <oklopol> hmm... so if you made unlambda return v instead everytime you're in an infinite loop, it wouldn't be turing complete?
16:38:52 <oklopol> i mean, theoretically speaking, since that's impossible to know
16:50:19 <SimonRC> oklopol: no, the detection system would be superturing
16:50:59 <oklopol> no, BECAUSE the detection system would be superturing?
16:52:02 <oklopol> indeed, that language would naturally be superturing
16:52:12 <SimonRC> I was responding to "16:38:01 < oklopol> hmm... so if you" .... "it wouldn't be turing complete?"
16:53:22 <oklopol> because lament said, i think, that a language can't be turing complete if it can't loop infinitely
16:53:59 <oklopol> but i guess it can only either be less than tc, or superturing, if it does that
17:11:25 <ehird`> sp3tt: mpd client.... commandline? qt?
17:19:47 <bsmntbombdood> what's a major global problem facing our planet as we move into the 21st ccentury
17:20:17 <g4lt-sb100> humanity, we must kill off all humanity
17:25:32 <SimonRC> solution: less anthopology, more apthropophagy!
17:26:15 <bsmntbombdood> i need a reputable source that says that if i'm going to do it
17:28:02 <g4lt-sb100> the population bomb, written in 1968, by Paul Erlich. it states we should resort to cannibalism in like three or four years from now
18:23:50 <ihope> Is there not enough food?
18:24:13 <ihope> How is overpopulation a problem?
18:25:07 <ihope> bsmntbombdood: is that a question for your geography class?
18:37:01 <ehird`> ihope: what do you mean, how is overpopulation a problem
18:53:12 -!- GregorR has changed nick to behypercubed.
18:56:55 -!- behypercubed has changed nick to _D6Gregor1RFeZi.
19:41:13 -!- oerjan has joined.
21:13:13 -!- cherez has joined.
21:35:04 -!- SEO_DUDE has quit (Read error: 104 (Connection reset by peer)).
21:49:56 -!- SEO_DUDE has joined.
22:00:12 -!- jix has quit ("CommandQ").
22:10:46 <oerjan> no! that cannot be! no way!
22:10:56 <ihope> So how is it a problem?
23:00:54 -!- Tritonio has joined.
23:16:25 -!- Tritonio has quit (Read error: 104 (Connection reset by peer)).
23:19:41 -!- Tritonio has joined.
23:21:08 -!- SEO_DUDE has quit (Read error: 104 (Connection reset by peer)).
23:22:09 -!- ihope has quit (Read error: 110 (Connection timed out)).