YREA-SLS/REPORT.md

82 lines
3.9 KiB
Markdown

# 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)
## 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.
**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.
## 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