00:00:00 --- log: started forth/12.03.06 00:29:02 --- quit: I440r (Ping timeout: 272 seconds) 01:06:26 --- quit: ttmrichter (Ping timeout: 246 seconds) 01:19:13 --- join: ttmrichter (~ttmrichte@61.184.206.85) joined #forth 01:19:13 --- mode: ChanServ set +v ttmrichter 01:20:51 --- join: fftw (~fastest@la-pinta.la.net.ua) joined #forth 01:20:52 --- mode: ChanServ set +v fftw 01:20:57 --- part: fftw left #forth 01:32:07 --- quit: ttmrichter (Quit: Leaving) 02:02:35 --- join: ttmrichter (~ttmrichte@61.184.205.48) joined #forth 02:02:35 --- mode: ChanServ set +v ttmrichter 04:21:16 --- quit: mtm (*.net *.split) 04:24:10 --- join: mtm (~mtm@adsl-99-48-184-49.dsl.snfc21.sbcglobal.net) joined #forth 04:24:10 --- mode: kornbluth.freenode.net set +v mtm 05:22:31 --- join: Kumul (~Kumul@67.224.128.143) joined #forth 05:22:31 --- mode: ChanServ set +v Kumul 06:29:52 --- join: nighty^ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 06:29:52 --- mode: ChanServ set +v nighty^ 06:30:11 --- quit: Kumul (Quit: gone) 08:38:57 --- join: Kumul (~Kumul@67.224.128.143) joined #forth 08:38:58 --- mode: ChanServ set +v Kumul 09:14:34 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 09:14:34 --- mode: ChanServ set +v MayDaniel 09:16:39 --- quit: MayDaniel (Read error: Connection reset by peer) 11:51:23 --- join: MayDaniel (~MayDaniel@unaffiliated/maydaniel) joined #forth 11:51:23 --- mode: ChanServ set +v MayDaniel 12:23:22 --- quit: MayDaniel () 12:49:47 --- join: mark4 (~mark4@24-183-5-217.dhcp.fdul.wi.charter.com) joined #forth 12:49:47 --- mode: ChanServ set +v mark4 13:19:15 --- quit: Kumul (Quit: gone) 13:42:02 --- quit: nighty^ (Ping timeout: 260 seconds) 13:58:02 --- join: nighty^ (~nighty@static-68-179-124-161.ptr.terago.net) joined #forth 13:58:02 --- mode: ChanServ set +v nighty^ 14:20:00 --- quit: DocPlatypus (Ping timeout: 240 seconds) 14:25:23 --- join: tschak__ (~tschak@vpn.touchtunes.com) joined #forth 14:25:23 --- mode: ChanServ set +v tschak__ 14:26:05 Is there a good paper/discussion on when to use the return stacks (a la >R R>, etc...) 14:52:01 I don't regard the return stack operators as "separate" from the data stack operators. All of them, collectively, are used to move data around in a way that makes it convenient and efficient to work on. >R, R@, and R> just get used "when it's right to use them." 14:52:31 I know that's a sucky answer, given your question, but I think you should think of stack manipulation as a holistic thing, not as disparate classes of operations. 14:54:05 The difference between return stack operators and data stack operators is that when you put something on the return stack with >R you have to explicitly get it back, whereas when you move something momentarily out of your way with, say, SWAP it's likely to show up on the top of the stack again on its own at some point. 14:54:25 In that sense >R is a bit more "persistent." 14:56:39 I think of the data stack operators like DUP, SWAP, OVER, etc. as offering more "fortuitous" effects (with good planning things show up when they're needed with no further work), whereas the return stack operators are more "manual" (when you want something back you go get it, and until then it's out of your way). 14:56:44 Does that help at all? 15:11:42 --- join: DocPlatypus (~skquinn@108-75-59-67.lightspeed.hstntx.sbcglobal.net) joined #forth 15:11:43 --- mode: ChanServ set +v DocPlatypus 15:59:51 --- join: Kumul (~Kumul@67.224.128.143) joined #forth 15:59:51 --- mode: ChanServ set +v Kumul 16:15:32 --- join: MrBusiness (~MrBusines@184.99.7.19) joined #forth 16:15:32 --- mode: ChanServ set +v MrBusiness 16:59:38 yeah, I just need to mess with it more. 17:00:00 I'm actually funny enough, using an old fig-FORTH to write a game demo and its associated tools for an Atari 8-bit 17:01:59 I try not to use the return stack, unless I absolutely have to, (mostly because of needing to keep track of when I push and pop things on and off) 17:33:47 --- quit: nighty^ (Ping timeout: 246 seconds) 18:56:38 --- quit: Snoopy_1611 (Ping timeout: 244 seconds) 19:30:02 --- join: tschak_ (~tschak@pool-96-226-11-78.dllstx.fios.verizon.net) joined #forth 19:30:02 --- mode: ChanServ set +v tschak_ 19:31:31 --- join: tschak (~tschak@pool-96-226-11-78.dllstx.fios.verizon.net) joined #forth 19:31:31 --- mode: ChanServ set +v tschak 19:32:37 --- quit: tschak__ (Ping timeout: 260 seconds) 19:34:56 --- quit: tschak_ (Ping timeout: 276 seconds) 20:10:12 --- quit: Kumul (Quit: gone) 20:55:16 tschak: Sometimes the return stack comes in just dandy handy, though... 20:55:31 yeah 21:01:38 I guess I kind of think that cleaning the return stack should be easy - after all, if you're not going to need that piece of data later, why would you push it over there to begin with? 21:03:27 makes sense. 21:08:49 Sort of like balancing parentheses in other languages. 21:09:44 But you are right in the sense that most compilers don't check for balanced return stack management. You're "on your own." 21:10:33 especially forth79 ala fig-forth heheheh 21:10:49 (yes, believe it or not, there IS a reason I am using this particular dialect) 21:10:59 :-) I'm a fan of those older Forths, actually. 21:11:16 I feel they're closer to the simple elegance of the concept than some of the newer stuff. 21:11:31 it is a classical fig forth, that means that it is all self contained, disk blocks and screens map 1 to 1, and when i save the environment, BAM, it's a bootable disk 21:11:34 ready to go 21:11:44 i just need to figure out where to patch ABORT so I can turnkey words 21:11:47 I spend a lot of time thinking about hardware implementations of Forth (FPGAs) - so simplicity and elegance is very important. 21:12:20 ahhh ok, i gather you watch Chuck Moore's fireside chats? ;) 21:12:32 honestly, I had heard about FORTH for almost 30 years 21:12:48 I am much more concerned with the lower levels - the inner interpreter and how it can be cast into hardware - than with things like blocks vs. files and so on. 21:12:57 and I finally decided to jump in and try it.. honestly, I am very impressed with the environment 21:13:02 I discovered it in college, back in the early 80's. 21:13:30 I used an HP calculator (41CV), so when I ran across this stack-based programming language I was immediately hooked. 21:13:48 Little did I know then that Forth's special magic goes way beyond mere RPN. 21:13:51 once i get used to the mundane tasks, I already understand that I can write not only the solution to a problem, but all the tools to solve that problem, in less time than most C programmers take shoehorning the the problem into the toolkit of choice. 21:14:24 Do you own a copy of "Thinking Forth"? 21:14:35 I um... "borrowed" a copy. ;) 21:14:42 Close enough. 21:14:46 It's very good. 21:15:05 yeah 21:15:07 Also "Forth Fundamentals" volumes 1 and 2 would be of interest to you. 21:15:11 iok. 21:15:24 basically, I am working on a graphic demo idea that i've had in my head for many years 21:15:45 Volume 1 lays out the "fundamentals" of the Fig-style engine, and Volume 2 gives you the definitions of the higher levels words, expressed in Forth using lower level words. 21:16:07 where Conway's game of life, is running and animating on a perspective flat ground, with a man walking above it, with a sky, with sun/moon, slowly changing, and an algorithmic melody track. 21:16:14 okay. 21:16:40 Those are pretty much strictly related to a "indirect threading" model, though, and some of the newer stuff (and all of my FPGA stuff) is closer to "direct threading". 21:16:52 yeah, so i've heard 21:18:52 i just wish i could convince my fellow colleagues about FORTH... they think i'm mental. 21:19:18 (but then again, I've got 40 or so language rattling in my head, I actually do daily work in Erlang...) 21:19:25 Forth is really the right idea. 21:19:30 yeah 21:19:45 the whole design of the interpreter etc, is so bloody tiny and elegant. 21:20:09 very little time wasted 21:20:22 The languages that have "caught on" are all about being able to deploy thousands, or tens of thousands, or whatever, programmers toward a task and having it inch toward realization regardless of the price paid re: complexity and overhead. 21:20:36 Forth is about getting it *right*. 21:20:54 I just really don't want to be one of thousands or tens of thousands. 21:22:12 me neither 21:24:11 people think forth is a write only language...but for me... I _MAKE_ myself build things small, and try to build high level words that make sense. 21:24:33 That's the only way to do it - think it through and get it right. 21:24:40 When it's "right" you know itl. 21:25:27 yes 21:25:31 and the best part 21:25:34 it's all UNIT TESTED 21:25:46 jesus christ, people talk about UNIT TESTING now... 21:25:52 it's natural in forth. 21:25:56 /buffer 8 21:26:01 :-| sorry 21:39:36 --- quit: ttmrichter (Quit: Leaving) 21:58:41 JFYI, in classical fig-FORTH disk blocks don't map to screens one to one. 21:58:44 See B/BUF 22:00:18 Also, it was pure rubbish the way it was implemented. 22:00:31 You could write all words as if it were one single line, 22:00:41 but not cross real buffer positions. 22:01:02 ok 22:01:26 Not to mention other "smart" solutions (like ENCLOSE). 22:01:35 how am i supposed to patch words to point to different words? a la patching abort, quit, etc for turnkey stuff? 22:02:08 In a system specific way. 22:06:12 In fact, the whole buffer/block/screen subsystem is rubbish. 22:06:23 The way it is designed in language is plain broken. 22:06:51 System can replace buffer under your feet without you noticing it. 22:08:41 this is why I don't use blocks 22:08:56 one of many reasons... I think blocks are a bit antiquated, and those who write the ANS spec seem to agree 22:09:20 The only way to use them is to replace the whole implementation with a saner one, 22:09:23 which doesn't pay off. 22:09:38 and yes, I drank a lot of the ANS Kool-Aid... granted, they did a few dumb things, but overall the ANS standard and its successors are more good than harm. 22:10:08 It is more 50/50 these days. 22:11:49 if I had to make my own Forth from scratch, I'd make it ANS compliant 22:13:20 It depends on what you call "ANS compliant". 22:21:58 * tschak honestly could care less. 22:22:17 no implementation of anything is perfect 22:22:45 always quirks to work around. 22:24:30 Not being perfect doesn't entail using quirks. 22:25:08 The latter is usual to Forth programmers but not to some others. 22:26:31 while I appreciate the pedantism, it is superfluous for me. 22:47:20 --- join: ttmrichter (~ttmrichte@61.184.206.85) joined #forth 22:47:21 --- mode: ChanServ set +v ttmrichter 23:59:59 --- log: ended forth/12.03.06