â†2006-12-29 2006-12-30 2006-12-31→ ↑2006 ↑all
00:51:36 -!- ivan`_ has joined.
01:03:09 -!- bsmntbombdood has joined.
01:09:23 -!- ivan` has quit (Connection timed out).
01:09:24 -!- ivan`_ has changed nick to ivan`.
01:31:08 -!- tgwizard has quit (Remote closed the connection).
02:26:17 -!- jix_ has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
03:07:21 -!- RodgerTheGreat has joined.
03:07:37 <RodgerTheGreat> howdy, everyone
03:07:46 <CakeProphet> vcnbv
03:07:47 <CakeProphet> ;'kl;k'
03:07:49 <CakeProphet> l'
03:07:50 <CakeProphet> k
03:08:06 <RodgerTheGreat> nice to see you too, CakeProphet
03:08:08 * CakeProphet made a semi-broken Lisp-like list constructor in Glass.
03:08:23 <pikhq> howdy.
03:08:26 <CakeProphet> and an incomplete BF interpreter.
03:08:26 <RodgerTheGreat> interesting
03:09:07 <CakeProphet> http://esolangs.org/wiki/User:CakeProphet#Glass_stuff
03:09:39 <CakeProphet> The con glass works fine (although I haven't tested the iter method yet)
03:09:47 <CakeProphet> but List doesn't work right yet.
03:09:56 <pikhq> ++++++++++>,<[>.,<-] | World's stupidest Brainfuck program.
03:09:57 <pikhq> Wheee.
03:11:40 <RodgerTheGreat> a 10-character cat command?
03:11:51 <pikhq> Yup.
03:12:03 <CakeProphet> Actually
03:12:04 <pikhq> Stupid, no?
03:12:17 <CakeProphet> !bf +.
03:12:20 <EgoBot> <CTCP>
03:12:23 <CakeProphet> Is probably worse.
03:12:34 <CakeProphet> or even just...
03:12:37 <CakeProphet> !bf .
03:12:43 <pikhq> My program at least indicates some knowledge of Brainfuck.
03:12:51 <CakeProphet> -.-
03:12:54 <CakeProphet> Thus... less stupid.
03:12:57 <pikhq> !bf -.-
03:13:00 <EgoBot> ÿ
03:13:01 <CakeProphet> haha
03:13:07 <RodgerTheGreat> I always thought the most stupid BF program was "[]", because it's what n00bs assume will i-loop an interpreter
03:13:18 <RodgerTheGreat> they always forget the +
03:13:19 <pikhq> It's not even a quine.
03:13:23 -!- cmeme has quit ("Client terminated by server").
03:13:24 <pikhq> !bf
03:13:27 <pikhq> I WIN!
03:13:34 -!- cmeme has joined.
03:13:37 <CakeProphet> hmmm... has anyone done a quine in BF?
03:13:43 <pikhq> Several.
03:13:44 <RodgerTheGreat> the null program isn't all that special in BF
03:13:44 <CakeProphet> that's not huge... and is something I would understand?
03:14:09 <RodgerTheGreat> most quines end up being rather brute-force, but the basic design is simple
03:14:34 <RodgerTheGreat> you need the source of your program stored in an encoded form and a decoder stub
03:14:54 <RodgerTheGreat> the stub will print out the encoded form and then the unencoded form (itself)
03:15:00 <RodgerTheGreat> bingo- quine
03:15:02 <pikhq> http://esoteric.sange.fi/brainfuck/bf-source/quine/quine410_with_comments.b
03:15:03 <RodgerTheGreat> :D
03:15:21 <CakeProphet> print (lambda x:x%x)("print (lambda x:x%%x)(%r)") is one of the coolest quines ever.
03:15:44 <RodgerTheGreat> wow- that's pretty readable
03:15:51 <pikhq> That's the commented version.
03:15:56 <RodgerTheGreat> kudos to the guy who wrote that one
03:16:06 <RodgerTheGreat> clarity in BF takes some skill
03:18:00 <CakeProphet> !bf ;+++++++++++++.
03:18:02 <EgoBot>
03:18:06 <CakeProphet> !ps
03:18:08 <EgoBot> 2 CakeProphet: ps
03:18:16 <CakeProphet> !bf ,+++++++++++++.
03:18:19 <CakeProphet> !ps
03:18:23 <EgoBot> 2 CakeProphet: bf
03:18:23 <pikhq> !bf ]
03:18:24 <EgoBot> 3 CakeProphet: ps
03:18:38 <CakeProphet> !i 2 A
03:18:42 <EgoBot> N
03:18:48 <CakeProphet> hehehe... ROT13
03:19:58 <CakeProphet> !bf +[,+++++++++++++.[-]+]
03:20:04 <CakeProphet> !i 2 Hello
03:20:12 <CakeProphet> !ps
03:20:16 <EgoBot> 2 CakeProphet: bf
03:20:18 <EgoBot> 3 CakeProphet: ps
03:20:24 <CakeProphet> !i 2 B
03:20:47 <CakeProphet> >.<
03:20:51 <pikhq> !kill 2
03:20:54 <EgoBot> Uryy|O
03:20:57 <EgoBot> Process 2 killed.
03:20:59 <CakeProphet> ooooh
03:21:04 <pikhq> Didn't give a newline. ;)
03:21:19 <CakeProphet> Thought it just spouted output on the spot.
03:21:22 <CakeProphet> but it buffers it.
03:21:44 <CakeProphet> !bf +[,+++++++++++++.[-]+]
03:21:52 <CakeProphet> !i 2 a
03:21:53 <CakeProphet> !i 2 b
03:21:55 <CakeProphet> !i 2 b
03:21:56 <CakeProphet> !i 2 a
03:21:58 <pikhq> !i 2 \n
03:21:58 <CakeProphet> !kill 2
03:22:00 <EgoBot> noon
03:22:03 <EgoBot> Process 2 killed.
03:22:03 <CakeProphet> ....
03:22:25 <CakeProphet> !bf +[,+++++++++++++.[-]+]
03:22:28 <CakeProphet> !i 2 a
03:22:30 <CakeProphet> !i 2 b
03:22:32 <pikhq> !i noon
03:22:32 <CakeProphet> !i 2 b
03:22:38 <CakeProphet> ...oh
03:22:43 <pikhq> !i 2 noon
03:22:52 <CakeProphet> !i 2 \n
03:22:53 <pikhq> I don't think it works fully.
03:22:57 <pikhq> !kill 2
03:23:00 <EgoBot> noo{||{-
03:23:02 <EgoBot> Process 2 killed.
03:23:04 <CakeProphet> haha
03:23:04 <RodgerTheGreat> wait, when did gregor decide to bring back EgoBot?
03:23:14 <CakeProphet> !bf +[,+++++++++++++.[-]+]
03:23:18 <CakeProphet> !i 2 a
03:23:20 <CakeProphet> !i 2 b
03:23:23 <CakeProphet> !i 2 b
03:23:27 <CakeProphet> !i 2 o
03:23:31 <CakeProphet> !i 2 \n
03:23:38 <CakeProphet> >.>
03:23:51 <CakeProphet> !kill 2
03:23:52 <EgoBot> noo|
03:23:54 <EgoBot> Process 2 killed.
03:23:57 <CakeProphet> :(
03:24:11 <CakeProphet> But yeah... it's a crude ROT13
03:24:15 <CakeProphet> otherwise that would have said "noob"
03:24:23 <CakeProphet> it doesn't wrap at the end.
03:28:09 <CakeProphet> hmmm...
03:28:16 <CakeProphet> so... I've been working on my IRP iterating quine.
03:28:23 <CakeProphet> so here's a test run:
03:28:28 <CakeProphet> Could someone please ask someone to repeat this request?
03:28:49 <pikhq> Could someone please repeat the previous request?
03:29:02 <RodgerTheGreat> "Could someone please ask someone to repeat this request?"
03:29:06 <CakeProphet> NOOB
03:29:08 <CakeProphet> NO QUOTES
03:29:22 * CakeProphet adds to the wiki
03:29:43 <RodgerTheGreat> ERROR 8: DON'T_BE_A_DOUCHE_TO_YOUR_INTERPRETER ERROR
03:29:45 <CakeProphet> with someone like "as you can see, the results are not always accurate" or something.
03:30:18 <CakeProphet> or I can just... strip the quotes and pretend the run went successfully.
03:31:13 <RodgerTheGreat> heh
03:31:20 <pikhq> ERROR 9: THE INTERPRETER DOESN'T EXECUTE THE LANGUAGE
03:32:15 <RodgerTheGreat> the only real problem with a quine in this format is that it could easily lead to infinite recursion, until the interpreters get bored. You might want to add a clause for that
03:32:23 -!- digital_me has joined.
03:32:31 <RodgerTheGreat> hi
03:32:31 <pikhq> That'd be SIGKILL.
03:36:11 -!- ihope_ has quit (Connection timed out).
03:37:21 <CakeProphet> IRP isn't Turing complete because it consists entirely of undefined behavior.
03:37:35 <CakeProphet> Nothing in the specification guarantees the a defined result.
03:39:05 <pikhq> It's occasionally Turing complete, but that's just out of sheer luck.
03:40:14 <CakeProphet> !help
03:40:17 <EgoBot> help ps kill i eof flush show ls bf_txtgen usertrig daemon undaemon
03:40:18 <EgoBot> 1l 2l adjust axo bch bf{8,[16],32,64} funge93 fyb fybs glass glypho kipple lambda lazyk linguine malbolge pbrain qbf rail rhotor sadol sceql trigger udage01 unlambda whirl
03:40:27 <RodgerTheGreat> I'm going to assume that Turing-completeness requires a certain degree of reliability, because it deals with solving computable problems in a finite amount of time
03:40:57 <pikhq> !daemon bf irp ,[.,]
03:41:00 <EgoBot> Huh?
03:41:05 <pikhq> Grr.
03:41:06 <CakeProphet> One of the requirements for Turing completeness is well-defined behavior.
03:41:08 <pikhq> !help daemon
03:41:10 <EgoBot> Use: daemon <daemon> <daemon-command> Function: start a daemon process.
03:41:15 <RodgerTheGreat> there you go
03:41:23 <pikhq> !daemon irp bf ,[.,]
03:41:30 <pikhq> EgoBot now does IRP.
03:41:46 <pikhq> !irp Please say "Hello, world!"
03:42:00 <pikhq> !irp \n
03:42:01 * CakeProphet has some weird Python classes that implement various forms of the computational classes.
03:42:01 <pikhq> XD
03:42:06 <CakeProphet> as they're formally defined.
03:42:11 <RodgerTheGreat> perhaps IRP would benefit from the use of legalese, it being a more precisely defined form of English
03:42:35 <CakeProphet> The problem isn't undefined input.
03:42:39 <CakeProphet> it's undefined output.
03:42:48 <CakeProphet> The interpreter can choose to output what it wishes.
03:43:08 <CakeProphet> which makes IRP intelligent... but not very Turing machiney.
03:43:14 <RodgerTheGreat> my point was that a more precisely defined program would at least make some progress toward predictable output
03:43:23 <RodgerTheGreat> true
03:43:25 <pikhq> IRP would benefit from gnomes that smack bad interpreters.
03:43:33 <CakeProphet> Yes.
03:44:04 <CakeProphet> or like... ops that kickban interpreters for "not adhering to the specification".
03:44:14 <RodgerTheGreat> heh
03:44:47 <RodgerTheGreat> Ah yes, the Merriam-Webster IRP spec.
03:44:50 <CakeProphet> Maybe... such interpreters just simply aren't adhering to the specification of the language.... which (should) state that output MUST be performed exactly as requested.
03:44:50 <pikhq> I've got a good idea.
03:44:53 <pikhq> #irp.
03:45:05 <CakeProphet> discussion about the irp language?
03:45:47 <CakeProphet> But is IRP truly esoteric?
03:45:56 <pikhq> No, for a controlled region where IRP may be interpreted.
03:46:26 <CakeProphet> Hmmm... I want to build a genetic programming language.
03:46:45 <CakeProphet> Are there any that I could take as an example?
03:48:08 <pikhq> Ideas for #irp policies?
03:49:20 <tokigun> how about limiting maximum depth of execution stack?
03:49:43 <CakeProphet> that's stupid.
03:49:50 <CakeProphet> our stack should be HUGE-ABLE
03:50:09 <pikhq> Send me suggestions; I'll write up an IRP#irp spec and set of policies.
03:50:36 <RodgerTheGreat> perhaps some sort of certification system to confirm the reliability of interpreter nodes
03:51:08 <pikhq> I prefer a kicking system to remove unreliable nodes.
03:51:54 -!- ihope_ has joined.
03:52:08 -!- ihope_ has changed nick to ihope.
03:54:13 * CakeProphet demands an example of a genetic/natural-selection-ish programming language.
03:55:14 <RodgerTheGreat> well, I've been working on one primarily based around self-modifying code- it's kinda the same base idea
03:57:02 <CakeProphet> hmmm.... maybe object-oriented?
03:57:16 <CakeProphet> a "species"... which is basically a class.
03:57:30 <CakeProphet> with some other base data structures.
03:57:38 <CakeProphet> hmmm... self-modifying seems interesting.
03:58:53 <CakeProphet> inheritane would be like creating a genus, phylum, etc.
03:59:34 <CakeProphet> hmm... I don't like the sound of that.
03:59:36 <CakeProphet> but.. eh.
04:00:10 <RodgerTheGreat> the approach I took was to make a command that can execute a string as a subroutine. Thus, you can treat strings as functions. Since the functions can be changed by other functions (or themselves), you have a powerful recursive programming language on your hands
04:00:20 <pikhq> Sounds like Redcode.
04:01:07 <RodgerTheGreat> redcode is essentially assembly with entirely relative addressing. And yes, it's a good language for genetic programming
04:01:26 <pikhq> And it's self-modifying.
04:02:06 <RodgerTheGreat> yeah
04:02:30 <RodgerTheGreat> redcode has a way of creating wonderfully elegant code.
04:02:35 <RodgerTheGreat> MOV 0,1
04:02:48 <RodgerTheGreat> I wonder if the imp can be considered a quine?
04:02:56 <pikhq> Not really.
04:03:15 <pikhq> The binary version could be, though.
04:06:39 <CakeProphet> oooh...
04:06:44 <CakeProphet> string functions... that's cool.
04:07:22 <CakeProphet> so like... each character reacts differently to other characters in other functions or something?
04:08:39 <RodgerTheGreat> kinda
04:11:21 <RodgerTheGreat> the basic idea is that everything is built around a stack- you push some parameters, then a reference to a function, and then do an "execute string" call. The function runs, with it's parameters sitting on the stack. If the contents of the string being used as a function is changed before it's "called" again, it may do something completely (or subtly) different
04:11:23 * CakeProphet will expand on his object-oriented idea.
04:11:43 <CakeProphet> stack-based?
04:11:50 <RodgerTheGreat> yes
04:11:56 <CakeProphet> Like how Glass does functions -nod-
04:12:14 <RodgerTheGreat> it seemed like the simplest way to make function calls.
04:12:19 <CakeProphet> oooh.
04:12:30 <CakeProphet> The function call can be altered mid-execution?
04:12:33 <RodgerTheGreat> I didn't realize that was how glass worked... heh
04:12:46 <CakeProphet> Well.. the parameters are sitting on the stack.
04:13:00 <RodgerTheGreat> well, I hadn't planned on that initially, but it's an interesting idea
04:13:05 * CakeProphet nods.
04:13:22 <RodgerTheGreat> it might make it needlessly tricky to do self-modyfying recursion, though
04:15:18 -!- ihope has quit (Connection timed out).
04:16:43 <CakeProphet> !glass {M[m(_e)I! (_o)O! (_e)i.(_o)o.?]}
04:16:57 <CakeProphet> !i 2 Lol cat
04:17:06 <CakeProphet> ... >.<
04:17:11 <CakeProphet> oooh
04:17:21 <CakeProphet> !glass {M[m(_e)I! (_o)O! (_e)i.?(_o)o.?]}
04:17:26 <CakeProphet> !i 2 Lol cat
04:17:29 <RodgerTheGreat> ?
04:17:46 <CakeProphet> should be a cat program. -.-
04:17:50 <CakeProphet> !ps
04:18:02 <CakeProphet> or... EgoBot isn't here?
04:18:18 <RodgerTheGreat> perhaps it broke again
04:18:26 <CakeProphet> How to fix??
04:18:40 <RodgerTheGreat> I could summon my bot, but it only speaks brainfuck and doublefuck.
04:19:09 <CakeProphet> Well... everything in Glass runs on a global stack... so function calls are basically the same as copying and pasting the functions code where the wall is...
04:19:34 <RodgerTheGreat> hm
04:19:39 <CakeProphet> and since the language allows you to access data based on its location on the stack... functions can access the last bits of data on the stack and manipulate them like parameters
04:20:27 <CakeProphet> It fits with the rest of the languages syntax... being postfix and all.
04:22:23 -!- ihope_ has joined.
04:22:37 * CakeProphet hits EgoBot with a hammer.
04:22:44 -!- ihope_ has changed nick to ihope.
04:22:45 <GregorR> :(
04:22:52 <RodgerTheGreat> I thought my best idea for my language was the datatype- everything is a string, and operators you'd expect to work with numbers deal with the first char in the top string. That way, everything on the stack can have the same type and you can use it for both math and function calls easily
04:23:07 <RodgerTheGreat> is egobot broken, gregor?
04:23:12 <CakeProphet> Yeah... I would have never thought of it.
04:23:16 <GregorR> Idonno, maybe? :P
04:23:27 <CakeProphet> string == function WTFerror
04:23:32 <RodgerTheGreat> heh
04:23:40 -!- EgoBot has quit (Read error: 54 (Connection reset by peer)).
04:23:41 <CakeProphet> hmmm...
04:23:44 -!- EgoBot has joined.
04:23:46 <CakeProphet> maybe linked lists as functions?
04:24:06 <CakeProphet> it would be like strings... except higher-up...
04:24:16 <GregorR> !undaemon cat
04:24:26 <RodgerTheGreat> well, my earlier idea was to represent functions as stacks of characters, but it's not functionally all that different from a string depending on how your operators work
04:24:27 <CakeProphet> instead of characters you have elements.
04:24:54 <CakeProphet> yeah... it wouldn't be that different.
04:25:27 <CakeProphet> Glass is kinda like that... since each character means something different.
04:25:33 <CakeProphet> but not -everything- is an item on a stack.
04:25:33 <GregorR> I ask you, television commercial, how do you dent your car when crashing into a tent?
04:26:01 <CakeProphet> the concept is different.
04:27:24 <CakeProphet> hmmm... I've considered doing a queue-based language... or a deque-based lanauge (which is basically a cross between a stack-based language and a queue-based language)
04:27:41 <CakeProphet> double-ended queues are essentially stack-ques.
04:27:43 <CakeProphet> queues
04:27:48 <CakeProphet> ...meh
04:28:46 <CakeProphet> set-based language as well. :D
04:28:57 <RodgerTheGreat> lol- I remember hearing stories about a CS professor that insisted "deque" was pronounced "deck"
04:29:20 <CakeProphet> I prenounce it "deek"
04:29:31 <CakeProphet> or just... don't pronounce it at all.
04:29:38 <RodgerTheGreat> it's "Dee-kyoo"
04:29:48 <CakeProphet> that's how I originally pronounced it.
04:29:53 <CakeProphet> but that's like dequeue
04:30:00 <RodgerTheGreat> exactly
04:30:44 <CakeProphet> hmmm... wonder if you could combined a set with a queue.
04:31:01 <CakeProphet> even though... the definition of a set specifically states "a collection of unordered elemenets"
04:31:24 <RodgerTheGreat> which makes storing code a bit problematic
04:31:34 <CakeProphet> hehe
04:31:49 <CakeProphet> associative-array-based language?
04:31:55 <RodgerTheGreat> ooo... how about a language based around my favorite data structure? Hashes.
04:32:03 <CakeProphet> Most popular languages can be described as a stack and a hash table of some sort.
04:32:06 <CakeProphet> ...
04:32:07 <GregorR> Suicide-note based language.
04:32:08 <RodgerTheGreat> man, we're on the same wavelength
04:32:21 <CakeProphet> hashes are pretty awesome.
04:32:32 <RodgerTheGreat> GregorR: Destructive-Execute programming? :)
04:32:35 <CakeProphet> Lua's base data-type is a hash (called a "table")
04:32:49 <CakeProphet> like cons in Lisp.
04:33:16 <CakeProphet> hmmm... it would be interesting to remove the stack from the picture... and just use -only- hash.
04:33:38 <CakeProphet> but if you did it wrong... it would just be a series of variable assignments.
04:35:21 <GregorR> Plof's only stack is a stack of hashes (the scope)
04:35:50 <CakeProphet> object oriented is something like a hash-based system.
04:36:05 <RodgerTheGreat> I was thinking about it a while back, and I think you could build a UTM out of nothing but LET statements and computed GOTOs in BASIC
04:36:20 <CakeProphet> since objects are typically just a hash with some rules for accessing a different hash when nessicary.
04:36:52 <RodgerTheGreat> of course, that idea is really a natural consequence of the Z3 turing-completeness proof
04:37:25 <RodgerTheGreat> (while-loop, variables, and the four arithmetic operators = UTM)
04:38:34 <CakeProphet> pfft...
04:38:38 <CakeProphet> while loops are so overrated.
04:38:46 <CakeProphet> and overused. >.<
04:39:43 <CakeProphet> A while loop is two ifs and a goto.
04:39:49 <RodgerTheGreat> I'm personally a fan of FOR...NEXT loops.
04:40:06 <CakeProphet> wassat?
04:40:17 <RodgerTheGreat> ...
04:40:23 <CakeProphet> Like a for loop in Python?
04:40:33 <CakeProphet> (iterators)
04:40:48 <RodgerTheGreat> for(int x=0;x<5;x++) {System.out.println(x);}
04:40:54 <RodgerTheGreat> ^ For...Next loop.
04:41:01 <CakeProphet> Ah... yeah that's a for loop in Python.
04:41:11 <CakeProphet> you're speaking to someone who's never bothered to touch C.
04:41:34 <RodgerTheGreat> 10 FOR X = 0 TO 4 STEP 1: PRINT X: NEXT X
04:41:40 <RodgerTheGreat> screw C
04:41:41 <CakeProphet> O.o
04:41:51 <CakeProphet> Indeed.
04:41:53 <RodgerTheGreat> I use BASIC, PHP and Java to do my dirty work
04:41:54 * CakeProphet doesn't like C.
04:42:10 <RodgerTheGreat> and I'm starting to warm up to Perl
04:42:12 <CakeProphet> Python... and... well just Python. But I also do a litle Scheme.
04:42:17 <CakeProphet> Perl is kinda cool.
04:42:36 <RodgerTheGreat> I only really dislike 3 languages: C, C++, and Ruby.
04:42:40 <CakeProphet> I haven't used it much... but I like the design concept... if a little unpredictable.
04:42:54 <RodgerTheGreat> C and C++ are inelegant, and Ruby is just a monstrosity
04:43:01 <CakeProphet> C, C++ here
04:43:11 <CakeProphet> Ruby looks kinda cool... but I've never used it or looked into it much.
04:43:48 <CakeProphet> C is one of those languages that sacrifices for the machine.
04:43:58 <RodgerTheGreat> it's painful... Imagine an unholy mix of Javascript, Perl, and a little bit of BF.
04:44:00 <CakeProphet> which is partly why it's so common... because it's at the base of every OS.
04:44:24 <CakeProphet> hmmm... Ruby does look a little like a weird syntaxed version of Python and Perl.
04:44:36 * CakeProphet is, naturally, a fan of Python.
04:45:06 <RodgerTheGreat> it's reasonably powerful, but it's syntax is all over the place. It's like it was designed by three people independently and then superglued together
04:45:21 <CakeProphet> Not because of any grand design concept... or because it does a paticular thing well... it's just -really- easy to work with and generally does what you think it would do.
04:45:44 <RodgerTheGreat> I haven't used python much, but it's syntax for working with strings is fucking brilliant
04:45:56 <CakeProphet> Which part?
04:46:06 <CakeProphet> interpolation?
04:46:15 <RodgerTheGreat> the way you access substrings or specific characters
04:46:21 <CakeProphet> slicing?
04:46:31 <CakeProphet> "Hello World!"[0] ?
04:46:33 <RodgerTheGreat> is that what it's called?
04:46:48 <CakeProphet> That would be "H"
04:46:51 <RodgerTheGreat> yes
04:47:10 <CakeProphet> Yeah... that's called slicing or indexing... it's basically like arrays.
04:47:20 <CakeProphet> Same exact thing... actually.
04:48:14 <RodgerTheGreat> I'd say my favorite language will probably always be BASIC, because of how it combines extremely friendly syntax and ease of use with ridiculous levels of power via PEEK(), POKE and CALL
04:48:38 <CakeProphet> I've never used basic... but it doesn't seem popular.
04:48:54 <CakeProphet> I remember it doing some weird context-based stuff with =
04:49:07 <RodgerTheGreat> plus, if you're fluent in BASIC you can instantly do cool things with any old machine from the 80's
04:49:20 <CakeProphet> which is a good idea for beginners.. but not too well for my tastes.
04:49:32 <CakeProphet> Python kinda reminds me of Lisp... in some ways.
04:49:54 <RodgerTheGreat> = is used for both assignment and comparison in BASIC, but the way it's used almost never leads to problems
04:50:29 <CakeProphet> Yeah... but then you can't do things like x = y == 2 (which, honestly... isn't very useful... but it's still nice to have the freedom)
04:50:45 <RodgerTheGreat> essentially, it solves the problem by making assignment done not by the = operator itself, but the LET statement
04:51:16 <CakeProphet> LET x = 2?
04:51:28 <CakeProphet> aaah.
04:51:34 <RodgerTheGreat> x=y=2 in BASIC generally does the same as x=y==2 in other languages
04:51:52 <CakeProphet> thought more ambiguous when you read it.
04:52:08 <RodgerTheGreat> LET is an interesting command, because it's usually implied. If a line doesn't contain a command, it's assumed to be prefixed with LET.
04:52:19 <CakeProphet> O.o
04:52:25 <CakeProphet> Weird.
04:52:38 <RodgerTheGreat> so, "10 LET x=y=2" is the same as "10 x=y=2"
04:53:11 <CakeProphet> Python's main design goal seems to be readability and ease of use.
04:53:19 <RodgerTheGreat> and both will store a boolean value (1 or 0, in BASIC's representation) representing wether y is equal to 2 or not to the variable x
04:54:03 <RodgerTheGreat> BASIC's main design goal is minimal memory use and the ability to function as both an interpreter and a rudimentary OS, much like FORTH
04:54:36 <RodgerTheGreat> there are a number of BASIC implementations that fit in less than 4k of ROM.
04:54:36 <CakeProphet> Python is OO at heart... but it has this weird conflicting idea of multi-paradigmism.
04:55:04 <CakeProphet> I've seen both "Python is an object-oriented language" and "Python supports multiple paradigms" as arguments for why something should be implemented into it.
04:55:40 <RodgerTheGreat> hm
04:55:50 <CakeProphet> It basically works with multiple paradigms... while being object-oriented at the core.
04:56:22 <CakeProphet> ...which... isn't really what I would call being multi-paradigmed.
04:57:15 <CakeProphet> BASIC sounds interesting... not sure if I'd like using it though. Might be cool.
04:57:24 <CakeProphet> Doesn't it use sigils like Perl?
04:57:46 <RodgerTheGreat> do you have a device that runs PalmOS?
04:57:54 <CakeProphet> Nope.
04:58:01 <RodgerTheGreat> damn.
04:58:07 <CakeProphet> Python seems tons more consistent than what I've seen of C.
04:58:11 <CakeProphet> C makes absolutely no sense to me at all.
04:58:16 <RodgerTheGreat> Cbaspad, one of my favorite BASIC implementations runs on PalmOS.
04:58:44 <RodgerTheGreat> My other favorite, DarkBASIC, I can't really play with anymore because it's windows-based.
04:58:57 <CakeProphet> C's semantics seems to change upon context...
04:59:09 <CakeProphet> in a really weird way.
04:59:11 <RodgerTheGreat> SmallBASIC is pretty nice- it runs on PalmOS, windows, and Linux.
05:00:01 <RodgerTheGreat> C just bugs me because it's obvious it was written by and for compiler writers, rather than as a clear or interesting way of expressing algorithms.
05:00:03 <CakeProphet> Like... function definitions are just... floating out in space with nothing defining them as such... and type declarations are kind of screwy and have different functions based on what other types are beig used.
05:00:36 <CakeProphet> yeah... its design goal is totally different than what it's being applied to.
05:01:29 <RodgerTheGreat> which really frustrates me when I've been exposed to so many languages that are better designed.
05:01:38 <CakeProphet> C's static typing also bugs me... but then again my first dive into programming was from within the comfort of a dynamically typed language.
05:02:26 <RodgerTheGreat> C maintains dominance in a circular fashion- applications are written in C because C is used to code other applications. Plus, it doesn't have a huge number of direct competitors.
05:02:52 * CakeProphet nods.
05:03:15 <CakeProphet> Makes me wish there was some other language that was really good at being a "base language" that didn't suck quite so much.
05:03:40 <RodgerTheGreat> BASIC is weak-typed, but Java has taught me the structural value of strong-typing. I still really enjoy weak-typing when I'm doing simpler tasks in a language like PHP
05:03:47 <CakeProphet> There's some OS project being worked on with most of the source being in a Python implementation.
05:04:19 <CakeProphet> it's a pretty interesting concept... orthagonal persistency and a weird memory layout.
05:04:38 <CakeProphet> http://en.wikipedia.org/wiki/Unununium_%28operating_system%29
05:05:13 <RodgerTheGreat> CakeProphet: well, I've been slowly working on a project to try to build an operating system, and that's pretty much what I thought, so I'm researching modern compiler design. Hopefully, I can come up with something that combines the positive aspects of C with the design of better structured languages.
05:06:06 <CakeProphet> hehe... an esoteric operating system?
05:06:22 <RodgerTheGreat> possibly.
05:06:31 * CakeProphet will be your Python codemonkey.
05:06:58 <RodgerTheGreat> although, I hope that it will one day become something on par with commercial OSes and the offerings of the open-source community.
05:08:55 <CakeProphet> hmmm.. orthogonal persistence is a neat idea.
05:09:21 <CakeProphet> uuu initializes the entire hard disk into the virtual memory... and manages it so that any changes to the virtual memory as saved to the hard disk.
05:09:28 <RodgerTheGreat> I agree- Uuu has some fascinating ideas behind it.
05:10:18 <CakeProphet> it makes sense... why the hell are we required to use databases and persistence libraries to do something that could be handled by the OS?
05:14:13 <RodgerTheGreat> you're talking to the person that thinks a kernel should consist primarily of a memory manager and an interpreter for a language that can serve in an interactive mode as a shell. :)
05:14:30 <CakeProphet> :D
05:14:46 <CakeProphet> I like the way uu did time.
05:14:54 <CakeProphet> solves the whole time problem.
05:16:11 <RodgerTheGreat> heh- yeah, it works pretty well
05:17:56 -!- digital_me has quit ("night").
05:20:45 * CakeProphet considers helping out uuu.
05:21:48 <CakeProphet> RodgerTheGreat, I'd love to do some crazy OS stuff... besides my totally lack of knowledge on how OSes are developed.
05:22:09 <CakeProphet> But... I'm sure there's new ways it could be done... so eh.
05:24:53 -!- wooby has joined.
05:25:15 <RodgerTheGreat> operating system development is the grandest challenge out there in the world of commercial software development- if I'm going to do anything in the industry, that's what I want to build.
05:25:29 <CakeProphet> ...except a lot of the developers seem like total assholes.
05:25:36 <RodgerTheGreat> well, yes.
05:25:41 <CakeProphet> Nothing annoys me more than grumpy coders.
05:25:49 <CakeProphet> which are strangely common.
05:25:57 <wooby> lol yes
05:26:04 <wooby> oh man OS dev is such a boondoggle
05:26:22 <RodgerTheGreat> yeah, it generally happens when coders find themselves having to do administrative things.
05:26:27 <CakeProphet> Well... I'm a reckless and overconfident n00b... so I'm up for it.
05:26:35 <RodgerTheGreat> boondoggle is an excellent word.
05:26:45 <wooby> indeed
05:27:07 <RodgerTheGreat> well, I think I need to get some sleep. G'night, guys.
05:27:24 <wooby> goodnight
05:27:44 -!- RodgerTheGreat has quit.
05:29:18 <wooby> what is new and good in the world of esoteric programming technology
05:29:30 <CakeProphet> >.>
05:29:53 <CakeProphet> I've got some ideas for a genetic-ish object-oriented programming language?
05:30:01 <wooby> sounds awesome
05:30:03 <wooby> what are your thoughts?
05:30:05 -!- ihope_ has joined.
05:30:10 <CakeProphet> possibly queue-based... or maybe double-ended-queue-based.
05:30:19 <CakeProphet> or some other crazy-data-structure-based
05:30:25 <wooby> i don't know much about genetic algorithms outside the few dewdney examples from however long ago
05:30:33 <CakeProphet> me neither :P
05:30:39 <wooby> lol
05:30:55 <CakeProphet> But I know the basic concept of natural selection... which is basically all you need.
05:31:03 <wooby> well yes
05:31:08 <wooby> my hunch is that it's like neural networks
05:31:26 <wooby> perhaps not
05:31:37 <CakeProphet> there was an idea tossed around briefly yesterday about a "spiderweb language" that worked kinda like a network of inter-related parts.
05:31:39 <wooby> well i'd imagine you'd need an algorithm that changed some property of whatever data structure you came up with
05:32:26 <wooby> hm
05:32:30 <CakeProphet> well..
05:32:45 <wooby> have you ever thought of the idea of like
05:32:49 <wooby> a massive human powered computer?
05:33:00 <wooby> like individuals doing operations and timing is done with music or something
05:33:05 <CakeProphet> A computer that eats humans?
05:33:12 <wooby> lol no
05:33:29 <wooby> anyways just a brainfart of mine
05:33:33 <CakeProphet> Sounds slow, cumbersome, inhumane, and inefficient.
05:33:35 <wooby> a programming language that simulated the design of such a thing
05:33:38 <wooby> indeed it would be
05:33:50 <CakeProphet> ooogh
05:34:50 <wooby> but yes
05:34:53 <wooby> on genetic algorithms
05:34:55 <wooby> i know nussing
05:35:15 <CakeProphet> (This is Bob) picks up (this is block-Sue)/(This is Steve) gets Sue from Bob with (this is a hammer-Kim)
05:35:52 <CakeProphet> a huge people metaphor.
05:38:06 <CakeProphet> We should band the entire esolang crowd together to make an esoteric operating system.
05:38:32 <CakeProphet> oh my... but what would the base language be?
05:38:40 <CakeProphet> BF isn't powerful enough...
05:39:01 <wooby> it could be
05:39:06 <wooby> what about a fullblown BF machine
05:39:18 <wooby> then an OS written in basic :)
05:44:16 <CakeProphet> ....
05:44:26 <CakeProphet> writing a whole OS in BF would be mind-boggling.
05:44:36 <CakeProphet> Maybe a combination of a bunch of languages...
05:44:53 <CakeProphet> esoteric languages are all fairly small.
05:46:49 -!- ihope has quit (Connection timed out).
05:48:35 <CakeProphet> Sure... we could put the whole lot of them into the OS... and somehow make the whole thing cohesive.
05:50:37 <wooby> it has potential
05:51:02 <GregorR> Yes yes, everybody's discussed this possibility.
05:52:11 <CakeProphet> So let's do it. ^.^
05:52:33 <GregorR> Fine fine, carry on.
06:00:36 <CakeProphet> ..
06:00:53 <CakeProphet> Where should we start?
06:00:58 <CakeProphet> Perhaps informing everyone?
06:01:45 <CakeProphet> I think the base languages should be BF, Befunge, Glass, and a bunch of otherones I can't think of right now.
06:03:11 <GregorR> I think you should start with a good idea, like EsoOS or, oh, EsoOS, or that other EsoOS, or EsoAPI or PEsoIX, or ...
06:03:25 <wooby> esOS?
06:06:42 <CakeProphet> esoos :D
06:07:08 <CakeProphet> We could bring it up on the Wiki... and decide a name there?
06:07:31 <wooby> that could be a good start
06:07:37 <CakeProphet> hmmm...
06:07:49 <CakeProphet> We could use a more modular version of BF.
06:07:53 <CakeProphet> I considered the idea myself.
06:07:59 <CakeProphet> Like a functional BF...
06:08:46 <CakeProphet> hehe... and we can ditch a filesystem... and the whole desktop metaphor.
06:13:22 <CakeProphet> hahaha... the entire OS could be a stack.
06:13:26 <CakeProphet> a stack-based OS.
06:15:26 <CakeProphet> OH
06:16:10 <CakeProphet> it could be represented as a infinite 2d grid... like befunge.
06:23:20 -!- cmeme has quit (Remote closed the connection).
06:23:36 -!- cmeme has joined.
06:24:03 <CakeProphet> hola
06:28:58 * GregorR hits his head against a wall.
06:30:23 <CakeProphet> hmmm?
06:38:35 -!- ihope_ has quit (Connection timed out).
06:45:45 -!- oerjan has joined.
06:48:09 <CakeProphet> http://esolangs.org/wiki/Esoteric_Operating_System
06:51:04 <oerjan> cakeprophet: did you notice my comment that the A class in Glass seems to be broken?
06:52:06 <CakeProphet> hmmm...
06:52:11 <CakeProphet> Nope.
06:52:48 <oerjan> the programs hang on the . lookup command.
06:53:08 <oerjan> at least they did yesterday.
06:53:17 <CakeProphet> !glass {M[m(_a)A!(_o)O! <2><2>(_a)a.?(_o)o.?]}
06:53:25 <CakeProphet> oh wait... I think EgoBot is ded.
06:53:28 <oerjan> !ps
06:53:32 <EgoBot> 1 oerjan: ps
06:53:35 <oerjan> nope
06:53:35 <CakeProphet> ....
06:54:19 <CakeProphet> Someone should fix it before we implement Glass into our operating system. ;)
06:54:21 <oerjan> !glass {M[m(_a)A!(_o)O! <2><2>(_a)a.?(_o)(on).?]}
06:54:39 <CakeProphet> oh... yeah
06:54:49 <oerjan> !glass {M[m(_a)A!(_o)O! <2>(_o)(on).?]}
06:54:51 <CakeProphet> Why must the output be split by type? >.<
06:54:52 <EgoBot> 2
06:55:34 <CakeProphet> The OS will need a universal system for retrieving data from various programs.
06:55:39 <oerjan> because Glass is not supposed to be easy :)
06:56:06 <CakeProphet> and I think we should ditch the desktop metaphor... and the filesystem.
06:56:59 <CakeProphet> Glass isn't all that hard once you get used to it.
06:57:03 <CakeProphet> which takes about a day.
07:40:47 <CakeProphet> Weird...
07:40:58 <CakeProphet> My very first BF interpreter....
07:41:09 <CakeProphet> and the Hello World program from the esolang wiki only prints out "Hello"
07:42:18 <oerjan> !bf >+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]
07:42:19 <EgoBot> Hello
07:42:41 <oerjan> !bf >+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]<.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+.
07:42:45 <EgoBot> Hello World!
07:43:05 <oerjan> whoops. you didn't happen to copy only the first line, too? :)
07:43:36 <CakeProphet> hmmm... possibly.
07:43:46 <oerjan> or perhaps your interpreter breaks when encountering the newline
07:44:26 <CakeProphet> Don't see why it would.
07:44:47 <oerjan> if you don't ignore non-command characters properly, say
07:44:52 <CakeProphet> !bf >+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.>>>++++++++[<++++>-]
07:44:54 <CakeProphet> <.>>>++++++++++[<+++++++++>-]<---.<<<<.+++.------.--------.>>+.
07:44:55 <EgoBot> Hello
07:45:21 <CakeProphet> That's exactly what I put into my interpreter.
07:45:48 <oerjan> so it seems likely that it breaks at the newline in the program, then.
07:46:24 <oerjan> either because you don't ignore non-command characters, or because the interpreter only reads one line of input.
07:46:27 <CakeProphet> EgoBot did the same thing...
07:46:52 * CakeProphet points above.
07:47:15 <oerjan> that's because EgoBot parses only one single line, which it pretty much has to do on IRC.
07:47:35 <CakeProphet> oh... yeah I forgot to get rid of the newline.
07:48:30 <wooby> !bf ++++++++[>+++++++++<-]>.<++++[>+++++++<-]>+.<++[>+++<-]>+..+++.++++[>++++++++<-]>.<+++++[>++++++++++<-]>+++++.<<.+++.------.<+++[>---<-]>+.
07:48:32 <EgoBot> Hello˜Ï
07:48:34 <CakeProphet> As far as I can tell... it ignores them completely.
07:48:34 <wooby> woops
07:49:23 <oerjan> what happens in your interpreter if you replace the newline with a space?
07:49:23 <CakeProphet> http://deadbeefbabe.org/paste/3085
07:49:38 <CakeProphet> ...nothing?
07:49:49 <CakeProphet> oh... what happens?
07:49:55 <CakeProphet> heh, lemme check.
07:51:41 <CakeProphet> now it just hangs and does nothing...
07:52:34 * CakeProphet figures out the problem with some breadcrumbing.
07:53:59 <oerjan> you mean you solved it?
07:54:26 <CakeProphet> no.
07:54:34 <CakeProphet> hmmm...
07:54:42 <CakeProphet> it seems to have faulty while loop parsing.
07:55:23 <oerjan> but then why would it get Hello right?
07:56:17 <CakeProphet> dunno..
07:56:30 <CakeProphet> I made some changes to the source inbetween runs when I noticed a bug.
07:56:34 <CakeProphet> could have messed something up.
07:56:41 -!- ivan`_ has joined.
07:56:56 <CakeProphet> Here;s the soure again... with a test run at the bottom
07:56:57 <CakeProphet> http://deadbeefbabe.org/paste/3085
07:57:09 <CakeProphet> The long line of commands is the symbol the interpreter was interpreting.
07:57:29 <CakeProphet> It seems to go on forever on the while loop.
07:57:54 <oerjan> there is something wrong with [, anyhow - it never skips the first iteration
07:58:09 <CakeProphet> Right.
07:59:14 <oerjan> which it cannot because of the way parse is called - you cannot escape from the "for char in toparse:" in parsecode. that must be changed.
07:59:56 -!- wooby has quit.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:02:16 <oerjan> anyhow this problem cannot be why the Hello World doesn't work.
08:04:08 <CakeProphet> it doesn't need to escape.
08:04:39 <CakeProphet> parsecode() calls parse() on each character in toparse
08:04:58 <oerjan> yes it does, because a loop shall not be executed at all if the cell is 0 on the first try.
08:05:40 <CakeProphet> oooh.
08:06:27 <oerjan> may i suggest something like "while self.pos < length(self.code):"
08:06:40 <oerjan> and then you make [ and ] adjust self.pos.
08:08:05 <CakeProphet> I've got a spiffier and more elavorate solution.
08:08:18 <oerjan> good :)
08:08:48 <CakeProphet> Using a coroutine. :D
08:08:56 <CakeProphet> Which is something I've yet to have a chance to use.
08:14:15 -!- ivan` has quit (Connection timed out).
08:14:16 -!- ivan`_ has changed nick to ivan`.
08:21:41 <CakeProphet> hmmm
08:21:53 <CakeProphet> oerjan, Not sure how to reliable tell where a ['s corresponding ] is.
08:22:08 <CakeProphet> hmmm... oh wait.
08:22:11 * CakeProphet facepalms.
08:24:06 <oerjan> got problems?
08:24:56 <CakeProphet> hmmm... just parsing problems.
08:25:32 <CakeProphet> Given the sequential order of parsing... I'm not sure how to reliably find the right ] to jump to.
08:28:54 <oerjan> the elegant solution is to have a separate parsing and execution stage
08:29:22 <oerjan> wait - another method.
08:29:57 <oerjan> have a flag that tells whether you are skipping or executing.
08:30:10 <CakeProphet> I considered that.
08:30:24 <CakeProphet> I don't really like it... but.. eh
08:31:20 <oerjan> you basically have to do _some_ non-executing parse at some step.
08:32:03 <CakeProphet> But then...
08:32:12 <CakeProphet> The problem with that is nested []'s
08:32:44 <CakeProphet> If I tell it to... upon always finding "]"... change the "amparsing" flag to True.
08:33:11 <oerjan> no, you should use recursion for [] like with ordinary execution.
08:33:58 <oerjan> the flag should be a method parameter, not an object property.
08:35:11 <oerjan> it needs to be combined with the self.pos adjusting approach.
08:44:04 <CakeProphet> heh... I did some funky stuff to get it to work right.
08:44:24 <CakeProphet> ...provided it works right.
08:44:33 <oerjan> btw the same advice i just posted to Sphen lee on the wiki applies to you too:
08:44:57 <oerjan> "It requires infinite lookahead/backtracking if you compile in the same step as parsing, but that works only for the simplest languages anyhow. Instead parse into an AST, then compile that. Much more flexible."
08:45:46 <CakeProphet> .....you want me to compile the AST of BRAINFUCK?
08:46:09 <oerjan> it is much simpler to handle loops if you reify them first...
08:46:42 <oerjan> well, compilation or interpretation, i was just quoting myself. :)
08:47:07 <CakeProphet> I really haven't figured out the difference.
08:47:26 <CakeProphet> They both involving parsing to a more machine-readable set of opcodes.
08:48:56 <oerjan> but getting the AST (before either compiling or interpreting it) is about getting the essential structure of your program, so you don't have to go do complicated text searches.
08:55:18 <CakeProphet> Either way... you're going to need to do some text searching to get the AST
08:55:21 <oerjan> brainfuck has very little structure (only loops), but it is still that structure that is giving you problems.
08:55:43 <oerjan> well, i meant back-and-forth searching.
08:55:59 <CakeProphet> How would I represent -single character commands- any more clearly with an AST?
08:56:41 <oerjan> yeah, needing more than just strings for those _is_ a bit annoying.
08:57:37 <CakeProphet> No I mean.
08:57:46 <CakeProphet> AST wouldn't help parse the syntax... because it's so simple to parse.
08:57:49 <CakeProphet> it's little just opcodes.
08:57:53 <CakeProphet> literally.
08:58:51 <oerjan> ok, i got another idea.
08:59:40 <oerjan> instead of a whole AST, use an initial parse to build a lookup table between matching []'s.
09:00:26 <CakeProphet> Well... I'm sort of just using attributes to keep track of how the execution is going.
09:00:37 <CakeProphet> it's not quite as fancy... but it gets the job done.
09:01:05 <CakeProphet> Plus I'm not sure how to... do that.
09:01:49 <oerjan> i may be spoiled by Haskell, which makes ASTs so easy...
09:02:32 <GregorR> Just use exclusively EgoBF and you'll be fine.
09:02:53 <oerjan> gregorR: seen my comment on the Glass A class bug?
09:04:40 <CakeProphet> Well... I was going to build a BF interpreter so I could subclass it and work on a functional BF I've been thinking of.
09:05:25 <oerjan> cakeprophet: do you have a paste of your updated interpreter? (and BTW does Hello World work now?)
09:05:49 <CakeProphet> Eh I'm still working on it.
09:05:56 <oerjan> ok
09:06:04 <oerjan> !glass
09:06:07 <EgoBot> OK
09:08:55 <CakeProphet> hmm..
09:09:35 <CakeProphet> My functional BF was going to have two pointers... and have a way to split BF programs into subroutines.
09:09:49 <CakeProphet> . would become a return statement of sorts.
09:10:12 <CakeProphet> and , would be function input.
09:10:54 <oerjan> do you mean function call?
09:10:57 <CakeProphet> but.... I'm not sure how useful a one-character return value would be. :/
09:11:08 <CakeProphet> no.. I mean , would represent whatever the functions input was.
09:11:20 <CakeProphet> parameters.
09:11:55 <CakeProphet> eh.. I'm still working it out.
09:12:30 <CakeProphet> A BF program would be a "pile" of subroutines.
09:12:35 <oerjan> perhaps you could put parameters on the tape instead.
09:12:37 <CakeProphet> like a two-dimensional array.
09:13:20 <CakeProphet> Well... I thought , would give the function more control over where the parameters ended up.
09:13:30 <CakeProphet> plus it fits nicely with the current syntax.
09:13:59 <CakeProphet> A @ command would switch your "current" pointer to the other one.
09:15:12 <CakeProphet> and & would call the subroutine that the "other" pointer is pointing to... using the "current" pointers cell as input.
09:15:58 <oerjan> so the tape would contain subroutines?
09:16:10 <CakeProphet> eh... it would be like a tape of tapes.
09:16:40 <CakeProphet> with a subroutine pointer and a multiple array pointers.
09:16:45 <oerjan> but a subroutine is code, so you would need to put code on the tapes, or at least code pointers.
09:16:56 <CakeProphet> right.
09:17:05 <CakeProphet> a tape of tapes... a tape of subroutines... which are all tapes.
09:17:33 <oerjan> reflective then, if you could access the source code directly?
09:18:24 <CakeProphet> The subroutine pointer just points to the subroutine that will be called when you do a &... not sure if that makes it reflective or not.
09:18:46 <CakeProphet> I guess it would be interesting to make it reflective like you said... sounds kinda neat.
09:19:00 <CakeProphet> but I'll have to change how it references other subroutines to do calls.
09:19:19 <GregorR> !glass {M[m(_o)O!(_a)A!<2><2>(_a)a.?(_o)(on).?]}
09:19:40 <GregorR> !glass {M[m(_o)O!(_a)A!<60><5>(_a)a.?(_o)(on).?]}
09:19:49 <oerjan> EgoBot, you are _so_ borken :)
09:19:55 <GregorR> !ps
09:19:58 <EgoBot> 1 GregorR: ps
09:20:05 <GregorR> !glass {M[m(_o)O!(_a)A!<60><5>(_a)a.?(_o)(on).?"foo"(_o)o.?]}
09:20:06 <CakeProphet> hmmm...
09:20:12 <CakeProphet> aah... I see what you mean.
09:20:26 <GregorR> I'll look at it tomorrow, I have to sleep.
09:20:44 <oerjan> well good night to you.
09:20:45 <CakeProphet> I was sorta just thinking the code would just be normal brainfuck programs with some delimiter between them... but having it like a tape of tapes is cool.
09:21:36 <CakeProphet> There could be two pointers on the big pointer... a subroutine pointer and a call pointer.
09:22:12 <CakeProphet> the subroutine pointer points to whatever subroutine you're "editing"... and the call pointer points to the subroutine you'll call via the & command.
09:23:17 <CakeProphet> so then... & by definition would temporarily move the subroutine pointer to the call pointer.
09:23:28 <CakeProphet> or something...
09:23:32 <CakeProphet> damn that's confusing.
09:25:18 <CakeProphet> OH
09:25:37 <CakeProphet> @ would swap the rolls of the "big" pointers.
09:26:05 <CakeProphet> current-tape pointer would swap places with function-to-call pointer.
09:26:44 <CakeProphet> er... wait.
09:27:41 <CakeProphet> damnit I'm confused.
09:30:25 <CakeProphet> I think it would make more sense to just simply do &(subroutiine reference name)
09:30:34 <CakeProphet> and be done with it :P
09:32:29 <oerjan> well, otherwise you need at least one tape whose contents represent points in the code
09:32:42 <oerjan> although that could be done in many ways.
09:33:12 <oerjan> *contents or positions
09:34:09 <CakeProphet> Having the subroutines on a tape would be the more BF-ish of the two.
09:34:30 <CakeProphet> but... it makes BF infinitely more useful if it had subroutine reference names.
09:35:34 <CakeProphet> heh... it would be kind of postfix notation.
09:36:08 <CakeProphet> generally subroutines would manipulate the contents of the array behind them... if there are more than one manipulated cells.
09:36:15 <CakeProphet> Like an add function.
09:37:06 <oerjan> just behind them?
09:37:11 <CakeProphet> +>+++>&(add)
09:37:21 <CakeProphet> would dump 4 into the third cell.
09:37:40 <CakeProphet> there would need to be some sort of "protocol" for subroutines to follow if they intended to be re-used.
09:37:59 <CakeProphet> it would be awkward in typical BF code for calls to occur before their data.
09:38:31 <CakeProphet> by "before" I mean spatially before.
09:38:44 <CakeProphet> >>+>+++<<&(add)
09:38:46 <CakeProphet> just doesn't seem right.
09:39:18 <CakeProphet> but then again... I've been doing a lot of Glass lately.
09:39:33 <CakeProphet> so maybe all that reversed subroutine calling has been fucking up my conceptualization :P
09:40:39 <CakeProphet> (in truth... Glasses subroutine calls are more accurately displated than in standard languages)
09:41:25 <CakeProphet> arguments are always evaluated and pushed to the stack before their subroutine calls are.
09:52:59 <oerjan> well, not always in Haskell :)
09:53:50 <CakeProphet> ....how?
09:55:31 <oerjan> Haskell is a lazy language, so arguments may not be evaluated until they are actually used by the subroutine.
09:56:07 -!- ivan`_ has joined.
10:13:44 -!- ivan` has quit (Read error: 110 (Connection timed out)).
10:13:44 -!- ivan`_ has changed nick to ivan`.
10:22:56 -!- okokoko has changed nick to oklopol.
11:12:19 <oklopol> good use for the start of the day
11:12:36 <oklopol> read everything talked in the 11 hours i slep
11:12:37 <oklopol> *t
11:50:53 * oerjan is in nearly complete agreement.
11:56:01 <oklopol> not just here, i'm on over 50 channels :)
11:56:20 <oklopol> (k i didn't read EVERY channel, but many)
11:56:28 * oerjan is no longer in nearly complete agreement :)
11:57:03 <oerjan> i couldn't even read that fast.
11:57:49 <oklopol> i thought i might learn writing binary fast in ascii today so i'm making a stepmania with ones and zeroes
11:58:28 <oklopol> i didn't read every <someone> !glass (stuph...) <same someone> DARNFUCK!
12:00:53 <oerjan> i do _not_ believe i used the f word.
12:02:40 <oklopol> you might not have, i don't think darnfuck is a word
12:03:05 <oklopol> i mean, i didn't read code that is indicated incorrect on the next line
12:03:49 <oerjan> actually some of that wasn't the _code_ being incorrect, but rather a bug in the interpreter.
12:04:11 <oklopol> i know, A
12:04:59 <oklopol> but anyways, i meant no use reading code when it's being further developed
12:05:09 <oklopol> (not generally, but in oneliners)
12:38:10 -!- jix_ has joined.
12:53:03 -!- oerjan has quit ("Up, up, and away").
13:09:32 -!- ihope_ has joined.
13:09:47 -!- ihope_ has changed nick to ihope.
14:20:20 -!- anonfunc has quit.
14:44:02 <oklopol> how does the thing work in freenode, if i should flood 500 lines of ososososososososososo here, would one of you get ops out of no where and kickban me?
14:44:09 <oklopol> and no, i'm not gonna try
14:49:01 <oklopol> then another mindboggler, can i make a regexp that... solved it but gonna say this anyway, it seems
15:32:39 -!- tgwizard has joined.
15:54:44 -!- pgimeno has quit ("reboot").
15:59:34 -!- pgimeno has joined.
16:11:37 -!- RodgerTheGreat has joined.
16:11:46 * RodgerTheGreat waves
16:16:07 <RodgerTheGreat> I was looking at yesterday's logs- an OS written in BASIC would be fascinating
16:30:35 -!- Sph1nx has joined.
16:33:21 -!- Asztal has joined.
16:54:42 -!- Sph1nx has quit ("äÏ Ó×ÉÄÁÎÉÑ ×ÓÅÍ!").
16:56:03 -!- Aardwolf has joined.
17:09:18 <CakeProphet> RodgerTheGreat, but but
17:10:17 <CakeProphet> http://esolangs.org/wiki/Esoteric_Operating_System
17:13:54 <Asztal> I would love to code shell scripts in befunge... well, I guess I already can
17:14:42 <SimonRC> sigh
17:14:53 <SimonRC> darn weather
17:15:33 -!- oerjan has joined.
17:16:12 <CakeProphet> If we had some hardware nerds we could even design our own assembly language. :D
17:16:37 * SimonRC indicates the INTERCAL microprocessor.
17:16:51 <CakeProphet> hahaha
17:24:48 * SimonRC considers the similarities between unununium and Smalltalk.
17:25:45 <SimonRC> The main one, AFAICT, is that Unununium's meta-object protocol is crapper.
17:25:59 <Asztal> OISC?
17:31:06 <SimonRC> I am suprised that one hasn't been implemented.
17:31:35 <SimonRC> You could get 3Ginstr/sec per core if it was
17:32:11 <oklopol> what hasn't been implemented?
17:32:26 <SimonRC> OISC
17:36:50 * Asztal wonders, on average, the ratio of OISC instructions per x86 instruction in a typical program ;)
17:37:15 <oklopol> you mean there is no physical implementation of an oisc?
17:37:58 <SimonRC> I think so
17:38:22 <SimonRC> c'mon, people don't do that much multiplication.
17:38:26 <oklopol> because for example the computer made in wireworld is an oisc
17:39:03 <CakeProphet> http://en.wikipedia.org/wiki/Oisc
17:39:05 <CakeProphet> oh yeah!
17:39:10 <CakeProphet> wireworld... that was crazy.
17:39:14 <CakeProphet> oisc is a KING OF KENT
17:39:20 * SimonRC reads the story of virtudyne on the front page of The Daily WTF. Absolutely amazing story.
17:39:25 <SimonRC> CakeProphet: heh
17:41:06 <CakeProphet> If you had a wireworld simulator... you could build a virtual computer.
17:41:42 <CakeProphet> but I guess it's not too surprirsing... the similarities between wireworld and actual electrical witing are very close.
17:42:00 <oklopol> did you see my paste?
17:42:09 <oklopol> i pasted one here
17:42:22 <oklopol> i mean, a link to it, not the code
17:42:48 <Asztal> Can floating point arithmetic actually be done in OISC?
17:43:21 <CakeProphet> oklopol, no
17:43:28 * Asztal can't see a way that wouldn't be horribly long-winded
17:43:32 <CakeProphet> Asztal, I'm sure it's possible... just don't know how easy it would be.
17:43:47 <Asztal> I'm sure bitwise operations are terribly useful there
17:43:53 <CakeProphet> You could represent it with two integers possibly...
17:44:24 <Asztal> true, that would be a lot easier
17:44:24 <oklopol> i lost all my logs, been running two mircs, they overwrite each others logs
17:44:39 <oklopol> so i can't find it anymoew
17:44:40 <oklopol> *re
17:44:42 <CakeProphet> in Python a floating point is implemented by a double in C. :D
17:45:45 <Asztal> still, I wouldn't want to be the person who has to write the logarithm function :)
17:46:29 <CakeProphet> ...yeah
17:46:44 <pikhq> Asztal: It's assuredly possible.
17:46:48 <pikhq> Just a bitch.
17:49:53 <pikhq> oklopol: It's a MOV machine. :)
17:50:16 <oklopol> not an oisc?
17:50:28 <pikhq> It's an OISC. . .
17:50:37 <pikhq> Just describing the specific type of OISC.
17:50:43 <pikhq> It's one instruction is MOV.
17:50:58 <pikhq> Special registers allow for one to get use out of that.
17:52:04 <oklopol> pikhq, i know how it works, so i didn't know why you told me that
17:52:50 <pikhq> I don't know, either.
17:52:59 <pikhq> Coffee hasn't hit the bloodstream yet.
17:53:29 <oklopol> poor you :(
17:54:40 <CakeProphet> http://www.quinapalus.com/wi-index.html
17:55:14 <CakeProphet> That one uses only one instruction set... but all the different registers react differently to it.
17:58:01 <SimonRC> actually, there is a wireworld computer around somewhere.
17:58:08 <SimonRC> It has 64 6-bit registers
17:58:20 <SimonRC> OST, 12-bit
17:59:06 <SimonRC> It can be found containing a program to calculate prime numbers.
17:59:31 <CakeProphet> ^
17:59:42 <CakeProphet> Pretty sure that was it.
17:59:57 -!- ihope has quit (Connection timed out).
18:00:47 <pikhq> SimonRC: We were *talking* about that computer. -_-'
18:02:20 <SimonRC> ah, I thought you were talking about one of the OISC machines.
18:02:50 <SimonRC> Though he ww computer is an OISC machine too, but not the traditional SJM type.
18:09:15 <oklopol> 1. that was the wireworld program i was talking about 2. that was the program simonrc was talking about
18:09:33 <oklopol> the link
18:17:05 <Asztal> #define IMAGE_FILE_MACHINE_OISC 0x301 ;)
18:17:50 -!- Asztal has quit ("p0w p0w!").
18:26:36 -!- Aardwolf has quit ("Leaving").
18:32:23 * pikhq defines behavior for IRP#irp
18:34:28 <oklopol> the irp-quine i saw here the other day, it's a bit cheatish, a quine should not read it's own source!
18:34:52 <pikhq> It's not reading it's own source. . .
18:35:00 <pikhq> It's just executing the source as defined.
18:38:06 <oklopol> hmm, well, that's philosophy, very hard to tell in this case :D
18:38:23 <pikhq> Heheh.
18:41:53 <oerjan> OK then...
18:44:27 <oerjan> Please say the following, first without quotes, then within quotes: "Please say the following, first without quotes, then within quotes:"
18:46:55 <oerjan> hm, IRP seems to be down.
18:48:10 <oklopol> Please say the following, first without quotes, then within quotes: "Please say the following, first without quotes, then within quotes:"
18:48:20 <oklopol> oerjan, have i told you you are a genius? :D
18:48:56 <pikhq> Go to IRP#irp
18:48:58 <oklopol> i tell that easily tho
18:48:59 <oerjan> i don't know, but someone around here promised to deify me for my shortened Glass quine.
18:49:14 <oklopol> :DD
18:49:19 <oklopol> ye it was me!
18:49:39 <oerjan> and Malcolm Ryan declared me insane for my Unlambda interpreter in Intercal, which I took as a great compliment.
18:50:37 <oklopol> if i hear of intercal one more time, i'm gonna learn it
18:50:39 <pikhq> oerjan: In #irp, we are working on giving IRP defined behavior.
18:52:44 <pikhq> And I'm wondering why the hell I can't get SSHFS to work.
18:54:31 <pikhq> Ahah.
18:54:49 <pikhq> fusermount, on Ubuntoids, is mode 700.
19:02:49 * SimonRC ponders some way of representing hex as surreal haiku, to make it easier to recognise.
19:02:52 <SimonRC> or even remember (!)
19:04:39 -!- calamari has joined.
19:06:54 <CakeProphet> hmmm... reminded me of "Yields falsehood when preceeded by its quotation" yields falsehood when proceeded by its quotation.
19:07:33 <CakeProphet> SimonRC, oh... yeah that would be cool. Haikus always have a fixed number of syllables. :D
19:09:21 <SimonRC> obvious;ly multiple haiku would be needed
19:10:53 <CakeProphet> You could use the kigo to represent some sort of encoding?
19:10:58 <CakeProphet> (the "season" word)
19:15:41 <CakeProphet> or... you could use all the craziness of http://en.wikipedia.org/wiki/Renga to construct various representations of numbers.
19:15:46 <CakeProphet> There's a crapload of terminology :P
19:16:43 <SimonRC> nah, i was thinking of some silly way of doing it in English
19:16:44 <CakeProphet> The haiku was based off of the opening stanza of a renga
19:17:24 <SimonRC> *was*
19:17:40 <SimonRC> in modern net culture, that is largely forgotten
19:18:00 <CakeProphet> Yah.
19:18:05 <CakeProphet> Each haiku could be a digit.
19:18:18 <CakeProphet> which would work nicely... as three haiku stanzas would form a hex triplet :P
19:18:42 <CakeProphet> -how- you calculate what the value is... will take some consideration.
19:19:48 <CakeProphet> Well... a haiku has 17 syllables... and a hex number has 16 possible values.
19:20:18 <CakeProphet> maybe certain properties of a haiku stanza make it either True or False.
19:20:26 <CakeProphet> and the hex value is the total of all the Trues
19:20:43 <CakeProphet> with the last syllable being some sort of metadata or something. :D
19:23:28 <CakeProphet> That would be awesome... as a full three-stanza haiku would be a hex triplet... which would be a color.
19:23:37 <CakeProphet> HOW POETIC
19:23:59 <SimonRC> I was thinking of something that would be suitable for recognising hashes, fingerprints, etc, actually
19:24:26 <CakeProphet> How do you do that?
19:24:37 * CakeProphet isn't familiar with using hex to... recognize hashes and fingerprints.
19:25:07 <SimonRC> I was thinking of using a load of lookup tables to encode 4 hexits per stanza, maybe 8, in rather surreal text.
19:26:14 <CakeProphet> hmmm...
19:27:00 <CakeProphet> So..
19:27:10 <CakeProphet> 2 or 4 hex values per stanza?
19:28:39 <CakeProphet> You could go with the length of each line.
19:28:52 <CakeProphet> that tends to give you a lot of freedom in what you can write.. but isn't as cool.
19:29:10 <CakeProphet> As its not the haiku itself that gives it a hex value... but the length of the haiku.
19:29:16 <CakeProphet> ...so it's not as nifty.
19:31:25 <SimonRC> I am ont really concentrating on the decoding, mor the encoding
19:45:54 <CakeProphet> hmmm...
19:46:01 <CakeProphet> septidecimal numbers?
19:48:32 <RodgerTheGreat> I've been doing some thinking about a proper name for EsoOS, and the idea that popped into my mind was "Framework"
19:49:11 * pikhq recommends that you make it an OS. :P
20:00:00 * SimonRC goes to dinner
20:01:16 <calamari> I still recommend having a random factor.. so that each user has a unique os.. nobody can provide support
20:03:08 -!- calamari has quit ("Leaving").
20:03:39 <RodgerTheGreat> perhaps make the OS a basic system that provides core services, and then has esolang "modules" loaded to provide functionality
20:04:20 <RodgerTheGreat> I could configure my system to run BF, DBF, SYNTHESYS, and perhaps Glass, while someone else could run BASIC and Befunge.
20:05:16 <RodgerTheGreat> the kernel would provide memory management, threading, a simple network stack, and a simple shell that can access modules as backends
20:06:08 <RodgerTheGreat> turn on the computer, and it can run a series of startup scripts using hosted languages, before providing the user with an interactive interpreter of their choice.
20:06:09 <CakeProphet> hmmm...
20:06:23 <CakeProphet> Sounds good... no need for files either.
20:06:26 <CakeProphet> Just "modules"
20:06:29 <RodgerTheGreat> yeah
20:06:50 <CakeProphet> That would of course require some sort of OS-level importing mechanism that would work in all interpreters.
20:06:58 <pikhq> Although files would be needed if you wanted to make it support PESOIX.
20:07:36 -!- RodgerTheGreat_ has joined.
20:07:37 * CakeProphet is working on a functional BF that's a bit more modular.
20:07:53 <RodgerTheGreat_> you could use a PalmOS-style "database" system for storing user data and code on media
20:07:57 * RodgerTheGreat_ mumbles some disparaging remarks about wifi
20:08:54 <CakeProphet> RodgerTheGreat Let's do orthogonal persistency... and make it totally weird!
20:08:54 <CakeProphet> weirdness + esotericism == good
20:08:54 <CakeProphet> The kernel could represent memory as BF arrays.
20:09:17 <CakeProphet> and access to it could use BF commands?
20:09:28 <RodgerTheGreat_> we'd probably have to be resigned to the idea of recoding all the interpreters we wanted from scratch, so we can make our own executable format for modules.
20:09:45 * CakeProphet nods.
20:09:52 <CakeProphet> What would be the base language?
20:09:57 <CakeProphet> to code all the interpreters.
20:10:18 <RodgerTheGreat_> I was thinking more in terms of creating a useful OS, but we could try to build some kind of capability for filesystem abstraction, etc.
20:10:20 <RodgerTheGreat_> hm
20:10:23 <RodgerTheGreat_> a good question
20:10:44 <RodgerTheGreat_> our first step could be designing such a language and it's associated development kit.
20:10:57 <pikhq> Or just use C and a special library.
20:11:01 * CakeProphet gags.
20:11:03 <RodgerTheGreat_> blech
20:11:03 <CakeProphet> NO C
20:11:15 <pikhq> The core OS, at least, would need to be in C. . .
20:11:31 <RodgerTheGreat_> nothing *needs* to be coded in C.
20:11:43 <pikhq> RodgerTheGreat_: You want it in D or ASM?
20:11:47 <RodgerTheGreat_> it just needs to be coded in something that ends up being machinecode.
20:12:04 <RodgerTheGreat_> no, I want to build a new language for the express purpose of avoiding C.
20:12:18 <CakeProphet> esooslang :D
20:13:30 <pikhq> Define some stuff. . .
20:13:48 * pikhq will be back
20:13:58 <CakeProphet> I think implementing the processor register as a BF array would be the esoteric way to do it... plus it's not terrible unuseful.
20:14:10 <RodgerTheGreat_> hm
20:14:24 <CakeProphet> brainfucks concept of memory storage maps fairly easily to a computer's main memory.
20:15:34 <RodgerTheGreat_> well, let's see... what does a low-level language need?
20:15:55 <CakeProphet> input, output, and something to move around.
20:16:19 <RodgerTheGreat_> memory allocation and deallocation, function definition
20:16:45 <CakeProphet> a functional BF? :D
20:16:48 <RodgerTheGreat_> I think that allowing inline ASM is an extremely bad idea, if we ever want to be able to cross-compile
20:17:08 <CakeProphet> I'm not familiar with what ASM is anyways
20:17:09 <oklopol> memory allocation in brainfuck: [>]
20:17:19 <RodgerTheGreat_> I suppose you could make it similar to BF, but we need a way to make the source a little more readable in general.
20:17:56 <CakeProphet> Using DefBF (functional brainfuck) would work nicely... it allows you to abstract BF to make it somewhat useful.
20:18:09 <CakeProphet> an extension to BF.
20:18:14 <CakeProphet> to make it more useful.
20:18:59 <RodgerTheGreat_> perhaps set it up to use a reasonably conventional function syntax, so you could make calls like substring[x, a] or something
20:19:54 <RodgerTheGreat_> advanced looping constructs aren't that vital if we allow normal- and tail-recursion
20:20:39 <CakeProphet> My first idea for my a functional BF just used named references to do function calls.
20:20:51 <CakeProphet> and the function would just start working with the current array.
20:21:01 <RodgerTheGreat_> hm
20:21:05 <CakeProphet> kinda like in Glass... except with an array instead of a stack.
20:21:31 <RodgerTheGreat_> well, if you use an array properly, it can do the same things as a stack
20:21:37 <CakeProphet> *nod*
20:21:55 <RodgerTheGreat_> so there isn't anything inherently wrong with doing it that way
20:22:07 <CakeProphet> my second idea, to make it more esoteric, involved a array of data and an array of subroutines... both having a pointer.
20:22:27 <RodgerTheGreat_> hm
20:22:33 <CakeProphet> but that makes it harder to get the function you want... as the functions are referenced by a name and you have to move around a subroutine pointer.
20:22:51 <CakeProphet> might not be suitable for an environment where it needs to be good at something.
20:23:00 <CakeProphet> aren't
20:23:06 <CakeProphet> referenced by a name ;)
20:23:08 <CakeProphet> typoz
20:23:15 <RodgerTheGreat_> I think the most important thing to add to BF if it's going to be used for a large project is some syntax for loading other source files as libraries and comment syntax.
20:23:42 <RodgerTheGreat_> they don't add anything to the actual language, but they add tremendous benefits in terms of organization
20:23:48 <CakeProphet> eh... the "ignore all non-commands" comment syntax works fine.
20:24:04 <CakeProphet> an "import" syntax as well as functions could be done.
20:24:10 <CakeProphet> essentially you'd be giving it namespaces. :D
20:24:39 <CakeProphet> sorta... the manipulated data remains universal nomatter what.
20:25:05 <CakeProphet> arguments to the functions would simply just be sitting on the array.
20:25:38 <CakeProphet> ++>++>&(add) creates [2,2,4,0,0,0,0,0,0, ...]
20:26:13 <CakeProphet> the exact mechanism for each function would differ.. but they would all follow some basic format.
20:27:23 -!- RodgerTheGreat has quit (Connection timed out).
20:27:36 -!- RodgerTheGreat_ has changed nick to RodgerTheGreat.
20:28:45 <oklopol> 0,0,4, maybe?
20:29:05 <CakeProphet> eh... depends on if you plan on reusing those values.
20:29:24 <RodgerTheGreat> yeah, there is the issue that BF tends to operate on values in a destructive manner
20:29:31 <CakeProphet> do you want it in-place... or do you want to create a new memory space?
20:29:41 <oklopol> you should have different versions of everything to be able to imply copying like in your example
20:29:47 <oklopol> since it's slower in bf
20:29:58 <CakeProphet> *nods*
20:30:10 <RodgerTheGreat> you might want some way in the function definitions to specify wether your code will preserve the original operands.
20:30:50 <CakeProphet> well... if the functions are literally just executed like normal code... there's no way to disginuish operands from other memory.
20:30:58 <RodgerTheGreat> you have to think of this on both sides- how will the coder work with it, and how will the compiler work with it?
20:31:18 <CakeProphet> One method is to have a (move) function for copying values into new cells.... which would be used extensively by functions so they don't have to destroy old values to get new results.
20:31:48 <RodgerTheGreat> that could be difficult to post-optimize
20:32:25 <RodgerTheGreat> hm
20:32:40 <RodgerTheGreat> how about giving BF pointers>
20:32:41 <CakeProphet> #rotates current value in the cell 13 places#%(rot13)+++++++++++++% #Main program ---># +++++++++++++++&(rot13)
20:33:11 <CakeProphet> using some implied psuedo-syntax for now.
20:33:17 <CakeProphet> we can work out syntatical details later.
20:33:22 <oklopol> rtg that sounded like a good idea
20:33:30 <RodgerTheGreat> make GOSUB and RETURN equivalents that take an argument from the current cell?
20:33:32 <CakeProphet> giving BF pointers?
20:33:39 <oklopol> so you could just have a call and a return
20:34:04 <oklopol> v=call, ^=return
20:34:09 <CakeProphet> How would you do binary operations?
20:34:11 <oklopol> those being just jumps
20:34:18 <pikhq> RodgerTheGreat: For libraries, try BFM. . .
20:34:21 <RodgerTheGreat> possibly also have such a system for the BF array pointer, so that you could pop it from place to place and back quickly and easily
20:34:22 <oklopol> and of course, you would need 64-bit
20:34:25 <pikhq> (shameless plug)
20:35:05 <CakeProphet> hmmm... maybe a mix of glass and BF?
20:35:09 <RodgerTheGreat> some of the BFM codebase would likely prove useful, although we'd have to modify it a bit to work efficiently in the new language
20:35:12 <CakeProphet> hehe
20:35:27 <RodgerTheGreat> at the very least, it'd be a good way to quickly have a standard library
20:35:31 <pikhq> Well, I'd of course want to rewrite the standard libraries.
20:35:57 <pikhq> But the core language would, in fact, make for a powerful way of operating in Brainfuck on this OS.
20:35:58 <CakeProphet> Use glass functions and stack pushes... but with BF syntax? :D
20:36:03 <RodgerTheGreat> we could take the BFM libraries to begin with, and then over time rebuild them to suit the new langage
20:36:50 <RodgerTheGreat> I just like the idea of augmenting BF with execution and memory pointers. It seems like an elegant way to build structured code with BF
20:36:52 <pikhq> Fortunately, BFM at the moment has been designed to be language-independent.
20:37:05 <pikhq> RodgerTheGreat: I really like that idea.
20:37:41 <pikhq> BFM would also allow for some pure-Brainfuck utilities in our language.
20:37:49 <pikhq> s/language/OS/
20:37:50 <RodgerTheGreat> take that basic idea, wrap it in a little syntactic sugar to make it programmer-friendly, and it sounds like we have ourselves a solid plan for a language
20:37:58 <RodgerTheGreat> good idea
20:38:30 <pikhq> And I've got to admit I like the idea of the whole OS being written in esolangs.
20:38:36 <CakeProphet> hmmm... not sure how it would work exactly though.
20:39:13 <CakeProphet> Like... how would you expand the syntax to make function calls take multiple arguments from multiple cells?
20:39:14 <RodgerTheGreat> by maintaining complete backwards compatibility and making it easy to simulate giving subprograms their own pristine memory space, the new language wouldn't have to abandon any existing BF code
20:39:30 <RodgerTheGreat> CakeProphet: I'm thinking...
20:39:42 <RodgerTheGreat> give me an hour or two, and I'll see if I can whip up a rough spec.
20:39:57 <CakeProphet> Currently the closest one to be conceptually realized is to simply make the array universal for all subroutines... and have some sort of built-in command for copying values.
20:40:01 <RodgerTheGreat> does anyone here have any experience in compiler design?
20:40:10 <CakeProphet> Nope.
20:40:27 <pikhq> Tiny amount.
20:40:58 <pikhq> I think calamari has a decent amount of experience.
20:41:19 <RodgerTheGreat> alright, I appoint myself and CakeProphet as language architects, and pikhq and calamari to the compiler implementation team
20:41:55 <pikhq> I'd recommend asking him, though. ;)
20:42:03 <CakeProphet> In glass having a universal stack works fine and doesn't make it hard to build working subroutines.... and by augmenting BF to have a quick way to copy values you can prevent the destructive nature of BF from destroying the coder's existing data.
20:43:10 <RodgerTheGreat> I think that a single tape will be fine, as long as we can call and return memory locations for the tape pointer
20:43:17 <CakeProphet> but then again... each-function-with-its-own-array works even cleaner... you just have to figure out how to make the syntax work easily.
20:43:46 <CakeProphet> whatcha mean?
20:43:51 <RodgerTheGreat> the big question is wether pointers should use direct or relative addressing.
20:44:06 * pikhq prefers some idea of a two-dimensional array. . .
20:44:08 <CakeProphet> *shrugs* I'm a high-level junkie... I don't anything about that. :P
20:44:17 <pikhq> More like, say, a stack of arrays.
20:44:27 <CakeProphet> that was my original idea.
20:44:34 <CakeProphet> sorta kinda.
20:44:37 <pikhq> Yeah.
20:44:53 <RodgerTheGreat> I'm thinking of the memory layout as a single array for BF memory, and then a pair of stacks for function execution and the memory pointer
20:45:30 <CakeProphet> Calls will be named right?
20:45:40 <RodgerTheGreat> you can simulate giving functions their own tape pretty easily, and the whole idea maps to assembly pretty neatly
20:45:42 <RodgerTheGreat> yes
20:46:10 <pikhq> Push a clear one on for a function, with the function's arguments copied onto the first cells.
20:46:21 <CakeProphet> and then alter add some form of import syntax... depending on how our memory is segmented (i.e. how we do file-like entities)
20:46:38 <RodgerTheGreat> hm
20:47:13 <RodgerTheGreat> what did we decided we want to name this language?
20:47:17 <RodgerTheGreat> *decide
20:47:24 <CakeProphet> !glass {M[m(_o)O! "lol"(_o)o.?]}
20:47:27 <EgoBot> lol
20:47:40 <CakeProphet> I've just been colling it "functional brainfuck" and "DefBF"
20:47:53 <RodgerTheGreat> DefBF it is
20:47:55 <pikhq> bf>++[-<+>]
20:47:55 <pikhq> ?
20:47:58 <pikhq> Ah.
20:48:05 <CakeProphet> It rhymes at least :D
20:48:24 <CakeProphet> Def-BF to make it look less crowded.
20:48:44 <CakeProphet> or Define Brainfuck if you're feeling verbose.
20:49:08 <pikhq> Out of curiosity, what sort of OS architecture are we talking about on top of this?
20:49:23 <CakeProphet> Most likely something unique. :D
20:49:51 <CakeProphet> I'd like to do the whole thing as a huge thought experiment.
20:49:56 <CakeProphet> no Unix-like crap.
20:50:19 <pikhq> How's about getting PESOIX as at least a basic sort of API?
20:50:42 <CakeProphet> I think a lot of the inter-communication will be tuned directly into the architecture.
20:50:48 <pikhq> At least an inspiration of how to do some additional API functions, like, say, hard drive access. . .
20:51:01 <CakeProphet> I like the "component" model of uuu... where there's no files and everything is on the same memory space.
20:51:18 <CakeProphet> yeah... we'll need to tweak all the languages a bit for more access.
20:51:48 <CakeProphet> if we do orthogonal persistency... we might not even need hard drive access.
20:52:09 <CakeProphet> !glass {M[m(_o)O! (_x)I! (_x)i.?(_o)o.?]}
20:52:18 <CakeProphet> !i 2 Hello World!
20:52:23 <CakeProphet> !i 2 \n
20:52:32 <CakeProphet> !ps
20:52:35 <EgoBot> 1 CakeProphet: ps
20:52:49 <pikhq> I think one should have additional functionality to the various languages via input and output. . .
20:53:23 <CakeProphet> We could universalize the data... so languages can share data.
20:53:35 <CakeProphet> Everything breaks down to numbers in the end...
20:54:50 <CakeProphet> A BF program could theoretically make a Glass program run, print an output, and use that for input.
20:54:53 <CakeProphet> using some sort of API.
20:55:20 <CakeProphet> The "filesystem" could be totally functional...
20:56:26 <pikhq> Allow me to at least write a cat program for this OS.
20:56:33 <CakeProphet> each program is a "function" that's called with an input and returns an output. The output would be universal to all languages.
20:56:35 <pikhq> @ char
20:56:36 <pikhq> in char
20:56:38 <pikhq> while char {
20:56:41 <pikhq> out char
20:56:42 <pikhq> in char
20:56:44 <pikhq> }
20:57:12 <pikhq> Presumably the shell will just call functions.
20:57:23 <CakeProphet> Basically.
20:57:40 <CakeProphet> If organizing names becomes a problem... we could do some sort of namespacing.
20:58:01 <CakeProphet> but not too complex... massive directory names have always annoyed me.
20:58:22 <CakeProphet> !glass {M[m(_o)O! (_x)I! (_x)i.(_o)o.?]}
20:58:30 <CakeProphet> !i 2 Lol
20:58:37 <pikhq> !eof 2
20:58:48 <pikhq> Hmm.
20:58:56 * pikhq sees one issue with that glass program. . .
20:59:02 <pikhq> No looping involved.
20:59:04 <CakeProphet> ah.
20:59:08 <CakeProphet> !glass {M[m(_o)O! (_x)I! (_x)i.?(_o)o.?]}
20:59:11 <CakeProphet> !i 2 lol
20:59:17 <CakeProphet> Actually... I just forgot to call the input method.
20:59:30 <CakeProphet> !ps
20:59:33 <EgoBot> 1 CakeProphet: ps
20:59:59 <CakeProphet> !glass {M[m(_o)O! (_x)I! (_x)i.?(_o)o.?]}
21:00:01 <CakeProphet> ack..
21:01:16 <CakeProphet> !glass {M[m(_o)O! (_x)I! (_s)S! /<1> (_x)i.? "\n" (_s)a.?(_o)o.?\]}
21:01:22 <CakeProphet> !ps
21:01:25 <EgoBot> 1 CakeProphet: ps
21:01:30 <CakeProphet> gmmm...
21:03:12 <CakeProphet> I think the neat thing about the OS would be the universiality... it could basically tie all the esoteric languages together and make them work as a collective whole to do something useful.
21:04:06 <pikhq> Heheh.
21:04:53 -!- calamari has joined.
21:06:01 * CakeProphet pokes RodgerTheGreat
21:06:35 <CakeProphet> !glass {M[m(_o)O! "RodgerTheGreat, calamari's here."(_o)o.?]}
21:06:39 <EgoBot> RodgerTheGreat, calamari's here.
21:06:50 <pikhq> !cat Whee.
21:06:53 <EgoBot> Huh?
21:06:58 <pikhq> Grr.
21:07:07 <pikhq> !daemon cat bf ,[.,]
21:07:11 <pikhq> !cat Wheee.
21:07:13 <EgoBot> Wheee.
21:07:36 -!- RodgerTheGreat has quit (Read error: 104 (Connection reset by peer)).
21:07:39 -!- RodgerTheGreat_ has joined.
21:07:40 <CakeProphet> ...
21:07:45 <CakeProphet> WELCOME BACK
21:07:53 <RodgerTheGreat_> woo
21:07:59 <CakeProphet> !glass {M[m(_o)O! "RodgerTheGreat, calamari's here."(_o)o.?]}
21:08:01 <EgoBot> RodgerTheGreat, calamari's here.
21:08:14 <pikhq> !cat !cat works better.
21:08:17 <EgoBot> !cat works better.
21:08:22 <RodgerTheGreat_> I have a nearly done spec for Def-BF
21:08:26 <pikhq> :)
21:08:44 <calamari> RodgerTheGreat: were you looking for me? :)
21:09:39 <RodgerTheGreat_> yeah- interested in joining an exciting and challenging project?
21:10:01 -!- oerjan has changed nick to oerjan_.
21:10:12 -!- oerjan_ has changed nick to oerjan.
21:10:18 <calamari> dunno.. I'm already working on such a project :)
21:11:01 <CakeProphet> Well... this one is better...
21:11:05 <CakeProphet> and more profitable.
21:11:46 <calamari> heh
21:12:26 <pikhq> FOR GREAT PROFIT!
21:13:04 <RodgerTheGreat_> CODE OFF EVERY ZIG!
21:13:04 <calamari> I'm currently working on putting wikipedia and the scriptures on my ipod
21:13:13 <calamari> writing the renderer now
21:13:23 <pikhq> We're discussing an OS written in Esolangs.
21:13:38 <calamari> doesn't sound profitable to me hehe
21:15:56 <RodgerTheGreat_> alright, here's the first revision of my spec.
21:15:57 <RodgerTheGreat_> http://nonlogic.org/dump/text/1167512946.html
21:15:58 <CakeProphet> RodgerTheGreat_, If the data of programs is universally accessible... an import syntax may not even be nessicary... a function call could just reach out to all Def-BF files.
21:16:19 <RodgerTheGreat_> take some time to read it over, and then we can discuss clarifications, changes, and additions.
21:16:30 <RodgerTheGreat_> hm
21:16:36 <RodgerTheGreat_> a good idea.
21:16:52 <calamari> ick.. need to clean my scanner.. that image looks horrible
21:17:09 <RodgerTheGreat_> however, some Def-BF compilers will exist for other operating systems, so it's probably a good idea to have an import statement in the spec.
21:18:25 <CakeProphet> RodgerTheGreat_, Should we set imported functions in a namespace?
21:18:38 <RodgerTheGreat_> I'm still thinking about that
21:18:41 <RodgerTheGreat_> not sure yet
21:18:52 <CakeProphet> Well... other than recommending some syntax changes... I still need to figure out all this addressing stuff. I'm a noob at low-level memory stuff.
21:19:32 <RodgerTheGreat_> we might do it like ReX, by calling all functions as Library.FunctionName[], with local functions called as just FunctionName[]
21:19:59 <CakeProphet> What's all this absolute address stuff?
21:20:09 <RodgerTheGreat_> at least, that's how I remember ReX working...
21:20:28 <RodgerTheGreat_> pointers have to be absolute addresses to be useful.
21:20:40 <RodgerTheGreat_> absolute is the opposite of relative
21:20:47 <CakeProphet> >.>
21:21:07 <CakeProphet> I've never delt with memory allocation...
21:21:17 <CakeProphet> garbage collection for the win.
21:21:17 <RodgerTheGreat_> like, with absolute addressing, 0x00000000 would be the VERY first memory address on your machine
21:21:22 <RodgerTheGreat_> heh
21:21:30 <CakeProphet> ah.
21:21:36 <CakeProphet> memory address... gatcha
21:21:39 <RodgerTheGreat_> 0x00000001 is the second, and so on
21:21:41 <CakeProphet> you have to specify that?
21:22:06 <RodgerTheGreat_> relative addressing is like in redcode, where 0 would refer to the current address, and 1 would refer to the next
21:22:12 <pikhq> With relative, 0x00 would be the current address. 0x01 would be the next, -0x01 would be the previous. . .
21:22:17 <RodgerTheGreat_> yeah
21:22:24 <RodgerTheGreat_> exactly
21:22:28 <pikhq> Like in Brainfuck.
21:22:55 <oklopol> why a separate stack for the calls?
21:22:56 <CakeProphet> But why do you need to specify absolute address?
21:23:04 <CakeProphet> and how would you know it?
21:23:16 <oklopol> just the one array
21:23:24 <RodgerTheGreat_> and relative addressing the primary reason that functional pure brainfuck would be really hard to code with, so we add pointer functionality
21:23:54 <CakeProphet> except... I have no clue how it works now. >.<
21:23:58 <oklopol> call = jump to whatever is in the current cell, store the previous place
21:23:58 <RodgerTheGreat_> CakeProphet: for the most part, the compiler will deal with and assign the absolute addresses
21:24:31 <RodgerTheGreat_> oklopol: it's the difference between making a jump in code, and a jump in memory location
21:24:44 <oklopol> yes, no jump in memory location is needed
21:25:08 <oklopol> you don't need anymore the pointer to where you came from
21:25:10 <CakeProphet> ...I don't really like the spec all that much... it doesn't really resemble BF anymore.
21:25:27 <oklopol> it's bf with a jump
21:25:32 <oklopol> the stack one has... stacks
21:25:48 <RodgerTheGreat_> the advantage of memory location jumps is that we can make functions that can pretend that they have their own independent memory spaces
21:26:10 <oklopol> well, true
21:26:18 <RodgerTheGreat_> I think of it as "BF with pointers"
21:26:42 <CakeProphet> but... by using variables and all really takes it a long ways from feeling BFish.
21:26:59 <oklopol> i just dislike the multiple stacks thing, but concurrency seems to need it
21:27:01 <RodgerTheGreat_> it doesn't do a whole lot that's impossible with normal BF, but it makes it more possible to code in a structured manner
21:27:04 <oklopol> now that i think of it
21:27:30 <CakeProphet> constants could just be functions...
21:27:31 * pikhq would rather see just BFM compiling to the low-level version. XD
21:27:52 <RodgerTheGreat_> pikhq: well, yeah- that's why both exist
21:27:53 * CakeProphet doesn't like it at all... :/
21:28:19 <oklopol> CakeProphet, what does "constants could just be functions" mean?
21:28:43 <RodgerTheGreat_> pure access to the nuts and bolts of the language, plus some nice features for less esoterically inclined coders
21:28:47 <calamari> RodgerTheGreat_: are you using @ notation?
21:29:06 <RodgerTheGreat_> erm... well, I use the @ character for something...
21:29:40 <oklopol> : resume execution from previous address
21:29:49 <oklopol> oh
21:29:50 <calamari> for example x=x+y, @y[@x+@y-@t+]@t[@y+@t-]
21:29:51 <oklopol> you said stacks
21:30:20 <RodgerTheGreat_> calamari: ah, I see what you mean- no, not currently
21:30:21 <CakeProphet> assuming % means "start definition" and "end definition"... %(lol)[-]+++++++++++% would be the same as a constant.
21:30:51 <calamari> RodgerTheGreat_: it does a lot to make it easier to code in BF, but can be easily converted to pure BF
21:31:01 <pikhq> source ^stdcons.bfm
21:31:05 <CakeProphet> giving functions scopes, returns, and arguments makes it look more and more like C-based languages.
21:31:07 <pikhq> consfoo bar : baz
21:31:08 <RodgerTheGreat_> yeah, I agree...
21:31:10 <calamari> err that program is flawed
21:31:10 <pikhq> ;)
21:31:21 <calamari> @y[@x+@t+@y-]@t[@y+@t-]
21:31:23 <calamari> there we go
21:32:05 <RodgerTheGreat_> I may revise the syntax to use that notation, if it's a common way of expressing BF algorithms already
21:32:08 <pikhq> For calamari's suggestion, I could just rewrite the "goto" proc in BFM, and automagically port every BFM program.
21:32:19 <RodgerTheGreat_> nice
21:32:24 <calamari> I thought that Easel, ESOapi or the like would be used for the os
21:32:40 <pikhq> I was thinking PESOIX.
21:32:41 <CakeProphet> RodgerTheGreat_, Wouldn't a global scope, and literally just substituting functions into the source be just as effective?
21:32:50 <calamari> then you wouldn't have to change bf at all
21:32:52 <pikhq> CakeProphet: That'd be a macro system.
21:33:16 <CakeProphet> It achieves much of the same effect.
21:33:46 <oklopol> runtime macros like that are much less bf
21:33:47 <oklopol> ish
21:33:50 <calamari> afk.. continuing my project
21:33:51 <RodgerTheGreat_> CakeProphet: yes- I would like to use global scoping, but I think a basic returning system would be a good idea
21:34:13 <CakeProphet> RodgerTheGreat_, What is there to return if it's global scope?
21:34:35 <oklopol> to continue the code
21:34:40 <oklopol> not return a value
21:35:06 <CakeProphet> like a "break"?
21:35:12 <RodgerTheGreat_> hm
21:35:13 <oklopol> like a return
21:35:16 <CakeProphet> to break out of the function?
21:35:20 <RodgerTheGreat_> yes
21:35:56 <CakeProphet> Not sure you'd need that if you do functions right.
21:35:57 <oklopol> is there a nice intercal reference?
21:36:14 <RodgerTheGreat_> that's effectively what the current "return" statement does- you can optionally use it to pass a specific pointer back to where the function was called from
21:36:42 <RodgerTheGreat_> if you already know where the function is operating in memory, you don't need it to pass back a pointer
21:37:26 <RodgerTheGreat_> the value of pointers is that they allow the compiler to arrange memory and code however it determines is the most efficient, without having to modify hardcoded values
21:37:29 <CakeProphet> Why pointers? Global scoping does the same thing as pointers.
21:38:08 <RodgerTheGreat_> in an interpreted language, they aren't very important. In a compiled language, they're extremely powerful.
21:38:28 <CakeProphet> Maybe the word "pointer" is just invoking images of C.
21:38:33 <CakeProphet> :P
21:38:45 <RodgerTheGreat_> yeah, I imagine it does.
21:38:55 <RodgerTheGreat_> we could go the Java route and call them "references"
21:39:09 <CakeProphet> We could just call them.... cells?
21:39:21 <RodgerTheGreat_> cell references.
21:39:24 <CakeProphet> It's the same thing.
21:39:53 <oklopol> call them cell indexes
21:40:05 <CakeProphet> ...
21:40:10 <oklopol> reference has an abstactionish feel to it
21:40:20 <oklopol> *abstractionish
21:40:43 <RodgerTheGreat_> alright, in the interest of avoiding any painful allusions to C, we will call what were previously referred to as "pointers" as "cell indices"
21:40:56 <CakeProphet> but I mean... how does using pointers and scopes make the language more efficient than a global array that simply takes the nearby cells as parameters?
21:41:10 <CakeProphet> meh... cell indices doesn't sound nice either.
21:41:24 <oklopol> what then?
21:41:25 <CakeProphet> :P
21:41:30 * CakeProphet grumbles.
21:41:47 <CakeProphet> Call them fish bowls.
21:41:55 <RodgerTheGreat_> a global array with no scoping OR pointers means that code can't be arbitrarily re-arranged without breaking it.
21:42:04 <RodgerTheGreat_> nor can memory.
21:42:12 <CakeProphet> Whatcha mean?
21:42:28 <RodgerTheGreat_> actually, they CAN, it's just nontrivial, and adds needless complexity to the compiler
21:42:46 <CakeProphet> ....but it seems simpler.
21:43:04 <RodgerTheGreat_> let's say your program assumes a memory model like [A][B][blank][blank[C]
21:43:14 <CakeProphet> a universal strip of memory... no referencing... and calls just substitute the functions definition into the code.
21:43:21 <RodgerTheGreat_> and then you add a function to make use of the blanks...
21:43:36 <RodgerTheGreat_> [A][B][D][E][C]
21:44:09 <RodgerTheGreat_> now, if a new function requires memory, it has to know these chunks are all full, and know how to get from it's own areas of memory to existing ones.
21:44:12 <oklopol> CakeProphet, are you talking about a runtime substitution?
21:44:21 <RodgerTheGreat_> the alternative with pointers...
21:44:32 <CakeProphet> *shrugs* nothing detailed... just "sbustition".
21:44:47 <CakeProphet> I'm talking in vague terms... it would have the -effect- of being substited.
21:44:54 <RodgerTheGreat_> {area1}[A][B]....{area2}[C]....{area3}[D][E]
21:44:58 <oklopol> runtime substitution wouldn't be very brainfuck imo
21:45:05 <CakeProphet> I don't know the specifics of how compilers do things
21:45:24 <RodgerTheGreat_> now, it doesn't matter where these areas are in actual memory, just that they have references to one another's locations
21:45:41 <CakeProphet> Glass would be a good example of this kind of universal stack... with functions that are still just as useful.
21:46:03 <CakeProphet> RodgerTheGreat_, Maybe I'm just not used to working at a low level.
21:46:11 <oklopol> CakeProphet, runtime would be very non-brainfuck and compile-time would be idiotic
21:46:12 <CakeProphet> I think of the memory of a BF array being literally.. side by side.
21:46:20 <RodgerTheGreat_> that could be it
21:47:38 <RodgerTheGreat_> I guess what I'm trying to get across is just that having something like a pointer makes it a great deal easier for the compiler to do it's jobs without the programmer having to know the precise memory layout of the entire machine
21:48:26 <oklopol> yes, changing the need for memory in one place would affect every single function in the whole computer
21:48:28 <CakeProphet> RodgerTheGreat_, hmmm... oh... this is for the machine's memory array?
21:48:29 <RodgerTheGreat_> it's a complication that you run into in the process of creating very large or memory intensive programs in BF
21:48:34 <RodgerTheGreat_> yes
21:49:15 <CakeProphet> ah... yeah, this is definetely going to need to be geared to a more lower-level application.
21:49:28 <CakeProphet> I do wish it were less memory-related. :/
21:49:32 <oklopol> with pointers you could have virtual memory and stuff much easier etc.
21:49:50 <oklopol> i mean, the compiler could allocate small things in virtual etc
21:50:22 <RodgerTheGreat_> pikhq: making a two-stage compile system might be a good way to do this- you can compile high-level code (or any alternate version thereof) into the basic Def-BF language, which can then be compiled into machinecode
21:50:23 <CakeProphet> I really have -no- esperience with memory allocation.
21:50:50 <RodgerTheGreat_> hey, I'm a Java coder myself.
21:51:07 <CakeProphet> can we at least make the statements one-character? :D
21:51:15 <CakeProphet> BF just doesn't look right with whole words in it.
21:51:36 <CakeProphet> well.. obviously we need function names in the code.
21:51:47 <CakeProphet> but the operations should all stick to the one-character commands.
21:51:58 <RodgerTheGreat_> the statements in the low-level version *are* one character. If you don't want words, you could easily create your own abstraction of the basic language
21:52:24 <RodgerTheGreat_> the whole point is just to standardize the basic version, and then allow abstractions to grow as needed
21:53:28 <RodgerTheGreat_> the only non single-character command is ?, which is entirely unnecessary aside from aiding in compiling to machinecode- don't use it if you don't want to
21:53:45 <CakeProphet> what about "define" and "return"?
21:53:52 <CakeProphet> and function calls taking variable arguments.
21:54:02 <CakeProphet> that's a huge step away from BF-style programming.
21:54:07 <oklopol> no
21:54:09 <pikhq> Those are high-level abstractions layered on Def-BF.
21:54:10 <RodgerTheGreat_> those are just abstractions of @/: and #/;
21:54:11 <oklopol> you allocate manually
21:54:19 <oklopol> or?
21:54:48 <oklopol> you aren't gonna put in functions(with,arguments) or smth like that are you?
21:54:51 <RodgerTheGreat_> pure Def-BF itself is just +-<>,.[];:#@
21:55:09 * CakeProphet feels much better now.
21:55:19 <CakeProphet> I thought return and define were -statements-
21:55:30 <RodgerTheGreat_> everything in the spec under "High-level programming" is just a convenience to programmers
21:55:57 <RodgerTheGreat_> all of those statements translate directly into a series of +-<>,.[];:#@
21:56:00 <CakeProphet> You should show examples of what it would look like in the actual code.
21:56:18 <RodgerTheGreat_> I guess code examples are the next step.
21:56:26 <RodgerTheGreat_> I'll do some work in that vein
21:56:31 <CakeProphet> and... do we need comment syntax?
21:56:45 <oklopol> the programs are in the same memory as memory, right?
21:56:49 <RodgerTheGreat_> I think it's worth having, but once again that's just part of the abstraction
21:57:07 <oklopol> so that you can dl programs etc :)
21:57:20 <RodgerTheGreat_> oklopol: not sure we can assume that, but that's most likely how it'll be on a real machine
21:57:29 <RodgerTheGreat_> fuck Von Neumann. >:D
21:57:31 <CakeProphet> Given the small nature of the command set... it seems the ignore-all-non-applicable-commands would work fine and be just as readable.
21:57:57 <RodgerTheGreat_> Like I said, comments are just part of the abstraction- not the core language
21:58:00 <oklopol> how could programs be added without programs being in the same memory?
21:58:11 <CakeProphet> bah... all this abstraction syntax is confusing me. :P
21:58:37 <RodgerTheGreat_> CakeProphet: then just ignore everything under this line: "High-level programming:"
21:58:52 <CakeProphet> Will do. ;)
21:58:58 <RodgerTheGreat_> :)
21:58:59 * CakeProphet found that part the most sickening.
21:59:26 * CakeProphet is happy now.
21:59:57 <RodgerTheGreat_> essentially, just think of @ controlling the program counter and # controlling the BF memory pointer
22:00:13 <CakeProphet> ah.
22:00:21 <CakeProphet> and what's the /?
22:00:28 <RodgerTheGreat_> nothing.
22:00:36 <RodgerTheGreat_> in english, it means And OR
22:00:44 <RodgerTheGreat_> which is how I was using it
22:00:53 <CakeProphet> oooh.
22:00:55 <CakeProphet> looked confusing.
22:01:24 <RodgerTheGreat_> @ works in tandem with : and # works in tandem with ;
22:01:30 * CakeProphet nods.
22:01:35 <CakeProphet> That makes a lot more sense now.
22:01:41 <RodgerTheGreat_> excellent
22:01:56 * CakeProphet thought all the pointer stuff was going to muck-up the brainfuckiness.
22:02:03 <CakeProphet> but it doesn't really.
22:02:04 <RodgerTheGreat_> so, are we all happy with at least the spec for the low-level version?
22:02:37 <CakeProphet> hmmm... yeah the spec works. ^ seems like a more descriptive command for : thought. :D
22:02:45 <pikhq> I'm not going to touch the high-level version, so, yeah.
22:02:45 <CakeProphet> : is kinda like a "return" right?
22:02:51 <RodgerTheGreat_> yes
22:02:59 <CakeProphet> thought so.
22:03:06 <RodgerTheGreat_> didn't really expect you to, pikhq. ;)
22:03:33 <CakeProphet> I'll need to figure out how # and ; work specifically... but I get their function now.
22:03:46 <oklopol> but, how do you do argument copying with the high-level version?
22:03:52 <oklopol> *low-level version
22:03:58 <RodgerTheGreat_> the high-level spec is just how I'd like to build a metalanguage out of Def-BF.
22:04:33 <RodgerTheGreat_> oklopol: assuming I understand what you're asking, you can still do it how you'd normally do it in BF.
22:05:04 <oklopol> but, "if a function call includes parameters, these pointers
22:05:05 <oklopol> are copied to the first x cells of the memory location specified
22:05:05 <oklopol> by the compiler."
22:05:12 <RodgerTheGreat_> yes
22:05:15 <oklopol> how does the low-level do that
22:05:18 <CakeProphet> # would be argument getters.
22:05:22 <CakeProphet> methinks.
22:05:23 <oklopol> it doesn't know about argument
22:05:28 <oklopol> ah
22:05:31 <oklopol> of course
22:05:37 <RodgerTheGreat_> it'd be a normal BF cell-to-cell copy
22:05:47 <oklopol> but with absolute addresses?
22:05:59 <RodgerTheGreat_> it just uses pointers to locate the source and destination
22:06:11 <CakeProphet> I'm guessing ; simply copies the altered value back to where it was taken from.
22:06:39 <oklopol> @[-;+@]; << like that? (i forgot the symbols :))
22:07:02 <CakeProphet> only one @
22:07:19 <oklopol> go back - [do things] - com back
22:07:23 <RodgerTheGreat_> yeah, something like that, except @ should be #
22:07:31 <oklopol> k
22:08:05 <CakeProphet> hmmm...
22:08:11 <CakeProphet> Doesn't it need a name though?
22:08:28 <CakeProphet> How do @ and # know where to go?
22:08:32 <RodgerTheGreat_> no, just a value representing a location- the absolute address
22:08:33 <oklopol> that was argument copying from the main program memory to function memory
22:08:42 <RodgerTheGreat_> CakeProphet: that's what the stack is for
22:08:55 <CakeProphet> ah.... the value in the current cell represents the address?
22:09:09 <RodgerTheGreat_> when you do a @, it pushes the old location onto a stack. When you : back, it pops off the old value
22:09:16 <RodgerTheGreat_> like a GOSUB... RETURN
22:09:36 <oklopol> with absolute addresses, it's possible to allocate and "infinite" bit of the tape for every function right?
22:09:53 <CakeProphet> where is the "old location" specified?
22:09:59 <RodgerTheGreat_> as far as the functions need to know. :)
22:10:01 <oklopol> because they can be moved around as needed etc if the address is absolute
22:10:11 <RodgerTheGreat_> yes
22:10:13 <CakeProphet> oh.... wait I think I get it.
22:10:31 <CakeProphet> the cell value represents the address of the function to call?
22:10:42 <RodgerTheGreat_> the high-level version ought to have some way of specifying how much memory a function uses, so that the compiler can allocate memory sensibly
22:10:51 <RodgerTheGreat_> CakeProphet: yes
22:11:08 <CakeProphet> and that address value will be replaced by whatever the function returns?
22:11:19 <RodgerTheGreat_> CakeProphet: OR, the address of the memory location to go to, depending on wether you're using @ or #
22:11:35 <RodgerTheGreat_> CakeProphet: you're confusing yourself with the high-level version again
22:11:36 * CakeProphet isn't familiar with the low-level aspects of a function call.
22:12:04 <RodgerTheGreat_> the low-level version of the language doesn't explicitly *have* functions, it just has mechanisms for implementing them
22:12:12 <oklopol> ++>++><addition function address here>@ ---- <addition function>(here the retriving of the arguments... how?)
22:12:27 <oklopol> in low-level
22:12:33 <CakeProphet> RodgerTheGreat_, Which is why I'm confused... I don't know the low-level mechanisms.
22:12:36 <oklopol> how do you call a function?
22:12:50 <oklopol> CakeProphet, it's the stack-way
22:12:52 <oklopol> as in glass
22:13:11 <CakeProphet> except... getting arguments is different.
22:13:20 <oklopol> is it?
22:13:22 <RodgerTheGreat_> oklopol: I guess it'd require knowing an absolute memory address to call in the first place
22:13:26 <CakeProphet> I get how to call them now...
22:13:34 <CakeProphet> well... the functions all have different scopes...
22:13:34 <RodgerTheGreat_> which is what could make coding in pure low-level problematic
22:13:41 <oklopol> <addition function address here> meant the absolute address
22:13:43 <CakeProphet> in Glass the functions just pick up values from the stack.
22:14:03 <RodgerTheGreat_> oklopol: oh, I see
22:14:26 <oklopol> CakePropher, the scope is the fact that you can push() in the stack even in the sub without altering main program data
22:14:47 <RodgerTheGreat_> oklopol: you'd want to either make the function call copy the arguments to the function's memory, or pass it (copy it) a reference to the location of those arguments
22:14:48 <oklopol> see an assembler-book :)
22:15:05 <oklopol> ah, of course, do the argument sending in the main prog
22:15:11 <RodgerTheGreat_> yeah
22:15:11 <oklopol> ...as in assembler actually
22:15:14 <RodgerTheGreat_> precisely
22:15:20 <CakeProphet> absolute addressing seems like it would be difficult to work with once you start using Def-BF away from memory allocation.
22:15:21 <RodgerTheGreat_> that's the whole idea. :)
22:15:44 <CakeProphet> perhaps there should be two different languages? One for the memory manamgement and another more usable, low-level form for more application-level stuff?
22:16:09 <pikhq> That would be the. . . high-level language.
22:16:18 <CakeProphet> absolute addressing would get confusing when you get out of the context of memory management.
22:16:21 <RodgerTheGreat_> CakeProphet: well, yes. That's what the abstractions are for. You can also make the executable format make all the absolute addresses relative, and convert them when the app is loaded into memory- that's how normal OSes work
22:16:32 <CakeProphet> but the high-level language looks more like C than Brainfuck. :o
22:17:02 <RodgerTheGreat_> it doesn't necessarily have to- as long as the base language is the same, you can abstract it however you want
22:17:30 <RodgerTheGreat_> you could make your own abstraction that looked like glass or Python
22:17:48 <CakeProphet> Huh?
22:17:57 <CakeProphet> That's syntatic differences...
22:18:14 <CakeProphet> I meant... the high-level version syntatically reminds me of pretty much all c-based languages.
22:18:35 <oklopol> (memory allocation function provided by the os here)@<<++[->>@+;<<]>++[->@>+<;<]>(find the add-function's address somehow)#
22:18:38 <oklopol> like that?
22:18:42 <oklopol> 2+2
22:18:45 <oklopol> =4
22:18:52 <RodgerTheGreat_> that's because I want *my* abstraction to look like Java to some extent, and it's a curly-bracket language
22:19:13 <oklopol> @ i meant as the memory jump
22:19:18 <RodgerTheGreat_> I think that would work, oklopol
22:19:20 <oklopol> # as the program execution jump
22:19:22 <CakeProphet> okay... so is the high-level version going to use the same syntax?
22:19:24 <oklopol> good
22:19:40 <oklopol> CakeProphet, you can make your own high-level
22:19:50 <CakeProphet> ...how?
22:19:59 <oklopol> since it's converted to bf anyway... or?
22:20:20 <RodgerTheGreat_> we all just agree on the low-level language, and then we make our own "compilers" to turn our abstractions into the low-level code
22:20:23 <oklopol> i mean, isn't the high-level just a way to write it nice, but insert as brainfuck?
22:20:28 <oklopol> ye
22:20:38 <CakeProphet> I'm talking about syntax differences... where in the specification does it let you alter the syntax?
22:20:57 <oklopol> the OS can of course have a function that does high-level -> low-level
22:21:22 <oklopol> CakeProphet, basically the high-level is just a standard way to make programs in a nice manner for the OS
22:21:31 <oklopol> i think
22:21:34 <oklopol> am i right?
22:21:46 <CakeProphet> >.> I thought we were just going to use esoteric languages to make the OS?
22:21:49 <oklopol> i mean, nice for the programmer
22:21:57 <oklopol> yes, the OS runs ONLY bf
22:21:58 <CakeProphet> C-look-alikes that convert to brainfuck isn't what I had in mine.
22:22:03 <oklopol> DEF-BF
22:22:48 <oklopol> it is only an abstraction, anyone can make one for themselves, but it's te core brainfuck of Def-BF that is used by the OS
22:23:04 <RodgerTheGreat_> yes
22:23:10 <oklopol> intel uses binary, but you write in python, CakeProphet
22:23:34 <oklopol> the same not anyone might wanna write everything in bf
22:23:58 <CakeProphet> hmmm...
22:24:21 <CakeProphet> alright... I understand.
22:24:27 <oklopol> what i like about this, the increment-system makes it O(n) to even do addition (unless done bitwise reducing to O(logn))
22:24:50 <RodgerTheGreat_> heh
22:24:53 <oklopol> so an irc client might have a hard time ponging the ping in the right amount of time in a concurrent system :)
22:25:11 <oklopol> exaggerating tho
22:25:14 <RodgerTheGreat_> well, in theory the Def-BF->Machinecode can improve that a bit
22:25:29 <RodgerTheGreat_> *compiler
22:25:49 <CakeProphet> yeah... no need to do one-by-one transitions.
22:25:59 <CakeProphet> the compiler can just convert it to specific instructions.
22:26:20 <CakeProphet> but on the programmers end it's good ol' BF.
22:26:26 <CakeProphet> with... some funky changes.
22:26:28 <RodgerTheGreat_> yup
22:26:39 <oklopol> but, i hope the bf is only converted to machine code when running?
22:27:00 <oklopol> no executable files etc (unless needed for the OS of course)
22:27:23 <RodgerTheGreat_> depends- we might use Def-BF to write the kernel and bootloader, in which case it'll need to become Machinecode eventually
22:27:34 <CakeProphet> I'd like a more friendly abstraction of def-bf that still looks like def-bf for making new stuff...
22:27:35 <RodgerTheGreat_> but it can be used both ways
22:27:51 <CakeProphet> Like with names instead of memory addresses.
22:27:59 <CakeProphet> more like the first idea I had for def-BF.
22:28:30 <RodgerTheGreat_> it'd be pretty simple to make the @-notation system calamari suggested as an alternate abstraction
22:28:41 <oklopol> no names in the def-bf code, not good, but you can have OS functions that switch string->address
22:28:49 * CakeProphet nods.
22:28:55 <CakeProphet> I meant... as an alternate language of sorts.
22:29:17 <CakeProphet> so I don't have to fool with memmory addresses with higher-level stuff I might want to play around with.
22:29:32 * CakeProphet will do that himself though.
22:29:55 <oklopol> btw is someone able to actually make a computer boot into their own os?
22:30:23 <CakeProphet> dunoo... I'm just having fun writing it out on paper.
22:30:59 <oklopol> the high-level is merely a tool, it's not important to have it until something big is done imo
22:31:15 <GregorR> Use OSKit or that other one that's like OSKit but more up to date.
22:31:20 <CakeProphet> Well... even for small things it's nice to... not-have-to-fool-with-memory-addresses.
22:31:57 <oklopol> GregorR can you link?
22:31:59 <RodgerTheGreat_> I was figuring we could use Def-BF to write the OS itself, with a bit of pure ASM to build the bootloader and such
22:32:04 <oklopol> i can google of course
22:32:10 <CakeProphet> the point of an OS is to manage memory addresses for us... so naturally an abstraction of the core language is needed to continue to make things easier.
22:32:15 <GregorR> oklopol: There's a good one on SF, the name of which eludes me X_X
22:32:48 <oklopol> k, i saw one once but it went offline before i managed to dl it
22:32:49 <CakeProphet> Unless it's easier than having to remember numbers....
22:32:57 <oklopol> you don't have to
22:33:10 <CakeProphet> If I understand correctly... def-BF doesn't have a concept of assignable names.
22:33:25 <CakeProphet> which is mainly what I would add to it.
22:33:35 <CakeProphet> outside of memory management
22:33:36 <RodgerTheGreat_> the core language doesn't, but the abstraction does.
22:33:43 * CakeProphet nods.
22:33:55 <CakeProphet> that's what I meant... should I decide to abstract it... that's what I abstract it with.
22:34:13 <CakeProphet> function names.... pretty much.
22:34:31 <oklopol> +>++>[-]<<<(address of an OS funtion that swaps string->address)# <<< and you have called the function with the name \0x1\0x2
22:34:46 <oklopol> you see what i mean?
22:35:06 <oklopol> the code must not depend on neither addresses of functions nor their names
22:35:19 <oklopol> (well, can be names if done like that in low-level)
22:35:40 <oklopol> you haven't called, sorry
22:35:54 <oklopol> you have "gotten" the function in that memory space
22:35:59 <oklopol> then do another # to call it
22:36:12 <oklopol> +>++>[-]<<<(addr)##
22:36:29 <oklopol> the address there can be a constant since it's an OS function
22:36:36 <oklopol> kinda like an interruption
22:36:38 <oklopol> in asm
22:37:00 <CakeProphet> heh.... unfortunately I didn't understand any of that.
22:37:16 <CakeProphet> damn low-level....
22:37:54 <oklopol> so, before call, memory is like [(address of the OS func),1,2], after the call to the os func [(address of the \0x1\0x2 func),1,2], in the end [whatever the func returned,1,2]
22:38:23 <oklopol> tho one might want to change 1 and 2 to something sent to the function, and actually send them
22:38:29 <oklopol> i hope someone understands me?
22:38:44 <CakeProphet> I got it... just not sure how that lets me do string names. :P
22:38:46 <RodgerTheGreat_> I believe I'm following you so far
22:39:03 <CakeProphet> I'd need an entire BF array to do a string name.
22:39:04 <oklopol> CakeProphet, this is very basic, for an OS it's the compulsory depth of lowishness imo
22:39:13 <oklopol> no
22:39:16 <oklopol> it's done by the os
22:39:36 <oklopol> the os function expects a null-determined string after the point at which it is called
22:39:40 <CakeProphet> ...and how does the program send the string name to the OS function?
22:39:48 <oklopol> and there you have \0x1\0x2
22:40:31 <oklopol> so you can have nice names in the high-level -functions and you can access them in other programs too because you store and retrieve the name with os functions
22:40:49 <oklopol> eh, store the name, retrive the address
22:40:52 <oklopol> more like
22:41:38 <CakeProphet> ++>++>%(add) ...how would my language interpreter... written in def-BF... transfer "add" to this OS function without doing something like (OSFunc, "a","d","d")
22:41:42 <oklopol> and the absolute need not be converted to relative because i believe this isn't brainfuck but Def-BF, which supports absolute?
22:41:44 <oklopol> right?
22:42:42 <oklopol> CakeProphet, your high-level would've changed the "add" into a code that assigns ["a","d","d"] into the memory and calls the necessary OS function for name->address
22:42:59 <oklopol> then taking the returned address of the program executed
22:43:22 <CakeProphet> Right... but it would need to use up a whole array, right? To ensure that it can take a string of variable length and store it.
22:43:24 <oklopol> Def-BF, am i right in saying this is a new language that extends BF a little for us?
22:43:42 <oklopol> CakeProphet, no arrays in BF
22:43:48 <CakeProphet> >.>
22:43:50 <CakeProphet> what?
22:43:54 <oklopol> just a few preceding cells
22:43:57 * CakeProphet 's head implodes.
22:44:00 <oklopol> that are needed
22:44:12 <CakeProphet> how can you not have an array in BF?
22:44:49 <CakeProphet> How can you represent a string in BF by any other means than multiple cells of characters?
22:44:54 <oklopol> you can, but it will just be the knowledge the next n cells are used for one var
22:45:05 <oklopol> null-determination prolly
22:45:07 <oklopol> easiest
22:45:42 <oklopol> or [length,char1,char2,etc]
22:45:44 <CakeProphet> hmmm... alright.
22:45:51 <CakeProphet> null determination would be better.
22:45:58 <CakeProphet> it makes string mutable-er.
22:45:59 <oklopol> i assume you understand i'm just representing a part of the main array python-tsyle?
22:46:01 <oklopol> *st
22:46:11 <CakeProphet> right.
22:46:18 <oklopol> good.
22:46:48 <CakeProphet> I'm just going over in my head how I would use Def-BF to write a new interpreter for an abstracted version of it.
22:47:04 <oklopol> oh yeah, been wanting to ask that
22:47:25 <oklopol> does the OS need to be writed in Def-BF too? i was thinkin it just ran it :\
22:48:14 <CakeProphet> We're going to implement a bunch of esolangs as core languages.
22:48:15 <RodgerTheGreat_> it doesn't *need* to be written in Def-BF, but it'd be nice if we could do that.
22:48:17 <CakeProphet> to write all the OS stuff.
22:48:50 <oklopol> i mean a normal c++ (or python or whatever) program that is the "OS", having an array of programs running and their memory pointers, running them one by one
22:49:00 <CakeProphet> If the kernel is designed for universiality in mind... allowing the core languages to interchange data should be a breeze.
22:49:32 <RodgerTheGreat_> Def-BF is an example of taking a canonical Esolang (BF) and extending it to be powerful enough to do the jobs of an OS. We could similarly extend other existing Esolangs to have these capabilities if we felt it necessary
22:50:01 <CakeProphet> I'd like esoos to be a big mass of esolangs working together. :D
22:50:28 <RodgerTheGreat_> well, we know for a fact that everything higher than kernel-level will be coded in an esolang.
22:50:34 <CakeProphet> with Def-BF being the base for memory management and constructing some simple interpreters.
22:50:39 <oklopol> i'd say we make the memory allocation etc in a "normal" language and then start making OS modules in Def-BF
22:50:44 <oklopol> oh :D
22:50:47 <oklopol> well then :D
22:50:52 <RodgerTheGreat_> how the kernel will break down remains to be seen
22:51:01 <CakeProphet> Def-BF was designed to be for memory management.
22:51:05 <CakeProphet> I think.
22:51:05 <oklopol> the kernel need not that many operations
22:51:12 <RodgerTheGreat_> yeah
22:52:27 <oklopol> but i'm thinking now of an only-Def-BF computer, that has been coded in two layers, c++/such, then esolangs for modules like virtual memory management, Def-BF being what actual programs are written in, am i right in this?
22:53:07 <CakeProphet> We were mainly using Def-BF so that we didn't have to use C or its variants.
22:53:14 <CakeProphet> C is yucky.
22:53:21 <oklopol> because you wanna use both hard-disk and ram without breaking off the "one tape for everything" principle
22:53:26 <oklopol> oh?
22:53:33 <CakeProphet> and shouldn't even be a major part of an esoteric operating system.
22:54:20 <RodgerTheGreat_> oklopol: universally contiguous memory is a major design goal
22:54:22 <oklopol> i'm a little confused still, k, can i use in this OS a program i use on my computer now?
22:54:50 <CakeProphet> Hmmm... dunno.
22:54:56 <oklopol> yes, but can be cut anyway we want in reality because Def-BF doesn't do everything relatively?
22:54:58 <CakeProphet> We haven't discussed portability yet.
22:55:24 <oklopol> okay, because i'm thinking the computer only runs brainfuck
22:55:31 <RodgerTheGreat_> oklopol: it depends on how we decide to build the kernel.
22:55:52 <CakeProphet> nah... it can run more than BF.
22:56:03 <RodgerTheGreat_> if the kernel itself is written in Def-BF, there will be a single tape and Def-BF will be used to host all the other language interpreters, in a sense
22:56:20 <oklopol> as i described before, array of "processes" where a process is two arrays (@; & #:), program pointer and a memory pointer
22:56:29 <CakeProphet> I don't know what the base-base language is... but Def-BF will be for the kernel and consttructing interpreters and some other super-low-level stuff.
22:56:31 <RodgerTheGreat_> but one way or another the OS will support a number of esoteric languages
22:56:37 <oklopol> and each is run one step sequentially
22:57:19 <oklopol> it will, because the first thing to do is to write interpreters in Def-BF
22:57:33 <CakeProphet> Yeah.
22:57:51 <CakeProphet> as well as a standard library of some sort.
22:57:52 <oklopol> but, i'd say Def-BF is kinda like asm of normal computers
22:58:28 <oklopol> i can't see why it should be the core language for PROGRAMMING the OS... even if that was it's original purpose :D
22:58:45 <RodgerTheGreat_> I'd agree with that idea
22:58:50 * CakeProphet wishes there was a named variant of def-bf that could be used for easier construction of a standard library.
22:59:10 <CakeProphet> it shouldn't... the OS should be programmed by esoteric languages in general.
22:59:30 <RodgerTheGreat_> it'd be trivial to compile such a language into Def-BF proper, which is probably how it'll be done
22:59:38 <CakeProphet> We just needed an extension to BF to make it a bit more useful.
23:00:13 <oklopol> true, things like brainfuck -> faster code are done on the fly i thing, they are coded in esoteric languages
23:00:19 <RodgerTheGreat_> I see Def-BF as being used to write the bulk of the OS, and other languages being used to write all the utilities and applications necessary to make it a complete system
23:00:42 <oklopol> bulk of the OS?
23:00:51 <RodgerTheGreat_> by OS, I mean the kernel
23:00:52 <oklopol> can you specify?
23:00:55 <oklopol> k
23:01:57 <oklopol> kernel does what exactly? (i'm really that stupid, yes :))
23:02:20 <CakeProphet> managemes memory, performs software-to-hardware transactions and disk writing.
23:02:44 <CakeProphet> among other things.
23:02:53 <RodgerTheGreat_> and coordinates the inter-operations between other software
23:03:18 <CakeProphet> oh... and it handles processes.
23:03:29 <CakeProphet> YEAH.
23:03:34 <CakeProphet> (caps lock)
23:03:41 <RodgerTheGreat_> heheh
23:03:54 <oklopol> was my idea of the processes a little correct? the array thing
23:04:07 <oklopol> because imo that's all you need for bf
23:04:08 <CakeProphet> not sure.
23:04:41 <CakeProphet> It would need to be more powerful than that.
23:04:41 <RodgerTheGreat_> I think it could work
23:05:03 <oklopol> even if you do things like +++++ -> 5, if we use bignums for the tape (we could :D) there just would be one operation instead of five
23:05:25 <oklopol> because a bignum can be used an array like [inc-oper,5]
23:05:27 <CakeProphet> hmmm... and we won't be doing a traditional filesystem will we?
23:05:30 <CakeProphet> directories are teh suck.
23:05:34 <oklopol> we can
23:05:38 <RodgerTheGreat_> Def-BF provides us with facilities for creating virtual tapes from our primary tape, so it wouldn't be ridiculously hard to implement
23:05:46 <oklopol> yep
23:06:24 <oklopol> of course with non-optimized brainfuck you always know when a program will end
23:06:39 <oklopol> because the ticks of the OS are at steady intervals
23:06:42 <CakeProphet> This is partially a thought experiment as well... to explore some new OS design ideas.
23:07:08 <oklopol> but in case of a change to the optimization algorithms, it's execution time can vary
23:07:23 <oklopol> of course, different options can be set for the optimization
23:07:38 <oklopol> ^^^^^^ these are the jobs done in esolangs
23:07:43 <oklopol> the optimizers etc
23:08:00 <CakeProphet> Everything is done in an esolang. :D
23:08:10 <oklopol> CakeProphet, i'd say it's pretty fucking experimental to do a BF-OS, but whatever
23:09:05 <oklopol> it's just, i can't figure out how to do the core without a lang that understands what is inside a computer
23:09:19 <oklopol> and esolangs are usually very abstract
23:09:24 <oklopol> am i making sence?
23:09:45 <RodgerTheGreat_> yeah
23:10:02 <oklopol> good then
23:10:19 <RodgerTheGreat_> my solution to that problem relies on the idea that Def-BF isn't overly complex to translate into machinecode
23:10:28 <oklopol> true
23:10:38 <CakeProphet> We have the Def-BF-to-machinecode compiler... the kernel... interpreters for a crapload of esolangs... some sort of modular structure for organizing programs, almost like individual functions to the OS.
23:10:45 <oklopol> hey! me got idea! :D
23:11:04 <oklopol> no i didn't
23:11:09 <RodgerTheGreat_> lol
23:11:09 <oklopol> it was stupid :(
23:12:05 <oklopol> but i mean, kernel needs to do the memory allocations etc, so it doesn't help if Def-BF to <internal> is easy, we need it the other way around
23:12:14 <RodgerTheGreat_> yeah
23:12:25 <oklopol> so, how?
23:12:39 <RodgerTheGreat_> ultimately, we may be forced to use another language to build some very core parts of the OS
23:12:44 <CakeProphet> Well... our esolang interpreters probably won't fit the specification exactly... and they'll definetely communicate with the kernel quite heavily to allocate inter-connection between differing programs.
23:13:05 <RodgerTheGreat_> in general, I think we should just try to place as little reliance on these other languages as possible
23:13:27 <oklopol> you mean to non-esolangs?
23:13:40 <oklopol> if so, you're right
23:14:00 <CakeProphet> I think esolangs would work fine.
23:14:04 <CakeProphet> If you organize it right.
23:14:05 <RodgerTheGreat_> bbl- dinner
23:14:12 <oklopol> but, Def-BF is slow, so i'd recommend we don't use it for the core, but rather as the primary lang to use for programs etc
23:14:27 <CakeProphet> It's only slow if you make it slow. ;)
23:14:35 <oklopol> most other esolangs on the other hand do not slow things don't at all
23:14:49 <oklopol> CakeProphet, do you understand the concept of ordo?
23:14:57 <CakeProphet> ordo?
23:15:00 <CakeProphet> big O?
23:15:04 <oklopol> yes
23:15:08 <CakeProphet> Yeah.
23:15:16 <oklopol> good
23:15:22 <oklopol> BF has only + and -
23:15:25 <CakeProphet> but it'll only be O(n) if you make it work like that.
23:15:32 <oklopol> addition is O(logn) max
23:15:51 <oklopol> and it becomes extremely verbose done like that
23:16:10 <CakeProphet> yeah... they're just syntax instructions... with the proper optimizations you can shorten computation times greatly.
23:16:43 <CakeProphet> The commands and what they do are just visualizations... you can compress it into smaller operations.
23:17:19 <oklopol> in most cases, yes, but in that case i'd say Def-BF is already used as the main language for the actual programs, so why not use something else for internal functionality of the OS
23:18:09 <CakeProphet> hehe... we could ues a modified form of Glass. :D
23:18:42 <oklopol> in brainfuck you think something, convert it to brainfuck by doing everything the hard way, when the computer tried to get "what you meant" from the bf-code which doesn't really show the "consept" at all, it might fail
23:19:06 <oklopol> leaving you with less optimizations than you would've had doing it with another lang
23:19:40 <CakeProphet> hey... if uuu is using --Python--, which is a super-high-level language, to construct an entire OS... it can't be that slow.
23:19:42 <oklopol> i doubt there is an interpretor that can convert a division from brainfuck [a thousand chars] to c++ [a/b]
23:20:08 <CakeProphet> characters do not translate to speed.
23:20:12 <oklopol> huh? the only thing slow is BF
23:20:52 <oklopol> what i mean is, the computer doesn't understand how easy it is for it to do the division
23:20:57 <oklopol> it has it built-in
23:21:24 <CakeProphet> a/b is an abstraction for some underlying low-level bit-by-bit operation...
23:21:36 <oklopol> but instead it tries to do it the brainfuck-way, no way it can figure out what it's really doing and substitute a DIV-asm-command
23:22:02 <CakeProphet> but what does DIV do at heart?
23:22:25 <oklopol> what i mean is, bf -> machine code is of course worse code than python -> machine code
23:22:31 <oklopol> what does that matteR?
23:22:32 <oklopol> *r
23:22:41 <oklopol> it's faster than doing a division manually
23:23:00 <CakeProphet> Programmers are terrible at conceptualizing how their programs work... because they're so damn abstract.
23:23:16 <CakeProphet> it's probably not even worth the trouble of considering it.
23:23:24 <oklopol> actually might not be, but are you really saying an interpretor can make brainfuck as fast machine code that it can make python?
23:23:40 <oklopol> might not be DIV faster that doing manually i mean
23:23:50 <CakeProphet> But what's "manually"./
23:24:03 <oklopol> that's not the point
23:24:20 <CakeProphet> in BF... the operations are just very specific... it doesn't nessicarily translate to any more work for the computer.
23:24:27 <oklopol> manually = with bit shifts and bitwise logical operations
23:24:48 <oklopol> omg i want RodgerTheGreat_ here... hopefully agrees with me :\
23:25:01 <oklopol> if he says what you say, i admit defeat
23:25:19 <oklopol> (i'm not really sure what you mean, actually)
23:26:37 <CakeProphet> yeah I'm probably wrong.
23:27:11 <CakeProphet> probably more wrong than you... but being right when it comes to optimization is nigh impossible.
23:28:12 <oklopol> huh?
23:28:25 <oklopol> what do you mean by that?
23:28:50 <oklopol> it's almost impossible to optimize?
23:29:31 <oklopol> almost, but not exactly! i can show you: ++--- -> - <<< i optimized here
23:30:34 <CakeProphet> meh... alright.
23:31:51 <CakeProphet> it's possible... but if you didn't -set the situation up yourself-, and the optimization wasn't so painfully obvious... I'm saying conceptualizing optimization to a certain extent, in less specific languages than brainfuck, can be difficult.
23:33:03 <oklopol> well then, how do you tell a brainfuck program to divide two numbers by each other using a fast way?
23:33:24 <oklopol> all you can do is do it the brainfuck way, which, believe me, is very verbose
23:33:54 <oklopol> that will prolly be translated to what it was in brainfuck, only with incs instead of +'s
23:34:15 <oklopol> so instead of a fast DIV a,b, tons of incs and decs and loops
23:34:21 <CakeProphet> alright... but if your BF implementation maps directly to machine code... it will be much faster than a BF implemented in C.
23:34:48 <CakeProphet> O() is relative to the environment
23:35:04 <CakeProphet> but yeah, you're right about BF being slower.
23:35:04 <oklopol> you talking about compilation of interpretinf?
23:35:06 <oklopol> *g
23:35:28 <CakeProphet> no.. I'm just talking about language.
23:35:31 <oklopol> i'm talking about the core, so compilation
23:35:35 <oklopol> just language?
23:35:40 <oklopol> k
23:35:41 <oklopol> i'm not
23:35:47 <CakeProphet> Python is implemented in CPython, which is implemented in C... O(n) in Python will be slower than O(n) in C.
23:35:50 <oklopol> i'm talking about the programming of the core
23:36:13 <oklopol> CakeProphet, no no no no no, O(n) in python is O(n) in C
23:36:28 <oklopol> but it's ALWAYS O(nlogn) in BF
23:36:51 <oklopol> actually, no ucase on the always
23:36:59 <oklopol> + is O(1) everywhere
23:37:03 <oklopol> for example
23:37:16 <oklopol> but python is conseptually the same as C
23:37:25 <oklopol> in speed
23:37:32 <oklopol> BF on the other hand is not
23:37:38 <CakeProphet> O(n) means n * times one comptation. one computation takes longer amounts of times in different languages.
23:38:18 <CakeProphet> O() is used to describe -relative- speed.
23:38:18 <oklopol> yes, what is your point?
23:38:27 <oklopol> orly?
23:38:28 <oklopol> :D
23:38:48 <CakeProphet> my point is that O(n) in C is faster than O(n) in Python.
23:39:03 <CakeProphet> because it's relative to the speed of "one computation".
23:39:04 <oklopol> then you don't know what you're talking about
23:39:11 <oklopol> well, technically
23:39:19 <oklopol> but it's not the point with O()
23:39:43 <CakeProphet> Any benchmark between C and Python involving something with the same O time will show that C is usually the faster of the two.
23:40:06 <CakeProphet> of course... the point of O isn't to comparse like that, you're right.
23:40:12 <oklopol> good
23:40:44 <oklopol> but, in python everything is guaranteed to be the same ordo as in c
23:40:48 <oklopol> everything normal
23:40:56 <oklopol> in brainfuck it isn't
23:40:58 <CakeProphet> How?
23:41:03 <oklopol> how what?
23:41:31 <CakeProphet> I mean... how can a language implemented in some other language have operations that are the same speed in the other language?
23:41:38 <oklopol> -__________-
23:41:54 <oklopol> let's say everything is compiled, for one
23:42:15 <CakeProphet> eventually, yes.
23:42:17 <oklopol> no c running when you run your python, no python running when you run your pythong code
23:42:19 <oklopol> *python
23:42:23 <oklopol> www.pythong.org
23:42:54 <CakeProphet> ...
23:43:07 <oklopol> written that wrong 3 times now, two times trying for www.python.org
23:43:25 <oklopol> maybe i'm subconsciously gay or something
23:43:52 <oklopol> but that's a teensy bit off-topic maybe
23:44:13 <GregorR> For your enjoyment, part of why it's interesting to be me:
23:44:22 <GregorR> I was trying to decide where to go for New Years ...
23:44:28 <GregorR> So I called some friends to see where they were going ...
23:44:37 <GregorR> At least four of them were already planning to come to my abode.
23:44:41 <GregorR> And have a NY party there.
23:44:45 <oklopol> :D
23:45:16 <GregorR> I don't have to plan a New Years party, it plans itself.
23:45:22 <oklopol> quine
23:45:30 <oklopol> not really
23:51:39 <oklopol> i wanted to code the NY but i gotta go party with my friends :(
23:57:18 <CakeProphet> hmmm... what's ASM?
23:57:59 <oklopol> assembly
23:58:06 <CakeProphet> ah.
23:59:14 <CakeProphet> I think glass would be a good candidate to use. :D
23:59:20 <CakeProphet> for some stuff.
â†2006-12-29 2006-12-30 2006-12-31→ ↑2006 ↑all