00:00:00 --- log: started forth/05.06.23 00:35:41 oh, good idea 00:35:52 hi 00:35:58 anybody here with windows? can you test americanportraitartist.com for me? 00:36:03 in IE 01:14:48 --- quit: Herkamire ("off to bed") 03:53:14 --- join: Topaz (~top@spc1-horn1-6-0-cust117.cosh.broadband.ntl.com) joined #forth 03:58:39 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 04:30:17 --- join: bot_test (~forthbot@pcp02123821pcs.milfrd01.pa.comcast.net) joined #forth 04:30:30 --- quit: bot_test (Client Quit) 04:31:11 cool. works on PPC now. 04:33:08 What does? 04:36:06 the IsForth sockets stuff and IRC bot 04:36:37 Ah, neat. 04:36:50 I440r wants to rewrite the sockets stuff 04:37:06 I thought I'd better get it working first 04:38:44 That argument is used against me a lot :) 04:39:13 :) 04:40:30 well, I needed to refresh my memory on how Linux socket stuff works, anyway. 05:05:55 --- join: PoppaVic (~pete@0-1pool67-111.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:06:07 Mornin' 05:06:32 morning 05:09:57 Hi 05:26:01 --- quit: PayphoneEd ("brb") 05:35:23 --- join: T0paz (~top@sown-86.ecs.soton.ac.uk) joined #forth 05:40:58 --- quit: Topaz (Read error: 110 (Connection timed out)) 05:41:26 --- quit: tathi ("foo!") 05:58:20 --- join: virl (Phantasus@chello062178085149.1.12.vie.surfer.at) joined #forth 06:00:15 Hi 06:02:55 Herkamire, americanportraitartist.com works here, looks good. 06:03:28 http://en.wikipedia.org/wiki/Love_Israel o_O 06:17:49 Hmm.. Once you fix "The Bug", compiling 'Until' is sort of.. interesting 06:26:21 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 06:39:51 hello 06:45:34 lo 06:47:48 Hi 06:48:22 what's everyone up to coding today? 06:48:28 Nothing. 06:48:45 Still beating my dictionary-stuff 06:49:14 Got 'Until' to build and run too, this am. 06:50:09 while I have not fixed the CODE, I have also given into pressure and decided the order-array is an order-list, instead 06:52:04 * tathi is doing network stuff in IsForth PPC 06:52:27 yeah, looked into isforth yesterday.. I was looking for the tarball ;-) 07:01:08 did you find it? 07:01:41 no, but I downloaded the ppc zip or whatever. THe site doesn't list a plain-old tarball 07:02:41 when you say "zip" you mean "gzipped tarball" I assume...? 07:02:49 yah 07:03:00 I was going to peruse the source 07:03:29 I don't know of anyone who posts uncompressed tarballs on the web. 07:03:47 no. foo...tar.gz 07:04:10 what I got was something for the ppc, and the others never mentioned plain old source 07:04:29 from isforth.clss.net? 07:04:39 yah 07:04:48 huh. 07:04:50 * tathi goes to look 07:07:22 hmm, that is kind of badly marked. 07:08:15 ok, on http://isforth.clss.net/d/download.html, under Flavors there are 3 links to .tgz files. 07:08:23 those are full source, plus a pre-built binary of the kernel 07:08:28 yah.. crosscompiled is great when life has kicked you in the nuts; otherwise source rules the world ;-) 07:08:38 AHHHHHHH 07:08:53 OK, cool.. Did not understand that 07:09:16 and also an extended binary 'isforth', it looks like. 07:09:41 thanks. Good to know. Page prolly needs a clue ;-) 07:10:16 yeah, that should be changed 07:11:56 --- join: PayphoneEd (~Ed@payphoneed.user) joined #forth 07:21:48 PoppaVic: so you have a PPC box then? 07:21:57 OS X or Linux? 07:22:10 --- join: sproingie (~chuck@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:22:34 me? I am - have been for 2+ years - on a powerbook G4 12". The linux box languishes in the gunroom 07:23:48 gotcha. IsForth doesn't run under OS X unfortunately. 07:23:49 macosx is.. well, I only like the fact there is a bsd core in there - somewhere - that works 07:24:02 ahh 07:24:08 I got my machine just before OS X came out, and didn't bother buying it. 07:24:13 Just went to Linux instead. 07:24:48 Not a BAD choice.. I am unimpressed with the tendency to special libs and obj-C as the "default" lingo 07:25:05 whats wrong with objc? 07:25:17 I'd wish it on enemies 07:25:24 probably a better choice for modular systems than plain C 07:25:32 Not interested 07:25:56 either obj-C should be a special preprocessor generating C, or they need a new name 07:26:20 ..cuz, I've seen some of the code - and it reeks 07:26:22 i think COM is better, but MS did a lousy job of front-ending that for so long 07:26:30 gahhh 07:26:52 the registration mechanism is still awful 07:27:14 regis - you mean their godcursed binary-ini crap? 07:27:29 oskit likes com, it's based on it 07:27:37 blech 07:27:41 not-interested 07:28:11 eh. linkers are ugly. can't all be in forth 07:28:25 interesting premise 07:28:49 C is where I live, forth is something I like. 07:29:06 i just see a lot of people bash C and the whole ABI 07:29:14 but never produce anything beyond small scale in forth 07:31:07 i can't stand linkers either. i'm not sure that converting everything to a trivially compiled language is the answer tho 07:32:54 The probs with C are the idiot committees and focus on semantics, rather than lib/header starndards as well as the - you are right - the lack of a thorough way to explain the ABI during build. THis is my current project. 07:33:48 My personal view is that everything in the universe is filters/transmogrifiers or translators. 07:34:39 you'd fit in nicely with the rewrite school 07:34:56 tho most of them have yet to come up with a compiler of decent speed 07:34:58 The prob is, there is almost no agreement in getting from Z down to machinecode 07:35:28 I don't let "decent speed" control me. It's AN issue, not THE issue 07:35:59 look at GNU as, for example. 07:36:34 Here you have nearly consistent preproc/directives' - shoveled right in with opcodes/regs, etc 07:36:45 WHY, I ask? 07:36:48 and slow as a snail relatively speaking 07:37:01 ns - doesn't matter in the least 07:37:23 my problem with gas is the horrible AT&T syntax it uses 07:37:52 while everyone else uses intel 07:37:55 I could care less, I ain't tweaked asm since Z80's, although I sometimes peer at a -S generated file 07:38:44 the opcodes/semantics of the assembly - not the directives and macros - are An Issue - and just irksome. 07:39:06 yet, they COULD have backed off a level and cleared it up. 07:39:22 Lacking a forthlike system, they did not and prolly could not. 07:40:07 What they did, really, is fold the macro-asm with the preprocessor AND the assembler. 07:40:17 which was just plain stupid 07:40:25 didn't know it actually used the c preprocessor 07:40:32 that's by far one of c's worst parts 07:40:35 they have their own 07:40:46 macro engine or something different? 07:40:56 * sproingie doesn't know gnu as that much, just asm blocks in C 07:41:12 the cpp was useful Long Ago, (and gcc still lets you use an external cpp), but the GNU dolts welded THEIR cpp to their compiler source 07:41:37 cpp can still be useful but it's horribly crippled 07:41:44 ..and reading the GCC source can make you blind and grow hair on yer palms 07:41:51 yep, and I agree 07:42:09 RMS has actually kept the gcc source deliberately obfuscated to prevent commercial forks of a backend 07:42:09 SOO, enter my project/obsession 07:42:20 he's an idiot, then 07:42:26 why yes, yes he is 07:42:46 he doesnt even code for gcc anymore, he just controls the gcc steering committee 07:42:51 basically, RMS is a politician 07:42:52 clear code is a marvel, and more enjoyable than sex (usually ;-) 07:43:09 * sproingie votes for sex 07:43:24 GIVEN that gcc is almost universal, solutions begin to become apparent. 07:44:07 some would say lisp is the solution ;) 07:44:15 BUT, bottom-up: the assembler is the first issue 07:44:22 lisp is an answer for lispers 07:44:27 no kidding 07:44:44 The assembler needs a breakout of at least one level 07:45:26 higher level? 07:45:39 not sure, could be lower - depends on viewpoint 07:45:59 I already accept that a linker is needed for .o/.a/.so and such 07:46:01 some might say C-- or LLVM is that other level 07:46:43 basically, with anything like GAS you need: pp[macro[asm[hex]]] 07:47:16 and this all begins to sound a lot like, to me, lexicons and vocabularies. 07:47:24 sort of 07:47:38 asm is designed to have a 1-1 correspondence with opcodes 07:47:43 just remember, filters/transmog. 07:47:43 that's probably necessary 07:47:47 nope 07:48:00 The CPU and platform dictate the opcodes/regs 07:48:08 forth HAS assembler 07:48:12 yes, and they need mnemonic encodings 07:48:25 enter asm, at least the non-macro kind 07:48:36 ..what we lack is a way to get from that out to textfiles to generate objects 07:49:16 recall that forth seems to often jumble preproc, "directives" and such 07:49:26 it's designed to 07:49:29 lisp is the same way 07:49:47 nope, it's a carry over - I've been around since FIG-forth was hotshit 07:50:06 lisp is lisp. It makes me ill to read and I can't follow it 07:50:37 on the WHOLE, forth-like stuff is easier to read and learn 07:50:38 the ability to flip between compile and run modes and use the same language in both is a feature of lisp and forth 07:50:50 sure, and that's not at issue 07:51:19 says a forther. i find lisp pretty easy. common lisp is COBOL-esque in its bureacratic verboseness, but more or less readable 07:51:26 there are actually 3 modes, but one is obscured by a bitflag 07:52:00 I'm not saying the bit is bad, but there are THREE minimal 07:52:08 * sproingie is an old hand at elisp, far less cumbersome than CL. lacks closures tho 07:52:16 what's the third? 07:52:32 preprocessing/immediate, compiling, running 07:52:45 states/modes are really, really wonky 07:52:49 what's the difference between immediate and compiling? 07:53:05 generating/allocating space/compiling 07:53:18 all part of compiling, i'd claim 07:53:29 I'd disagree, but so be it 07:56:22 Think of it this way: pp(affect the system); compile(affect word/mem); execute(affects anything not protected) 07:57:02 It's not seriously CLEARCUT, but yeah.. They are somewhat different. 07:57:13 pp and compile are seriously intermingled in forth 07:57:20 yeppers 07:57:21 by design. metaprogramming and all that 07:57:41 almost the same in C, with less you can do about extending it. 07:57:58 naw, C can't affect its own compilation in C 07:58:06 not unless you use OpenC++ or something like it 07:58:08 sure it can 07:58:27 look at the billion special args that gcc uses internally 07:58:39 those are just hardwired magic tokens 07:58:48 you can't extend it in the same program as you're compiling 07:59:10 Meanwhile, as I said: the layering/transmog and idea of state PLUS immediate is a real pita 07:59:48 I agree, C extending C - even in gcc - is nearly moot: ain't likely to happen w/oeven MORE of their obfuscated voodoo 08:00:37 forth has another advantage, too 08:00:49 defered words vs replacements. 08:01:20 or, func-ptrs and func-ptr-ptrs 08:02:02 My biggest rant is still that forth is neither pcode nor .o(bject) 08:02:07 forth has a problem in indicating what's an arg and what's data on the stack 08:02:19 this makes it nigh impossible to assign registers 08:02:46 Yep, that issue doesn't bug me. because I plan to use C stackframes and my 'datastack' is a tagged queue. 08:02:49 unless you use stack effect inference. at which time it's no longer as fast to compile 08:03:20 tagged queue of stack frames? 08:03:26 the regs are rightly managed by the platform and the imp, there is no other reason to allow folks to dive into them - on the whole. 08:03:34 no 08:03:48 regs have to be managed by the compiler 08:04:04 the retstack will not exist: using C stackframes. The datastack is a queue where every node is tagged 08:04:04 optimal register assignment is np-complete. you're not likely to solve it in silicon 08:04:20 regs are almost totally controlled by the platform 08:04:42 gcc and even gforth accept this 08:04:58 ..and, hey - np: folks can shoot their feet off, not my prob 08:05:26 gcc has a register allocator based on RTL 08:05:34 moving to SSA now 08:05:35 the regs really end up being part of the ABI 08:05:45 no idea what those are 08:06:05 RTL is register transfer language. it's arcane and impossible for mere mortals to comprehend 08:06:12 ahh 08:06:21 "voodoo" 08:06:21 gcc does it with flair, it actually has a sexp-based RTL 08:06:38 nice :) 08:06:40 compile factor with gcc 3.3 and you'll see RTL, because an allocator bug will spew it at you 08:07:07 all I care about is getting closer and closer - from higher and higher - to generating a file that compiles a linkable or runable object. 08:07:38 yes, I stopped trying to build gcc a few years ago.. Like building the kernel, it's too painful to suffer 08:07:38 SSA is Static Single Assignment. real simple dataflow stuff that most functional languages already do explicitly 08:08:05 there's a decent wikipedia article on SSA 08:08:23 * Robert is a member of SSA. 08:08:46 thanks, I'll pass for now.. I've got about 15-30 other issues sweirling thru my neirons 08:09:24 "neurons" and "swirl", damn.. 08:09:43 the nice thing about SSA is that other good research compilers also target it 08:09:56 like LLVM 08:10:27 * sproingie wonders what MSVC uses ... whatever it is, it's all kept in-core and hidden 08:11:14 all that matters is getting text - ascii-text - more and more filtered right down to where the hex reflects local opcodes. 08:11:48 well, that's compilers for ya 08:11:59 or translators 08:12:24 ..and frankly, translators/filters/transmog is where I see the huge room for improvement. 08:12:39 there's been quite a lot of work in that field 08:12:49 rewrite systems and graph reduction 08:12:54 not enough, or we'd see better shit 08:13:22 I think what we see are scholars and statisticians/mathheads trying to impress each other 08:13:22 there is better shit, it's just hard to integrate into existing systems 08:14:08 stratego gets a lot of good things said about it 08:14:16 http://www.program-transformation.org/Stratego/WebHome 08:14:26 It's like watching CS/CE students trying to one-up each other talking about 0(n) and semantics 08:15:06 rewrite systems gave us pattern matching, which are finding their way in everywhere 08:15:13 well, ML and rewrite systems anyway 08:15:47 umm... fine. It misses the point though. As is usual. 08:16:01 not yer fault, either. 08:16:03 what is ultimately the point? 08:16:24 They want to write one great, universal "language" - like XML 08:16:41 used at eery point with different rules/etc 08:16:47 eery/every 08:17:36 not that i can see. it compiles to C, for one thing 08:17:48 I'm saying simply that the text INPUT at every level should proceed to generate something lower. And, while I know they will do so, skipping levels is prolly not wise. 08:17:57 looks like it can also compile to java 08:18:25 that's simply describing what compilers do. the how is the hard part 08:18:29 even C is "nonportable" inasfar as gcc/ms/platforms, ansi/posix/iso and platform, and the ABI 08:18:52 C has nasty policy issues, C-- is a better target 08:18:59 i know ghc has a c-- backend now 08:19:13 yes, and I'm saying - and insistent - that after all these years we should have better and clearer. 08:19:25 I've heard of c--, and glanced at it. 08:21:35 better and clearer what? 08:22:10 so if i'm understanding right, the main problem is that we don't have rich enough separate tools for each step of transformation and can't extend them arbitrarily up? 08:22:58 yeah, that sounds about right 08:23:03 lispers have been bragging about being able to go up arbitrary levels of abstraction for decades. failed pretty miserably on the separate tools part tho 08:23:27 been looking at the Qi language, and i gotta say i agree with the abstraction abilities tho 08:23:31 yeah, I know a major lisper - they get peeved when you question them deeply 08:23:41 qi is a pretty spiffy language built on lisp 08:24:12 and it can *probably* run on any lisp. but lisp systems themselves are largely monoliths 08:24:32 * sproingie er, run on any common lisp ... elisp is probably out of the question ;) 08:24:41 I dunno 'QI', but I do know that a forthlike 'see foo' is great, and so are debuggers. BUT, we need to abstract more and then ACCESS the abstractions in ways that emphasize portability. 08:25:09 yes, lisp suggests the same issues as forth, re: "monolithic" 08:25:11 well if you don't like lisp, you won't like qi :) 08:25:35 but as a language it's got some interesting stuff. pattern matching, sequent types 08:25:37 also look into #ferite - I followed it for a year or two, then I lost interest 08:25:55 got a url for ferite? 08:25:57 folks overrate "pattern matching" 08:26:08 check the channel, I think it's ferite.org 08:26:25 pattern matching is a wizzy feature which i agree is not the end-all 08:26:45 as a module or lib, it works fine. 08:26:51 looks like Yet Another Scripting Language to me 08:27:06 My bitch always was that grep did it one way, and everyone else does it Yet ANother Way 08:27:36 --- part: tathi left #forth 08:27:40 that's the beauty of standards, always several to choose from 08:27:41 last I did wildcarding like that, I dove into pcre and just suffered it 08:28:10 people here bitched about BART costing so many millions for using a nonstandard gauge 08:28:11 AND, "pattern-matching" is just another damned lexicon 08:28:22 I can't blame them 08:28:25 of course the reason they built it that way is because it's one of the smoothest rides in the country 08:28:33 standards schmandards 08:28:43 ns: standardize or force a new std 08:29:26 i'd say perl's regex syntax has taken over 08:29:28 mass-transit and amtrak make me laugh and all should die ugly - and will 08:29:33 for the best of reasons: it's the best 08:29:49 I disagree, but then: our choice of libs is limited 08:29:54 every new regex implementation is using perl's syntax. even grep does with the -P flag 08:30:08 grep and sed are *old*, before any standard was apparent 08:30:34 if that's your argument, I am not impressed 08:31:23 the variety of tools in fact forces the modularity you're looking for 08:31:38 they manage to interoperate despite having different interfaces 08:32:00 the way they do so is extraordinarily ugly. 08:32:22 glue is generally kludgier than what you're gluing 08:32:42 BUT, nm - I'll return to my code and then call it a day - getting physical chores done. 08:32:58 would be nice to have something like msh/monad for a unix shell. all we need is for everyone to agree on a single object model 08:33:02 no problem at all ;) 08:33:25 the minish is the basic unit, once I get past my module 08:38:32 --- quit: sproingie ("Konversation terminated!") 08:42:47 --- quit: PoppaVic ("Pulls the pin...") 08:57:52 --- join: tathi (~josh@tathi.bronze.supporter.pdpc) joined #forth 09:07:02 --- join: }Topaz{ (~top@spc1-horn1-6-0-cust117.cosh.broadband.ntl.com) joined #forth 09:07:07 --- quit: T0paz (Read error: 110 (Connection timed out)) 09:30:37 --- quit: }Topaz{ ("Leaving") 09:49:01 --- join: Herkamire (~jason@c-24-218-95-147.hsd1.ma.comcast.net) joined #forth 09:49:01 --- mode: ChanServ set +o Herkamire 09:50:28 --- join: PoppaVic (~pete@0-1pool66-191.nas22.chicago4.il.us.da.qwest.net) joined #forth 09:50:50 Back 09:54:29 Bacon 09:55:33 well, I tile-cemented the tile-edging into place.. I sure hope that shit works. 09:56:56 Methinks I have "improved" the guts of my interface. 10:00:39 madwork: given an exposed 'tag' var for EVERY stack-datum, what would you recommend as tags/types? 10:03:21 Forthy currently has int, double, string, and user (void*). I'll be expanding this though, and instead of having a tag, it will be an interface pointer for the type contained within. 10:03:43 I want you to think about it 10:04:21 Think about it? 10:04:25 What specifically? 10:04:43 tags ID'ing every element shoved to the stack. Size, mostly. 10:06:26 I think of them as the basic printf fmt-chars, but KNOW those are short of reality 10:07:28 Well, I told you what I use currently. My value struct has a type field, with a union of the supported types. 10:07:52 sure, and remember: a union is always max-sized in reality. 10:07:56 Yep. 10:07:59 ok 10:08:19 I've also got a pointer which is a back-reference to a refcount node (if it exists). 10:08:25 I'm almost considering the idea that the tag really parallels the stack, for checking input/output 10:09:13 I've decided I almost like forthish "locals", but they ignore another facet which I BELIEVE was called "anon variables" 10:09:24 I'd make the tag a pointer to an interface struct of function pointers. Then you can have stuff like file handle types and what not that automagically close themselves if they are dropped off the stack. 10:09:39 hmm... 10:09:52 I'd have to read that again, maybe with some examples. 10:10:15 What I did weeks ago was design my stack/queue to use an int-tag in the NODE to id the void* 10:10:26 Yep. 10:10:36 But instead of using an int-tag, use a vtable pointer. 10:10:49 oh, crap.. ANOTHER???? 10:11:01 Heh. 10:11:13 dude, I already have like 4 or 5 vtables 10:11:34 Well, you can switch/case on each tag ID, or just work through the tag's interface. Up to you. 10:11:37 I prefer the latter. 10:11:49 Then the user can easily extend the system with new types and interface implementations. 10:11:52 hmm, we may be on intersecting planes 10:12:24 I almost see yer point, but the func-vec would NOT be useful for getting shit from the stack, near as I can tell 10:12:58 It could be. You'll have your primitive access functions for built-in types like int, float, etc. 10:13:18 Then, have a user-access function that just returns the void* for the type. 10:13:26 They can query the interface for extra info. 10:13:34 ie. return a type description, ID, or whatever you want. 10:13:38 OK, trying to visualize 10:14:06 You can even quickly test for the value's type by comparing the interface pointer that's returned. 10:14:47 so something like: void *get_user_data(offset, *interface); 10:15:38 hmm 10:16:24 The interface functions would take the data as a parameter. 10:16:39 id=interface->get_id(data); 10:16:40 yeah, not sure this gains anything at the mo 10:16:59 Well, it does in this case: inteface->delete(data); 10:17:05 hmm 10:17:14 int foo=interface->convert_to_int(data); 10:17:16 etc. 10:17:34 nah, it's a queue/stack 10:17:40 but, I see yer point that it can be vectabled to ctor/dtor 10:17:55 Yea, but I'm operating on a stack item level here. 10:18:00 however,... 10:18:09 damn... trying to SEE and express, wait a sec 10:18:28 Anyway, I'm just spewing what I'm planning to do for Forthy. Maybe it lines up with your needs, maybe not. 10:19:08 ok... instead of a plain int 'tag', which you'd HANDLE or reject, you are suggesting a func-ptr that can create/destroy or convert. 10:19:23 OK, that's sorta' interesting 10:19:42 and "convert" could be akin to "cast" 10:19:55 Yep. 10:20:07 And if your stack contains malloced objects, you'd want to be able to delete them too. 10:20:18 And if it's a user-defined object, the interface is the way to go IMO. 10:20:20 hmm - you need to get yer source visible, I'm working HARD to visualize this and how to exploit it. 10:20:39 I wish I could... it's currently just in my head ATM. ;) 10:20:49 yeah, sorta' a perverted twist on vompiler-words, verbs, etc 10:20:51 Forthy currently uses int tags like you described. 10:21:06 vomp/comp 10:21:27 NO, I sorta' like yer idea 10:21:54 prolly the issue is in my head where 'interactive' and 'compiler' start to meld and slow down. 10:22:39 See..? I have this "issue" wherein I want decent interaction, but know humans are slow; and 'fast' where we've already been thru this mess. 10:23:01 hmm.. 10:23:27 ok, wait - brainfarting... 10:23:56 Heh. 10:24:12 typedef ala' C.. size, immed/preproc(), literal() ptrs 10:24:47 interactive uses the vtable and var; COMPILED uses a vector and literal 10:25:03 ok, NOW it's percolating better 10:25:18 interesting 10:25:33 Hmm. 10:25:45 what would you use for generic versus "I already pushed that, biotch!"? 10:25:56 brb 10:25:56 Not sure what you mean... 10:37:01 hmm 10:37:16 I thinkI see it, now.. (had to help with groceries) 10:37:54 There is at least one prob with the datastack as-is-common. 10:38:18 That is, you expect N inputs - and there is no typing. 10:38:40 if there are N+, fine; N-, fail - otherwise trust them. 10:39:48 "you" expect N inputs... who? 10:39:57 What we NEED is to differentiate generic input from typed input or output 10:40:05 any word 10:40:10 ?params 10:40:26 yeah, again: this merely tests count 10:40:57 have you ever had gcc and the new warnings for *printf/*scanf scream at you? 10:41:19 Make a word to test the stack parameters then. 10:41:21 args( int float int int string ) 10:41:30 Something like that. 10:41:36 And, no to your question/ 10:41:40 yes, but it's ugly 10:42:06 ahh, well trust me: it can be useful - but there is at least one fmt where it ALWAYS whines and whimpers 10:42:16 func: foo args( int float int int string ) 10:42:22 Doesn't look too ugly to me... 10:42:44 : foo (( int float int int string )) 10:42:46 yeah, but you are now reusing '(' and ')' and back to tags 10:43:01 --- join: alex4nder (~alexander@69.17.112.153) joined #forth 10:43:02 hey 10:43:06 I mentioned awhile ago I found the { locals --- } shit interesting 10:43:18 Yea, so make your own version for testing types. 10:43:26 Like I just pseudocoded above. 10:43:30 we need also anon-var, and yes: something for stack-typing 10:43:35 It's Forth, you can make it look however you want. 10:43:51 anon-var... like >R R> R@ 10:43:56 yes, but I am DISCUSSING this with you 10:44:09 no, more like C frame/local vars 10:44:43 you need foo[3] and n-p all of int, lets say 10:44:54 W/O all the damned gymnastics 10:45:26 the gymnastics are fine for what we'd consider cpp/ipc 10:45:57 but, presume you may need a few temps for local-use PLUS the locals-gig. 10:46:32 the temps live only as long as the word is running 10:46:45 (stackframe) 10:47:03 the locals are shit passed in that we expect to consume or pervert 10:47:28 hell, you may leave behind more than you consume 10:48:11 Two stacks. 10:48:18 so, { A B C --- } is insufficient, but the solution starts to merge with yer idea 10:48:24 Anon locals stack, and data stack. 10:48:26 yeah, I am thinking of that as well 10:50:31 But, it does make life interesting 10:51:32 it may even be that we can use the core of the { stack --- } system and ADD locals. 10:52:01 ..sweeping away all that do not exist on the right side 10:55:10 consider.. ": type { z:s n:x --- } ..." and even here ," test" .s <1> 208368 ok 10:55:10 count ok 10:55:10 .s <2> 208369 4 ok 10:55:10 followed by { z:s n:x --- } 10:55:28