Plan Composition Using Higher-Order Functions

Elijah Rivera, Shriram Krishnamurthi, Rob Goldstone

ACM Conference on International Computing Education Research (ICER) 2022

Paper Link: https://dl.acm.org/doi/10.1145/3501385.3543965 

Blog Post: https://blog.brownplt.org/2022/07/09/plan-comp-hof.html 

Students can write plans! We use higher-order functions (HOFs) as the main "language of planning," represented as a custom interface using Snap! blocks, and show that students are able to write correct plans for simple data processing problems before writing the code for the problems.

Observations on the Design of Program Planning Notations for Students

Elijah Rivera, Shriram Krishnamurthi, Kathi Fisler

ACM Technical Symposium on Computer Science Education (SIGCSE TS) 2024

Paper Link: https://dl.acm.org/doi/10.1145/3626252.3630901

Blog Post: https://blog.brownplt.org/2023/12/27/plan-notations.html

Not so fast! We tried to transfer the previous result to a more novice student population, on a slightly different style of problem, and it did not work well at all. The following semester we relaxed the constraints, allowing students to plan in whatever interface/medium/style they preferred (including the previous Snap! interface). An overwhelming majority of students wrote simple (and correct!) to-do lists in English prose, not wanting to learn a separate "language for planning."

Iterative Student Program Planning using Transformer-Driven Feedback

Elijah Rivera, Alexander Steinmaurer, Shriram Krishnamurthi, Kathi Fisler

ACM Conference on Innovation and Technology in Computer Science Education (ITiCSE) 2024

Paper Link (pre-print): https://cs.brown.edu/~sk/Publications/Papers/Published/rsfk-planning-w-gpt-feedback/

Blog Post: Coming Soon!

At the root of our desire to have a more formal planning notation is a desire to be able to give feedback on high-level plans before students start programming. But with the advent of powerful large language models (LLMs) like GPT4, maybe we don't need that formalization. We built a tool to give test-case-style feedback on student plans, by using an LLM to translate the student plan into code. The tool has its benefits, but is still quite unreliable.

(Coming Soon!)

We want to give feedback on program plans, but introducing too much formalization makes the process confusing and cumbersome for students, and using less structured natural language means relying on the still-unreliable LLM. What other feedback mechanisms might we be able to leverage instead?

Other PL + CSEd Projects

Structural versus Pipeline Composition of Higher-Order Functions (Experience Report)

Elijah Rivera, Shriram Krishnamurthi

ACM International Conference on Functional Programming (ICFP) 2022

Paper Link: https://dl.acm.org/doi/10.1145/3547633

Blog Post: https://blog.brownplt.org/2022/08/16/struct-pipe-comp.html

In the process of designing our first planning study (see above), we ran into some difficulty designing HOF composition problems. At the root of the problem are two different possible ways to compose HOFs, and a significant difficulty gap between them.  In this paper we both explain the different kinds of composition and their respective levels of difficult of student understanding, and then discuss the implications for functional programming pedagogy.

Automated, Targeted Testing of Property-Based Testing Predicates

Tim Nelson, Elijah Rivera, Sam Soucie, Thomas Del Vecchio, Jack Wrenn, Shriram Krishnamurthi

The Art, Science, and Engineering of Programming (<Programming>) 2022

Paper Link: https://doi.org/10.22152/programming-journal.org/2022/6/10

Blog Post: https://blog.brownplt.org/2021/11/24/pbt-revisited.html

When teaching property-based testing (PBT), it can be difficult to accurately assess the predicates that students write. We provide a methodology by which instructors can automatically generate test suites for PBT assignments, and then detail how effective these automated methods are at catching student errors when compared to a human best-effort.

(Old) Programming Language Safety

Keeping Safe Rust Safe with Galeed

Elijah Rivera, Samuel Mergendahl, Howard Shrobe, Hamed Okhravi, Nathan Burow

Annual Computer Security Applications Conference (ACSAC) 2021

Paper Link: https://dl.acm.org/doi/10.1145/3485832.3485903

Several large applications currently written in C/C++ are in the process of migrating to Rust. These migrations do not happen all at once, but piece-by-piece, resulting in an intermediate stage where a main Rust application is calling out via FFI to several C++ libraries. Rust is a memory-safe language, but those safety guarantees go out the window as soon as C++ has access to the same memory. Can we do anything to still preserve the guarantees of the Rust portion of the code?

We can with Galeed! "Galeed" is from the Hebrew for "witness heap," and is the name Jacob gives to the marker between his camp and Laban's in Genesis 31, which he swears to never cross to do harm. Our system similarly does not permit anything to cross the boundaries set up by the heap. Rust application memory is isolated using Intel's Memory Protection Key (MPK) technology, and C++ is never given direct access to it. Instead, the compiler translates pointer accesses to FFI calls to Rust. Rust will then perform the appropriate read/write in a memory-safe way.

Preserving Memory Safety in Safe Rust during Interactions with Unsafe Languages

Elijah Rivera

Master's Thesis, 2021

Paper Link: https://dspace.mit.edu/handle/1721.1/139052

(see above)