<rdrop-exit>
even though the canon cat is Forth based, the editor and user interface aren't block based, so my editor will definitely have major differences
<veltas>
Cool
<rdrop-exit>
Raskin later wrote up many of his ideas from the Cat in the book "The Humane Interface"
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #forth
<antaoiseach>
Just curious - why does gforth not have "forget"? I tried reading up on markers in the gforth documentation, but couldn't make much sense of it.
<antaoiseach>
dzho: Thanks! That actually looks quite promising
<antaoiseach>
So basically, wherever we put a marker, that is a point-in-time marker, and when we invoke the given name, it resets to that point-in-time ... is this correct/
<antaoiseach>
?
<veltas>
antaoiseach: It can be used for temporary scope, freeing up memory, or before recompiling some source. Since the dictionary is linear it's one of the 'obvious' operations to support.
<veltas>
That example on Stack Overflow uses the current, more portable, standard forth version of 'forget'.
<veltas>
But it works much the same way
cantstanya is now known as frank
frank is now known as cantstanya
<veltas>
The reason it is more portable is because the assumption the dictionary is in a simple linear layout is not always true, some forths have more complicated layouts, so the word MARKER is introduced to give the forth environment an explicit opportunity to save any state that might be needed to 'restore' the dictionary in more involved ways
<antaoiseach>
veltas: Thank you very much! I think I get the broad picture now
<antaoiseach>
So using this, inside of scripts, I could potentially define some variables, use them, and then discard them - sort of simulating scope as you mentioned?
Labu has quit [Quit: Leaving.]
<veltas>
It is one way you can do that, yes
<veltas>
Unfortunately this is not a totally flexible method (after all, you might want some scoped variables within words that will be executed during compilation, well obviously that is not possible).
<antaoiseach>
veltas: Haha ... I came to that same realisation after I wrote it!
<antaoiseach>
yes, you're right
<veltas>
That sounds promising antaoiseach
<veltas>
Forth is like this, we get a lot of really simple tools and it is kind of our job to understand a bit about how they work and therefore when they won't work
Zarutian_HTC has quit [Ping timeout: 260 seconds]
<antaoiseach>
veltas: Indeed! I'm an absolute beginner, but I'm slowly beginning to appreciate it as much more than a barebones RPN calculator (which most tutorials seem to focus on) - I am actually working on "The Complete Forth", and I love the book so far. It's making a whole more sense than "Starting Forth" (which I found a bit tedious)
<veltas>
lol it seems there are two kinds of people
<veltas>
I will say it's not unique to Forth, all languages have these considerations. Try explaining to a new C programmer why a const variable's value is not considered a 'constant' when the initialisation is already visible and 99% of modern compilers would not have a hard time retrieving it there and then.
<antaoiseach>
Hehe ... fair point
<antaoiseach>
What do you think of more modern languages like Rust and Zig, which do enforce much stricter constraints?
<veltas>
I haven't used either of those but there are always dumb holes in languages, hard to not do.
<antaoiseach>
Oh, absolutely.
<veltas>
In Forth it's actually less of a "dumb hole" and more like a big walkthrough of how the compiler and interpreter is generally guaranteed to work
<veltas>
and then you *know* without being told where the 'holes' are
<veltas>
You have to guess a bit with higher level languages because they will present the highest level view they can
<antaoiseach>
What actually makes me a bit uneasy is how flexible the system appears to be ... I presume the standard defines some basic words, but then there appear to be many ways of doing I/O, for instance
<antaoiseach>
I had been working through "Starting Forth" and the chapters on disk access (?) did not work at all
<antaoiseach>
How does one deal with such issues?
<antaoiseach>
I mean ... Forth seems to be nothing and everything at the same time ... not sure if I can put it better
<antaoiseach>
Right now I'm sticking to gforth and trying to learn by sticking to the standard, but the real benefits of Forth seem to be specific to systems?
<veltas>
I 'learned' by reading Starting FORTH, the gforth tutorial, a bit of the gforth manual, and trying stuff out with Forth 2012 to hand.
jsoft has joined #forth
<veltas>
I think there is an innate benefit shared by most forths that they have a relatively simple and open approach to interpretation and compilation
<veltas>
And generally they can be pretty small too, which is useful in certain applications, but also it means inherently that they are very *factored*
<antaoiseach>
Hmmm
<antaoiseach>
So, from experience, how much does actually carry forth between systems? Is it mostly the experience of having worked with a Forth? Substantially more? less?
<crc>
for me, I don't carry forth code between systems. (this is probably due at least in part to the deviations my forth makes from the standards)
<veltas>
You can choose to write standard forth, and then your forth will work on many forth systems, and more with a few shims.
<crc>
I can't bring myself to use a standard forth anymore outside of occasional tests
Zarutian_HTC has joined #forth
<antaoiseach>
two very different and interesting perspectives!
<antaoiseach>
+crc: does that mean though that you have to relearn a substantial part from scratch?
<antaoiseach>
(I presume that basic stuff like loops, conditionals are more or less standard across forths?)
<crc>
my conditionals, loops, and such are all non-traditional (I use quotations, anonymous nestable code blocks, for them)
<crc>
antaoiseach: re: relearning, I don't see this as a big issue. I deviate from the standards, but it's not so f
<crc>
different that existing skills can't be reused
<crc>
my word names are sometimes different, and my string words are completely different, but it's not overly difficult to adapt at least smaller programs to run on my forth
<veltas>
I will agree with that assessment of retro, as an '''impartial''' observer, a lot of it seems to just be making things more consistent than what you get in a normal forth
<veltas>
And choosing a more consistent naming scheme
<antaoiseach>
+crc: whoa ... that looks so very different! Is it your custom Forth?
<antaoiseach>
veltas: Thanks for that observation - it can be quite intimidating for a beginner like myself! :-)
<veltas>
What is the point of AHEAD?
<antaoiseach>
Maybe this is a stupid question, but how fast can you guys read your own Forth code? For my rudimentary programs, I find that composing *some* viable solution seems fast enough, but reading it back, even with meticulous stack notation and comments seems quite a bit slow, especially since I try to mentally keep track of the stack state
<antaoiseach>
That, in fact, seems to be my biggest problem right now - feeling like the stack myself :D
<veltas>
I am very new, I find it easy to read *my* code because I have conventions for making it a bit easier to track the stack
<antaoiseach>
veltas: Hmmm... maybe I need to finish the basics and start writing more code! :-)
<veltas>
Every time I change the stack layout, except inside one line, I will put a comment like ( a b c ) to quickly describe what's on the stack
<veltas>
On the next line
<antaoiseach>
Interesting!
<antaoiseach>
I can see how that would help indeed
<veltas>
And I don't bother if the word is very short, which words probably should be in general
<veltas>
People tend to add extra spaces on a line to indicate grouping
<veltas>
i.e. 2 spaces between two distinct logical parts of a calculation
<antaoiseach>
veltas: Hmmm... right now I tend to put them on different lines, but that sounds like a good idea as well ..
<antaoiseach>
Just curious - which Forth are you using and for which system? I mean, a specific controller?
<veltas>
I mostly used gforth
<antaoiseach>
+crc: Also, I found this - http://forth.works/retro-unix.c. This your Forth implementation, right? Should be fun studying it
<veltas>
Right now I am writing a forth for the ZX Spectrum
<antaoiseach>
veltas: Oh, nice! I was also planning on doing some small projects using only gforth till I get settled in! :-)
<antaoiseach>
In Forth?
<veltas>
I'm writing it in assembly and raw colon definition codes
<antaoiseach>
Ah, right...
<antaoiseach>
So the bare minimum words would be in assembly, and then build up on those in Forth itself, right?
<veltas>
I'm also writing most of the colon defs in Forth alongside the raw code, hopefully I can actually convert most of this code to forth instead
<veltas>
Yes bare minimum and anything that requires being fast
<antaoiseach>
veltas: Thanks! Will keep an eye on it ... should be useful for me later on
<veltas>
Why is that?
<antaoiseach>
And I presume this should run fine on an emulator, right?
<veltas>
Yes
<veltas>
I'm developing it on an emulator right now, I'm lockdowned away from my actual Spectrum :(
<antaoiseach>
veltas: I would like to write a Forth from scratch myself! :D .. .maybe not for the same machine exactly, but this should be handy as a reference!
<antaoiseach>
veltas: haha... yeah, this whole lockdown has been terrible.
<veltas>
Are you familiar with the spectrum?
<antaoiseach>
veltas: not much - just as part of some history of the models from that era ..