00:00:00 --- log: started forth/05.08.26 01:06:09 --- quit: crc (Read error: 110 (Connection timed out)) 02:30:46 --- quit: YoyoFreeBSD_ (Read error: 110 (Connection timed out)) 03:04:31 --- join: qFox (n=C00K13S@92pc222.sshunet.nl) joined #forth 03:33:15 --- join: amca (n=plump@as-bri-3-171.ozonline.com.au) joined #forth 03:35:28 Gday 03:45:47 mornin :) 03:46:27 Evening here :) 03:48:10 Is there a difference between "variable foo 10 , 20 ," and "create foo 10 , 20 ,"? 03:49:03 yep 03:49:11 What is it? 03:49:20 "variable foo" is equivilent to "create foo 0 ," 03:49:45 Ah 03:50:17 So variable initialises the first array position? 03:50:44 it's usually used when you just want one 03:51:16 Or do you mean "variable foo 10 , 20 ," would allocate space for 3 numbers whereas "create foo 10 , 20 ," allocates space for only 2? 03:51:36 right 03:51:48 I'm not entirely sure the first would work in all forths 03:52:07 It does in gforth 03:52:14 it's possible the space for one number allocated by "variable" would be in a different place in some forths maybe 03:52:18 maybe 03:53:04 well, gotta run. ttyl 03:53:21 http://rafb.net/paste/results/8wyHhr52.html 03:53:25 ok bye 04:56:29 --- quit: amca ("d34d") 05:31:39 --- log: started forth/05.08.26 05:31:39 --- join: clog (i=nef@bespin.org) joined #forth 05:31:39 --- topic: 'Forth: One language, many dialects. #forth - general forth discussion. #c4th - ColorForth. #retro - RetroForth. #c4th-ot - social channel. #1xforth - a secret channel for 1xforthers. #concatenative - the category of language that forth belongs to (sorta).' 05:31:39 --- topic: set by crc on [Sat Jul 23 13:29:38 2005] 05:31:39 --- names: list (clog skylan qFox ianp @JasonWoof warpzero ccfg OrngeTide saon docl Raystm2_ Snoopy42 virsys slava saon|fbsd Jim7J1AJH I440r Quartus onetom) 05:34:09 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 05:34:54 --- nick: Raystm2_ -> nanstm 05:35:21 --- quit: cmeme (Client Quit) 05:36:04 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 05:37:18 --- quit: cmeme (Client Quit) 05:38:01 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 05:39:14 --- quit: cmeme (Client Quit) 05:39:56 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 05:52:59 --- join: YoyoFreeBSD_ (n=yoyofree@222.90.3.96) joined #forth 05:57:22 --- join: snowrichard (n=richard@adsl-69-155-177-155.dsl.lgvwtx.swbell.net) joined #forth 06:06:22 --- join: madwork (n=madgarde@derby.metrics.com) joined #forth 06:25:34 --- quit: I440r ("Leaving") 06:48:08 --- join: PoppaVic (n=pete@0-1pool46-103.nas30.chicago4.il.us.da.qwest.net) joined #forth 06:48:29 G'day 06:49:05 hi 06:54:45 --- quit: snowrichard ("Leaving") 07:03:54 --- join: snowrichard (n=chatzill@adsl-69-155-177-155.dsl.lgvwtx.swbell.net) joined #forth 07:05:17 --- quit: snowrichard (Client Quit) 07:08:20 --- join: snoopy_16 (i=snoopy_1@dsl-084-058-160-031.arcor-ip.net) joined #forth 07:09:50 --- join: sproingie (i=foobar@64-121-15-14.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 07:09:59 Mornin' 07:10:40 morn 07:11:31 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 07:14:49 --- quit: Snoopy42 (Read error: 60 (Operation timed out)) 07:15:02 --- nick: snoopy_16 -> Snoopy42 07:18:37 --- join: derv0 (n=derv0@proxy1.nscl.msu.edu) joined #forth 07:23:20 --- join: virl (n=hmpf@chello062178085149.1.12.vie.surfer.at) joined #forth 07:29:35 --- quit: qFox ("this quit is sponsored by somebody!") 07:42:26 --- quit: PoppaVic ("Pulls the pin...") 08:07:11 --- join: bigPoppi (n=derv0@proxy1.nscl.msu.edu) joined #forth 08:09:18 --- part: bigPoppi left #forth 08:10:42 --- join: bigPoppi (n=derv0@proxy1.nscl.msu.edu) joined #forth 08:16:18 --- quit: derv0 (Read error: 110 (Connection timed out)) 08:46:06 --- join: PoppaVic (n=pete@0-2pool198-51.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:49:17 I miss anything invigorating? 08:52:06 nope, dead calm all morning 08:52:15 dang, that's sorta' depressing 08:52:33 except amca was asking if there's a diff between create and variable 08:52:50 hehe - I'll bet that was confuzzling ;-) 08:53:04 actually in retroforth, create just makes a stub whereas variable actually allots space 08:53:24 yeah, it varies all over 08:53:32 I think variable is create allot or some such 08:53:44 it certainly can be 08:54:32 I've been looking over my stuff (again), and thinking of tathi & sproingie... Also double-thinking the database-idea 08:54:46 in #perl they were talking about bear-baiting 08:54:52 .sigh 08:55:00 perl... What a waste 08:55:05 hehe 08:55:20 folks always forget the purpose of the stupid language. 08:55:25 pragmatic and easy to learn, what's not to like? 08:55:40 :P 08:55:45 not to like... Um, I avoid it like plague 08:56:07 mostly because it almost makes C look attractive 08:56:40 nah, all that meaningless structuring and casting you have to do in c is automated in perl 08:56:53 it isn't meaningless ;-) 08:57:08 and, yes - perl will holdyer hand nicely 08:57:51 of course python does about as well if you're not into messy coding 08:58:01 I believe about 70-89% of the complaints about C come from kids that started out in perl, python, php or some sorta' doze-script 08:58:10 yup probably 08:58:40 as I did, since I had no easy alternatives 08:58:42 "why do I have to {allocate, free}?" "WHY can't I return an array?" 08:59:42 yeah that's probably why I have a mental block against c to this day. I'm too used to hand-holding 09:00:33 but I'm starting to get the picture on why things go the way they do in c and other medium-level languages 09:00:56 yah 09:01:08 I will guarentee forth-guts help that along 09:01:59 I was discussing with madwork on #retro about the idea of making executable delimiters, so not everything needs a space 09:02:09 heh 09:02:13 Good luck there 09:02:14 would be necessary if I want to emulate the feel of other languages 09:02:24 Yes, I've got it on my agenda 09:02:51 it necessitates a better parser-systemology 09:02:54 we might need to switch to a hashed dictionary for speed. I'm reading the wiki entry on hashes now 09:03:10 Need to lookup every character as you parse it, essentially. :) 09:03:20 (depending on state) 09:03:25 I don't really understand hashing in my guts, I always think of balanced-trees 09:03:37 I understand hashing. If you get stuck let me know. 09:03:48 madwork: right, and I sorta' plan to make it possible to switch testers/parsers in and out 09:03:53 --- quit: bigPoppi ("Client exiting") 09:04:05 we're thinking newbies might be more comfortable with other syntaxes than : ; like maybe c{ }c and the like 09:04:12 sure 09:04:28 Tis what I started to do for my minish sub-project 09:05:00 docl: it also - done properly - can clean up semantics and syntax. 09:05:30 thing is there are good and bad hash algorithms, and you have to use the right ones to get any kind of efficiency 09:05:49 yeah, that's the primary reason I just use avl-trees 09:06:31 Go for *very* simple. You're effectively hashing English text, when hashing a Forth dictionary. Multiply each character by a small prime and add; you'll find you get very good distributiojn. 09:06:34 -j 09:06:52 yeah, I've tried both. 09:07:07 hash functions for single-character delimiters should be simple. 09:07:20 I've tried that sorta' hash and then LL, and it works. 09:07:22 Er, sorry. Painkillers. Add each character and multiply the sum by a small prime. 09:07:46 ..but a tree is just as easy to my mind - of course, I *LIKE* reusable code 09:07:52 If you use a heavy hash algorithm, you'll a) not get any better distribution and b) waste time, when the whole idea is to speed things up. 09:08:00 yep 09:08:24 I also recommend hashtable sizes that are a power-of-two. This is contrary to the texts, but it works fine. The texts are wrong. 09:08:30 to be honest, a mmap'd binary datafile is prolly even more economical 09:08:47 Quartus, I came up with a hash function that works well on power-of-two sized tables a little while ago, plus it's fast. 09:09:04 I'd like to see it. 09:09:30 heh - I use 2^ often, but... I found that using some prime value in there does balance the array better 09:10:09 Yes, as long as you're not using a prime-sized table and doing a modulus on the hash value. :-& 09:10:19 the kicker, to me, is to blackbox whatever you can 09:10:36 Quartus, let me track down my function... 09:10:38 aye, as long as it's good 09:10:49 Division is slow. 09:10:58 madwork: nah, I can't recall the funcright now, but I believe I hashed char-groups into a prime-sized array of tree-roots 09:11:21 seems like duplicating the symantics properly, you could import code from any language 09:11:29 yep 09:11:39 or a damn good subset 09:11:47 Quartus, look at hash_rand8(), hash_rand9(), and hash_rand0() on this page: http://www.freelunchdesign.com/cgi-bin/codwiki.pl?PaulPridham/CodePaste 09:12:02 then we'd almost instantly have the whole GNU+ collection of open source stuff for retro 09:12:19 or quartus, factor, etc. 09:12:38 sure - did that suprise you? 09:13:09 kinda. it hasn't been done has it? 09:13:21 docl: be advised, this is what doze does for all their stupidscript-engines. 09:13:24 madwork, that's the idea. Even smaller multipliers work with Forth. 09:13:38 you use a basic VN and all other shit must go thru the vm-universe 09:14:02 VN/VM 09:14:23 ok, cool. so that's kinda what cygwin does? 09:14:24 docl: it's what I'd like to get done for *nix, too 09:14:49 particularly if we can expect/offer translation INTO a proper, lower language 09:15:33 so, sure - emulate/interpret/forth "compile"... and also offer an exporting-capability, like gcc tries with asm 09:16:19 When testing hashfunctions I compared against a hashfunction built with the MersenneTwister; can't do any better than that for distribution. 09:17:04 Quartus: I'd still say it should be blackboxed 09:17:18 Something's gotta be inside the box, whatever colour it is. :) 09:17:35 like with libdb, it should be damn-near invisible 09:18:24 Quartus: hell, sure... basically it's all key/value add/remove/find/create/delete 09:18:44 Quartus, I was thinking of trying the MersenneTwister for hashing too. But the rand calculation I do is simpler, and it's only a one-time hit. 09:19:02 madwork: all the work up front? 09:19:02 hash_rand8() turns out to be a little bit faster than superfasthash. 09:19:28 PoppaVic, at the end, but yea. 09:19:53 yah. so, "get a name", smurf!, lookup. 09:20:26 hash_rand0() would be the best one to adapt to a single-character delimiter lookup. 09:21:06 I'd be suprised if you even let them know it's 1 char. There is no need-to-know for blackboxing 09:21:08 I'll have to test it though, to see how distribution is over the range of 8-bit numbers. 09:21:10 different hash algorithms go better in different situations 09:21:18 docl, yep. 09:21:28 docl: sure, they all say that ;-) 09:21:34 so label the blackboxes with stats or something 09:21:41 hmm? 09:21:55 docl: all you dois specify an input and an output 09:21:59 PoppaVic, it only needs to be one char for simplicity. if the delimiter wants to belonger than 1 char, it can handle that case when it executes. 09:22:13 you need to make sure they can pick the right one for the job, right? 09:22:26 madwork: absolutely - what I mean is the bb can use 1 - or N - the user has noNeed To Know 09:22:43 Sure. 09:24:00 so, "+" and "+!" may be in the same hash, or the same tree, or different hashes/trees - all we care is "feed it" +"expect" = "returning" 09:25:07 docl: this is also why Bog created vectored-functions ;-) 09:25:53 Bog? 09:26:13 I think vocabularies are the best way to handle different syntax. 09:26:24 well, God, gog/magog are busy 09:26:28 hehe 09:26:50 madwork: yes, I'm considering a scanner/parser func-ptr for them, too 09:27:47 ..add in the search-order stack and shit, and it seems likely to me we can get along nicely w/o lex andgoddamnedyacc 09:28:07 Damn skippy. 09:28:28 Or "pee" and "poo" as I like to call them. 09:28:28 well, I LIKE delegation and structures 09:28:57 folks just never seem to grok "context structures" 09:29:20 ..close as they come is goddamned C++ and "Classes" 09:29:44 hmm context structures. nice idea 09:30:33 docl: very, very old 09:30:45 What do you mean by "context structures?" 09:30:48 predates C++ by a long margin 09:31:15 madwork: a structure passed to a collection of funcs so they are all working together. 09:31:29 or a *, actually - same-same 09:31:53 The only drawback is it immediately costs an arg in C 09:32:18 in a VM, well - perhaps it is a member of the "global" struct 09:32:43 Ahh. OK, I do this all the time. 09:32:48 sure 09:32:58 anyone that likes reusable code learns it asap 09:32:59 It's the "this" in C++ 09:33:04 righto 09:34:08 Context structure with a pointer to a vtable, I think we were talking about this a while back, PoppaVic. ;) 09:34:51 yes, add a vtable* and you now have a compact, method-func system embedded as well - well beyond C and forth deferred 09:35:39 I have been thinking about these things for years and years... I LIKE forth, and I LIKE C - but neither ever seems to learn from the other. 09:37:02 I'd even be happy to have a decent forthish shell/interp and live there while being able to say "there! now generate my C source!" 09:37:07 hashing? numbers as word names are faster ;-) 09:37:27 numbers as delimiters, ick. 09:37:49 no, he means like (int)"expect" 09:38:11 that really does no good at interpret-time. 09:38:29 You still have to look up "expect". 09:38:32 it's another of those "hashes are tossups" things 09:38:59 no, no - "expect" is a string: treat N characters as components of an int at that place 09:39:08 Ahhh... but, if you don't mind having a 256-entry table, then delimiters can just index directly into it by ASCII value. 09:39:15 yup 09:39:17 wouldn't an escape character (like \) make delimiters possible without checking every single character against an entire hash? 09:39:30 How? 09:39:31 foo: 09:39:35 folks are abusing the term "delimiter" 09:39:38 foo\: 09:39:48 docl: why bother? 09:39:50 So, you want to define new words this way? 09:40:04 I meant ': 123 ;'(but in bytecode) 09:40:25 docl: I already told you - we'd certainly want a better, distributed scanner/parser 09:41:06 ..and, certainly we could care less if 'compiling'/'interpreting' wastes a few millisecs 09:41:06 yeah 09:41:26 once we have a word built, THEN we want the sob to run like a bat outta' hell 09:41:34 which syntax do you want` 09:41:42 `=? 09:42:29 docl: one of the ways it seems quite possible is to segregate "operators" into a voc 09:42:52 and why should be numbers as word names be tossups? they would really speed up lookup 09:44:11 harder to remember 09:44:18 docl: recall that almost all forths use a (can't recall the func) ' ' word-parse sorta' thing.. the topmost int on stack is delimiter. it's a really limited system 09:44:33 wsparse ? 09:44:38 virl, if you want to use numbers as word names, compile them literally. This can already be achieved. 09:44:42 not on my machine, but sure 09:45:14 32 parse foo 09:45:21 I hate it when people don't understand me... I said that all the time 09:45:32 docl: now, if the entry was a ptr to a string where ANY is viable as a delimiter, and you can also check a VOC for a complete word... Yer stylin' 09:45:46 sorry virl 09:45:51 madwork: thanks, been awhile ;-) 09:46:11 virl, but direct compilation isn't really making use of language extension capabilities... it doesn't improve things for the average user. 09:46:27 I use it in my bytecode vm to define new words, and a vm which interprets bytecode doesn't need that big uplooking mechanism. 09:46:40 Certainly not! 09:46:53 But, I think we're discussing a higher-level of user interface mechanism here. 09:47:03 Not the Forth writer, but Forth user. 09:47:24 union { char buf[MAXWORD]; int hashish; } 09:47:47 I don't know that, I overread that sry. 09:48:16 but, the guts are guts - blackboxing is ALWAYS sensible 09:50:04 One of the issues with forth is allowing full low<->high in the same voc - it becomes hard to mentally track value from noise. 09:50:38 hmm yeah blackboxing in forth isn't always done enough 09:50:48 well, it's the same in C 09:51:03 virl, the main concept that I brought uplast night in #retro is that if you have executable delimiters, then you can do stuff like this: 09:51:04 foobar: 123 . ; 09:51:04 The : would be an executable delimiter, and parse backwards in the input stream to read the name of the new word definition. 09:51:27 ...I already did my screaming about functions doing loops in loops to loop and reloop - mention some should be funcs and they smirk about "Mr. Pascal" 09:51:53 madwork: HORRIBLE sematic, anywhere 09:52:13 PoppaVic, eh? 09:52:28 going forward to go back and then forward - nasty 09:52:50 : foo 123 . ; istrivial - he needs to consider some better examples 09:52:55 This is how it must be done with a one-pass compiler. 09:53:09 yes, and god save us from 1-pass 09:53:13 foo( int a, char b ) 09:53:28 There you go. 09:53:50 And I don't fear controlling the input stream, I think it's quite a powerful ability. 09:54:02 how about this: "uname -a 2>/dev/null" 09:54:12 BAS{ print "Hello" }BAS 09:54:33 Yes, " is another case. 09:54:45 above offered several issues, yes - " is one of them ;-) 09:54:52 " delimiter parses ahead until it sees another " No trailing space required. 09:54:57 C{ void main(void) { printf "Hello\n"; } }C 09:55:23 docl: this is not a bother to me, I can envision it. 09:55:30 system("uname -a 2>/dev/null") 09:55:47 ahh 0 NOW yer hurting - switch to popen ;-) 09:55:53 heh 09:56:09 this is where I'd like to thrash the vm/forthish guts 09:56:21 This stuff simply enables easy infix/prefix notation. 09:56:27 sure enough 09:59:32 madwork: .... " INFIX: ..... ; ;INFIX ..... ; : CINFIX .... ;" ;-) 10:00:49 although, I suspect "INFIX:" should just run to EOL 10:01:22 somehow it looks horrible 10:01:29 Heh, yea sure... but then you need to write an actual infix parser in there, which is more work than using smart delimiters. 10:01:44 the good old C looks better 10:01:59 madwork: you misunderstand... it'd trigger those vtable-settings we'd spoken of ;-) 10:02:37 which would mean the delimiters could be used in multiple-contexts ;-) 10:02:47 INFX{ ... }INFX 10:03:32 docl: yet, "}INFIX" is a substring, not a char-trigger (see where we are going?) - It might not work as wanted 10:04:08 I do believe, however, that yer attempt sorta' points out the crux of the issue 10:04:33 we need to damn-nearly get a lex-like system in place. 10:04:38 Well... with the basic, simple smart delimiter functionality, anything could be built upon it. 10:05:01 So, lex-like whatever can be an additional lib, or not. 10:05:06 yes, madwork - using a delimiter-voc and sub-parsers? 10:05:24 The delimiters themselves are the sub-parsers, yes. 10:05:50 yer assuming - what - for a "delimiter", assuming we are gathering a string into a buffer? 10:06:02 Yes, the input stream. 10:06:03 forward parsing would be better than the backward thing. 10:06:15 And the backward parsing isn't really backwards at all... 10:06:18 it's the current token. 10:06:23 right 10:06:24 We're still matching it! 10:06:37 yep. Just trying to envision the flow 10:06:37 When we reach the delimiter, we just handle the token as it is, however we see fit. 10:06:45 And the delimiter can call EVALUATE or whatever they need to in order to get the job done. 10:06:54 right.... I think 10:06:55 It's extremely simple. 10:07:27 well, writing for lex IS simple. Doing anything from there can suck 10:07:28 Delimiters are fully qualified words in their own right. So they have all the power of Grayskull during parsing. 10:07:52 Yea, but that's not our problem. ;) It's the problem of the language writer. 10:08:02 Delimiters gets them there much more easily. 10:08:07 ahhhh hehe - shovel it off, eh? ;-) 10:08:15 YES, dammit! ;) 10:08:18 I can't follow your thoughts, please describe it clearly so such a natively german talking person with not perfect english abilities can understand you ;-) 10:08:35 The lang itself should offer the proper demonstrative examples, mind you ;-) 10:08:36 virl, I have that problem with PoppaVic as well. ;) 10:08:49 PoppaVic, sure. 10:08:52 * PoppaVic spanks mad ;-) 10:09:05 It could come with an infix math vocabulary, or a subset of BASIC. 10:09:19 BASIC would be great, actually, to welcome the newbies to the system. 10:09:38 And imagine a language-extensible BASIC! 10:09:45 I honestly think that the parsing/scanning and vocs/words/immediate needs a rebuild.. It's a pardigm-shift, and it deserves a lot of cogitation. 10:09:54 Yep. 10:10:29 madwork, please not another Java/Python/PHP/etc. please 10:10:56 it seems to me that we start out with a forthish parsing, to get the basics cheap. 10:11:14 ..and the complexity needs to evolve/build 10:11:41 a forthish parsing? you mean wordword... 10:12:00 virl, well my point is not to design a new language. 10:12:11 My point is enable Forth to easily allow this flexibility of extension. 10:12:19 Trying to envision forth/vocs behaving like mini-lex .l files can be a bit confuzzling 10:12:42 The vocs would simply be the language context. 10:12:58 madwork, which extension? another syntax? or to change forths syntax into anything elses syntax? 10:12:59 oh, well shit.. I have no prob thinking "new language", but mostly it's building in elements and tools that can BE used 10:13:14 You could, of course, use the facility to create a lex/yacc for creating new language vocs. :P But that would be typical overdesign. 10:13:27 madwork: remember, I mentioned vocs might have their own vectored-funcs ;-) 10:13:43 virl, yes to both questions. 10:14:08 PoppaVic, why would it matter what was in the voc? It's flexible, put what you want in there. 10:14:36 no, I mean an element OF the voc - that means switching to it from the CLI or the search-order ;-) 10:14:37 virl, but mostly to allow someone to create a new language syntax on top of the Forth. 10:15:02 madwork, that means seperating syntax from functionality. 10:15:15 How so? 10:16:09 One of the issues Ican easily envision is.. it means that you'd need a special colon-word sorta' thing for any 'word' having a delimiter-embedded. 10:16:32 Only if the vocabulary that the delimiter exists in is in the search order. 10:17:06 Really people, this is the simplest idea. These delimiters don't even have to be used. The most basic situation is that of a regular Forth syntax, and the default delimiters used are whitespace. 10:17:20 how about any word between { } or words including them, gets parsed more closely. stuff not in curlies stays as regular forth with just wsparse 10:17:20 because you need basics from where you could build a new syntax, like that the output operator must have a basic form. it's like mathematic which their fundamentals which would crash mathematic when they would be wrong. 10:17:23 yeppers, but I was considering "Let us consider "[](){};;\"\'" 10:17:28 Now if someone wants to extend the language and not be tied to purely-whitespace delimiting, they can. 10:18:09 madwork: I cannot remotely denigrate whitespace-as-easy, it just screws up advanced infix 10:18:25 That's why you need smart delimiters. ;P 10:18:43 yes, and a smart-scanner 10:18:49 and a smart ass! 10:19:10 Well the smart-scanner looks up the delimiters as it looks up tokens. 10:19:17 I am sorta' "seeing" a delimiter-array and a delimiter subvoc 10:19:28 yeah 10:19:43 but it should be optional 10:19:44 If the only delimiter was whitespace, then the whitespace delimiter, when executing, would look up the rest of the characters in the current token and execute/compile. 10:19:50 you'd check charset-delim, then delimiter-voc, then voc-order 10:20:22 FOO 10:20:32 heh 10:20:33 executes, FINDs FOO in teh dict, compiles it. 10:20:42 This is essentially what already happens. 10:20:59 Except that it's usually a special-case handling of whitespace, specifically for dictionary lookup. 10:21:04 yep, because was either in the delim-charset, or a delimiter-voc word 10:21:08 Yep. 10:21:08 hmmm 10:21:20 ok, then we need a GOOD parser for : 10:21:32 So, you put in , alias and etc. to , and yo uhave normal Forth operation. 10:21:38 basically, we need an escapish-system for 'words' 10:21:46 a { word would just vector the wsparse to look in it's preferred delimiter vocabulary 10:22:09 PoopaVic, example? 10:22:15 then } would devector it 10:23:20 the new vector func in retroforth probably makes all this stuff easy 10:23:49 ok, wait a sec - I've a brainfart working 10:23:58 basically any word cen be pointed to a custom value, then reset to the default when it's done 10:24:32 vectors? why the hell vectors? 10:24:35 1) we are coming quite close to the goddamned issues with urls and idiot "folders" with the comline - where a space can ruin yer day 10:25:24 2) we are starting to talk about a different sort of lookup, too: sorting longer-words foremost (like lex) 10:25:58 hmm 10:26:33 madwork: oh, I was thinking of the sorta' '%20' workaround of urls or string-quiting for shells 10:26:48 quoting, two 10:27:08 It's a very weird situation 10:27:26 Not sure why that would be an issue. 10:27:30 you have to tokenize things somehow 10:27:39 In fact it's not at all, because you have control of delimiters. 10:27:40 spaces are easy on the eyes 10:27:47 The current forthish mess is pretty well THE most flexible, if uncomfortable 10:27:49 Also, you can parse-ahead as in normal Forth parsing. 10:28:05 The infix-mess almost makes lexx glow 10:28:36 madwork: well, recall: there are several TYPES of "delimiter" - they can be chars or substrings 10:28:59 Well, the true delimiter is just a char. 10:29:05 Then that delimiter parses its own substring. 10:29:10 or, unifying it: a delimiter is a string of 1...N chars 10:29:14 So if it wants to skip spaces, it's well and dandy. 10:29:36 yeah, thisis what I am cogitating 10:29:44 A delimiter should always be 1 char. 10:30:03 And since it's a fully qualified word, it can do anything from the point it executes. 10:30:11 however, getting a colon-def for a control-char is amusing, I'm trying to think how that'd best work 10:30:13 It could interpret the rest of the Forth program, for all it matters. 10:30:31 Putting the name before the colon instead of after. 10:30:51 in fact, getting a ^c embedded IN a word is also legal (and obtuse), then 10:30:55 Yep. 10:31:00 Could also go Unicode. :) 10:31:06 Woohooo, Wingdings! 10:31:08 not today, please 10:31:12 ;) 10:31:41 : Ö¯Ñ ... ; 10:31:49 I'm trying to envision the current forth declarators, and twist it... 10:32:07 It almost suggests a cpp sorta' layer 10:32:09 This would be a nice word def syntax: 10:32:16 foo{ 123 . cr } 10:32:28 I could live with it, yes 10:32:41 But, it makes me think, also... 10:32:46 foo { 123 . cr } 10:32:51 "undefined" at '{' - soo? 10:32:52 This would be an error. 10:32:59 undefined at 'foo' 10:32:59 hmm,cppdoes that now 10:33:11 right 10:33:21 But you simply need to be able to handle this in the whitespace delimiter! 10:33:32 yes, I see the pt 10:33:52 So it's quite powerful in its simplicity. 10:34:01 it's interesting, yes 10:34:12 it frees up multiple chars themselves, too 10:34:15 * madwork has dibs on the patent. ;) 10:34:56 oh, hell - I looked at it all years ago -let's not get greedy ;-> I'd rather pervert the next few generations! ;->> 10:35:07 why not code { to look backwards for foo? or foo to look forwards for {? 10:35:24 docl, that's what I was saying for { 10:35:28 Same as foo: 10:35:45 ok 10:35:47 and could take "foo" and look forwards for a delimiter before giving up an error. 10:35:54 (if you wanted to go that far) 10:35:58 docl: I'm beginning to think we need to, essentially take control of word-use-of []{}() sorta-things, and consider nesting 10:36:10 This would allow both foo{ 123 . cr } and foo { 123 . cr } 10:36:15 yeppers 10:36:47 Could also do interesting things with . 10:36:49 foo.bar 10:36:53 123.456 10:36:54 madwork: I also have no issue with acting like cpp with foo