cpcallen
commented
4 years ago Thinking more about this and about parsing in general:
- It would be nice if
$.user.createcould be "createnamed " instead of "… as ". - But "named" doesn't really make sense to be included in a generalised list of prepositions.
- So more flexibility in how verbs are defined in general would be great.
- So not only might we be changing the available list of prepositions, or the possible values of dobjspec/iobjspec, but we might want to completely change how verbs are specified—perhaps (and this is just an illustrative example) to something a little bit regexp-like—e.g.:
l…ookat/in to/into<this>cr…eate<$.physical>named/called<string>turn<$.key>clockwise/counterclockwise/anticlockwise/cw/ccw/acwin<this>wear<this>|put<this>on|puton<this>
The entire verb section of the Function tab—unlike the rest of the editor (except for SVG restrictions)—is really specific to an English-language, MUD-style UI. If this section could be served up by the database (rather than from static/) then it would give us a lot more flexibility to implement these kinds of changes in future.
LambdaMOO (and, at the moment, CodeCity) provide exactly three options for dobjspec and iobjspec:
none, which disallows a direct or indirect object respectively;this, which must match the object the verb is on; andany, which allows any text (or none) at all.In many cases—e.g,
$.container.putany in this, we'd actually like to constrain 'any' a bit. The obvious constraint is that it unambiguously match a single$.physicalobject; the proposed name for this option is "something".We might wish to be even more general, and allow any
.dobjand.iobjto be set to$.physicalobject, with the verb matching ifdobjstrand/oriobjstrare instances of that prototype—so, e.g., a lock could have$.lock.unlockthiswith$.key.$.utils.command.executeto apply new options.