4.2 KiB
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
Language Specification Repository (Private):
git.purplecello.org
Language Implementation Repository:
git.purplecello.org
Language Implementation Repository (Mirror on GitHub) (Private):
github.com
Assignment Page (Private):
snow.instructure.com
Problem and Interest
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.
Languages
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.
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.
The special feature for the Rust port is being able to export and import the
interpreter state in the repl using #save <filename> and #load <filename>.
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.
Lessons
Struggles
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.
https://en.wikipedia.org/wiki/HP_48_series https://en.wikipedia.org/wiki/HP-28_series https://en.wikipedia.org/wiki/RPL_(programming_language) https://gitlab.com/da_doomer/markdown-slides