00:00:00 --- log: started retro/12.09.30
01:18:32 <tangentstorm> docl : thanks! i'm still arguing with that guy in my head, months later :)
06:56:44 <docl> :)
08:38:49 --- join: kumul (~kumul@adsl-72-50-90-224.prtc.net) joined #retro
08:43:41 <crc> revision 364 has the new words: functions and also shows function names in 'explore'
08:43:48 <docl> sweet
09:39:38 --- quit: clog (^C)
09:39:38 --- log: stopped retro/12.09.30
09:40:07 --- log: started retro/12.09.30
09:40:07 --- join: clog (~nef@bespin.org) joined #retro
09:40:07 --- topic: 'Retro Language | http://retroforth.org | Logged @ http://rx-core.org/dev/rancid | Latest Release @ http://s3.retroforth.org/download/11.x/retro-11.4.tar.gz'
09:40:07 --- topic: set by crc on [Tue Jul 17 13:54:58 2012]
09:40:07 --- names: list (clog kumul tangentstorm @ChanServ SimonRC karswell_ ivan`` docl yiyus oPless saper @crc)
10:11:56 --- join: erider (~chatzilla@unaffiliated/erider) joined #retro
10:14:56 <crc> hi erider
11:07:18 <docl> tangentstorm: that guy seemed to miss your point. but he was kind of right that you were abusing the word "concurrent" to include paging stuff that is actually sequential
11:08:06 <docl> tangentstorm: on the other hand the point you were going for was that OO is compatible with concurrency, i.e. works just fine in concurrent environments almost by definition
11:08:56 <docl> at least if you do it right. I'm still a little confused about how modern languages pseudo-OO works against that.
11:11:19 <docl> rereading
11:15:05 <tangentstorm> hey all
11:15:44 <docl> hi tangentstorm 
11:16:38 <tangentstorm> docl: i guess the point i was trying to make is that objects are inherently concurrent... like conceptually, they're separate machines that share no state whatsoever, communicating only through message passing
11:17:51 <tangentstorm> systems like erlang or unix qualify as objects to me because they treat programs that way
11:18:12 <tangentstorm> the fact that they may be implemented under the hood by one master process switching back and forth is just an implementation detail\
11:18:28 <docl> conceptually concurrent yeah, but you want to avoid seeming to say that automagically makes them work on real hardware
11:18:39 <tangentstorm> well it does
11:18:52 <tangentstorm> but the objects everybody is used to don't work that way
11:18:58 <docl> no locks and threads?
11:19:22 <docl> or is the locking and stuff basically happening in a hidden way
11:19:35 * docl has the barest grasp on this
11:19:51 <tangentstorm> you don't really need locking because there's no shared state :)
11:20:28 <docl> hmm. trying to picture how that works.
11:20:36 <tangentstorm> you and i are communicating via messages right now... we could collaborate on a project, and we wouldn't need locking
11:21:02 <docl> take an sql database for example. you get 2 write messages. one has to happen before the other.
11:21:42 <tangentstorm> even file locking in older version control systems is kind of a byproduct of using giant text files
11:22:11 * docl always kinda suspected locking is a case of doing it wrong.
11:23:15 <tangentstorm> well, okay... there probably are all kinds of places where you do need some kind of locking mechanism, but i don't know what they are :)
11:24:14 <tangentstorm> what i was saying about languages like java not really doing OO the way it was intended has to do with the fact that instead of message passing, you use function calls
11:25:09 <docl> interesting. what distinguishes the two?
11:25:17 <tangentstorm> the way most languages work today, methods are just functions / subroutines in some other namespace, and the caller blocks until the subroutine finishes and returns the result
11:25:37 <docl> should methods be something more generic? like a quote maybe?
11:26:03 <tangentstorm> in erlang, you just send messages and get messages. there is never any waiting for the result from another node. 
11:26:43 <tangentstorm> ... were you the one talking about monads the other day? I have no idea how to scroll back in my irc client :)
11:26:52 <docl> yeah that was me
11:27:13 <tangentstorm> yeah.. well i was saying the compiler state was a bit like a monad in forth.
11:27:21 <docl> also was babbling about yield and generators, which I have the barest grasp of as well.
11:27:22 <tangentstorm> but i forgot about retro's class handlers
11:27:53 <tangentstorm> class handlers... i don't think that's the rigth word... lemme find the docs
11:27:59 <docl> yeah class handlers kind of get in there and change the word around in terms of what it does
11:28:11 <docl> like .word .macro .data
11:28:22 <tangentstorm> yeah that's what i mean
11:28:37 <tangentstorm> i'm thinking that's where you'd implement monads in retro
11:28:43 <docl> .word executes it, unless compiler state is true then it compiles it
11:29:29 <docl> .data shoves it on the stack, unless compiling in which case it compiles with a "literal" machine code
11:29:55 <tangentstorm> a monad's basically just a function that expects a certain kind of package, does something with the data inside, and then puts the result back in the exact same kind of package.
11:30:15 <tangentstorm> forth itself is a monad that uses a stack as the packaging type
11:30:39 <docl> takes a message, supplies a message
11:31:21 <tangentstorm> so imagine that you have a process that you want to do over and over again... like raytracing all the pixels in a 3d scene.... or some kind of big map-reducy program like a google search
11:32:31 <tangentstorm> you could have a big loop through all the pixels, but you could also just have one computer per pixel
11:32:59 <docl> cause it's not dependent on the output of the others?
11:33:09 <tangentstorm> let's say that in order to render one pixel, you have to do steps a, b, c, and d.
11:33:56 <tangentstorm> in java you do :   pixel render( x, y : int ) { a(); b(); c(); d(); return this.pixel }  or something.
11:34:28 <tangentstorm> err... return this.rgb probably, since pixel is a type there :)
11:34:34 <docl> that kinda code just does not make sense to me
11:35:23 <tangentstorm> in forth you would write:    : render ( xy-c ) ( c meaning "color" ) a b c d ;
11:35:42 <docl> right
11:35:55 <tangentstorm> but there's a huge huge difference here
11:36:14 <docl> and a, b, c, and d would all be like ( xy-xy ) except d would be (xy-c) maybe
11:36:21 <tangentstorm> yes
11:36:31 <docl> or you'd initialize a variable and have them each use the same variable
11:36:38 <tangentstorm> in a real monad, they'd all be xy-xy
11:36:55 <tangentstorm> well okay let's call it the RAY monad
11:37:00 <tangentstorm> they'd all be of type ray
11:38:29 <tangentstorm> so  : render ( rxy-rc ) ( points and colors in the ray monad ) a b c d ; 
11:39:10 <tangentstorm> maybe you stick the r on top, and shuffle it to the return stack and back each time...
11:39:35 <docl> so a b c and d are all handled by the .ray class?
11:39:37 <tangentstorm> anyway "ray" is the box and it contains all the info about the scene that you're rendering... or at least the parts needed for the raycasting pipeline
11:40:17 <tangentstorm> hrm
11:40:25 <tangentstorm> how about this
11:41:24 --- quit: kumul (Quit: WeeChat 0.3.8)
11:41:27 <tangentstorm> so  : render ( xyr-cr ) ( points and colors in the ray monad ) (( a b c d  )) ; 
11:41:36 <tangentstorm> where (( and )) are like the "do" block in haskell
11:41:52 <tangentstorm> they'd be immediate words that change the behavior of the compiler
11:42:21 <tangentstorm> and i guess since retro doesn't have a type system you'd have to also tell it about the ray monad
11:42:22 <docl> ok
11:42:26 <tangentstorm> okay.. let me back up then :)
11:42:54 <docl> you could probably use [[ a b c d ]] in that case I think, as long as they are defined right beforehand.
11:43:40 <tangentstorm> the basic idea about monads is that you're separating the box-handling from the handling of what's in the boxes
11:44:17 <tangentstorm> so if you stick something into tho UPS monad you can move it around the country, no matter what it actually is 
11:44:23 <docl> those switch the compiler off and on without compiling in an exit. or you could accomplish the same thing by making the words type .macro
11:44:25 <tangentstorm> the whole world basically
11:45:00 <tangentstorm> well what they'd need to do is inside of there, you need an extra parameter that says which box-handler you're using
11:45:07 <tangentstorm> UPS, Fedex, snailmail, etc.
11:45:38 <tangentstorm> in this case, it would be a container called "ray"
11:45:48 <docl> ok
11:46:46 <tangentstorm> okay, so... this isn't the world's greatest metaphor, but... the forth data stack is the box, and the forth address stack is the label
11:46:49 <docl> "ray" is a function at this point? a block of code?
11:47:28 <tangentstorm> i'm not sure.
11:47:41 <docl> block of memory to be written to?
11:47:47 <docl> could be both
11:47:49 <tangentstorm> it's just a marker that says what monad you're in
11:47:55 <docl> ok
11:48:20 <tangentstorm> see... like.... lemme show you a question i aksed on stackoverflow, because the guy that answered it kind of blew my mind about monads
11:48:43 <tangentstorm> http://stackoverflow.com/questions/7024248/monads-at-the-prompt
11:49:27 <tangentstorm> it's the one at the bottom with 10 upvotes that i was thinking of
11:51:05 <tangentstorm> honestly, i don't understand exactly what he's saying even now, but the gist of it is that   "do" and ">>>" and "return" ... they work with  IO, Maybe, [], State ... pretty much anything
11:52:16 <tangentstorm> well.. my metaphor sucks because a monad really is both the different kinds of package and a different "postal worker" for each kind of package
11:52:55 <docl> hmm. so when you say these a b c d funcs are in the ray monad, what does that imply?
11:53:07 <tangentstorm> if you execute   do { a; b; c; d; return rgb }  in haskell, the type would be...
11:53:41 <tangentstorm> :: (Monad m)=> m a -> m b 
11:53:43 <tangentstorm> pretty sure.
11:53:51 <tangentstorm> not 100% sure, but i think that's right.
11:54:22 <docl> it's like a tag?
11:54:57 <tangentstorm> return takes a value  and packs it back into whatever monad you're talking about
11:55:12 <docl> "return to box"
11:55:27 <tangentstorm> do { } is syntactic sugar for the real thing, which is something like this : ( it's been a while )
11:56:36 <tangentstorm> a >>= \x b x >>= \y c y >>= \z dz >> \rgb rewrap rgb
11:57:06 <tangentstorm> where x, y, and z are values of some arbitrary type we don't need to know about 
11:57:22 <tangentstorm> but in retroforth, their types would match the stack comments for a, b, c, and d
11:57:51 <tangentstorm> so the (( )) would be macros that do this transformation
11:58:06 <tangentstorm> ( \x  b x  ) is lambda x : b(x) in python, btw
11:59:22 <tangentstorm> and >>= is "put the result in a box, ship it to the next thing in the chain" ... where the next thing is a lambda that takes a box with something in it 
12:00:46 <tangentstorm> the trick is that each monad has its own version of " >>= "
12:01:16 <tangentstorm> or at least its own verson of "wrap" and "unwrap", which >>= uses
12:01:20 <tangentstorm> no
12:01:36 <tangentstorm> >>= unwraps    return wraps     sorry :)
12:02:28 <tangentstorm> okay. so how about this:  the monad is   both a special size / color of box, and special handling instructions for putting things into, taking things out of, and transporting those kinds of boxes.
12:03:19 <tangentstorm> so do {{ }} is like the guy in the mail room, that knows whether to send a particular box through ups, fedex, local courier, etc.
12:03:52 <tangentstorm> do { }  in haskell and my  (( )) concept here
12:04:59 <tangentstorm> but: in retroforth, there already is one and only one kind of box, and it always contains two stacks and a dictionary
12:06:30 <tangentstorm> maybe "image" is the better word... it's really the mutable variables that are important, and i'm not sure if they're really in "the dictionary"
12:07:25 <tangentstorm> anyway... so all that means is that everything is already running inside the "Retro" monad
12:09:20 <tangentstorm> but monads can take parameters... which means they can be nested... like, the list monad can contain submonads, like this::  [ Maybe [ Either ( Maybe int ) ( String )]]
12:10:17 <tangentstorm> each do { }  only cares about the topmost, outer layer ... so in this case   do { }   would be in the list monad, which is basically foreach() 
12:11:22 <docl> hmm. we have code that steps through a list. like "words"
12:12:12 <tangentstorm> and if you wrote a retro interpreter in haskell, you'd write a Retro monad that would basically be a retro interpreter.
12:12:47 <docl> should I be thinking "monad = separate sub-program"?
12:13:00 <tangentstorm> like you would say do { push; no_op; inc; divmod }   .... and all of those things would be functions of type    Retro a -> Retro b
12:13:30 <tangentstorm> monad is a stupid word :)
12:13:35 <docl> :)
12:13:43 <tangentstorm> it doesn't correspond to any one thing in the physical world
12:14:03 <docl> except 'burrito' :)
12:14:21 <tangentstorm> it's a   tag, like you said, along with instructions to pack, unpack, and transport.
12:14:57 <tangentstorm> so for [] ( the list monad ) ... the   packing operator is called cons, the unpacking operator is called head or car, and the "transport" is called foreach
12:14:59 <docl> 'tag with associated behaviors that are consistent with the types of things we are doing stuff with'
12:15:33 <tangentstorm> yeah
12:15:42 <tangentstorm> or you could think of it as an object with 3 methods
12:15:59 <tangentstorm> or rather... it's an interface that consists of 3 methods, which any object can implement
12:16:12 <docl> pack, unpack, transport?
12:16:16 <tangentstorm> yes
12:16:51 <tangentstorm> let's call it handle
12:17:02 <tangentstorm> hrm
12:17:04 <tangentstorm> yeah
12:17:30 <docl> pack, unpack, handle??
12:17:46 <tangentstorm> because there may be special instructions not just for UPS, but for everyone that touches the box in the assembly line, etc...
12:17:50 <tangentstorm> yes
12:17:54 <docl> ok
12:17:57 <docl> that makes sense
12:18:15 <docl> list is super basic, I can generalize from that
12:18:19 <tangentstorm> but not like "if your name is fred then do this.."
12:18:32 <tangentstorm> they're universal handling instructions like
12:18:39 <tangentstorm> "this thing is radioactive"
12:18:51 <tangentstorm> which is basically what the IO monad is
12:19:02 <docl> :)
12:19:11 <docl> user danger
12:19:26 <tangentstorm> "this code is potentially unsafe.. so if you don't have a hazmat suit, you mustn't touch it"
12:20:47 <tangentstorm> IO is special because... you as a programmer are "inside" the IO monad and thus have no way to access "unpack"
12:21:09 <tangentstorm> which is what prevents you from passing IO values into purely functional code
12:21:21 <tangentstorm> okay... so that's monads
12:22:41 <tangentstorm> now... here's the thing... since forth words already have the single container type.... we have some flexibility
12:23:06 <tangentstorm> we could chose to use one retro interpreter that executes a, b, c, d   in sequence
12:23:52 <docl> hmmmm. like a saved copy of retroImage?
12:25:34 <tangentstorm> or we could have one retro interpreter each running a loop that looked like this:    : main ( - ) begin readstate a dumpstate repeat ; 
12:25:53 <tangentstorm> and others that did the same for   b , c and d 
12:26:07 <tangentstorm> and then chain those together with unix pipes
12:26:10 <tangentstorm> or telnet
12:26:16 <tangentstorm> or carrier pigeons
12:26:59 <docl> :)
12:27:04 <tangentstorm> that's message passing ... 
12:27:59 <tangentstorm> now that i think about it, dumpstate probably doesn't even need the return stack.. and the only variables that need to be in there are the scene data for the pixel we're rendering
12:28:04 <docl> currently reading your blog post btw
12:28:28 <tangentstorm> yeah.. it's like 22 pages.. i tend to ramble a bit :D
12:28:31 <docl> yeah, you would want to restrict to relevant data
12:28:39 <docl> the state I mean :P
12:28:50 <tangentstorm> well, yeah.. but also... you don't really need to return
12:29:07 <tangentstorm> if i send you a message, you can reply or not
12:29:13 <docl> true
12:29:49 <tangentstorm> if we're in an assembly line, i can pass you the thing i'm working on, and you don't need to come back after each one and tell me it's done
12:29:58 <tangentstorm> i'm not your boss, i'm just the guy next to you in the chain
12:30:13 <tangentstorm> but in java, i'm your boss
12:30:47 <tangentstorm> and once i pass the widget to you, you do your thing, and pass it to the next guy... and then it has to get passed back the chain to me, and then i pass it to the guy on the other side of me
12:30:57 <tangentstorm> and then he does the next step and passes it down some other chain
12:31:05 <docl> yeah. I hate that mentality in programming. like the crazy programs in windows that demand full admin privileges.
12:31:25 <tangentstorm> because in java, you're not really passing a message, you're invoking a function.
12:31:32 <tangentstorm> :)
12:32:29 <tangentstorm> so in java's version of OO, there's only one widget being worked on at a time in the entire factory... unless we use threads adn then sometimes you wind up with 2 widgets at once or whatever
12:33:07 <docl> woah that's crazy
12:33:11 <tangentstorm> in a real object oriented system, there's one widget active for each person 
12:33:28 <tangentstorm> and ideally you find the slowest guy and everybody moves at his pace
12:33:57 <tangentstorm> so that's the difference between real object oriented programming and what java does
12:34:41 <docl> we should totally aim to replace java :)
12:34:42 <tangentstorm> what i was going to say about monads is that because retroforth has the return stack and it has the "class word" concept...
12:35:14 <tangentstorm> you could have a thing that said "OKAY! THE POINTY HAIRED BOSS IS COMING! EVERYBODY KICK IT JAVA STYLE!"
12:35:53 <tangentstorm> then later: "whew, he's gone!... let's do it the other way"
12:36:32 <docl> :)
12:36:40 <tangentstorm> i'm being unfair to java though
12:37:08 <tangentstorm> say step b is slow
12:37:17 <tangentstorm> you can hire 10 b guys
12:37:57 <tangentstorm> ... well...
12:38:01 <tangentstorm> hrm
12:39:26 <tangentstorm> okay... some idiot in department B left the door open and everyone in the factory died of radiation poisoning from the IO monad
12:39:30 <tangentstorm> you're the only one left
12:39:48 <tangentstorm> guess what? you put on your hazmat suit, and you follow the java rules, because there's only one of you.
12:40:23 <tangentstorm> so the widget flows through the same stations ... but because you're carrying it back and forth
12:40:41 <tangentstorm> those rules make perfect sense when there's only one worker in the factory.
12:41:32 <tangentstorm> and that pointy haired boss started this whole place on his own and that's how he did it and became a millionaire, so obviously that's how it ought to be done now, right?
12:42:37 <tangentstorm> no.. as an entrepreneur, he had an inherrently concurrent process, but he treated it as a sequential one because of a resource constraint.
12:45:13 <tangentstorm> so basically java is a smart entreprenuer that struck it rich in the widget business which later got bogged down in bureaucracy because he couldn't let go of the past, and would have failed long ago if there weren't so many smart guys on the line compensating for him.
12:45:18 <tangentstorm> the end.
12:46:21 <docl> lol
12:47:44 <tangentstorm> no.. i skipped over the point i was trying to make :)
12:48:21 <tangentstorm> SOME processes are inherently concurrent but are implemented sequentially due to a resource constraint like having only one thread of execution.
12:49:02 <tangentstorm> but there are other processes that are inherently sequential... like, say, generating the mandelbrot set
12:49:38 <tangentstorm> we can dedicate one worker or team to each pixel on the display
12:50:47 <tangentstorm> that's inherently concurrent, because the mandelbrot set is just the set of all coordinates ( imaginary numbers ) that have a particular boolean property.
12:51:17 <tangentstorm> so if you have an infinite number of computers, you can test the entire set of imaginary numbers at once
12:51:29 <docl> right
12:51:39 <docl> or generating bitcoin hashes
12:51:40 <tangentstorm> but : the test itself is iterative...
12:51:44 <tangentstorm> yes
12:51:59 <tangentstorm> same thing with bitcoin.. you have to do the hash function, and it takes time
12:52:10 <tangentstorm> and you can't just take all the steps and do them at once
12:52:15 <tangentstorm> because they depend on each other
12:52:32 <tangentstorm> you may be the world's best adder, but if i say what's two plus...
12:52:39 <tangentstorm> you have no idea until i finish the sentence.
12:52:57 <tangentstorm> so that's inherently sequential
12:53:39 <tangentstorm> and for that there's no point hiring one guy for each step... you do it the way old man java did... one guy doing one step at a time
12:53:59 <tangentstorm> so... 
12:54:21 <tangentstorm> you don't REALLY want to just yell out "everybody switch from sequential to parallel processing"
12:54:50 <tangentstorm> you want to say "you guys over here can be in parallel" ... "you guys over here need to use the return stack"
12:55:28 <tangentstorm> but always remember that one guy alone can do the work of any parallel team.
12:55:54 <tangentstorm> so.. if you make a "parallel" class in retroforth... 
12:56:09 <tangentstorm> it can choose at runtime to distribute the work to other retroforths, or do it all in one node
12:56:22 <tangentstorm> based on available resources
12:56:29 <docl> with bitcoin mining, the goal is to generate lots of hashes as quickly as possible. so they use parallel processing for that a lot.
12:57:58 <tangentstorm> yeah :) i've never really done any bitcoin mining, but i've studied the problem because it's a good test case for this stuff. (and also i was hoping to get rich!)
12:58:05 <docl> but obviously each of those processes has a certain indivisible complexity that has to be done sequentially
12:59:00 <tangentstorm> yes... the hash function has a lot of "waiting for the results from the other guy"
12:59:10 <docl> gtg
12:59:24 <docl> I'll be back later to read the logs :)
13:00:53 <tangentstorm> haha.. i think i'm done... :) the point was just that you can use the "parallel" class as a monad... and then update the class handlers to account for which monad is active
13:01:31 <tangentstorm> <something like that>
13:01:38 <tangentstorm> later
13:50:29 --- join: arescorpio (~arescorpi@222-206-17-190.fibertel.com.ar) joined #retro
16:21:45 <docl> tangentstorm: maybe I could visualize it better if I had a working example in front of me.
16:22:09 <erider> hi a
16:24:34 <docl> hi erider 
16:24:40 <crc> good evening
16:25:07 * crc is starting to think about exporting parable code into C or Python
16:25:32 * docl is still reading http://b4lang.blogspot.com/2012/09/sprawl-or-oberon-forth-and-stackwise.html by tangentstorm.
16:25:51 <docl> I remember ZZT and Commander Keen :)
16:25:56 <erider> hi guys 
16:27:13 <crc> Commander Keen was the first computer game I played...
16:27:42 <docl> does it work on freedos, I wonder?
16:27:43 <tangentstorm> commander keen's probably all grown up now and still wearing that helmet.
16:28:03 <docl> I was disappointed he never saved the universe.
16:28:29 <docl> Apparently he got shot in a secret level of Doom or some such.
16:28:39 <tangentstorm> well... we're still here so maybe he did... maybe he just did.
16:28:42 <crc> docl: it should. it works under dosbox (I've used that to run it on os x and windows machines)
16:34:26 <crc> docl: there was a part of doom where you could kill keen: http://images.wikia.com/doom/images/d/dc/Map32_commander_keen.png
16:36:33 <tangentstorm> aww :(
17:05:33 --- join: kumul (~kumul@adsl-72-50-90-224.prtc.net) joined #retro
17:31:39 <tangentstorm> i've been thinking about the bootstrapping process some more. the way the metacompiler works now, there's a dependency where you have to have an image to get an image
17:33:43 <tangentstorm> but it's possible that the words are arranged such that if you have the tools for building the dictionary entries ( the meta compiler, i guess )... then you could do the whole thing from ngaro assembly language
17:36:15 <tangentstorm> there's a point where the system becomes self sufficient and each newly defined word can only be defined in terms of previous words.
17:37:05 <crc> originally the initial kernel was written in assembler using an assembler written in toka (which erider is fond of)
17:37:09 <tangentstorm> but i'm confused about whether that point is the first entry or if there is a little bit at the start where the earliest words are defined in terms of later words.
17:37:28 <erider> :) 
17:38:54 <tangentstorm> if there's a tangle up front, i'd like to untangle it. once there isn't a tangle, i want to rewrite the metacompiler in machine code.
17:39:27 <tangentstorm> or just write an implementation in machine code.. i wouldn't necessarily advocate that you actually use the code :)
17:41:28 <crc> the problem is that I assumed that a full retro would be used to build a new one, so I used a lot of the later features
17:41:56 <tangentstorm> yeah
17:41:58 <crc> (parable avoids this, mostly, since the parser is part of the vm, and only [ ] and define are needed to build the rest)
17:42:37 <crc> this is something that needs to be dealt with for retro12 (someday...)
17:43:07 <tangentstorm> but... when you say you use the later features... do you use them in the metacompiler itself, or in the definitions?
17:44:26 <tangentstorm> i think i ought to be able to answer this myself by looking at the meta.rx file but i get confused not knowing the class of each word
17:44:27 <crc> both. I know that prefixes are used in the definitions (for handling the initial strings for the dictionary and such)
17:45:10 <tangentstorm> yeah but prefixes execute at compile time, right?
17:45:35 <tangentstorm> they're just macros that expand to something else in the actual definition that gets written to the image... (?)
17:45:42 <crc> prefixes are essentially a class handler, they execute interactively or at compile time
17:46:32 <crc> e.g., __" is used for building strings. if compiling, it'll embed the string, compiling a jump and such around it, or if interpreting, leaving it in the rotating string buffer
17:46:46 <crc> IIRC, this is the only prefix needed by the kernel at this point
17:47:45 <crc> meta-alt.rx has the start of a metacompiler code using only the kernel-provided functions
17:48:18 <tangentstorm> the test for whether it's tangled or not is this:  does there exist a word anywhere in the dictionary such that the *compiled* definition has an implicit call instruction referring to a word with an address later on in memory.
17:49:02 <tangentstorm> argh.... gotta go. bbl. :/
17:49:10 <crc> ttyl
18:04:54 <docl> https://gist.github.com/3808899
18:14:46 <docl> cleaned up a bit
18:15:23 <docl> doesn't save the stack or anything, but does save where at in the function you were when you hit the yield.
18:15:54 <docl> not sure if it's useful or not though.
18:25:18 <docl> works with : foo   ( - ) 10 repeat dup putn yield 1- 0; again ;
18:32:51 <crc> docl: interesting
18:33:40 <crc> i'll take a closer look at this tomorrow
18:33:49 <docl> :)
18:35:09 <docl> hmm. the stack diagram is now confusing because it leaves the counter on the stack until it hits 0.
18:37:54 <docl> on the other hand, conceptually, it hasn't stopped running until then.
18:39:00 <crc> true
18:42:11 <docl> that might be a use for a class handler, to track the stack before it starts so yield can compile in code to grab anything from the stack when it exits / add it back in when it resumes.
18:43:03 <docl> do we have a way to save the stack state / restore it?
18:44:33 <docl> alternately we could just change the stack diagram to reflect what it might do, ( - || -n )
18:45:19 <crc> at this point there is no way to save/restore stacks
18:48:06 <crc> I could probably come up with something, but it would be wasteful in terms of space and cycles
18:49:53 <docl> yeah
18:56:58 <docl> otoh : foo   ( n-n ) repeat dup putn yield 1+ again ; is valid
18:58:16 <docl> that may be more the expected format for a generator anyway
20:39:00 --- quit: arescorpio (Quit: Leaving.)
21:51:34 --- quit: kumul (Quit: WeeChat 0.3.8)
23:59:59 --- log: ended retro/12.09.30