REPLs & tamsyn & bytes, oh my! @millihertz@oldbytes.space

the specific problem with ABORT" is that i can't see how it passes the address of its string back to the exception handler. it looks like there's magic involved... which is a very bad look. you'd think that given the Forth Standard zeal for overspecifying everything else, they wouldn't have overlooked that...

i mean, it would even have made much more sense to define

  : ABORT -1 THROW ;
  : ABORT"  POSTPONE S"  POSTPONE THROW ;
      IMMEDIATE

and specify that the first 256 negative numbers are specific, system-defined exceptions, and anything else will be printed as a string by the top-level CATCH

...but then, there's a more fundamental problem: the definition of CATCH is wrong too. it takes a single xt, but it needs to take two, and only execute the second one if the first one THROWs. it's too late now, but maybe Forth needs a TRY that works that way

and having just read the standard definition of THROW, which is supposed to be an ultralight exception handling mechanism...

If the top of the stack is non zero and there is no exception frame on the exception stack, the behavior is as follows:

If n is minus-one (-1), perform the function of 6.1.0670 ABORT (the version of ABORT in the Core word set), displaying no message.

If n is minus-two, perform the function of 6.1.0680 ABORT" (the version of ABORT" in the Core word set), displaying the characters ccc associated with the ABORT" that generated the THROW.

no no no! what the hell were you thinking?! if you want THROW to double-time with ABORT. then ensure there is always a handler that does that, so THROW always lands in a matching CATCH; and if you want a THROW" to correspond to ABORT", then define one! don't overload THROW like this!

it's not that a forth standard is a mistake - it's just that the people in charge of it are profoundly mistaken

so it turns out that the current Forth Standard proposal is having some trouble with character literals. it defines the syntax '<ch>' where <ch> is any printable character... but the set of printable characters includes ascii 32, and if you type ' ' you get the xt of '.

...and this is why hardcoding literal recognition into the forth interpreter is just a bad idea, even if it stops at single precision integers! if you want a literal, define a word that parses literals and use that - that's the Forth way, even if it does mean you can't type 2 3 + . any more

i don't normally repost from twitter, but this caught my eye...

https://nitter.it/LStorgaardNO/status/1558737059015266307

...mainly for the lack of self-awareness. that's basically what most software products look like WITH maintenance! without, they'd basically just be four rotten bits of wood...

any time you start talking about all the wonderful things your language can do at compile time, i've already lost interest

the only issue i have with little VMs is that by necessity they waste about 80% of the CPU power they consume (on modern PCs with speculative execution). not their fault - there's just no way around that.

on slower, in-order machines with no branch prediction, the still lose about 80% of their cycles, but mostly to pipeline stalls (which don't consume a whole lot of power)

and put bluntly, power consumption is the only damn metric that means anything any more. lower is always better. (which is why this trend towards web apps is so fucking offensive to me, and frankly to the planet - instead of a little app with a local database sipping at its host's resources, we now have the power consumption of the browser on the local machine, the server farm on the other end, and all the networking equipment in between. set against that shitshow, a little VM wins without even trying.)

re LB: oh for christ's sake

...because let's face it, it's pretty clear now that we're doomed. not least because none of the people who could effect meaningful change are even interested in acknowledging the problem, let alone finding anything approaching a solution.