Category: forth

We have a little game loop running, and it gets keyboard lines and echos them. Should we integrate something into the loop? If so, what? Also: Love one another.

I added quite a few words, and found some issues. But we also need some big features. How shall we proceed? Also: Love one another.

Our little typing spike leads me to some design thinking. Spikes often unblock the thought paths, and that happens today. Also a few lines of code and a much improved 'UI'. #StopTheCoup!

OK, I'll do the PyGame text pane. It seems to be the simplest thing that could possibly work Unfortunately, it's more than one small step. #StopTheCoup!

I know what I would like to accomplish next. If there's a way to do it, I can't find it. I need help, or a change in direction, or both. #StopTheCoup!

I feel that I've shown that I can program A Forth, but I don't really know how to program IN Forth. Time to begin to learn. #StopTheCoup!

#StopTheCoup! We need a FileProvider to feed us tokens from files. And we need file names, I suppose ...

#StopTheCoup! Let's go after those skipped tests. I think they just need recasting. All goes pretty well!

#StopTheCoup! We're working toward an INCLUDE word to read Forth from a file, where we'd save the definitions for whatever app we're writing. I think we need an inversion of control.

#StopTheCoup! Some thoughts on using compiled words for things like looping. Our next priority is loading definitions from files. How might we do that?

#ElonaldDelendaEst! Let's review the conditionals and looping. Let's think about what seems to happen when we do as we do. Let's think about more Forth and less Python.

#ElonaldDelendaEst! One pair of looping words is now using our new CompileInfo compile stack protocol. There is one more looping construct that needs attention. We create and remove duplication, making the program simpler.

#ElonaldDelendaEst! Applying 0BR, BR, and the new CompileInfo protocol in conditionals has resulted in simpler and more consistent code. Let's take a look at loops. BEGIN-UNTIL goes nicely. Just one small misstep.

#ElonaldDelendaEst! How do we add simplicity? By removing duplication and redundancy, and occasionally by generalizing specifics. Sometimes it takes a few tries.

#ElonaldDelendaEst! Now that CASE is stable, let's use what we learned elsewhere. I think we'll simplify things a bit.

#ElonaldDelendaEst! I test some CASE results. Looks good!

#ElonaldDelendaEst! Continuing the implementation of CASE-ENDCASE. I think we need to do the case-sys, collect the branch points, and fill them in. I believe we have nearly-right mechanisms in OF-ENDOF, and we'll use those and make them more right.

Our CASE-ENDCASE only needs its branches hooked up to work, I believe. I'd like to find a simple test for the actual branching words.

It turns out that a bit more study would have shown me that I already did a trivial Sys object and put it in play. Let's normalize that and then move a bit forward. A small surprise, and a bit of improvement.

If I recall correctly, it's time to start patching branch locations in CASE. Let's see how we might do that. We get a really nice start, despite nearly a week of forgetting everything we knew.

I'm going to try some further work on CASE, keeping it simple. Just pushing it forward a bit, if I can. I think we get a nice increment. Odd approach to testing.

Today I plan to actually begin the coding of the CASE-Of-ENDOF-ENDCASE phrases. And I have a glimmer of a better way to do it. Will the glimmer become light ... or darkness? Wisely, for once, I stop while I'm ahead.

Let's start thinking about CASE-ENDCASE. Thinking seems important right about now.

Reader Laurent points out a problem. I was going to fix it today, by accident. Let's do it on purpose. And maybe we can get down to cases.

I'm not sure what to do next. I'll reflect on some ideas exchanged with GeePaw Hill and then pick something, probably something easy.

I'll begin the morning with a bit of 'design thinking' about how we might interface our Forth to a bunch of robots. During that we find and fix a bug! Er, defect.

I have a little time. Let's see what we can do. Many tiny changes produce improved code. Who knew? (We did!)

It is literally oh-dark-thirty, and I am awake. Time to work on Forth. Is there a larger lesson? Yes, I think so. Things go well!

FGNO observations suggest a radical change to my 'Forth' spec, which should improve the supporting design. We FAFO a bit. Looks good. No great strides.

I have at least two more things to do before this thing is even good for its initial purpose. And I have what I think might be an interesting idea. Kind of a ragged morning.

I think yesterday's experiment with a pure interpreter has told us enough to decide not to do it. We'll discuss that, what it implies about experiments, and then look at next steps. Result: We have REPL!

I did an evil thing last night. It is tempting me toward a hard right turn. Must think about this. After too long, I realize that I was distracted by the shiny thing and didn't see its fangs.

Yesterday's pleasant discovery suggests that reducing our two word classes to one should be easy. Then, if it works as I expect, we'll talk about woulda coulda shoulda.

I'm interested in reducing my two classes, Primary and SecondaryWord to a single object that will feel more like a classical Forth word. This will require some thinking and doubtless some experimentation. Result: I am pleasantly gobsmacked!

At this writing I lack a feeling of direction. I'll muse briefly on the causes of that feeling, then try to find something interesting to do. We explore, change a few things, get a few ideas, then wander off. Pride in our work.

I've been busy programming in another universe, and fretting on this one's decline. It's time to get back into this Forth diversion from the Robot World, itself a diversion from something or other. Brief reflection on the olden days.

