Home Original page

GitHub - brownplt/stacker: A notional machine for the SMoL languages

Stacker

Take me to a running stacker

This tool presents how programs work. It focuses on presenting on the (call) stack, environments, and the heap. Such program must be written in SMoL, an educational language that support many language features commonly found in modern programming languages. SMoL has three surface syntaxes: Python-like, JavaScript-like, and Racket-like. Although programs must be written in the Racket-like syntax, this tool is able to present programs in two other, possibly more favorable syntaxes.

What is SMoL?

SMoL = Standard Model of Languages It includes (mutable) variables, mutable vectors (i.e., arrays), and first-class function.

See this document for more details.

API

All parameters are optional.

(URL) Parameter Type Meaning
program String the program to run, written in the Lispy syntax
syntax Lispy or JavaScript (or JS) or Python (or PY) the syntax in which to present everything
nNext Non-negative Integer simulate clicking the Next button nNext times
randomSeed String the seed used to generate heap addresses
readOnlyMode Anything when this parameter is set, stacker will present a much simpler UI that is just enough for reading the trace
printOnRequest Anything when this parameter is set, stacker will only print values as requested by (print v) (rather than printing all values returned to the top-level)

To see examples of parameters, you can run programs in the stacker and then click the share buttons.

Limitations

Potential Problems: limitations that might exist, but we are not sure

Programs that can be presented in Python-like syntax might or might not have a Python-equivalent semantics.

Programs that can be presented in JavaScript-like syntax might or might nor have a JavaScript-equivalent semantics.

To-do: limitations that we plan to remove

See the GitHub Issue page.

Know Issues: limitations that we don't plan to (or simply can't) resolve

Some programs can't be presented in Python-syntax. This restriction is mostly caused by the facts that Python have no let expressions, and that Python's lambda only allow exactly one expression as its body.

Python uses the same syntax for variable definition and variable mutation. Although this design might work well most of the time, there are programs, especially tricky programs, where disambiguation is needed. Python disambiguates with local and global keywords. We made some effect to insert the keywords properly, but there is likely a few corner-cases where the Python mode doesn't faithfully represent Python or where a SMoL program can't be translated to Python. For example, if a lambda mutates a free variable, we can't translate that to Python.

Development

For every fresh clone

This will install dependency packages.

For every (local or remote) update

This will start a ReScript program that keeps .res programs and .js programs in sync.

This will run a Webpack program that keeps .css, .js, etc. and the final webpage in sync.

File Types

  • Xyz.res: a React component
  • xyz.res: a module
  • webpack.config.js: the webpack configuration

Accessibility Consideration

No ARIA?

https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

"No ARIA is better than bad ARIA."

No tooltips?

https://inclusive-components.design/tooltips-toggletips/

Tooltips are a last resort, where space really is at a premium

Contributions

This software application is developed by Kuang-Chen Lu (me) and Shriram Krishnamurthi.

The design is originally based on the systems designed by Shriram and John Clements. The original design can be found in the following publication:

Clements, John, and Shriram Krishnamurthi. "Towards a Notional Machine for Runtime Stacks and Scope: When Stacks Don’t Stack Up." Proceedings of the 2022 ACM Conference on International Computing Education Research-Volume 1. 2022.

During the revision of the design, many people have contributed feedback, notably: