#retroforth — Public Fediverse posts

There is something extremely satisfying and almost magical in playing with small yet powerful #programming languages, especially if they can be distributed as single statically linked executables, with all the batteries included. #JimTcl, #RetroForth, #Rebol #RedLang

@robby @vidak That's what I thought a few months ago too ... but then I found #retroforth and I think I prefer the assembly language there now!

@rickcarlino @crc I often think about redefining the whole grammar to fit my own mental model of what's happening with each word; I don't like some of the historical names many Forths use for things, and I guess I'd end up building my own DSL when the domain is "my preconceptions".

One of the things I love about #retroforth is that it is so well documented and constructed that I know I could achieve this easily if I tried :-)

Hi #retroforth and other #forth people!

I've been trying and failing to understand Variables, and in particular how I should handle the storage and use of a fixed-length string that I have here ...

It starts off life on the stack; originally it came from #0 script:get-argument. I'm pretty confident that this means the data for it is up at the top of memory, between EOM and STRINGS.

Then I declare a Variable to use with this; Variables are basically Dictionary entries, and if I was declaring a new word, I'd expect d:xt to point to the beginning of the code ... so for a variable d:xt should point to the actual data?

I use allot to push Heap forward by the right size, so now I believe I have the space for the string ... but I don't know how I should copy it into there!

// With my string on the stack ...
dup 'Board var-n
s:length allot

So I'm sure I'm not doing the right thing with var-n - the string on the stack isn't a number, and although it is an address, it's up in the STRINGS space - but there doesn't seem to be a var-s.

There also seems to be different idioms around how to put new entries in the Dictionary, with one example being

:TempStrings ; data #32 !TempStrings

that I would have thought was calling out for var-n :-)

So ... after all that exposition ... what should I be doing in RETRO Forth, when I want to store a dynamically-created string value somewhere for later use? :-)

Debugging the #retroforth image file, wanting to see how the Dictionary is structured first-hand.

How long do you think it took me to realise that the memory location referencess were counted in RETRO's 32bit 'cells', and not the 8bit bytes I was reading the file in?

Far too long, that's how long. I messed around with endian-ness, I looked for offsets, I constructed fearful hexdump formats to show me all the details ... I didn't consider "multiply by 4" for a long time ...

Loving #retroforth so much!
For some reason I, apparently, am fluent thinking in it.
Starting to code some stuff in literate programming style with unu. Also great format to convert to gemini/html to share on pachapunk.

Should have looked in the examples/ directory, seems like there's what I need in there :-)

Thanks #retroforth (and @crc of course)

I feel like I'm a slow learner, instead of trying to figure out what I did wrong I'm trying to understand how the unwanted side-effect happened in the first place, and I'm very much not used to digging in to how a language is working, but this Forth provides all the parts and they're documented, so I can go from userspace to the core language, to the VM its running in, and below that to how the VM was implemented. Plus now I've found an implementation of the VM in RETRO Forth itself which is even more interesting!

I'm trying to grok #forth in general, and would appreciate some advice ... to help me understand what tools are already there that I haven't understood properly yet.

I'm not working with constrained resources, this is for general-purpose programs running on general-purpose machines; in some way there's no need to be using Forth except fun 🙂

The data stack is great, and of course gets messy while you're working in it ... but doesn't feel like its suited for permanence in any way - I can't keep an input on there, and keep on referring to it in lots of different places, without some ungodly "it's 8 places deep right now, how do I get a copy back up here to work on?"

Having allocated space in the dictionary for "named variables" is possibly the right thing; although I feel a little like I'm doing C pointer arithmetic trying to step through my "internal" data structures in there, and if the security world has taught me anything over the last mumble years it's that C pointer arithmetic can be very dangerous ...

#retroforth has some interesting looking features, like arrays, quotations and namespaces that feel like they might be great at resolving these feelings, but I'd like to know if I'm missing anything else more basic?

Like perhaps, every time I alloc some space for what will end up being used in a complex manner, should I be going down the Object route, defining my own data types & providing setters and getters etc etc before starting to use them?

Okay, I'm several days behind in #adventofcode and I have a little time before I should get to bed, so let's start at day 7 and go backwards, shall we?

As usual, streaming at my #owncast server. Come hang out while I grumble at #RetroForth for a bit! https://stream.cincodenada.com

#adventofcode2021 #forth #programming #livestream

This year for #adventofcode, all the languages I was interested in playing with felt like they were gonna be a lot of work to learn and actually solve things in. I didn't feel quite up to it this year so I hacked out day 1 in #QB64 - which is a delight but hardly new, QBasic is the first language I coded in!

But then @nihilazo started poking around in retroforth. Forth was high on my list but I didn't know what flavor to go with, so I gave retro a run, and it's nice, just enough bells and whistles to be approachable.

After porting over my initial #QB64 solution to Forth and tearing my hair out over variable declarations, I took a fresh run at it with stacks in mind, and ended up with what I think is a pretty nice, tidy solution. Especially nice was that when I needed to clean up the stack to do the full solution rather than leave the whole list in memory, it was literally removing one word. Fun! Yay fedi folks!

https://gitlab.com/cincodenada/advent-of-code-2021/-/blob/main/day1.forth

#adventofcode2021 #forth #stackbasedlanguages #retroforth #programming