Well, our creation of Heap yesterday went smoothly, but it was all we did. Let's review the Forth code a bit more and see what it might be wishing for.

Now that CREATE-DOES> works, and I am reasonably confident that I have it right, let's review the code and check out the concerns left open last time. A perfect morning. (Added: P.S.

This time it's going to work, I'm sure of it. I promise not to change the title, or the blurb up to the next period if it doesn't. (Results: As predicted! Out of the park! Yay, team!)

I come before you today armed with information, if not knowledge. We'll try some small steps toward what I think I somewhat understand.

I fully expect to fail this morning: I don't see how to do what I need to do. I'll try to fail in a way that sets me up for a win sometime soon. Result: Bah!

I just deleted this morning's entire article. On purpose. Here's why.

I think we'll do variables and constants today. I also feel a pivot coming on. Unless I'm just hungry.

Interesting though compiled immediate words might be, I decide that variables are more important. I experiment with a somewhat smart heap and then, suddenly, realize how much we can do with a very rudimentary heap. I think we're onto something good!

If we're to be able to define compiler words with colon definitions, we'll need better access to the word under construction. I see options, vaguely. And I need information. Design musing here, little more. TL;DR may apply. We have an amazing interlude. We end with a Dangerously Clever Idea.

After this morning's somewhat lackluster performance, I do a bit of off-line refactoring and now I think we'll do a Lexicon. Can't hurt, might help.

There's refactoring to be done, including, possibly, some Big Changes. What shall we do? How shall we proceed? (Results: Two small steps; much confusion.)

My "friends" have well and truly nerd-sniped me. We're going to digress to look at Forth's tiny primitives that can be used to build words like IF-ELSE-THEN and such. Spoiler: A lot of thinking, and then a tiny but significant SUCCESS!

I've come up with an interesting possibility for reducing method clutter. Let's see what we think. (We think we like it!)

And so, Forth. Here chez Ron, it's another morning with Python and Forth. Some new year wishes within. Read on. (Spoiler: As often happens, things do not unfold as I anticipated. No worries.)

Unless I am mistaken, which is often the case, this morning's refactoring is going to be fine, F-I-N-E FINE. And I do not mean the meme, I mean really fine.

I think our little Forth is working as so far intended. Let's improve the code. Some thought on the original Forth(s).

I think I see, vaguely, what needs to be done to get our Forth to accept any Forth string and execute it. I am hopeful, if not entirely confident. Spoiler: It works!!!

We need to change our little Forth so that it can 'compile' and execute any Forth code, not just compile definitions. I'm expecting trouble and will regroup in that case. Results: I do a little refactoring and decide to regroup.

I think I'll invent the famous Forth return stack and use it to create a new looping kind of thing. Curiously that's almost exactly what actually happens. I even do R> and >R, and then don't use them.

Some Forth planning, and then, I write a POWER word that is hard to understand, and that could have been a trivial primary. Plus Forth comments, because POWER really needs them.

Today is my birthday. To celebrate, I think we'll implement DO-UNTIL.

Today, before the celebration begins, we'll do ELSE. Then we refactor the code. It takes me three tries to get code that I like. Long article, mostly just pasted and re-pasted code with small changes. Unwrap when ready, if you celebrate in a truly odd fashion by reading this.

With any luck, we'll do THEN today, which will make IF-THEN work. But first, some feedback led me to a very interesting site.

OK, after those nice improvements, let's get started on IF-THEN. Really. We complete *IF with a few lines of code.

Today I believe we'll actually get IF-THEN working. But first, I want to mention an odd thinking mistake that I made. (Result: Good changes, no work on IF. Yet.)

I haven't forgotten about IF. It's just that tests would be a lot easier if I had literal numbers. This goes really well.

The main story is still IF. Ron has what may be a good idea. We'll divert for literals. Lots of thinking written down here. A bit of code; a bit of success.

Ready for the next step in implementing IF-THEN. Is this a debacle, or a successful spike? Very long. Somewhat confused.

Our next story is IF-THEN. How might we do this pair of Words? Triple, if you count ELSE.

I've made some improvements. And I have a concern. Longish article, probably a quick read.

I read about how IF works according to Loeliger. Weird. How should we do it?

We need many things in our little Forth thing. Let's try to get clear on what we're doing here, and what we're not. Bad forth code slows me down. But we're doing OK.

Our first experiments went well. Let's start an implementation that's more like the kind of code we like to write. [Result: I am delighted!] (Also lambdas!)

A bit of reading and thinking is beginning to give me a sense of direction. Let's talk about it, and maybe implement a little something. This is how I work: read, think, code, rinse, repeat.

With a little help from my friends, I begin to reach some clarity on what this idea is and is not, and on why Forth has a 'compiler'. HYPOTENUSE! Gesundheit!

Still very early days for the Forth idea. I'll report on what I've been reading, muse a bit, perhaps try some code, if I can think of anything I want to learn. Progress!

I'm going to take a hard right turn and see about giving the game a 'scripting language'. I am proposing a Forth dialect. This could get weird. (Oops, it's Forth not FORTH. Sorry, Chuck.)