https://github.com/namin/lisp-variations

variations on lisp, exploring reflection
https://github.com/namin/lisp-variations

lisp meta reflection scala scheme

Last synced: 2 months ago
JSON representation

variations on lisp, exploring reflection

• Host: GitHub
• URL: https://github.com/namin/lisp-variations
• Owner: namin
• Created: 2022-03-01T03:02:52.000Z (about 3 years ago)
• Default Branch: main
• Last Pushed: 2023-12-31T18:47:22.000Z (over 1 year ago)
• Last Synced: 2025-03-17T18:55:38.388Z (2 months ago)
• Topics: lisp, meta, reflection, scala, scheme
• Language: Scala
• Homepage:
• Size: 177 KB
• Stars: 10
• Watchers: 2
• Forks: 1
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Lisp Variations

This development served as the basis for some assignment in the [Course on Metaprogramming](https://github.com/namin/metaprogramming), University of Cambridge, UK Michaelmas Term 2018.

It will now be extended to further experimentations.

## Motivation

### Quotes by Alan Kay

> The MOP example is to decide after the fact to change the execution

> strategy and tactics for how dynamic instances are represented while

> running -- e.g, can you decide that some objects should better use

> hash tables rather than arrays to represent them?”

> Similarly, the MOP example is *really interesting* if the new

> behaviors added via reflective access are automatically compiled to

> be part of the base languages machinery (rather than being an

> interpreted add-on).

## learn by doing

Running `./ex.sh` will produce folders and zip files for exercise `ex1`.

For exercise `ex2`, see the [LMS branch](https://github.com/namin/lisp-variations/tree/lms).

## done

- The [LMS branch](https://github.com/namin/lisp-variations/tree/lms) has some variations that use [Lightweight Modular Staging (LMS)](https://scala-lms.github.io/tutorials).

- [`lispi.scala`](lispi.scala) is the basic interpreter.

- [`lispb.scala`](lispb.scala) turns all the interpreter structures into object

  structures (primitives, environment, continuations), so we can later

  do reification/reflection.

- [`lispc.scala`](lispc.scala) adds `FSUBR` and exposes the interpreter functions,

  adds `FEXPR` and implements a `set!` with history tracking.

- [`lispd.scala`](lispd.scala) adds `call/cc` as a built-in or user-defined form.

## todo

- How much of Purple's infrastructure do we want to re-use? What is the intellectual contribution wrt to Purple?

- Thinking by-hand about the compilation FEXPRs. What should happen for `(foo (+ 1 2))`? or `(lambda (foo) (foo (+ 1 2)))`?

- Consider a Just-in-Time model of guarded optimizations.

- Consider open implementations. How can the system provide compilation / implementation directives?

- Consider restrictions to the semantics so that compilation is more reasonable. (How, without losing the spirit?)

- Contrast FEXPRs implemented as a user-level concept in

  [Black](https://github.com/namin/black/blob/fexpr/examples/fexpr.blk)

  /

  [Purple](https://github.com/namin/lms-black/blob/master/src/test/scala/lms/black/fexpr.scala)

  with the built-in FEXPRs here.

  Explore compilation and "bugs" (does compilation change the semantics? maybe not, because not optimizing compiler?)

  in FEXPRs in Purple.

- Try modifying `base-eval` so that it records the calls to it as they happen.

  Should notice that base operations are not affected, only explicit calls to `base-eval`.

  How could `base-eval` be truly modifiable? Would it cause an infinite recursion, unlike in the tower model?

- Try making `base-apply` more flexible, adding new custom calling conventions.

- Consider making environment functions like in Brown'84 to support custom behaviors during lookup?

  Or add a lookup function?

- Add compilation to `lispc.scala`. How do we achieve that? We

  have to compile wrt to the current semantics. We need a way to

  distinguish environment entries that are stable. We put compilation

  under user control, with functions as a unit. What do we do with

  `FEXPR`? Impose restrictions? Perhaps, follow the [Purple](https://github.com/namin/lms-black) model.

- Support macros in macros naturally? Do we need a macro calling convention? Do we need to define new calling convention at the user level?

- Support macroexpansion separate from evaluation at the user level.

- Implement quasiquotes in the reader, and then as a user-level macro.

- How could one implement vectors at the user level?

- Implement structs at the user level (using a macro), possibly following [Matt Might's blogpost](https://matt.might.net/articles/implementation-of-scheme-vector-struct-in-syntax-rules/).

- Implement a file loader.

- Support variadic arguments.

- Functions are opaque. Open them?