00:00:00 --- log: started forth/19.01.03
00:27:43 --- quit: pierpal (Quit: Poof)
00:28:03 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
00:51:54 --- join: xek (~xek@apn-37-248-138-83.dynamic.gprs.plus.pl) joined #forth
02:03:44 --- quit: ashirase (Ping timeout: 246 seconds)
02:06:58 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth
02:17:18 --- quit: rdrop-exit (Quit: Lost terminal)
02:19:11 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
03:08:42 --- quit: proteusguy (Remote host closed the connection)
03:16:32 <the_cuckoo> woot - got one of my colleagues to test rpany on windows - some minor changes forced on me there, but mostly just corrections anyway - that's ... unusual
03:16:37 --- quit: proteusguy-ad (Ping timeout: 250 seconds)
03:28:44 --- join: proteusguy-ad (~yaaic@cm-58-10-154-246.revip7.asianet.co.th) joined #forth
03:58:29 --- quit: dddddd (Remote host closed the connection)
04:32:23 <corecode> hi
04:36:47 <crc> good morning corecode
04:38:56 <corecode> oh ttmrichter is around
04:43:48 <john_cephalopoda> https://hackers.town/@nobody/101349154586584167 :D (+ thread)
04:45:18 <ttmrichter> corecode: I'm very sensitive about my weight.  Please stop commending on it.  :D
04:54:13 <john_cephalopoda> The Apollo Guidance Computer had 2 MHz, 4KB of RAM and 72KB of ROM. The Intersil RTX2010, which has been used on Philae and has been in production since 1988, has a CPU clock speed of 8 MHz, two 256 (16-bit) word stacks.
04:54:38 <john_cephalopoda> I couldn't find information on possible memory configurations yet.
04:57:54 <john_cephalopoda> But since the address width is 20 bit, a bit over 1 MB should be available.
04:59:20 <john_cephalopoda> Pretty cool: http://soton.mpeforth.com/flag/jfar/vol6/no1/article1.pdf
05:10:34 --- join: proteusguy-ad2 (~yaaic@2001:44c8:428c:a866:1:1:e82f:ec7d) joined #forth
05:12:45 --- quit: proteusguy-ad (Ping timeout: 250 seconds)
06:19:22 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth
06:42:51 --- quit: proteusguy-ad2 (Read error: Connection reset by peer)
07:06:30 --- join: plugd (~plugd@bsse-bs-dock-dhcp-263.ethz.ch) joined #forth
07:16:02 --- join: Kumool (~Khwerz@adsl-64-237-235-38.prtc.net) joined #forth
07:39:12 --- quit: plugd (Remote host closed the connection)
07:43:41 --- quit: tabemann (Ping timeout: 272 seconds)
07:46:57 --- join: xek_ (~xek@37.248.253.89) joined #forth
07:49:10 --- quit: xek (Ping timeout: 245 seconds)
07:51:15 --- quit: Kumool (Ping timeout: 245 seconds)
07:53:29 --- join: Kumool (~Khwerz@adsl-64-237-234-233.prtc.net) joined #forth
08:40:03 <PoppaVic> The sad part is, while it looks nifty - try to buy a handful.
08:41:25 <john_cephalopoda> Radiation-hardened hardware for space applications. Of course that stuff is expensive as hell.
08:43:09 <PoppaVic> THey don't have to harden ALL production-runs ;-P
08:44:18 <john_cephalopoda> Radiation-hardening is in the design from the beginning.
08:45:00 <john_cephalopoda> They use a giant process with large transistors in order to have maximum resistance against radiation.
08:45:54 <john_cephalopoda> Also I doubt that there is a market for a non-radiation-hardened 8MHz CPU with a Forth-like instruction set.
08:50:52 <corecode> how would you call a word that acts like R@, just on the second item on the return stack?
08:51:49 <corecode> maybe i should have RPICK
08:53:30 <PoppaVic> I, J, K ;-)
08:59:33 --- quit: X-Scale (Ping timeout: 244 seconds)
09:08:14 <Zarutian> corecode: well ROVER of course!
09:08:41 <Zarutian> just dont get run over by it, eh
09:16:53 <john_cephalopoda> CURIOSITY ROVER
09:17:07 <john_cephalopoda> I bet there's some rover that runs Forth :þ
09:17:27 --- join: X-Scale (~ARM@31.22.200.7) joined #forth
09:18:10 <john_cephalopoda> Zarutian: I'd expect ROVER to do OVER on the return stack. Maybe ROVER@ would be clearer.
09:20:27 <PoppaVic> and, this is what I and J do, afaik
09:27:01 --- quit: dave0 (Quit: dave's not here)
09:47:44 --- join: dys (~dys@tmo-103-124.customers.d1-online.com) joined #forth
09:50:00 <the_cuckoo> i know it's not normal forth, but is there really any reason why you can't define a dictionary like : new-dict : word1 blah ; : word2 blah ; ; - ie: defer creation of word1 and word2 until execution of new-dict
09:50:36 <zy]x[yz> no
09:51:13 <zy]x[yz> I mean, you would need some way to tell it not to enter compilation mode after "new-dict", but conceptually there's no reason why you can't do that
09:51:17 <PoppaVic> I don't understand yer syntax, but it sounds like you want deferred words
09:51:45 <zy]x[yz> no he wants to nest words inside the definition of new-dict to syntactically encapsulate his dictionary
09:51:55 <zy]x[yz> (i think)
09:51:56 <PoppaVic> ah
09:51:57 --- join: mahmudov (~milisman@5.176.12.195) joined #forth
09:52:01 <the_cuckoo> yup
09:52:25 <PoppaVic> I've never seen a good system for that, although the standards and gforth suggest wordlists
09:52:30 <the_cuckoo> i know there are other ways to do it, but just talking about the syntatic form - gforth rejects it anyway
09:53:34 <zy]x[yz> might be easier to do something like "dict foo { : word1 blah ; : word2 blah ; }"
09:53:55 <the_cuckoo> hmm
09:54:45 <zy]x[yz> you might could also do ": foo { ... } ;", where { would be an immediate word to patch the previous word to be a new dictionary and then leave compilation mode
09:55:49 <zy]x[yz> this is kind of why I built mine the way I did: ":" only creates a new word, but doesn't enter compile mode.  instead, after creating the word you define what it does, and you use "does" to enter compilation mode
09:56:48 <zy]x[yz> so my forth does have stuff like  : foo 1 , 2 , 3 , ;  or sort of a structure syntax (which I don't like and plan to get rid of):  : point { : x cell field ;  : y cell field ; } ;
09:56:53 <the_cuckoo> mostly thinking about my own parser of course - naturally, it feels to me that the embedded : ... ; stuff in a word should just work (as i'm now considering the proper parsing side of things :))
09:57:23 <PoppaVic> sounds like you just need a VOC! word
09:57:35 <the_cuckoo> got an example?
09:57:41 <PoppaVic> just define a word, and then <somevoc> VOC!
09:58:03 <zy]x[yz> the problem is that, using traditional forth syntax, if you write  : foo : bar ; ;  is that the definition of the word bar nested in the word foo, or is that the word foo which calls ":", and then calls "bar", and so on?
09:58:19 <PoppaVic> although this is exactly why we have a vocstack current and context
09:58:21 <zy]x[yz> (with traditional forth it's the latter)
09:59:59 <PoppaVic> or, you can define your own syntax, so the solution is: ": VOC:WORD ... ; ;-)
10:00:15 <the_cuckoo> :)
10:01:27 <the_cuckoo> yeah - there seem to be a number of ways to tackle with word definitions - i think my implementation (which i haven't done yet) would support the inner : ... ; stuff out of the box
10:01:45 <zy]x[yz> then how do you define a word that calls :?
10:02:13 <PoppaVic> POSTPONE, I suppose
10:02:20 <PoppaVic> ..all the kewlkids do it
10:02:24 <zy]x[yz> ah, yeah
10:03:36 <the_cuckoo> defer execution until the outer word is called - the inside would be parsed/'compiled' but not executed on the outer : voc ... ; stuff - hence only voc would be introduced at this point
10:04:00 <PoppaVic> so far, this sounds intensely overcomplicated
10:04:01 <the_cuckoo> all theoretical though - still playing with the details
10:04:11 <the_cuckoo> i dunno
10:05:13 <the_cuckoo> don't think what i have in mind is complicationed - should be reasonably ok from an implementation point of view (but then it'd be in c++ and not forth)
10:05:34 * PoppaVic sighs
10:05:43 <the_cuckoo> :)
10:09:36 <the_cuckoo> i don't mind if i drift from standard FORTH (am doing that anyway - pointers aren't a thing - stack is made of objects - that's a pretty major shift in itself)
10:10:17 <PoppaVic> <shrug> So you end up copying umpty bytes endlessly.
10:10:51 <the_cuckoo> hmm - no - don't think so
10:11:13 <PoppaVic> Also, pointers-are-objects ;->
10:11:48 <the_cuckoo> indeed - but there's a arithmetic you can apply to a pointer which don't quite work with objects (not without risking things anyway :))
10:13:08 <the_cuckoo> pointer arithmetic on a struct pointer is ok in some cases, but objects are more difficult to navigate like that
10:15:34 <the_cuckoo> (and yes, internally, the compiler does pointer arith on an object, but that isn't something which should be done at an application level :))
10:18:56 <the_cuckoo> anyway - still in design mode for the parsing logic - may well decide that i need another approach :) - but for now, i'll continue trying to formalise the approach i have in mind - it seems simple enough, but it seems to do things which standard FORTH wouldn't allow (like embedding : ... ; in word definitions)
10:19:21 <zy]x[yz> i would really suggest you try implementing the basics before you start designing off the beaten path
10:19:39 <the_cuckoo> i'm already way off the beaten path :p
10:20:12 <corecode> oh no, now i need to implement immediate in my metacompiler
10:20:44 <corecode> this will be an infinite stack of turtles
10:21:04 <zy]x[yz> but turtles are slow.  immediate words need to happen NOW!
10:21:12 <corecode> yea tell me about it
10:21:24 <corecode> i'm stepping through my code and i see a POSTPONE
10:21:28 <corecode> oups
10:22:16 <corecode> not sure how to deal with this tho
10:22:35 <corecode> maybe i can implement postpone especially
10:23:06 <corecode> but i still need EXECUTE for immediates
10:23:10 <john_cephalopoda> corecode: You could just postpone implementing POSTPONE and implement more pleasant words ;þ
10:23:20 <corecode> not helpful
10:23:33 <the_cuckoo> :)
10:23:53 <corecode> uh but then i need to implement all kinds of other words as well
10:24:02 <corecode> once i start executing imediates
10:24:36 <john_cephalopoda> I honestly have no clue how I'll do immediates in my Forth.
10:25:02 <john_cephalopoda> Maybe I'll just end up doing something horribly exotic in order to avoid them :þ
10:26:27 <zy]x[yz> it's simple: when your parsing loop encounters a word, if it's in compile mode and the word isn't immediate then compile the word.  else, execute it
10:27:16 <zy]x[yz> that dual vocabulary method of doing it is confusing to me
10:42:28 --- quit: gravicappa (Ping timeout: 268 seconds)
10:42:33 <corecode> yes, it's simple
10:42:45 <corecode> but then i need to implement all the words that those words use
10:42:48 <corecode> in my metacompiler
10:43:14 <corecode> which means it becomes a whole forth kernel
10:48:51 <crc> in my forth, each header has an associated class handler. This is a word which takes an xt and does something with it. So adding immediate words is just two simple definitions.  :class:immediate call ;  :immediate &class:immediate reclass ;
10:50:38 <zy]x[yz> wut
10:51:43 <crc> normal words are handled by something like:   :class:word compiling? [ compile:call ] [ call ] choose ;
10:52:28 <corecode> well, the forth should be able to do it right
10:52:42 <corecode> just the python metacompiler isn't set up for it
10:52:55 <crc> the token processor pushes the contents of the xt field to the stack and then calls whatever handler is associated with the word in question
10:53:11 <zy]x[yz> oh, i get it.  your definition for immediate resets the class handler for the last-defined word to :class:immediate, which is just a call
10:53:37 <zy]x[yz> why even have :class:immediate?  why not just "&call reclass" ?
10:53:40 <crc> yes
10:54:15 <crc> I name the class handlers to make it easier to identify them. Just my personal preference.
10:54:26 <zy]x[yz> how do you postpone immediate words?
10:55:02 <crc> I use a | prefix to postpone words
10:56:02 <zy]x[yz> but it seems like your class handler would have to have a postpone method, too.  shouldn't immediate words be postponed differently than regular words?
10:56:29 <crc> https://forthworks.com/share/fd9e375a7c3ee8a116c6d772e2f0dcbd
10:56:29 <crc> gopher://forthworks.com/0/share/fd9e375a7c3ee8a116c6d772e2f0dcbd
10:58:45 <crc> I never implemented a POSTPONE in a conventional Forth, this is basically what I've always used in the current and prior generations of my forth.
10:59:33 <crc> It probably differs in action somewhat from POSTPONE, but it meets my needs
11:03:42 <WilhelmVonWeiner> afternoon forth heads
11:03:58 <WilhelmVonWeiner> I've been playing video games all day and now my brain is mush
11:04:20 <zy]x[yz> if it wasn't super metroid then what are you doing with your life
11:04:59 <WilhelmVonWeiner> it was Resident Evil 7 for maybe 4 hours
11:05:12 <WilhelmVonWeiner> then Puyo Puyo Tetris was delivered and I played that for another 6
11:05:56 <zy]x[yz> neither of those sound like super metroid
11:06:36 <WilhelmVonWeiner> Tetris is the defacto best game of all time
11:06:58 <WilhelmVonWeiner> Arika tetris #1
11:11:54 <corecode> meh i don't want to implement a forth again
11:12:00 <corecode> just to compile my forth
11:12:39 <zy]x[yz> in my experience, this is how forth works: you implement it over and over and over again and never actually do anything productive
11:13:22 <corecode> boo
11:13:51 <WilhelmVonWeiner> zy]x[yz: This is accurate
11:14:18 <WilhelmVonWeiner> which is why I use Lina forth, gforth on BSD, and Retro
11:14:43 <WilhelmVonWeiner> the only "Forth" I'll implement is for my zero operand cpu scripts
11:14:49 <WilhelmVonWeiner> when I get around to it
11:34:51 <crc> zy]x[yz: that does tend to happen; I try to avoid falling into that trap :)
11:35:41 <zy]x[yz> i also try.  i found the most effective method is to use a different language
11:36:42 <zy]x[yz> just accept that i'm going to be subserviant to some other loser's compiler
11:39:00 <WilhelmVonWeiner> tut tut tut
11:39:03 <WilhelmVonWeiner> lacking in self control
11:40:12 <WilhelmVonWeiner> From what I've gathered, people misinterpret CM's philosophy as "you should always implement your own Forth", I've always read it as "You should always make Forth do what you need it to do, the way you want it to work"
11:40:51 <WilhelmVonWeiner> It was reading a paragraph about ANS and application programmers learning implementation details that I came to this conclusion
11:41:26 <zy]x[yz> yeah, i'm really not being entirely honest.  i really do appreciate forth and find it fun to play with, but the truth is i really miss features from c when i'm working with forth, and that really hampers my motivation
11:42:22 <Zarutian> zy]x[yz: features such as?
11:42:42 <zy]x[yz> of the top of my head, a big one is the polymorphic operators
11:43:05 <zy]x[yz> if i'm working with some structure in memory, for example, i have to know how big the fields are to use the right-sized word for fetching and storing
11:43:56 <Zarutian> you dont use field accessor words then?
11:44:17 <zy]x[yz> i guess that's the forth answer, but it just seems awfully tedious
11:45:45 <Zarutian> more tedious than doing struct.field in C?
11:45:57 <zy]x[yz> yes
11:46:15 <zy]x[yz> because it would look like struct->field struct.field!
11:46:21 <zy]x[yz> or struct>field, rather
11:47:35 <Zarutian> oh, that is usually just style issue, I think. I often use objVar @ .x@ to access such fields
11:47:56 <Zarutian> (the x field of whatever objVar points to)
11:48:08 <zy]x[yz> what if you have two different structures with an x field
11:48:47 <Zarutian> depends, if the fields are in the same place then I just use the same word
11:50:28 <Zarutian> but if I am going to start to do polymorphism I rather do it via the object having a pointer to a call dispatching routine that gets passed pointer to the object.
11:51:57 <Zarutian> or, barring that, I just check the typetag of the object in the field accessing object
11:52:06 <corecode> that seems complicated
11:52:10 <corecode> runtime dispatch
11:52:51 <corecode> now, do i implement postpone and all the loop control words, or do i implement evaluation and all the primitives
11:52:53 <Zarutian> hell of a less complicated than trying to, badly, make an static type analyser that then gets more in your way than not.
11:52:55 <corecode> for the metacompiler
11:58:25 <WilhelmVonWeiner> When I write C I miss a lot of Forth features
11:58:29 --- quit: jedb (Ping timeout: 240 seconds)
11:58:29 <WilhelmVonWeiner> mostly the stacks
12:07:58 --- quit: pierpal (Quit: Poof)
12:08:15 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
12:09:03 --- join: proteusguy (~yaaic@cm-58-10-154-246.revip7.asianet.co.th) joined #forth
12:09:03 --- mode: ChanServ set +v proteusguy
12:11:34 --- join: jedb (~jedb@199.66.90.113) joined #forth
13:05:56 --- quit: Kumool (Quit: EXIT)
13:07:57 --- quit: xek_ (Ping timeout: 272 seconds)
14:04:06 <the_cuckoo> zy]x[yz: lol and yes, that re-implmentation thing happens - though i gave up trying to do any kinda standard FORTH many years ago, i have implemented a shitload of stuff which follows the general pattern - from comms to video to robotics - some useful, some not so, some good, some very bad - it's the pattern which persists, and it's more often worked than not
14:09:11 --- join: Kumool (~Khwerz@adsl-64-237-234-233.prtc.net) joined #forth
16:07:47 --- join: dave0 (~dave0@47.44-27-211.dynamic.dsl.syd.iprimus.net.au) joined #forth
16:08:34 <dave0> hi
16:12:32 <crc> Hi dave0 
16:12:56 <dave0> hi crc 
16:13:02 --- quit: john_cephalopoda (Ping timeout: 252 seconds)
16:14:54 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth
16:20:20 --- join: rdrop-exit (~markwilli@112.201.166.158) joined #forth
16:42:29 --- quit: nonlinear (Ping timeout: 240 seconds)
16:52:22 <WilhelmVonWeiner> Little girls need to stop being the bad guys in horror movies and games
16:52:37 <WilhelmVonWeiner> I could beat up a little girl without breaking a sweat
16:52:51 <PoppaVic> oh, please - little boys, teens, and <anygender> idiots are too common to erase
16:53:24 <PoppaVic> WilhelmVonWeiner: My bottom line is.... "We really need Velociraptors"
16:54:35 <WilhelmVonWeiner> "The Ring" would've been a lot more frightening if a velociraptor dove through the television, you're right
16:55:02 <PoppaVic> Nah, I just want them recreated - and released in every megaplex around the world..
17:01:31 <zy]x[yz> girls are terrifying
17:01:41 <zy]x[yz> i don't go near them
17:02:06 <PoppaVic> I though courts/lawyers/judges/cops were, but - I am sure you got some intersection in there
17:02:30 <PoppaVic> zy]x[yz: make them sign the paper FIRST ;-)
17:03:54 <john_cephalopoda> The most frightening thing is obviously Nazis.
17:04:02 <john_cephalopoda> The Ring, but Hitler comes through the TV.
17:04:22 <PoppaVic> <shrug> you folks are really wired too tight
17:05:33 <PoppaVic> I might understand if you had said Spaceballs, or singing nazis (Springtime For Hitler)...
17:07:06 <john_cephalopoda> The most creepy stuff out there is "Salad Fingers" and "Cyriak" anyway.
17:07:38 <rdrop-exit> Hello Forthwrights
17:07:42 <john_cephalopoda> Hey rdrop-exit 
17:07:54 <rdrop-exit> Hi John
17:07:54 <PoppaVic> no, "creepy" covers most everyone Out There.
17:15:11 <crc> Odd conversation...
17:15:54 <PoppaVic> every day in here where 2+ speak it's "odd".
17:23:44 <WilhelmVonWeiner> the real oddity is "scary children"
17:24:04 <WilhelmVonWeiner> I don't think I would lose a fight to any U13 unless they had a gun
17:32:31 --- quit: pierpal (Ping timeout: 246 seconds)
17:34:32 <WilhelmVonWeiner> or two stacks
17:37:54 <john_cephalopoda> WilhelmVonWeiner: The real oddity is that I'm floating in a most-a peculiar way. And the stars look very different todaaaay!
17:38:26 <john_cephalopoda> I should maybe get to bed before 3 am. Night.
17:38:42 <WilhelmVonWeiner> I have absolutely no idea what you're referencing.
17:39:11 <dave0> david bowie
17:39:17 <john_cephalopoda> "Space Oddity" by David Bowie https://www.youtube.com/watch?v=iYYRH4apXDo
17:39:19 <john_cephalopoda> A classic.
17:40:04 <dave0> is it a reference to using Forth on space applications? :-)
17:40:23 <john_cephalopoda> :D
18:27:36 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth
18:28:10 --- quit: proteusguy (Ping timeout: 246 seconds)
18:28:28 --- join: proteusguy (~yaaic@2001:44c8:451f:d253:1:0:3b0:73de) joined #forth
18:28:28 --- mode: ChanServ set +v proteusguy
18:36:35 --- quit: dddddd (Remote host closed the connection)
18:44:28 <Croran_> is there an equivalent of .s for the float stack in gforth?
18:46:28 <tabemann> I don't think it's in any standard, but it's not hard to write provided there is a word like FDEPTH or FP@
18:46:44 <tabemann> donno about gforth
18:46:56 <tabemann> but we here tend to prefer to not think to much about gforth
18:50:37 <PoppaVic> 1e1 1e2  ok
18:50:37 <PoppaVic> f.s <2> 1.000000000000E1 1.000000000000E2  ok
18:51:24 <Croran_> thank you
19:39:11 --- quit: tabemann (Ping timeout: 244 seconds)
19:50:51 * Zarutian issues https://tinyurl.com/2019-01-04-FORTHVMCHALLANGE
19:53:03 * Zarutian notes that there is an error specifing the 1LBR instruction, it is just a Left Bit Rotate by one instruction
20:17:22 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:7d04:1e92:6395:7db) joined #forth
20:36:00 <tabemann> question
20:36:08 <tabemann> what is the best way of doing exceptions
20:36:17 <tabemann> I know ANS/2012's way of doing it
20:36:30 <tabemann> but people here have mentioned simpler exception mechanism that could be used
20:59:38 <rdrop-exit> One simplification is to use addresses rather than exception numbers.
21:01:25 --- quit: mahmudov (Remote host closed the connection)
21:04:14 <tabemann> how would this work?
21:05:32 <rdrop-exit> i.e. the exception number is the xt of the fallback exception handler.
21:05:48 <rdrop-exit> e.g. : xeoi ( -- ) " Unexpected End of Input"  alert ;
21:06:34 <tabemann> so it's basically like ABORT, but to a specific handler
21:06:54 <rdrop-exit> If no intermediate levels handle the exception, it eventually percolates up the the top level exception handler that just executes the xt.
21:07:31 <tabemann> ah
21:07:36 <rdrop-exit> If I want to throw xeoi I throw the xt of xeoi.
21:07:43 <tabemann> gotcha
21:07:49 <tabemann> I'll go with that
21:08:32 --- join: gravicappa (~gravicapp@h109-187-254-198.dyn.bashtel.ru) joined #forth
21:08:44 <rdrop-exit> Here's an example, it works similarly to an assert:
21:08:45 * tabemann is gonna go with [COMPILE]/COMPILE instead of POSTPONE because ANS is bad mm'kay?
21:08:48 <rdrop-exit> : read ( fd a # -- +n ) (read)  dup 0>= averts xeoi ;
21:10:05 <rdrop-exit> POSTPONE isn't that bad, but having the factors is fine too IMO
21:10:26 <tabemann> I'll probably leave it up to the user which they want to use
21:11:04 <tabemann> I've already implemented [COMPILE] and COMPILE
21:11:52 <rdrop-exit> In the example above, if an end of input condition is not exceptional, I would just call (read), but if I don't except an end of input I call read instead.
21:13:12 <tabemann> opinion question - what do we nave our catch/throw words
21:14:00 <PoppaVic> it's "eieio", sheesh
21:14:16 <rdrop-exit> My catch/throw mechanism is non-standard, I use TRY
21:14:49 <rdrop-exit> and RAISE
21:15:07 <rdrop-exit> actually ?RAISE
21:16:11 <tabemann> I'll go with TRY, RAISE, and ?RAISE, just to avoid confusion with ANS CATCH and THROW
21:16:30 <rdrop-exit> TRY attempts the word, ?raise is analoguous to THROW, then I have various higher level words that have ?RAISE as a factor.
21:16:55 <rdrop-exit> Sorry I meant ?RAISE, I don't have a RAISE anymore.
21:17:10 <tabemann> I assumed ?RAISE was like an assert
21:17:19 <tabemann> and RAISE was like just raising an exception
21:17:49 <rdrop-exit> Right, but I decided I was better off always having the check for 0.
21:18:07 <rdrop-exit> So I always use ?RAISE
21:19:35 <rdrop-exit> The AVERTS in the example above includes ?RAISE as a factor.
21:20:03 <rdrop-exit> If the condition isn't met, it raises the exception.
21:20:11 <tabemann> separate ?RAISE and RAISE makes sense to me if the exception is specified as a parsed argument, whereas just ?RAISE makes sense if you use it like ['] QUUX ?RAISE
21:21:46 <rdrop-exit> I usually do <condition> AVERTS <exception>
21:22:57 <rdrop-exit> e.g.
21:22:58 <rdrop-exit>  : xundefined ( -- ) " Undefined Word" alert ;
21:22:58 <rdrop-exit>  : defined ( mask <name> -- la ) token lookup averts xundefined ;
21:23:25 <tabemann> I think I'll go with this design
21:24:39 <rdrop-exit> Another example:
21:24:41 <rdrop-exit>  : >unsigned ( a # base -- u ) over averts xnan  (>unsigned) ;
21:25:17 <rdrop-exit> XNAN was previously defined as:
21:25:17 <rdrop-exit>  : xnan ( -- ) " Not a Number" alert ;
21:26:51 <rdrop-exit> I have a few other words that use ?RAISE as a factor, but you get the idea I think.
21:27:30 <tabemann> I assume AVERTS as you use it is an assertion - it throws when passed 0
21:28:22 <rdrop-exit> Exactly, it checks that a pre- or post-condition is true.
21:31:28 <rdrop-exit> I also have SUPPRESS which suppresses a particular exception
21:32:23 <rdrop-exit> but lets others through.
21:34:38 <rdrop-exit> But the core words are TRY and ?RAISE, everything else is higher level.
21:36:18 <rdrop-exit> i.e. syntactic sugar
21:38:27 <rdrop-exit> Here's an example for TRY
21:38:28 <rdrop-exit>  : outer ( -- n/a )
21:38:29 <rdrop-exit>    token  try dispatch  intercept  refresh  recur ; compiled
21:39:25 <rdrop-exit> In this example TRY attempts DISPATCH this is similar to CATCH
21:40:01 <tabemann> back
21:40:05 <rdrop-exit> INTERCEPT handles the exceptions that may have been raised by the DISPATCH attempt
21:41:33 <tabemann> what I don't get is this
21:41:57 <tabemann> how are TRY / ?RAISE different from CATCH / THROW except you use xts rather than exception numbers
21:43:58 --- join: pierpal (~pierpal@95.239.223.85) joined #forth
21:45:36 <rdrop-exit> Aside for syntactic sugar not much, using XTs simplifies some things. I'd have to compare with a particular implementation. My "catch frame" is 3 cells, haven't checked what other Forth's use.
21:46:47 <rdrop-exit> The "catch frame" is on the return stack.
21:47:15 --- quit: pierpal (Read error: Connection reset by peer)
21:48:13 <tabemann> for attoforth I basically used Forth 2012's sample design, except that I put the handler variable in the task-local space, and I saved some extra things on the return stack
21:49:20 <tabemann> for hashforth there are no task-local spaces by default, because it's a single tasking design, but one that is meant to be easily tied into cooperative multitasking, which'd be a simple matter of having multiple stack sets and saving the handler variable for each task
21:49:21 <rdrop-exit> I'll take a look at the Forth 2012 document when I get a chance.
21:49:35 <tabemann> apparently Forth 2012 is ANS redux
21:49:47 --- quit: proteusguy (Read error: Connection reset by peer)
21:50:02 --- join: proteusguy (~yaaic@ppp-124-120-187-9.revip2.asianet.co.th) joined #forth
21:50:02 --- mode: ChanServ set +v proteusguy
21:50:07 <tabemann> hashforth is turning out to be much, much simpler than attoforth
21:50:12 <rdrop-exit> Cool
21:50:50 <tabemann> I managed to get rid of the LATESTXT primitive, btw
21:51:06 <rdrop-exit> ok
21:51:22 <tabemann> because as I'm already implementing :, :NONAME, and CREATE as non-primitives, I just made LATESTXT a normal variable
21:51:47 <rdrop-exit> I don't have :NONAME
21:52:26 <rdrop-exit> Would be easy to trivial to implement if I ever needed it, haven't needed it so far.
21:54:42 <rdrop-exit> bbiab
21:58:37 <rdrop-exit> What page is the sample implementation of CATCH/THROW?
22:04:39 <tabemann> http://lars.nocrew.org/forth2012/exception/CATCH.html
22:04:51 <tabemann> http://lars.nocrew.org/forth2012/exception/THROW.html
22:05:52 <rdrop-exit> thanks
22:12:27 --- quit: Kumool (Quit: EXIT)
22:13:20 <tabemann> I almost tried using AVERTS in my assembly code
22:13:30 <tabemann> and then I realized that it was assembly and not real Forth
22:13:40 <tabemann> so I was stuck with using ?RAISE
22:29:39 <rdrop-exit> Their implementation is very similar, their overhead is over the top course since it's coded in high-level Forth for illustration purposes..
22:37:42 <rdrop-exit> A catch needn't be 10+x more expensive then a normal call.
22:38:27 --- join: proteusguy2 (~yaaic@2001:44c8:451f:d253:1:0:48d:cf4) joined #forth
22:40:00 --- quit: proteusguy (Ping timeout: 245 seconds)
22:42:38 <tabemann> okay, I've gotta go night night now
22:43:10 <rdrop-exit> Good night Tabemann :)
22:43:37 <tabemann> g'night
22:43:38 --- quit: proteusguy2 (Read error: Connection reset by peer)
22:43:52 --- join: proteusguy (~yaaic@cm-58-10-154-246.revip7.asianet.co.th) joined #forth
22:43:52 --- mode: ChanServ set +v proteusguy
22:46:23 --- join: proteus-guy (~proteus-g@cm-58-10-154-246.revip7.asianet.co.th) joined #forth
23:17:25 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:19:48 --- quit: MrMobius (Ping timeout: 244 seconds)
23:19:49 --- nick: [1]MrMobius -> MrMobius
23:21:40 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth
23:24:35 --- quit: MrMobius (Ping timeout: 258 seconds)
23:24:35 --- nick: [1]MrMobius -> MrMobius
23:43:32 --- join: proteusguy2 (~yaaic@2001:44c8:451f:d253:1:0:48d:cf4) joined #forth
23:44:10 --- quit: proteusguy (Ping timeout: 245 seconds)
23:49:48 --- quit: proteusguy2 (Read error: Connection reset by peer)
23:50:01 --- join: proteusguy (~yaaic@mx-ll-183.89.213-60.dynamic.3bb.co.th) joined #forth
23:50:01 --- mode: ChanServ set +v proteusguy
23:50:49 --- quit: proteus-guy (Ping timeout: 240 seconds)
23:58:13 --- quit: dys (Ping timeout: 246 seconds)
23:59:59 --- log: ended forth/19.01.03