#lang scribble 2024 04 02 Another try at a formalism for a text adventure game. Start by generalities. Mix in specifics, even things too specific to be thought of as a formalism. Or too general Language 'Iform' I've seen has choice lists in it. Lists that are chosen from randomly by the system, Sometimes they're once-only -- it keeps track what you've seen before and never repeats. It it runs out, is that an error? Or merely a local failure? Or is there a default alternative/ Sometimes they can repeat freely -- nothing to keep track of. But there's something I call the scope of the choice -- something that language knows nothing of. Yet it's important. Where does it localise the list of chosen things so as not to repeat them? If it's setting up a room, say, there can eb a list of things that might be there. There might be a list of things to do there. But some of them are things that could be in another room. You need to localise the list of chosen options. If you go into a room and see a bed there, it could be tedious to be told that again. But it you go into another room, it's fine to have another bed there. A list of machine-made decisions las a locus, a scope, and there are likely a variety of things that could have loci attached to them. And, of course, there could be a global locus -- for events that sould be unique to the entire game. What kinds of choices are there? Classifiations: * on the basis of agency: * choices the machine makes. * choose from a programmer-coded list * use other algorithm * choices a player makes. * system provides a list of alternatives and/or free-form input. * On the bases of stability: * transient * permanent These nees a scope. * initialising. (may change as a result of game events late) These need a scope. * on the basis of repeatability: * repeatable choices. These may be chosen again lster. * nonrepeatable choices. These are available once only and will never be selected again. These need a scope. So ... Inform's mechanism of annotationg shoices with asterisks or pluses isn't enough for all these possibilities. AND we need a nechanism for denoting scope. What scopes are there? * a room * global (this is the one Inform provides) * an object being desribed. * probably some other possibilities. Let's say you have a choice. The word choice is quite ambiguous. It could refer to the entire set of alternatives and the at of choosing. And it could refer to one of the alternatives you are choosing from. Choices. And it can refer to the specific one you have chosen. SO, either the entire set, or one of them. Are there more specific choices. Same ambiguity exists with the word 'decision'. Now inform has all these choices explicitly coded as code. Can they be stored in a database instead? And what form should that database take? No. It shouldn't have to be a relational database. It shoul be free-er than that I suspect. Some kind of object store. Perhaps a permanent backing store an a set of updates resulting from play. And it should be possible to have some kind of nontrivial data structure. Is onpactness of the in-core notation important? I suspect it's not as important as it once was. Should se search for things having particular properties? Or shoudl we have pointers straight to them? I coul start out with Lisp S-expressions. Or Tree structires that can be written as JSON or some such. Later I can replace if something else seems to be better. S-expressions and an interpreter? Xexp and an interpreter? Modifiable loci within the data structure? Copy-on-write from the permanent stuff but in-place ... I'm thinking of executable code versus modifyable data. Do I want a firm distinctionsssssssss/ So. How should scopes be defined. Can a data structure be adequstely implemented by an expression that *is* the data structure? Or should it be a level on notations interpreted to product the data, which is istelf not executable in the ordinary programmatic sense of the word? Or like a Lisp quote-unquote combination? Or a data structure with exceptions that get piecesise executed once their dependencies are available? With the constant parts of the data structures getting copied? A well as the executable parts that don't have all their variables available yet? A kind of partial evaluation that's careful not to prejudge independent evaluations while still depending on previous ones? A kind of copy-on-revelation mechanism? Does this mean we have scoped revelations? With scopes being implemented by copying code? Could maybe work. I'd have to try it to know. Hmmm. Could use eq to decide whether something has been copied-with-changes or merely copied unchanged. Building an object from possibly altered subobjects can use eq to see if subobjects have changed and use the old object as copy if the subobjects have not been changed. That's how you change something in an immutable data structure, isnb't it? copy it with changes and just use the original if it doesn't. Is this a better data structure for the pict's I build for my pictures of houses? Probably not for the actual picts, because I don't have an exception mechanism or picts that have as yet undecided contents. But it could be used for s-expressions that represent algorithms for objects. Yes, call regular List functions when that's easy. But treat it all as copy-refinement. Hmmm. Still might want Pict to hang around. Ad still might want to do explicit drawing sometimes. Is explicit drawing compatible with the textual copy-refineent mechanism? Certainy it is if I draw only when the entire picture structure has been completely refined. Not at all if I draw when I have only partial evaluation. Making picts for constant subpictures is probably OK. I think this writing while designing and not yet implementing is working. I'll have to go on when I do further design and implementation. Summary: Do some partial copy-evaluation for each decision-scope I create. Question: will that really take care of tll the relevant cases? Will it even handle backtracking? In the existing picture-drawing I use association lists to track what I now call scoped decisions. Does it faithfully implement thae same stuff? Which is more efficient? Is one of these more general thatn the other? Can the value created by a decision create further choices that will eventally make new scoper? >>> I suspect neither of these systems are adequate when scopes are not nested. It may be fine to store chosed values in the code itself. But how to properly associate with objects when the objects are long-lasting things in the world model? Once you create a specific object that may as yet be incomplete you don't want it copied to make multiple differeng versions. If some choices remain lazy you will want them to be permanent for the object. I guess that is a difference between an object and a notation for generating an object. An actual object has noncopyable identity. Can I make sure actual objects are always fully evaluated? Or is it enough to block copying once I'm in an actual object and instead do changes in-place? Is it possible that variables in an actual object might still be unknown at object creation time? And when *is* object creation in the partial evaluation model? Surely object -- like dynamically created rooms -- still have transient or nonrepeatable choices! That depends on the scope of the choices ... if not purely local (i.e. at most room-scoped) they will be tracked elsewhere. So when are choices marked as belonging to a scope. In the evaluated code that will have to be explicit. The object can't be created before activating the scope. And it can be created as an object in the world anytime after the nonlocal scopes in it are known ???? Is this a workabe model? I suspect I eed to get the midel exactly right and there's little room for variance -- just like with function scopes in Algol. 2024 04 15 I'll be writing based on notes I made on paper yesterday at breakfast. Ideas for a formalism for text-adventure games. Somewhat similar to Inform, I suppose, but infused with some concepts from programming language design, At this moment I don't know whether it'll be English text or code or a mixture of the two. Most likely documentation for what I might eventually decide not to do. the notes seem to be predominantly about describing sets. Sets of alternatives for the machine or DM or player to choose from, sets of things found in a room, etc. The somplest set is just a list of elements. But each item in the list can also be another set (absorbed by incusion), a predicate (which could filter a completely free choice), a constraing (also represented by a predicate), etc. I don't yet know what all could be under 'etc.' Syntax? (set component...) component: (item whatever) | (include set) | variable | (optional set) | (count min max set...) at least min and at most max chosen from set. The numbers are ignored during recognition. | (code some-nullary-function) ignored during recognition | (predicate some unary function) ignored during construction (except as a chack during debugging) A set like this can be used as a generator and as a type. As a generator it must generate objects that satisfy the requirements of the type. As a constraint it must check an object against the listed components. The predicate function must be satisfied if nione of the other alternatives match. TODO: these nullary and unary functions will likelyhave some other arguments containing contextual information. Hmmm. count requires some thought. How many? And if it's embedded in another set we're choosing from, how to manage the count? Generating is easy -- just pick a number and extract. Checking requires counting the number of ... whats ... and seeing if in range. What of two counts in a list with overlap? option requires similar effort. Easy to admit or refuse the item -- but if I'm choosing, what is there isn't anything else? 2024 04 18 We need choose operations. It can choose from a set to produce * an item, or * a subset, or * a nonempty subset. Also may want a partial refinement. Maybe not now maybe much later. We need tha actual and formal declarators from A68. The actual spcifies details; the formal just says what's aceptable. I'm not sure what the virtal declarators were. 2024 04 23 Need a mechanism for enuring some specific thing is paced somewhere in an area, or in a class of rooms. First, make a scope. Later, att places into the scope. Later, pick one of the places at random, and put it in there. (define (scope) (Scope contents) (scope '()) ) (define (possibleplace scope) (add possibleolace to the scope)) (define (place onbjec scope) (insert object (nth (random (length (scopecontents scope)))) ) This seems to do the trick. Do we need to close the scope? Maybe. Likely not. It'll get garbage-collected. And if we can still access it, we can add other objects later. We will need to close the scope during game play if players have searched all the containers in a scope: there's no more possibility to add anything then. So we have to either close the scope when we've used it, or remove things when they're looked into. Doe this mean that containers all have to know what scopes they are part ot so as to be able to remove theselves from it? Scopes are meant to be used before play enters a region, and even while the region is being created. Scopes are meant to make the region contain theing that ahave to be in the region for the game to proceed. Emplacement of special objects is meant to happen before gameplay enters the region. Probably shouldn't call them scopes, unless I have other uses for them that are consistent with this usage. The other usage is probably primary. Ths original use for scopes: Inform has a machanism for ramdom choices of things to happen. with the constraint that none shall be repeated. That 'none' needs a scope. If you are trying something in a room, it may be pointless to do the same thing twice, but useful to repeat it in a different room. The room is this a scope for these actions. So ... make the room a scope, and let the choice refer to this scope to determine which things have already been done. A new room will have a new scope, and a new (possible a copy) of the list of alternative events. Inform uses this to have different things happen just once in a particular piece of code. I'll constrain it to a scope, not a piece of code. Now this could be implemented by creating a copy of the list of alternatives when creting the room/scope. In fact, this is probably the easieerst way to implement it. OK. Let's call the 'scope's from becore 'regions'. (struct Reqion (containers) #mutable) (struct Container (contents) #mutable) (define (region) (Scope contents) (Region '()) ) (define (reginal-place region container) (set-Region-containere (cons container Region-containers))) (define (emplace object region) (define container (list-ref Region-containers region) (random (length (Region-containers region)) (set-container-contents (cons object (Container-contents container))) (nth (random (length (scopecontents scope)))) I suspect this can be used relatively easily. Exception: what if there are no containers in the region when it's time to emplace? That's a game design error. I'd like to catch it statically, but I suspect that isn't easy, given the dynamic natue of room creation. Hmmm.... TO do it statically we'd have to make sure there's at lease one container in the region. And if the region has subregions, we's have to pass that obligation to at least one of the subregions... That leads to a completely different mechanism for emplacement. We'd be emplacing a contianer instead of an object, and this would hae the same problems ar a different level. It is possibly useful that many things can be containers. There are boxes and the like, of course. but there are also rooms, fields, yards, ... So when we make an area of any kind we'll have to make sure whether it is a container. Most such areas will be continers by default. A container will have to have a mechanism to add things into it. The above code assumes that containers will all have a easily identifiable list of contents. Is this realistic, given the immense variety of possibilities? Do I wand something like duck typing? I'll ahve to see how this evolves. When creating a room or a container, I'll have to have a mechanism whereby its initial contents can be determined. I have discussed this when describibg choices and sets. # Sets, again. Have to distinguish specific sets from properties of sets. A specific set is, in first instance, a list of elements. But it could also be an algorithm for generating elements. Wheresas a property of a set is a differnet kind of thing. For one thing, you can't, in genereal, use a property as a generator. I had been thinking of a notation which proposed elements, bu either explicit enumeration, by algorithmoc generators, or by properties. And which of these would be considered in an operation would depend on the operation. Alternatives which did not apply would simpy be ignored. That could work. But it seems kludgy A coing convention whereby sets that enumerate would contain only enumerating entries, sets whie choose contain onlly choise rntries, etc., woud seem appropriate. Do I need to do this in somehting ike a type? Yhe things I called set in my precious coding exercise was more like a union, contianing actual elements and other vaguer things. I'll start to cal it a union. # racket I seem to have forgot how to ru tests in Racket. At least. not the module+ test stuff when used in drracket. And I can't find the code where I used it. Well, I figured out and out in some tests. Don't know what to do to test ransom choices. Maybe run them a dozen times and check that they're not al the same? Possibility valid code failing such a test. 2024 04 30 Glad I got my tax return in and paid yesterday. Othewise I'd be writing tax return todaay. So far I've described a wa to make some containers and give them contents. Now I can get a bit of geometry by putting cotainers into containers. An I'll need a mechanism for connecting containers. last time that got to be a complicated database. I'll have to do something simpler. I'll also need a way of identifying things the game can do in reaction to user actions, and a mechaism for identifying user actions. I'll do it quite simply -- generate a list of things a player can do, and let him choose one. But I have to make the list. It cold be made from affordances of what's present where the player is. A box can beopened or closed; a door can be gone through; etc. Doors can come in different colours and materials, so the player can choose between them meaningfuly. TODO: Will I have to make a way of naming otherwise identical objects so the player can actually decide meaningfully and tell the game what to do? Object 1, object 2, etc.? I guess I'll find out. I could assign arbitrary serial numbers to every single thing in the universe and use them, showing the serial numbes every time I mention the object. SOunds klunky. But other kinds of descriptions could end up being identica, and therefore ambiguous by accident. Is that good enough? Maybe. Try it simply and see. So each object, container or not, is going to have affordances. Each object will have a type, which can have methods that apply to obects as affordanes. This can be simpler for data representation. Or not? Let's say an object has a function that gives a list of affordances. * Does this list have the various possibilities I deigned into the choicee mechanism in previous sessions? Seems reasonable. * And the affordances are potential actions. Each one will have to have a description and an function that actually does the thing. What is a desription of an action? Possible a string. But ti may be easier to have a function that generates the string from other information in the object and its type. And eventually I'll wand a short description an a long one. So something like (struct object (type, description, short description, action , and then other fields?)) If the object is a container, it'll have to have contents. Consternating. It's gettin complicated. And Racket structs don't have a way to be complicated, with different instances having different fields. I'm not eager to ut a property list onto an object to attain flexibiity, but I may have to, Well. I can manage a property list for now. There will be a function of functions to inspect and change properties on the list, including adding and deleting them. Presumably if I figure a better data structure I can change it later. I'd have to change wither functions or every use of them if that happens. Feels ugle, but is likely rather general. So I get (struct object (properties)) Or maybe (struct object (type properties)) Type is maybe the wrong word, because it may conflict with similar terminology int tped Racket. So let's do (struct object (kind properties)) And 'kind' can also have properties. Properties will be a simple list of ons-pairs: (propertyname ' c=value) and I'll have to make sure it's a mutable cons and a mutable list. I guess containers will now have to have a property list with a property for their contents. Isn't there some better mechanism for this in Racket? I think so -- a mutable hash table. Can every object ba a hast table? How much storage will that waste when the lists are likely short? Maybe the complicated cases are the kinds. There may be many objects with little information in themselves; most of the actual data will be in the functions in their kinds. I hace a suspeicion that it ight be best to start with a fairly free formalism and end up discovering what I need, and what patterns it's practical or desirable to impose -- but only when I've got some experience using thsi formalism. I certainly do not intend to encourage widespread use before I have some of this experiece and have ha a drastic revision from first principles. So now I have containers, objects, and actions. Rooms (f the traditional RPG game kind) are a kind of container. There's going to be a kind of isa relationship between kinds. Perhaps I'll Call it a subset relationship. Subsetting with change it default properties. I suspect I have created a complicated tangle so far. Containers should be objects. Can actions be objects as well? Is there some kind of already-available formalism that is simple and also easy to use? Probably. But I'm not at all sure how to go about looking for it. --- Just googled "object formalisms" and went off the deep end looking at a few paprs that were more into philosophy than mechanims. I syspect i want lomething like the knowledge representation methods from the sixties or so. A mechanism whereby I camodularize in the extreme. I think that the module structures in modern programming languages are fine as ar as they go. But I need more graularity of structure. More mixinx and types for mixins. So ... an ofbject will have kinds. Kinds will be collections of propeties for an object. And I'll have some mechanism for shoosing between kinds when there are several applicable ones. Perhaps instead I'll have multipld mechanisms for combining kinds to make new kinds. Kinds will have poperties, and the kind will be responsile for how the properties are physically represented. Simplest mechanism will be and association list. An object itself can have an association list for properties unique to it. (Os this simpler than makeing a special-purpose kind for each object? I don't know. That mechanism will still be avilable -- just have an empty propety list. So ... Kinds can be build in different ways. * An associatino list * A list of kinds -- search them in order until you find something. * Others I haven't thought of yet. This there are several kinds of kinds. I'm not at all sure I should use a metarecurion here whe formulating kinds of kinds. Are kinds of kinds a different lind of thing? Maybe. So far, the data structure of a kind could be represented as (struct kind (association-list, kind-list) where a lookupgoes through the assiciation list first, and afterwards through the kind list. I think that may be simple enough. It y however, still be too complicated. NEXT: I should probably draft-code this formalism, including lookups and changes, for propertied of objects and kinds. Given an assocoatin list in a kind, might a specific object itself be represented merely as a kind? 2024 05 14 It has not escaped me that the raw mechanisms I'm building for procedural generation in a text adventure ight be useful ways to do other kinds of procedural generation. But what's likely just for text adventuring is syntax generation. I'm talking generation, not parsing. I'll want a formalism for inflection and for arranging syntax based on something like semantic functions. Ideal if those notations can also be used in something like formal logic. Tracery (a very limited random text geerator that is common to use in nanogenmo)) has suffixes .a and .?? on words. .a means to prefix the world with 'a' or 'an' depending on whether there's a vowel starting the word. (I don't know what it does with and initial 'y', which can be used as a vowel oc a cononant. Nor with an initial 'h', which some people pronounce as if it weren't there and treat the follosing letter as an initial vowel) Of course, I don't want random text. Whie open to elegant variation, I will have an intended meaning. And I forger what the other suffix does. Maybe something to do with plurals??> Let's use Lispish notation, since I'm using Lisp. (sentence subject verb [object]) for an ordinary indicaive sentence. (ask sentence) t convert a sentence into a yes/no question. (w) to mark the thing being asked about. e.g. (ask ((w) let (the dogs) out) No. I'll have to hae several costructs here. (w) shoul be (who) or (what) or ....? and the verb 'let has to have a built-in separable modifier. (verb let out) (ask (sentence (w) (let out) (the dogs))) (ask (sentence subject verb [obect])) -> verb sentence [object] or (sentence subject (verb l o) obj) -> subject l obj o I'm going to have to work on this. It's not at all obvious what the right constructors and transformations are. Or in what order the transormations need to be applied. And therre'll be a final pass emitting all the actual verbs without the constructors. Once everything is in order. Or is that final pass really the deforested transformations? And a few more: (compound ...) where several words behave as one, though still spelled with spaces between them. Those subwords will *not* be separated by transformations. (word ...) Several forms of the word under different inflections. Maybe for singulat, plural, first, second, third person, etc. I'll have have some notation for describibg the causes for inflections. Probably I'll want to have a separate lexicon. I'll likely use words more than once. https://randomwordgenerator.com/paragraph.php So the lexicon should indicate transformations of the word under different circumstances, such as singular/plural, person, maybe gender, tense, mood. Does interrogative count as a mood? Does ... so: lexicon facet will be something like (contexts -> word) where each context is singular | plural | first | second | third | mae | female | ?other? | neuter | present | past | future | interrogative | assertive | imperative | mandative | contrafactual | ... And there should be a default version. And there should be algorithms for when the particular desired context hasn't been prebuilt into the lexicon. I suppose that a lexicon entry could be a function. Or a list of partial functions -- use the first that applies. Some words will have functions of their own; others will share them with many, many others. That list of partial functions mechanism -- it could be a notation for making partial functions out of other partial functinos Am I getting too complicated? I think not. But most of these mechanisms will not be used for most syntactic constructs. The simplest thing woukd be to do almost nothing. To generate txt by mostly cipying lists of words codd explicitly. But for th elists to have an exception mechanism whereby they could contain something like Scheme expressions that get evaluated during conversion to text. Initially, there would be mo sich cubexpressions, but they could be introduced ad-hoc only when they proved to be necessary. Note: we'd want something like that to substitute parameters into sentences anyway, like in Tracery.S?? In Scheme, quoting and backquoting would probably suffice, with functions to do necessary inflection. Might want another notation, but I'm likely to know what only with experience. 2024 05 15 Doors. Doors are kind of in rooms, but they lead to other rooms. So I can treat a side of a door as being in a room, and the other side as being in another room. But the two sidew have to be connected. So a side of a door will have to identify the other side. This is a nonhierarchical data structure. It means that I can't just recursively and independently build both rooms and furnish them doors to be inside the rooms. Unless I build the adjacent room as if it depends on the original room. And incidentally make it part of the same contextual area as the original room. Or tie it to a door in the context, to allow movement from one area to another. Seems a bit complicated. Kind of like putting a special object in an area. I'm not really happy with this. NOTE: I suspect unless I want to get *very* complicated I won't be placing rooms in a geometric grid; I'll be usig a graph structure rather than a geometry. This is a big limitation. Hmmm. Can I assign coordinate at the same time, say, on a grid? And place doors only where there's enough space to make another room? This might work, but I won't be doing it initially. Should a region's rooms be done with the same mechanism as a room's objects? 2024 04 21 Let's try freewriting possible game intreactions. Many will probably not be feasible to implement, but maybe if I just start writing somethig I'll find a few, very few, things that can be adapted. Scenario: Things keep going wrong and You can't stay in the easy chair. Scenario: Just flirting on the front porch (until? even after?) the pretty girl next door's boyfriend shows up? Scenario: searching for things in boxes in ... Scenario: fighting random monsters. Some should have unknown vulnerabilities. a: You hear the doorbell ring * ignore it * get up and answer the door. * remember mask, or don't remember mask. * open door. * It's the pretty girl who lives next door. * she shies away (if you haven't your mask on) * You can still put the mask on and she stope shying away * She tells you (flirtaciously?) that your wifi is off. * Oh. I wan't using it. * Please? * OK. I'll try start it up again. (You know she uses your wifi regularly because hers is shitty and you have an umlimited contrat) * You go away to the wifi machine * You leave the door open|closed * if open, she follows you in. * You see the modem. * It's switched on/off * off: You turn it on * on: you scratch your head * It looks slightly charred. * You'll need a new power supply. * Call the ISP. * They tell you what kind of power supply you'll need. * You ca go off and buy one, or * wait for them to send you one, which will take at least two days an you'll have to be home when it arrives. * If she's here, tell her he sad news. * Pleading eyes. * You go off to the spare eletronic parts store with the specs, * You come back with a new power supply * she watches you plug it in. * You say, There. That should do it. * She goes oward front door; you follow * Meet boyfriend coming up front steps * What were you doing in there? * Turning the wifi o. * Why do't you use the wifi I provided. * It never works, * Excuses!!! *(addressint you) So why are you kuring my girlfriend into your house? Groomin gher? * No. Just making wifi work again * Don't you come near my girlfriend again. * I didn't. * She intervenes. (how?) * Go back home; I'll be along soon. I have to thank him. * He looks askance at you * I bet I know how you'll be thinking him... * He grabs her and starts to pull her toward the stairs. She resists -- beig pulled down stairs is dangerous. * Do you intervene physiscally? by grabbing her? * Do you leave them alone -- not your problem? * Do you try to push him away? * Pulled out she stumbles and falls. Boyfrined manages not to get hurt, but she has a bad fall and hits her head. She doesn't get up immediately. * Boyfrind to you -- See what you've done? * You. Looks like it's time to cal 9-1-1. * you take out hour phoe and do so. * Boyfried is gowering at you instead of seeing if she needs help. * Ambulance comes surprisingly fast. Examines her quickly, uts her on a stretcher and takes her away. * You guys are left sanding there. Hope for the best? "I think you'd better leave. You've done enough." (Could be either You of boyfriend saying somethig ike this.) Hope for the best. Now most of htis converstion has to be hand-written and tied in closely to events. And almost nothing happens in the events. The infrastructure I coded previously doesn't look as if it'll get used much. I think I may still have some choice-enumerators and choosing functions. I'll look into whether they are in any way ready to use for such conversations. I have a rather stupid model of in-then-else in mind. Suspec TI'm going to have to have a more compicate state machine -- various things here have some state. Where people are. Whether you've ignored the doorbell. the state of the modem. Soe of these just fit into the narrative, leaving not much to record. But if I want to be able to branch freelt, I'll have to record the state of these things more robustly than implicitly. And have state-dependent triggers?? Looks like it. Like whether girl is lying on the concrete. Like whether she follows you in. Like whether she has followe you in. and whether boyfreind is there when you coe out... We'll have atributes of the main players and objects, and the tests and settings will be on those attribute. How does that fit into the enumerated choices? Presumably I'll have to check the properties of the relevant Obs that are present in the scene. And maybe others that have relevance or are remebered. 2024 05 28 So ... what's the next missing thing to write. SO far, the actual game is largely independent of the game state data base I've built up. And the data base is not saved on disk, not on request, not ever. Considering it contains functions, that's probaby inevitable. Do I have to rewrite to have actual functions that can be written to disk? Another interpreter so that I can write interpreted code to disk? I need to be able to write game state in order to perform save and restore actions, necessary for longterm play of for recovery from system failures. As far as I know, Racket does not have a save-complete-system operation, unlike some of the very early Lisp systems. In a copletely interpreted system, that's easy to build. I remember building one for the CDC Cyber long ago. 'define' stored the source code, of course, but it also placed an entry in a save list. I could xecute a save operation that went through the entire save list, fetching the interpretable code for every function and writing it to a file -- a file that could be executed later to restore much of the system state. I had also written a simpe structire editor, which would walk through the Lisp tree structure under interactive control, making changes. I even used that editor to edit the editor while it was running! Doing that kind of saving for racket functions, which have environments, is beyond my ability. Doinf it for functione embedded in a data structure, well, I give up already. But I will need some kind of save tool. Should I represent functions within a data structure douby, once as a Racket funcion, and once as Lisp code, including some form of Lisp environment, so that on rereading that data structure I can reconstruct the Lisp function? Or should I end up with a new interpreted language for all the dynamic code-in-data-structure? I suspect racket has no built-in solution to any of this. I'll have to special-case it or write an interpreter. A Scheme-like interpreter in Scheme. Maybe building specialty combinators for every piece of Scheme cod hat embeds itself ito y data structure. That might work. Ugly, but likely feasible. SO do I have to write a programming language that gets maro-processed into such a collection of combinators? Is there a consistent naming scheme that can keep the combinator names stable during code changes for bugfixes? I guess I can explicitly have combinator names within the code I'm writing to compiled into some kind of combinator form and later interpreted. Names in the source code can be somewhat trusted. And if a name is removed from the source code, woe be to any saves states using it. I'd have to wait and see how it gets used before I know to what extent such compatibility becomes a problem. And I don't even have any such special language around yet. I've enquired on the Racket forum, but don't expect much in the way of an answer. --- Time to leave this topic for a while. Maybe I'm worrying about nothing that will be an actual problem. Tested Racket -- there doesn't seem to be a easy way to write out data structures containing functions. Even 'serialize' won't do this. I tried writing out 'pending', the event queue. All events looked like # whatever I tried. And 'serialize' ahd a contract violation. .