A peculiar and fun Forth like compiler targeting bash functions, recently made available.

[Bushmills]

As I like Forth to be fun too, apart from its practical aspects, I've been enjoying Forth written in lesser likely languages, from scripting languages to editor macros to mobile device "automation" apps.
Here's my recent concoction, named yoda which is now at the point of starting to even become somewhat useful, with the gravest flaws and problems now eliminated.
It's a Forth-like implementation not based on a virtual machine, but compiling to bash functions. These compiled functions execute in the same context as the compiler responsible for generating them, which means that the compiler won't compile to a file which is then loaded and executed, but to the environment wherein it is running itself, very much like you're familiar with from about any Forth interpreter.
It features reasonable code transparency, by providing the words to access and view the source compiled words have been compiled from, as well as the generated code. It also features built-in word description lookup capabilities, aiming to lower the threshold to fledgling Forth users.
But in fact I shouldn't call this a "Forth", as it's merely "Forth like", as I didn't bother about trying to adhere accurately to one or several of the available standards, which is partly due to the host platform (bash) making it somewhat hard. Example: double cell integers, no "real" memory access, code space separated from (virtual) memory space, a return stack which doesn't live up to its name. However, it's up there for inspecting, toying with it and hopefully enjoying it.
About half of the words it provides has by now been described ("documented", sort of)

Requirements:
a computer running bash (that means, probably some Unixoid system), which has coreutils and sed installed.
Additionally, a text editor would be nice too. (sed dependency has been dropped)

[MitchBradley]

This is amusing to me because just yesterday I was thinking how funny it would be to implement Forth in BASH. There is no way I would have done it though.

[Bushmills]

Here's another Forth in bash, but this one is virtual machine based, and therefore a tad slow:
bashforth
This is older stuff, close to 20 years ago now that I enjoyed coding this.
yoda is faster by a factor of about 30 to 50.

[MitchBradley]

About 30 years ago I wrote Forth in PostScript in one page of code.

[Bushmills]

At a point I attempted to code a Forth in Brainfck :) I got to the point of working random memory access, then I gave up on the attempt. That was about the time when I then switched to a Perl implementation, going the lazy route :)
That implementation is on my page of my projects on github too, btw, but the completely incomplete Brainfck version I eradicated, no trace left of it.

[MitchBradley]

I was mentoring a high school student a few years ago and gave him a quick lesson in Forth. A couple of weeks later he came to me with an implementation in Haskell. He was having trouble with implementing data space but we figured out a way to do it by forking the workspace on every store operation. Hideously inefficient, but hey.

[Bushmills]

mentioning Haskell, I was wondering what the most unlikely language used to implement Forth in was, thinking of a handful of code golfing languages like Jelly, Vyxal, and also Husk which took some inspiration from Haskell. My personal favourite may be a Forth running on a set of pneumatic or hydraulic valves as host CPU.

[catb0t]

This is great! Definitely one of the most unusual Forth implementations I've come across.

[niclash]

Here is another implementation challenge; Minecraft Redstones. Cheers Niclas

…

On 2022-01-09 03:47, Cat Stevens wrote: This is great! Definitely one of the most unusual Forth implementations I've come across. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications on the go with GitHub Mobile for iOS [3] or Android [4]. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> Links: ------ [1] #110 (comment) [2] https://github.com/notifications/unsubscribe-auth/AAA2BROKBXALVES4Y6DGWCLUVDZLFANCNFSM5LP5BV3A [3] https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 [4] https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

[Bushmills]

I got the wiki running and a handful of pages populated, aiding with the description effort of everything related to yoda

[ruv]

@Bushmills, I have looked at the differences, and I wonder why not use just another name when a word behaves differently?

For example, you could rename your variants:

• parse to parse$ (since it places a string on the string stack)
• immediate to compile-only (since your variant actually works as the latter one in many Forth systems)
  • and define immediate to copy a header to the compiler vocabulary
• abort to (throw)
  • and define throw as : throw ( x|0 -- ) dup if (throw) then drop ;
  • and define abort as : abort -1 (throw) ;
• ?abort to ?throw (probably, for compliance, it should not throw code 0 by any means)
• string patter "ccc" to "ccc"$ or $"ccc" (to indicate that the string is placed on the string stack)
  • and make the string pattern "ccc" to place (c-addr u) on the data stack only
• <# # #s #> to <// // //s //> or <⌘ ⌘ ⌘s ⌘> (for pictured numeric output of single-cell numbers).

[Bushmills]

@ruv, thank you for your thoughts on standards compliance. This is valuable and very much appreciated input!
Renaming parse to parse$ makes entirely sense, and I will follow that suggestion. The current naming is due to parsing preceding strings in yoda and me not reconsidering the name choice of parse once strings were implemented.
The general answer to "why not use just another name" is that a system is either compliant or not compliant - an "almost" compliant system is still a non-compliant system, and given that I'm unlikely to manage "full" compliancy, I didn't bother much about eliminating single aspects of non-compliancy, as with the examples of same naming for different behaviour. With some, such as with throw, implementation is still pending, which is why I wouldn't, even temporarily, want to use these words up now already. I rather change abort once throw exists, letting it take advantage if it, and consider abort for the time being a stop-gap measure.
About changing string pattern, I'm hesitant. Mostly due to wanting to avoid c-addr u type strings altogether, or as much as possible: dealing with that type of strings - each char stored as it's ASCII value in a single array entry - is rather inefficient in bash, so I want yoda to default to string stack for strings related operations, and only unpack vs pack them when it's inevitable. Using "these type of string" just reads more naturally in this context, as I don't have plans to implement s" for c-addr u type strings. I may - possibly - think of adding a ." string pattern for output, but as there's no storing of strings involved, there should exist no need to identify by naming what kind of string was output.
Your immediate vs compile-only suggestion I will consider. yoda used a precedence flag before, so it was easy to keep the immediate word where it was used, while only changing it's implementation. I'm undecided with regards to this choice, and that's when I like to listen to opinions others may have.

[Bushmills]

Just another quick additon on the abort issue: yoda error handling hasn't been finalized: for proper error handling I want real warm start capability - which I haven't at this point. Currently, errors are partly signalled back through nested words, in the hope of reaching from/evaluate or even quit eventually. This is messy and not to my liking, and this also affects the preliminary status of error/abort/throw and related words. Probably there can't be a definitive implementation before knowing the best way how do deal with the occasional need of warm starting the system.

[MitchBradley]

I too am a big fan of changing the name if the detailed semantics change. Otherwise anyone else trying to read the code can become utterly confused. And if you do decide to try and implement the standard version, you can do so without having to rewrite old code that uses the variant. My mantra: Names Are Cheap

[Bushmills]

Valid points you have there, @MitchBradley. You guys make so much sense here.

[Bushmills]

I've followed your valuable suggestions re word naming, and made compiled from immediate. For consistency, former - misnomer - interactive is now interpreted.
Thank you!