00:00:00 --- log: started forth/06.03.25 00:40:08 what is a good philosophy for a piece of code? running under every condition or running even in worse conditions? 00:44:13 eh? 00:45:03 I'd say: solving the percieved problemlem in a simple and legible way. 00:45:31 having problemlems thinking straight 00:45:33 it's late 00:46:55 --- quit: JasonWoof ("off to bed") 05:03:42 --- join: oldman (n=nobody@lsi-01.bit.uni-bonn.de) joined #forth 05:11:47 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:12:39 --- join: PoppaVic (n=pete@0-1pool64-224.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:25:52 PoppaVic, xell.forthworks.com/blog what do you think? 05:28:41 Mornin, sorry - was in the head 05:29:07 http://xell.forthworks.com/blog ? 05:29:52 my blog about xell and co, thanks to crc 05:30:43 hmm... if a lib didn't exist... How would you call a func in it? 05:34:10 because of default values 05:34:32 well, the linker would scream - unless you mean via dlopen-mecahnisms? 05:34:59 overall, I'd say you've met or opened as many worm-cans as I've tripped over 05:35:23 opened worm cans? 05:35:46 yeah, like "To byte or not to byte - that is the question.." 05:37:26 well, it's a dlopen thingy and when it gets compiled to machine code it gets simply ignored, I see there no problem. 05:37:26 amca was all hot on the subject, yesterday... I can't lead him too far, as he seems to lack a lot of reference-works - using mostly google instead of books. 05:40:52 As I told him at the time, I've about concluded that a "bytecode-engine" would be a major project in and of itself. I think I'm going to need to admit that I can't blithely expect to "compile" bytecodes to "run". In fact, I'm pretty sure we just need source for a loader/saver pair - which recurses thru the desired words to create a reusable file. And, if need THAT, we are as far ahead with source. 05:42:54 I still think our huge strongpoint is our major-integration of interactive/compiled and preprocessing (immediates). 05:43:42 well, I do it in this way. 05:49:23 I see that from the point of the machine, humans can work easily with source but machines don't. they need easy constructs and that are for me bytecodes. 05:50:13 another thing is that bytecode is memory friendlier than source 05:50:45 yes, they could be. I was hard pressed to explain examples like the 8080 and z80 to him. And, it was difficult to explain that the bytecodes would likely add another layer of indirection and time. 05:51:13 oh, my god - of course it: the bytecode is the "compiled form" 05:51:21 you keep saying that 05:51:28 another layer of indirection and time as compared to what? 05:52:12 tathi: I'm speaking of the fact the 'byte' is a token, and you still need to reach "code" that the token represents. 05:52:24 well one layer of indirection which can be resolved back to machine code, I hope I can do that cleanly. 05:52:36 virl: right, I hope so as well. 05:52:41 yes, but you have to reach "code" somehow 05:52:55 certainly, that is understood. 05:52:55 what alternate compiled form do you have in mind that would be faster? 05:53:29 tathi: the only method I can see for myself, for now, is compiling ptrs and literals. 05:53:29 machine code 05:53:46 what they used to call "direct-threaded", I believe. 05:53:54 oh, ok. 05:54:12 or pointers to words. 05:54:15 If POSSIBLE, I'd love to get a bytecode-layer shoehorned in. 05:54:19 virl: right 05:54:59 Because, otherwise, for every "issue" I think I resolve, two more grow up - or 3 want to mutate. 05:57:23 ah, ok. whatever works better for you. 05:57:27 hmm, it might even be possible to retrofit your bcode - just adding a layer/func post-compile and w/i the executor 05:57:57 tathi: well, there are only so many issues you can tackle at once, if you hope to get something to run. 05:58:39 yeah, I was only objecting to "bytecodes would likely add another layer of indirection and time". 05:59:05 in my experiments to date, there is only a marginal speed difference. 05:59:19 right.. I don't like to keep mentioning it, but the "other camp" always wants to write "efficient asm" 05:59:35 that would be me :) 05:59:38 tathi: yeah, I had hoped to see your engine running. 06:00:01 yeah, one of these days. 06:00:14 I'm getting to the point in one of my projects where I need it 06:00:53 ain't that the truth? ;-/ 06:01:11 I have a little game that's almost clean enough that I want to have the engine in C and the game logic in a script 06:01:31 right.. I don't do games, but that was my reasoning as well. 06:02:04 So.. maybe soon, but no promises :) 06:02:05 tathi, me too 06:02:27 I also like games 06:02:38 virl: yeah, I've read a little of your stuff 06:05:07 I like your motives, I just don't like the way you keep condemning things that you don't actually seem to know anything about. :P 06:06:41 and that would be? garbage collectors? nyquist? or what 06:07:43 yeah, garbage collectors for one 06:08:24 I mean, it's fine for you to hate them 06:08:28 I don't much LIKE GC, but.. there often seems to come a point where there are so goddamned many xrefs you can't track them easily. 06:08:53 But to go around trying to convince everyone else that they are evil doesn't help your credibility :) 06:09:01 true enough 06:09:36 otoh, over in ##C, I certainly prefer to tell the newbies to learn the basics before buying a wheelchair. 06:10:00 oh, sure. 06:10:27 And, I am sure you can agree a lot of GC is used in places that are just plain silly or weird. 06:10:33 ok, that's hard for me. 06:12:27 tathi I said in my blog that I hate the discussions about GCs 06:12:34 hehe 06:12:51 virl: sorry, I'll drop it now 06:12:58 They end up being amorphous and opinion ;-) 06:13:41 what discussions? 06:14:04 exactly. 06:14:13 * PoppaVic chuckles 06:14:28 and what does he drop? 06:14:39 precisely. 06:15:24 I wish we had a nice, portable objectfile lib. *sigh* 06:16:05 heh. 06:16:22 unfortunately that's a lot of work 06:16:51 it sure would be, since it - by def - is tied to the underlying formats, like Elf and Mach-O 06:17:36 and to the calling conventions, which I gather that gcc changes (on x86 at least) at the drop of a hat 06:17:45 but it sure would be nice 06:17:55 I saw that the Darwin manpages have _something_ like this, but only for Mach-O - and it not only was ugly as hell, but it's (again) nonportable. 06:18:08 yeppers. 06:19:13 well, tathi did you ever implemented a GC? 06:19:53 virl: not really. A couple toy implementations when I was in university 06:20:46 but my point is that, if you're talking to someone who is successfully using GC, and using unsound arguments, you look like you're reacting emotionally. 06:20:49 Even a simple-minded reference-counter (time-to-die) would help a lot of folks. 06:21:28 and saying "most languages that have GC are slow, therefore GC must be slow" is a totally baseless argument 06:21:41 things happening in combination does NOT imply cause and effect 06:21:49 yup 06:22:34 There may be hard evidence out there that most garbage collectors ARE slow, but you're not pointing to that 06:22:47 You're just claiming (AFAICT) that they're always evil. 06:22:58 I've always felt that one possible solution for GC would be to use a 100% "handle-based" system. 06:23:12 tathi, that's only your point of view, not mine. 06:23:35 did he misread the blog? 06:23:37 virl: ok, sorry for the misinterpretation then 06:24:02 I was a little lost in the blog myself, subtle word-use, punct and such 06:24:07 but you do make it easy to interpret what you're saying that way. 06:24:30 mixed-subjects and run-on sentences? 06:24:56 PoppaVic: I assume virl isn't a native english speaker 06:25:07 they look like the usual sorts of errors 06:25:09 I did as well, I interpolated all over 06:25:27 but yeah, some of it was pretty hard to follow 06:26:35 hmm...my last attempt at a bytecode engine was way too complex. Guess I need to start over. 06:27:10 amca was all over the subject the other day.. I suggested z80-style "windowed opcodes" 06:27:49 I want something as dirt-simple as possible. 06:28:23 keeping extensibility in mind, but not really worrying about it until I have a working system 06:28:35 well, the kicker is almost always the same sort of instructions as a CPU would need. 06:28:52 how's that? 06:29:11 push/pop, load/save, add/subtract, etc, etc 06:29:27 yes, how is that "the kicker"? 06:29:36 I have no problem designing and building a VM 06:29:42 fovium works great, for instance. 06:29:59 well, isolating and identifying all the opcodes you need - and then insuring they are within "the universe" 06:30:12 iirc, fovium is still x86, isn't it? 06:30:17 no. 06:30:19 never was. 06:30:30 I did a PPC asm version (which is now out of date, I believe) 06:30:34 and there's a portable C version. 06:30:36 hmm.. I wonder what happened to mine... oh, ahh 06:30:53 it's when I start adding things that a CPU *wouldn't* have that I run into trouble. 06:31:01 dictionaries and such. 06:31:07 right 06:31:29 I would expect that doing those would necessitate the code in the bytecode itself. 06:31:56 I just need to get my design goals clear, so I have a basis for deciding what to leave out :) 06:32:07 or add in, right. 06:32:28 Well, my philosophy of coding is more about leaving things out. ;) 06:32:38 * virl needs to rewrite his blog article about GCs, it seems to offensive and too emotionally 06:32:42 I meant in terms of layers or modules. 06:32:54 virl: sounds sensible. 06:32:58 I don't like those so much either :) 06:33:19 at the time I wrote it, was angry on slava. 06:33:28 tathi: well, in my case - I keep seeing the z80 prelude-codes. 06:33:32 virl: hey, it's a blog, ranting is what they're for :P 06:33:54 hrm...please explain -- it has been a long time since I did any z80 06:35:01 well, the z80 was 100% 8080 compat, and they took unused codes of the 8080 (windows) to open a new page of opcodes that could FOLLOW that prelude-byte 06:35:22 oh, right 06:35:26 now I'm with you 06:36:16 I always felt it was a sensible idea. Basically, they'd add shit that you COULD tediously code in level0, but give it a new opcode and name and you just "went" 06:37:52 I'm not worried about the bytecode being extensible like that. 06:38:08 one "new level" I'd recommend is a collection of MM bytecodes - to insure everyone is using the same bloody interface. 06:38:11 tathi, am I so uncredibility 06:41:09 virl: you could be better 06:41:42 But I don't usually follow the conversations between you and PoppaVic 06:41:58 tathi: I've a translator-layer built-in ;-) 06:41:59 And I haven't hung out in #xell or checked out what code you're actually writing 06:42:18 so I shouldn't say that you don't know what you're doing. 06:43:12 I guess I'm mostly reacting to the negative stuff -- when you take exception to what people are doing that is working (for them). 06:44:15 I don't mind disagreement. 06:44:27 I've noticed that :) 06:45:22 Of course, some folks can't ever come to terms with "I can respect him,but I don't like him", either. 06:45:50 virl: It's also that (at least early on) you made a lot of big claims about how great xell would be. 06:46:09 And in my experience that usually goes with open source projects that never get anywhere :) 06:47:18 tathi, well that was a failure 06:47:28 that? 06:48:19 btw, I found fovium.c - yeah, quite primitive. Needs a good example of main(), too 06:48:23 making big claims, at the moment I was very enthusiastic 06:48:46 Nothing wrong with enthusiasm. 06:48:51 PoppaVic: you probably have one that isn't finished then 06:48:56 ahhhh 06:49:25 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 06:49:26 tathi: well, if you run across a surviving copy, just email-attach the sucker to me, please? 06:50:08 I was getting the URL for my svn repository 06:50:15 cool 06:50:29 but my apache seems to be wrong, somehow. 06:50:36 Man, I am sooo tired of writing notes. 06:50:38 very odd...I know Jason was using it the other day... 06:51:19 Did the "final" copy end up creating the dictionary as well? 06:51:56 no, no. 06:52:00 it's just a VM 06:52:01 ahh 06:52:05 right 06:52:05 does the things a CPU would do. 06:52:46 aha. it's my http proxy, not the server. 06:53:05 try http://josh.qualdan.com:3/svn/fovium/ 06:53:51 ahhh 06:54:05 but yeah, it's alive. Jason is building a forth system on top of it. 06:54:16 although I haven't done much with it since writing it initially. 06:54:35 right.. I'll bookmark and wait for the latest & greatest 06:54:58 I'dtarball the silly thing, too ;-) 06:55:06 ok, then lets take a look. 06:55:20 I could mail you a tarball. 06:55:36 please do. I'll archive it on the next /Download burn 06:55:46 currently it's pretty much a private project between me and Jason; and we both have svn, so no need for tarballs. 06:57:06 virl: I'm not sure I like some of the design decisions; particularly how branches/calls are encoded. 06:57:15 But the basic bytecode interpretation stuff is pretty sound, I think. 06:57:38 What was the ppc-asm all about? 06:58:13 oh, we were talking about how low you could push the overhead 06:58:27 also, it does a couple of things in a different way than the C version 06:58:32 oh, so it was experimental. 06:58:35 so it was useful for debugging in the beginning. 06:59:07 it was a perfectly valid implementation 06:59:35 well, I meant a test-case (experiment) 07:00:30 No, I was originally planning to keep it up as a faster alternative. 07:00:34 a big switch in keys. 07:00:36 And maybe do an x86 asm one too 07:00:42 but I've let it lapse 07:00:55 will be interesting to see. 07:01:02 virl: yeah, Jason did that. I haven't looked at it to see if there's a better way. 07:02:07 keyboard input doesn't need to be efficient, anyway 07:02:18 the computer is plenty fast enough to keep up with someone typing 07:02:18 well, I don't know how gcc interprets it and compiles it, so I can't say if it's good or not, but it's quite readable. 07:02:39 yeah, it's just so that the key numbers are sure to stay the same across platforms 07:02:55 key-codes or digits? 07:03:42 what's the distinction? 07:03:53 key-codes, I think. 07:04:14 '1' versus - ahh, nm.. Yer normalizing, instead of praying for ascii. 07:04:32 praying ascii? 07:04:38 [for] 07:04:57 raw-input and scancodes get really noxious. 07:05:09 yes 07:07:50 it sounds like more of a key mapping issues, and I swear to god we could use better layering for a variety of things in C. 07:08:55 I agree 07:08:58 btw.. I think I can squint and see a "logical progression", if we twist a few terms... 07:09:23 Although I think things are getting better at the low level (e.g. Linux kernel is more consistent than it used to be) 07:09:39 Let C be "assembler" - the results are "ucode" (we don't even WANT to know) - and the VM is "the language" 07:09:42 --- quit: oldman ("I am going away") 07:11:21 It's be interesting to see how a new Fovium would handle devices, dirs, and files.. Pipes, sockets. All that stuff really puts a hurtin' on C. 07:12:24 I don't think he plans to deal with that very much, but we'll see. 07:12:45 yeah... well, I was also thinking of your new-rendition. 07:13:05 Oh. I'm not too concerned about it either :) 07:13:09 The biggest issue with forth is it's own self-image, and C then suffers similarly. 07:13:11 I haven't had any problems with that stuff in C 07:13:27 me top 07:13:29 me too 07:14:07 sure.. I've been cogitating, and it looks to me like most "primitives" are just C, with a wrapper for headers. 07:14:14 Oh. I'm thinking of this new rendition as a scripting engine, so it probably doesn't care. 07:14:22 Ahh 07:14:35 entirely within the context-space, eh? 07:15:13 As long as the app has room to add its own primitives, like guile or lua or whatever, I should be fine. 07:15:31 yes. 07:16:06 I've been pondering... I have to wonder if we could benefit from a "preprocessor" that took a metafile and generated header, pcode and primitives sources to further process. 07:16:32 generated in what kind of form? 07:16:42 Sometimes, it's handy to see things in "universal context" 07:17:30 hmm, I'm thinking of .h and .c extractions, and laying out the .c for "the headers/vocs/wordlists" 07:17:52 It seems like it would work to coordinate better. 07:18:39 Even laying down a .c for the pcode.. I dunno. 07:19:07 ah, to generate a wrapper to present a C function as a primitive, that sort of thing? 07:19:10 There are so godawful many xrefs and forward/resolves to generate a basic system 07:19:14 right 07:19:19 when I would know how to write a dictionary in C 07:19:30 that could be useful 07:19:33 virl: elaborate, please? 07:19:38 I gather SWIG has quite a few adherents :) 07:19:53 Idunno swig other than the term 07:20:33 I'm trying to write it since a lot of months and I don't come over it. 07:20:55 virl: ahhhh well, there are a shitload of dictionaries and header-layouts and such 07:21:03 Simplified Wrapper and Interface Generator (www.swig.org) 07:21:29 tathi: that's a java thing, or something - isn't it? 07:21:49 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 07:21:49 --- mode: ChanServ set +o JasonWoof 07:21:50 PoppaVic: it's used with a bunch of scripting languages AFAIK 07:21:57 huh! 07:21:58 perl, python, etc. 07:22:05 I may look into it. 07:22:14 probably bigger than you want to use, but might be worth a look. 07:22:27 It's likely it's not friendly to our goals though, yeah 07:22:47 well, it would be a compile-time dependency. 07:22:47 tathi, I never used it, how big is it exactly? 07:22:59 yeppers 07:23:02 virl: I don't know, I'm just guessing :) 07:23:07 ..and I am trying to avoid such 07:23:14 virl: so...what's giving you trouble about dictionaries? 07:23:30 well, compilling 07:23:36 PoppaVic: also, depending on how deep you need to dig, it might be needed only by developers 07:23:46 you can "lay out" headers and stuff fairly early, but then you have to resolve a lot of stuff. 07:23:47 i.e. you might be able to just put SWIG's output into your tarballs 07:24:00 tathi: very good point 07:24:21 that's a level of ideation I get bollixed on 07:24:40 ..like goddamned "cross-compiling" 07:25:00 never done C-C and never want to. 07:32:36 humph 07:34:06 I'll have to review that damned url, tathi - shit. I still feel it's a developer-dependency that may mean doing backflips. 07:34:25 it may very well 07:34:51 But, yeah.. the idea is there... I swear I thought it was script-specific. 07:35:10 :) 07:35:33 btw... What are your feelings on plugins and an access-structure? 07:35:43 access-structure? 07:36:55 yeah... Most folks just write a lib of shit and access bits. I concluded a few years back that it's easier to expect a name and a struct to provide further info about access-abilities, like vocs or structs/members/methods. 07:37:21 basically: "You can extend me, but you must comply" 07:38:01 ah. but if it's forth, doesn't a plugin just provide a bunch of words that you can use? 07:38:03 I always felt such an arrangement really acted like those "windowed opcodes" 07:38:12 so you can just check the vocab to see what's there? 07:38:16 tathi, it might. 07:38:43 and maybe some standard things like ANS's environment queries too, I guess 07:38:50 otoh, I know how "people" (users) think, and vocs/wordlists are not on their agenda. 07:39:48 seems like everyone wants to herd-together and "just code" - until they learn about namespace-ideas, and even then - it confuses them. 07:40:30 ..of course, those same folks will segregate into groups at meetings or parties. 07:41:15 I keep thinking that your fovium-concepts are really amenable to plugins. 07:42:14 yeah, the core idea is just a generic bytecode interpreter; you can do lots of different things with it. 07:42:19 For example: you used an array.. Which is fine, but.. if it was a structure with a size-count and such..? 07:42:51 I'd stick with fixed-size opcodes and an array, for speed. 07:42:58 Just fill unused entries with a no-op primitive. 07:43:26 And if you need more opcodes, define some that use the next opcode slot as well as the current one. 07:43:42 sure, now... think thru.... what if an opcode was to KNOW it was supposed to read another byte and execute that code in the other table? 07:43:57 yeah, exactly 07:44:07 it complicates the compiler a bit, of course. 07:44:08 bingo.. OK, yer on the same page 07:44:20 yeah, I started writing one. 07:44:38 but it was more than I needed 07:44:40 yeah... I've been cogitating the compiler as well.. 07:45:03 no, what am I saying? the compiler needs to know about the opcodes anyway. 07:45:17 so it really doesn't make much difference if some are extension opcodes and some are normal. 07:45:29 I've been wondering if we shouldn't design the header with xrefs to "compiletime" and "runtime" 07:45:34 yeppers 07:46:52 yeah... ANS just has IMMEDIATE words, so if you want different compile-time vs. runtime semantics you have to go state-smart 07:47:12 Chuck's dual-dictionaries get around that. 07:47:33 I think gforth uses two xts in each header, as you're suggesting 07:47:56 really? Never noticed in the source. 07:48:29 I haven't looked at the source 07:48:38 I thought about "dual dict", but it seemed to me that it might muck with "order" and duplicate heads 07:48:40 but it seems to function that way 07:49:02 you can have compile-only words, and there's a creating word that takes two xts and sets them as the compile-time and runtime semantics. 07:49:35 I figure that the 'immediate' flag is one thing, but "ctime" and "rtime" are not exactly the same. 07:49:46 right, I saw those new ops 07:50:09 ..so, they basically retrofit the concepts. 07:51:10 seems like they really have to stir up header-layout and bodies, plus duplicate a lot to do silly, simply things. 07:51:22 of course, Anton pretty much recommends just having separate word names 07:51:28 foo and [foo] or whatever 07:52:01 I would tend to agree with him, if we could glean prefix and suffix out of the stream 07:52:22 why would you want to do that? 07:52:41 To be honest, I'm beginning to think I might as well keep all the heads in a db file. 07:53:19 tathi: I think we need to consider FICL-type "get a prefix" stuff, but I wish we could also get a suffix. 07:54:45 I can live w/o the latter, of course 07:56:09 I start to wonder if we should consider at least punctuation as a terminator/originator. 07:56:28 sadly, it would change almost too much to bear 07:56:41 I've followed that path a little bit -- it seems to get ugly pretty fast 07:56:56 BUT, the FICL-idea of "prefix" seems to offer some ideas. 07:57:03 I don't see why it's a problem just having foo and [foo] being separate words 07:57:31 it wastes space, but... if I use a db for headers, I could care the hell less. 07:58:18 it's not that much space, and you can always strip out unused headers 07:58:52 We both know that users are slower than anything, lookup for compiling is always slow, and after that, it just chugs along. 07:59:03 when you say "use a db for headers", you mean use some external lib instead of writing the code yourself? 07:59:15 lookup for compiling isn't that slow. 07:59:36 it depends on your dictionary format, of course. 07:59:44 no, I meant "extract 'heads'" to a file we can search - it should be abstractable anyway. 08:00:03 well, "slow" was relative 08:00:56 oh. yeah, sure, store them however you want :) 08:01:05 humans and fingers are dead-slow; perfect-hashes and trees are far, far faster; and even vectored-code is FAST 08:01:17 ok. 08:02:03 So, the other issue would be... "when do we need lookup?", and - afaik - that's only at interpret-times. 08:02:04 I don't see that it makes much difference (to the user) where you put them, as long as you can find them when they're wanted. 08:02:26 tathi: right, until some lunatic starts making assumptions. 08:03:09 huh? 08:03:32 assumptions like what, exactly? 08:03:47 So, I often believe headers are a disrespected issue - as are vocs and such.. THey want to gloss over shit and pretend they are sole-owners of space and time, and then write "cute tricks" 08:04:03 again, like what? 08:04:18 give a concrete example or stop being so damned paranoid 08:04:20 tathi: pfa, cfa, offsets, whatever 08:04:28 tathi: paranoids live longer ;-) 08:04:43 yeah, but who are you writing this software FOR, anyway? 08:04:59 just boot the lunatics out -- they can go back to autoconf/automake 08:05:01 Users. I always write libs and tools, always. 08:05:10 hehe ;-) Right! ;-) 08:05:37 if you provide words to access any parts of the headers that people might actually need 08:05:42 and someone writes nonstandard code anyway 08:05:44 tathi: yer good for my shoulders - you brush them-there monkeys right off! ;-) 08:05:52 and it breaks when you change something, that's their own stupid fault 08:05:56 right 08:10:31 BTW.. someone had mentioned "stack machines" at some time... Somehow suggesting we could live w/o registers. 08:11:14 I finally saw a potential way to handle that, but I suspect it would NOT be "friendly". 08:12:43 I don't see the problem; stack machines are fun ;) 08:12:59 write fovium-new that way ;-) 08:13:12 the old one IS that way 08:13:24 I think we have different ideas of "fun" ;-) 08:13:34 ok, IIRC it has an address register, but that's a convenience, not a necessity. 08:13:48 Hmm, iirc, the old one had a set of "registers" we call "variables". 08:13:53 or maybe we're using the same term for different things again 08:14:04 it happens often 08:14:13 oh. internally. 08:14:17 yah 08:14:59 I thought we had been over this; "stack machine" doesn't mean that it doesn't HAVE registers, just that it doesn't expose them to the programmer 08:15:02 except as a stack 08:15:10 er, the stacks 08:15:53 ahhh, but... those "regs" exist - somewhere.. There is a way to ignore most of ;em. 08:16:00 I get the point, though 08:16:11 just like any processor has a Program Counter or Instruction Pointer or whatever, but you usually don't have direct access to it. 08:16:21 right. 08:17:01 ok, so what's your unfriendly solution? 08:17:04 I sometimes think that I end up arguing with guys not seeing the mecahnical distiction, and then semi-solve just to shut them up. It wasn't you. 08:17:51 you pass a context around, which is almost 100% "the stack[s]", and you use the first slot or so to record BOS and maybe REG-COUNTER 08:18:31 it'd be a bitch, but it'd be flexible and "eliminate registers" 08:19:54 It looked to me like a "nitwit solution", but it seems likely to make some lunatics happy. 08:20:20 huh? ficl does that; you pass the Vm or System struct around everywhere. 08:20:25 it allows you to run more than one instance 08:20:38 but maybe that's not a goal of yours? 08:21:04 ohhh...I see. never mind. 08:21:13 sure, but THIS would eliminate "registers" - and allow "us to work within the 'stack'". I had some flak one day, and it bugged me. 08:21:21 yeah, that would be AWFUL :) 08:21:30 right - makes yer head hurt 08:22:40 otoh, it does sorta' force folks into THINKING "contexts" 08:48:39 --- quit: PoppaVic ("brb") 08:50:09 --- join: PoppaVic (n=pete@0-1pool74-99.nas24.chicago4.il.us.da.qwest.net) joined #forth 09:00:13 Anyway, yeah.. I look forward to yer rewrite.. I've love to get involved and even see how we can add dir/file/device, etc.. It's that "systems" shit that kills everyone. 09:04:24 tathi: how would you express piping and redirection, in a forthish semantic? 09:04:34 you, meaning YOU 09:11:04 I've never really thought about it 09:11:59 comparing forth and shit like bash... Let me know what you'd respect. 09:12:43 so you are searching for a better bash 09:13:42 hmm. I might have to think about that for a while 09:13:44 virl: I need a shell, I will combine make and bash behaviors, stir with forth and mix within C. 09:14:20 tathi: please do. It sometimes matters - sometimes even SILLY "shit" matters. 09:15:07 Off the top of my head I'd have to say I like the bash syntax; can't you just do that in forth? 09:15:24 But since you're asking I'm guessing there are issues with that :) 09:16:07 perhaps, it'd be my goal anyway... I just wondered if someone was seeing a variant that made me sit straight and yodel 09:18:36