etng-r2/pattern-matching-ftw.txt
changeset 282 36ad47fbeb8d
parent 280 f0535598e4af
--- a/etng-r2/pattern-matching-ftw.txt	Tue Aug 11 01:47:29 2009 +0100
+++ b/etng-r2/pattern-matching-ftw.txt	Fri Aug 14 10:15:46 2009 +0100
@@ -114,3 +114,65 @@
   follow :: -
   many :: -
   many1 :: -
+
+
+14 August 2009
+---------------------------------------------------------------------------
+
+Objects need to present alternately as *interpreter* and
+*interpretee*. Interpreters are in the pattern-match role;
+interpretees are data (ADTs etc). Data and co-data?
+
+So presenting as an interpreter is straightforward. Presenting as data
+is trickier. Ordinary expressions combine objects, interpreter in head
+position and syntax in non-head positions. On the pattern-matching
+side, the matching logic embodies the interpreter. The matching logic
+examines the offered data either *reflectively* or *interactively*.
+
+(Ha - where COLA has a recursive lookup that is ground-out on the
+primitive lookup object, we here have a recursive streaming-of-data
+that needs to be ground-out on primitive data streams! (as in,
+messages should be able to be Real Streams With Behaviour, but in
+order to be well-founded, some fake/primitive implementation needs to
+be available.)
+
+Reflective examination actually feels pretty interactive, just on the
+object's metaobject. Is representation (i.e. normal meta stuff) the
+same as data/interpretee in this sense? After all, a pattern-matcher
+may wish to examine an object's structure either at a physical level
+or a logical level. Normal meta stuff is the physical, representative,
+stuff; this interpretee idea is the logical level.
+
+Objects should be able to control how they are presented as data. One
+possibility is a two-stage menu/inject, where the interpreter offers a
+menu of contexts and the datum injects a context into the menu,
+backing off and trying an alternative context on DNU. The symmetric
+case works just as well, though, where the datum presents a menu and
+the interpreter injects into it. This is effectively multiple dispatch
+:-(
+
+    -- an interpreter menu
+    -- context     representation-pattern
+    { .stream -> { .pair head tail -> ...;
+                   .nil            -> ... };
+      .tuple  -> { length          -> ... } }
+
+This is also really similar to HTTP content negotiation.
+
+Actually on second thoughts perhaps it's better for the interpreter to
+inject a preferred interpretation into the datum, and have it answer
+either a representation under that interpretation, or DNU.
+
+    -- data menu for cons
+    { .stream k -> k .pair head tail;
+      .tuple  k -> k 2 head tail }
+
+    -- data menu for nil
+    { .stream k -> k .nil;
+      .tuple  k -> k 0 }
+
+Is using DNU appropriate here, or is an explicit failure-k better?
+
+    { .stream kt kf -> kt .pair head tail;
+      .tuple kt kf -> kt 2 head tail;
+      _ kt kf -> kf () }