<tabemann>
well, I've got zeptoforth that it complains if the user enters something other than a valid number
iyzsong has joined #forth
xek has joined #forth
jsoft has quit [Ping timeout: 240 seconds]
xek has quit [Ping timeout: 265 seconds]
iyzsong-x has joined #forth
iyzsong has quit [Ping timeout: 258 seconds]
jsoft has joined #forth
iyzsong has joined #forth
iyzsong-x has quit [Ping timeout: 265 seconds]
dave0 has quit [Quit: dave's not here]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
jsoft has quit [Ping timeout: 258 seconds]
_whitelogger has joined #forth
iyzsong-x has joined #forth
iyzsong has quit [Ping timeout: 258 seconds]
iyzsong has joined #forth
iyzsong-x has quit [Ping timeout: 260 seconds]
gravicappa has joined #forth
_whitelogger has joined #forth
iyzsong-x has joined #forth
iyzsong has quit [Ping timeout: 272 seconds]
dddddd has quit [Remote host closed the connection]
jsoft has joined #forth
gravicappa has quit [Ping timeout: 260 seconds]
xek has joined #forth
proteus-guy has joined #forth
<veltas>
This is going to sound really stupid but how do I subscribe to comp.lang.forth with just an email address, no google account or usenet subscription?
<veltas>
Is that possible?
<veltas>
I'm assuming that would require some kind of mailing list being set up somewhere which doesn't exist but I thought I'd just ask first
<proteus-guy>
veltas, you'd have to find some usenet email service. It's been years since I had such a thing. I expect they're out there however.
<veltas>
I think I'll wait for Google to refresh my recovery phone number
<veltas>
This whole issue is I don't want to use my gmail email (which nobody knows) for the group, but it won't let me add an alternative email to subscribe with without my recovery number first
<veltas>
And I just started beating my head against the desk and wishing it was the 90s again
<proteus-guy>
veltas, do you find useful content on comp.lang.forth?
<veltas>
I don't know I was going to subscribe and then read content and see if it was useful/interesting
<veltas>
And then unsubscribe if not
<veltas>
It shouldn't be a huge commitment to subscribe to a newsgroup but unfortunately it is. There should be a mailing list but I suppose the transition was never prescient enough
<proteus-guy>
it has earned a rather poor reputation I'm afraid. but, again, it's been years since I was on it. could be better. this channel was dead for a number of years but has really been quite useful for the last 2-3. wonder if it means a resurgence for forth as a technology?
<veltas>
Maybe, I can't remember where I learned about Forth but I literally learned it over the last few weeks and am trying to understand it well enough to write an 8-bit Forth ROM for the ZX Spectrum
<veltas>
That is what I am up to, pretty useless I know
<veltas>
I want to make it a 'Forth-2012 System' though, I wonder if anyone even cares about the standard
<proteus-guy>
writing your own forth is the single most useful useless thing I think a person can do. ;-)
<veltas>
Especially for dead hardware
<proteus-guy>
got two stacks, talk in RPN? you're a forth. that's my standard. ;-)
* proteus-guy
isn't even aware of a Forth-2012 System.
<veltas>
I only care about it because I don't know the culture, so the standard probably understands Forth culture better than I do
<veltas>
Maybe it doesn't
<proteus-guy>
er.... standards and good forth seem to anathema to each other in my experience.
<veltas>
They have got a locals syntax: {: :} which I think nobody actually uses and doesn't highlight correctly in my text editor
<proteus-guy>
yeah... so locals and forth... er... hahaha generally a red flag.
<veltas>
I have had an easier time understanding the intention of words for extending the compiler in the original "Starting FORTH" PDF that's available online
<veltas>
than I have had from reading anything else
<proteus-guy>
yep it's good.
<veltas>
It hurt my head a bit at first which is always a strong sign of a language that I need to mentally strain myself to grok it
<veltas>
The last time my head hurt learning the language it was Haskell
<proteus-guy>
Anyway - I think making a forth for ZX Spectrum is a great way to get into forth.
<veltas>
Thanks I don't think it's a terrible way to learn it, even if the output is not really useful
<veltas>
There are already multiple FORTHs for the Spectrum, mostly from the 80s, some are actually quite good
<proteus-guy>
the skill of getting real work out of a tiny limited system is one that will always be valuable. don't underappreciate that ability.
<veltas>
Do you think that locals are an anti-pattern in forth?
<proteus-guy>
if you're a haskell fan then you might appreciate a forth for a TI calculator (Z-80 processor) written in scheme that a colleague did recently.
<proteus-guy>
veltas, locals are a red flag but not always wrong. in forth you're expected to know the difference.
<veltas>
My experience so far is if I have a very short function I don't even want locals, it seems 'nicer' to just do stack operations
<veltas>
So I can imagine locals being a red flag that factorisation is needed maybe
<veltas>
I have written some longer functions with loops that there weren't obvious candidates for factoring in, and where I had to work with enough variables to fancy using a couple locals
<veltas>
Okay I will check that out
<proteus-guy>
he's a haskell/functional guy so you might appreciate his coding style. smart guy.
<proteus-guy>
veltas, there are certainly common situations when you need more placeholders than what is convenient for two stacks. what the correct solution is in those cases is quite context sensitive.
<veltas>
Hmm
<veltas>
I think that is one thing that I noticed about Forth, that its syntax reminded me of a functional programming language's
<veltas>
Also its syntax extension ability is similar to that in other languages
<veltas>
But it's for totally different reasons, the fact that Forth is so small is really impressive in a mathematical sense because it's like we're talking in a better factored language for the computer
<proteus-guy>
veltas, being concatenative it is actually cleaner than the prefix notation for functional style, imho. it's syntax extension ability is superior to any other I've yet encountered. that's why all good forth programs are creations of a DSL first and foremost.
<veltas>
Hmm I can't wait to apply this more seriously and create such a DSL, really see how powerful it is
<proteus-guy>
Once you figure out how to implement your compiler words and extension words you'll be a proper forth-er and able to build all kinds of dsls quickly. enjoy.
Keshl has quit [Read error: Connection reset by peer]
jsoft has quit [Ping timeout: 258 seconds]
gravicappa has joined #forth
frumbleme has joined #forth
frumbleme has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #forth
cp- has quit [Quit: Disappeared in a puff of smoke]
cp- has joined #forth
gravicappa has quit [Read error: Connection reset by peer]
gravicappa has joined #forth
gravicappa has quit [Ping timeout: 265 seconds]
Keshl_ is now known as Keshl
KipIngram has joined #forth
KipIngram has quit [Quit: WeeChat 1.4]
KipIngram has joined #forth
KipIngram has quit [Client Quit]
KipIngram has joined #forth
<remexre>
are there any competing exception mechanisms to ANS's throw+catch?
<remexre>
I don't love the idea of every error sharing the same handler, but I don't have a particularly better approach
rdrop-exit has joined #forth
<rdrop-exit>
remexre, a simpler mechanism is to use addresses of fallback handlers instead of ANS style throw codes
<remexre>
hm, like separate errors into three or four categories, and e.g. jump to one on programmer errors (e.g. stack underflow), another on platform errors (e.g. SIGBUS), a third on program-specific error, etc?
<rdrop-exit>
No categories, just handlers
<remexre>
er, I meant specifying a single handler handles all the errors of a certain category
<rdrop-exit>
there are no categories, the fallback handler is the exception itself
<rdrop-exit>
if some code wants to intercept it and replace it with another handler it can
<remexre>
isn't that how ANS's works?
<rdrop-exit>
ANS uses throw codes
<rdrop-exit>
here's an example:
<rdrop-exit>
: xabort " Abort..." alert ;
<rdrop-exit>
: abort ( -- ) raise xabort ;
<remexre>
I'm possibly reading the wrong document, then?
<rdrop-exit>
that's the ANS document, ANS uses throw codes, e.g. -1 for ABORT
<remexre>
okay, yeah; I'm just unfamiliar with the RAISE word
<rdrop-exit>
In ANS the "throw code" for ABORT is -1, in my example the "throw code" for ABORT is ' XABORT
<rdrop-exit>
Another example:
<remexre>
ohhhh I thought your example was an example of what was meant by throw codes
<rdrop-exit>
I'm using the address of the fallback handler for an exception, as the "throw code" of the exception
<remexre>
isn't raise foo just equivalent to ['] foo execute, though? or, how is control flow affected?
<rdrop-exit>
So if no one intercepts that exception, it will eventually execute XABORT
<rdrop-exit>
For ANS it would be equivalent to ['] xfoo throw
<rdrop-exit>
(if ANS used XTs instead of throw codes)
<rdrop-exit>
here's another example:
<rdrop-exit>
: x/0 ( -- ) " Divide by 0" alert ;
<rdrop-exit>
: example ... 0= triggers x/0 .... ;
<rdrop-exit>
: example2 ... 0<> averts x/0 .... ;
<rdrop-exit>
In the above the xt of x/0 is the "throw code" for division by zero
<remexre>
ok, I think I get that
<remexre>
what happens control-flow-wise when a fallback handler gets called?
<rdrop-exit>
If no one "catches" x/0, it eventually gets executed by the outer interpreter
<remexre>
as in after the x/0 word executes, it hits QUIT?
<rdrop-exit>
I don't have QUIT
<rdrop-exit>
: outer ( -- ? )
<rdrop-exit>
begin token try dispatch intercept again ; compile-only
<remexre>
that... sounds like QUIT to me :P
<rdrop-exit>
close enough :)
<rdrop-exit>
The word TRY is the closest thing I have to CATCH
<remexre>
does that mark the after-x/0-return-point to be at intercept ?
<rdrop-exit>
When TRY returns it will have either 0 or an XT, intercept deals with it
<remexre>
ah
<rdrop-exit>
TRY is similar to CATCH execpt my "throw codes" are XT's
<rdrop-exit>
or 0
<rdrop-exit>
* XTs or 0
<rdrop-exit>
you can just execute it
<remexre>
ok, makes sense
<rdrop-exit>
When I need a new "throw code" I just make a new fallback exception handler definition, usually I name it x<something>
<rdrop-exit>
xoverflow xbus xnan etc...
<rdrop-exit>
It's just a naming convention
<remexre>
okay, makes sense
dave0 has joined #forth
<rdrop-exit>
ANS style throw codes are unecessary overhead IMHO
<rdrop-exit>
We have names and XTs, that's enough
<rdrop-exit>
Instead of saying -1 is the "throw code of abort", the XT of XABORT is the "throw code of abort"
<remexre>
though wait, how do you intercept execptions then
<rdrop-exit>
Same as ANS
<remexre>
so you'd have a CATCH, and you do a test on the XT it returns after?
<remexre>
or, a TRY I guess
<rdrop-exit>
In ANS if your intercepting an division by 0 you compare the throw code to -10, in my approach you compare the throw code to the XT of X/)
<rdrop-exit>
* X/0
<remexre>
okay, that's the part I thought was kinda gross
<remexre>
because in ANS I'll just do -10 CONSTANT exn-x/0
<dave0>
does X/ just print a "division by 0 erorr" ?
<rdrop-exit>
remexre, in my system the throw code for division by zero is ' X/0
<rdrop-exit>
(or ['] X/0)
<rdrop-exit>
dave0, you define X/0 to do whatever best suits your system
<dave0>
rdrop-exit: nice
<dave0>
recovery is something you never see in C code
<dave0>
after a fault
<rdrop-exit>
dave0, it's a fallback handler for when no one deals with the exception
<remexre>
rdrop-exit: yeah, XTs instead of magic numbers is definitely nicer, but the thing I was hoping to improve was the dance one needs to do to handle only one error
<remexre>
and to some degree, it'd be nice if there were more flexiblity, like in CL conditions
<remexre>
where your handler can say where control flow should resume at
<rdrop-exit>
that's just sugar over the basic mechanism