From 2482636d9ba8b2864b8ef33b981a02bc8478b05c Mon Sep 17 00:00:00 2001 From: sforman Date: Sat, 26 Aug 2023 10:56:21 -0700 Subject: [PATCH] Note on Variations --- docs/source/Thun.md | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/source/Thun.md b/docs/source/Thun.md index fdc9392..901f532 100644 --- a/docs/source/Thun.md +++ b/docs/source/Thun.md @@ -219,6 +219,28 @@ but perhaps in practice it won't come up. (Because writing Thun code by derivation seems to lead to bug-free code, which is the kinda the point.) +### Variations between Interpreters + +There are several small choices to be made when implementing a Thun +interpreter (TODO: make a comprehensive list), for example, the Python +interpreter keeps all of its functions in one dictionary but most of the +other interpreters have a `case` or `switch` statement for the built-in +functions and a separate hash table for definitions. Additionally, of +the interpreters that have hash tables most of them check the hash table +after the `case` statement. This means that one cannot "shadow" built-in +functions is some interpreters. You can `inscribe` them, but the +interpreter will not look for them. + +I haven't yet formally made a decision for how Thun *shall* work. +Letting built-ins be shadowed is fun and useful for exploration, and +letting them be inviolate is useful for unsurprising behaviour. + +Another choice is how to handle duplicate definitions in general. Should +you be able to reuse a name? Or should `inscribe` throw some sort of +error if you try? + + + -------------------------------------------------- Copyright © 2014 - 2023 Simon Forman