# YREA SLS *Kyler Olsen* *October-December 2025* *Snow College* *SE 3250* *Survey of Languages* *Final Project* Language Code Name: YREA **SLS** (*Stack Language Specification*) Language Webpage: [sls.purplecello.org](https://sls.purplecello.org) Language Specification Repository (Private): [git.purplecello.org](https://git.purplecello.org/KylerOlsen/LangsFinalPlaning) Language Implementation Repository: [git.purplecello.org](https://git.purplecello.org/KylerOlsen/YREA-SLS) Language Implementation Repository (Mirror on GitHub) (Private): [github.com](https://github.com/SnowSE/final-project-KylerOlsen) Assignment Page (Private): [snow.instructure.com](https://snow.instructure.com/courses/1154808/assignments/16233203) In 1986, Hewlett-Packard released their HP-18C and HP-24C calculators, which introduced their new RPL operating system and programming language. The language was based on LISP and Forth (a stack-oriented language). RPL, aka Reverse Polish Lisp, was used by HP in several of their calculators through the 1990s and 2000s, most famously on the HP-48 series of calculators. HP calculators have been a favorite among engineers because of their post-fix notation. When in my journeyings on the internet a few years ago, I discovered Uiua, a pre-fix, stack-based, array-oriented language, which inspired me to create my own, except more largely inspired by HP's RPL. I started planning out an idea, but never made it far. This semester I was again inspired by looking at the various programming languages to again make my own, this time throwing in C to the mix. What resulted is my *Stack Language Specification*. Having difficulty coming up with a name for the language, I went with SLS. SLS is a stack-oriented language with C inspired syntax. While these have not been implemented for the assignment, I do plan on adding a Rust inspired type system, as well as Uiua and LISP inspired array operations. Memory management follows the pattern in RPL, everything is on the stack. One of my goals with this language is also to have it able to run on an embedded system, such as my own custom calculator. **C** was my selected language. It was an excellent choice for my project as it is well suited for systems programming. It is a low level, yet powerful language. While string utilities are not as robust as most modern languages, I still feel like it was an excellent choice. Other major interpreted languages also use C to implement their interpreters, such as Lua and Python. Manual memory management was a slight difficulty for me. The only way I could find what was causing a segmentation fault was to run the binary with `gdb`. Still my experience programming C in a Linux environment was fun and rewarding. I became accustomed to utilizing the man pages (or manual pages) for documentation on the C standard library. I did use structs and unions heavily which we learned about when we looked at C. With them I was able to use polymorphism in defining tokens and data types. I am able to successfully compile and run this implementation on a Raspberry Pi Pico with a RP2040 microcontroller. You can interact with the REPL over a serial connection. **Rust** was the first language I tackled porting my project to. I am not as familiar with Rust as I am Python, so thats why I wanted to get going on this port first. I avoided using external libraries with C as they can be famously difficult to link and compile. Rust's build system, cargo made that issue basically non-existent. It is also memory safe with its barrow checker. With it being another systems programming language, and these modern features, I feel like it is just as good of a choice of a language for my project. In the past I have often fought with the barrow checker but with this project, either my experience, memory mindfulness in my original port, or the extensive AI help, I had no fights with the barrow checker this time. The special feature for the Rust port is being able to export and import the interpreter state in the repl using `#save ` and `#load `. **Python** was my final port. With it being the language I am most comfortable and experienced with, this was an easy port to make. While it is very easy, even for someone without my experience, and it has many of the same modern conveniences with package management as Rust. Where it is not a systems programming language, I would not be able to run this project on an embedded system very cleanly or easily, making Python not as good of a choice with my goal of portability to embedded systems. The special feature for the Python port is the SLS Calculator App. --- https://en.wikipedia.org/wiki/HP_48_series https://en.wikipedia.org/wiki/HP-28_series https://en.wikipedia.org/wiki/RPL_(programming_language)