2024-04-19 11:29:44 <hello-operator> zelgomer: Yup, you get `1` out, or whatever code you put in, but also that junk pointer as well
2024-04-19 11:33:35 <hello-operator> interestingly `: y  1 throw ;  : z  ['] y catch ;` works as you would expect
2024-04-19 11:34:23 <hello-operator> 1 : q throw ;  : z  ['] q catch ; .s <1> 1  ok
2024-04-19 11:34:23 <hello-operator> 2 z  ok
2024-04-19 11:34:30 <hello-operator> wut?
2024-04-19 11:34:56 <hello-operator> But that doesn't
2024-04-19 14:20:00 <zelgomer    > that makes sense
2024-04-19 14:21:03 <zelgomer    > it's because you're passing the code before catch, so your stack depth is 3 when it enters catch
2024-04-19 14:21:08 <zelgomer    > 1 2 xt catch
2024-04-19 14:23:02 <zelgomer    > the xt is consumed by catch, the 2 is consumed by 2, the stack pointer is reset to the depth it was before catch with undefined values, and the xt is replaced with 2
2024-04-19 14:23:21 <zelgomer    > 2 is consumed by throw
2024-04-19 15:18:07 <hello-operator> That doesn't make sense, putting junk on the stack always? 139895769808864 isn't an execution token, it's random nonsense
2024-04-19 15:18:46 <hello-operator> Why would anyone want a word that did that?
2024-04-19 15:23:48 <hello-operator> It's also not what the reference implementation does, or what the stack comment suggests
2024-04-19 15:51:26 <zelgomer    > sigh
2024-04-19 15:52:09 <zelgomer    > do you recognize the difference between  1 2 :noname throw ; catch  and 1 :noname 2 throw ; catch  ?
2024-04-19 15:52:33 <zelgomer    > note the depth of the stack when it enters catch
2024-04-19 15:52:44 <zelgomer    > those two examples are not the same
2024-04-19 15:53:46 <hello-operator> *EVEN BIGGER PASSIVE AGGRESSIVE SIGH*
2024-04-19 15:53:56 <hello-operator> Yes I know they're not the same
2024-04-19 15:54:33 <zelgomer    > then why do you think it's "putting junk on the stack always?"
2024-04-19 15:55:03 <hello-operator> Because a random pointer appears - it's not the execution token
2024-04-19 15:56:02 <zelgomer    > you're right, it's not. it's /an undefined value/.
2024-04-19 15:56:25 <zelgomer    > probably an artifact of the inner workings of throw/catch
2024-04-19 15:58:50 <zelgomer    > hello-operator: maybe this will help. try this one   : y  2drop 3 throw ;  : z  1 2 ['] y catch ;  z .s
2024-04-19 16:03:35 <hello-operator> That's completely different - I would expect junk in that case
2024-04-19 16:10:49 <lf94        > heh.
2024-04-19 16:10:54 <lf94        > hello-operator: you have my sympathy.
2024-04-19 16:11:20 <lf94        > I suggest at this point looking further into gforth, or look at another forth
2024-04-19 16:12:54 <hello-operator> lf94: Cheers, I'll think I'll try to work around it for now
2024-04-19 16:13:21 <lf94        > I wouldn't delay the inevitable. Just open up another forth and look at the result :)
2024-04-19 16:14:38 <crc         > The behavior makes sense to me. See http://sprunge.us/F3my1l for my notes and http://lars.nocrew.org/dpans/dpansa9.htm#A.9.6.1.2275 in the ANS spec
2024-04-19 16:15:29 <crc         > the appendix notes that "The values of the i*x stack arguments could have been modified arbitrarily during the execution of xt. In general, nothing useful may be done with those stack items, but since their number is known (because the stack depth is deterministic), the application may DROP them to return to a predictable stack state."
2024-04-19 16:22:00 <lf94        > I would expect it to be an address to the point-of-throw, but if it's not, I would consider that weird
2024-04-19 16:25:31 <zelgomer    > hello-operator: it isn't completely different. it's another example of exactly what you're doing, it's just the "junk" stack position is a parameter to throw rather than to 2drop
2024-04-19 16:46:43 <lf94        > I will need to read that standards description to probably understand "why"
2024-04-19 16:46:57 <lf94        > But I'm in the middle of a web app redesign x_x
2024-04-19 17:04:30 <lf94        > I wish the PX-15C had a BOM
2024-04-19 17:04:42 <lf94        > I don't want to buy the parts off of Tindie and be overpriced
2024-04-19 17:06:25 <lf94        > Is there no way to wrap a number from -1 to N without a copy of -1?
2024-04-19 17:06:27 <lf94        > exampl
2024-04-19 17:07:09 <lf94        > x 1 - dup 0 < if 6 then swap drop
2024-04-19 17:07:29 <lf94        > erm
2024-04-19 17:08:09 <lf94        > x 1 - dup 0 < if 6 else dup then swap drop
2024-04-19 17:08:33 <lf94        > I know we can use modulus if we're going the other way
2024-04-19 17:08:37 <lf94        > 0 to N
2024-04-19 17:09:43 <lf94        > x 1 - >r r@ is-neg if 6 else r@ then r> drop
2024-04-19 17:10:12 <lf94        > (alternative, imo maybe easier to read)
2024-04-19 17:25:50 <lf94        > I'm kind of irked there's no non-piecewise way to do this
2024-04-19 17:26:16 <lf94        > I guess modulus is similar
2024-04-19 17:26:24 <lf94        > like, if modulus didn't exist, I'd have to do it the opposite way
2024-04-19 17:26:48 <lf94        > I'd call this operation... nodulus B)
2024-04-19 17:26:57 <lf94        > (if-negative-modulus)
2024-04-19 18:36:57 <lf94        > ah. derp
2024-04-19 18:36:59 <lf94        > we can do
2024-04-19 18:37:09 <lf94        > x 1 - n mod :)
2024-04-19 19:26:01 <zelgomer    > hello-operator: sorry, i got overtaken by several distractions there. i've tried to break it down more clearly here: https://paste.debian.net/hidden/8d7882df/
2024-04-19 21:18:54 <hello-operator> zelgomer: Cheers, I'll take a look!