M: i've been working on this; see what you can make of it, and if it's enough for you to finish up the part i haven't gotten to yet:

// // means comment, ignore the entirety of the rest of the line // OVERNOTE TO SELF: IF YOU'RE GOING TO RUN THIS THROUGH GPT FOR FORMALIZATION HELP, THAT MEANS: // DRIVING YOURSELF NUTS MAKING EVERYTHING 100% UNIFORM IS A USELESS FRUSTRATION // you get the concept in your head; if it's solid, GPT will be able to iron out the written wrinkles

// this whole thing is largely (initially) supposed to be an HTML pseudo-wrapper; that is, like markdown on wikis, it's supposed to be a quick clear way to indicate for a WHAQ specific content which is intended to be expanded to HTML according to what instructions are given; it's intended largely to allow easy creation/manipulation of pure TXT style stuff as is usually found in FAQs into a standardized setup; though maybe it's better to say that it's a little more potentially complex as a wrapper, because some labels are less intended for straight up search/replace reformatting, and more for non-linear processing-for-content-construction; but the final product is supposed to be linearly accessible, with any of the processed bits intended for supporting reference // honestly, while it might prove useful, part of this is just because i hate trying to use the </> keys while typing... // :: is a command separator; it linearly indicates an instruction, then the parameters/guidance/whatever; if the parameter is expected to be a keyword and actually is an expected keyword (two separate ideas, depending on user error), the next separator continues the pattern, either reading an expected keyword or just text as parameters - until the command sequence is finished, and the next entry becomes the initial instruction for another sequence; at the current time, all instructions take parameters, even if those parameters are moot or blank; in theory, comments could be made in blank situations, but it'd be advised against if just for clarity; if OCD or clarity calls for it, substitute an appropriate single word for the case, such as 'start' or even just 'blank' // keywords are subjective and flexible, particularly when used as parameters; for example, the term 'money' can be a keyword for 'form', but in any place calling for a parameter it is a valid entry, and should not cause any errors in interpretation // handlers should be as forgiving as possible unless collapse is imminent; for example, a non-keyword in a position requiring an instruction should be skipped, not kill everything; debug-handling would be nice, though

// inchoate, subject to modification or collapsing into another system; intended to indicate a kind of global constant, in this case what kind of prefix/suffix the game uses to indicate the common cash; needs expandability to handle situations with multiple cash type, like silver/gold/platinum or gold/resources // inchoate concept in response to multiple-cash-format issue: numerics attached to keywords indicate a subjectively defined array entry - allowing money1, money2, money3 to all represent money; if a keywords is used without a suffix, the handler assumes that the first entry is used - so in mono-cash systems, etc, money=money1=exactly what's needed ::form::money1::name::Gold ::form::money1::suffix::g

// items are any equipment; it's one of the few things so far that hasn't suggested a need for a parameter or anything - inventories are basic, I guess... // some keywords are containers - that is, everything between the opening instruction and the second version with ::items:: // table-like situations are defined by two internal instructions: 'fields' defines the titles of the fields (and provide table headers), while 'entry' is a repeating instruction with a CSV defining the value for each field; it can be accurately thought of at the moment as being equivalent to 'th' and 'td' tags respectively; handlers should be able to understand that a newline is not -required- at the end of an instruction sequence - it's only there for legibility - but in general whitespace formatting is shunned beyond using newlines
::fields::Item,Category,Effect ::entry::Heal Berry,Consumable,+200 HP::entry::Antidote,Consumable,cure Poison::entry::Medicine,Consumable,cure Disease::entry::Violet Rose,Consumable,cure Silence::entry::Heat Salve,Consumable,cure Paralysis::entry::Long Knife,Equip-Weapon, ::items::end

// the primary walkthrough is defined by nested 'acts', the equivalent of a 'div' or 'p' tag; internal numbering for anchors is the current paradigm - anything beyond the word 'act' should be thought of not as an actual label, but only applicable in the code as a way of marking which 'act' instructions are paired with an 'act::end' instruction // 'act' uses whatever follows as the text intended for the section name, like an 'h1/2/etc' entry or other title heading formatting choice ::act1::I. The Festival // 'guide' is something like visible commentary, something a little bit less than the primary atom of a 'step' which someone would follow but still necessary; basically when the user might need to know something but it is more outside the narrative than involved with it ::guide::These first three chapters are a prologue that can be done in any order; this list is merely in order of first to last presented in-game. // i came back up to add this; it may be better to expand the syntax of 'guide' to allow situational placement/editing, but allowing some items to be labeled as being part of a high-level over-guidance section instead of limited to the location that generated it ::guide::The game manual can be found online, for example at archive.org; this WAQ assumes you know the interface or have access to the information in the manual. Item usage will be described when appropriate and not available in the manual (for example, the Heal Berry gives 200 HP when used, but neither the game or manual mentions this explicitly.)

// this is less than developed; i just realized a choice needed making; and since this is voluntary, it'll involve some methodology that i don't feel like handling right now ::selection::1a,1b,1c::

::act1a::A Wandering Youth // 'place' is a meta-container not necessarily associated with the transcription-to-readable-format; it is not necessary, and can span outside of the container in which it's initiated; it is intended to give a location for reference if someone is looking to backtrack or figure out where a particular step occurred // 'town' is a keyword for guiding 'place' - it does not necessarily correspond 1-to-1 with the idea of a town, but is simply what in a game could be called a locale: it could be a major city or a peaceful clearing; its primary defining/limiting factor (as opposed to, say, a 'dungeon') is that it is (at least initially) presented as a spot where the player interacts with NPC and won't have any fights; the definition is, honestly, potentially flexible - at the moment, it doesn't have enough attributes to be useful beyond labeling - but categorization helps with generating lists from the entire thing, at least // inchoate - maybe make it so that the instruction after 'place' is not a predefined keyword, but WHAQ defined categorization: so while one game has a soft definition of 'town/dungeon/etc', another would have 'arenas/routes/etc', where every category has the same base attributes and the distinction lies in how the game calls for it to be used; we're going to continue as though that's what will happen until we find out where it butts up against some usage problem // after the categorizing instruction, the following item in the sequence is the label attached to this 'place'; reminds me that the 'place' label probably should have its own internal labeling system, like with the 'acts', for internal handling and nest tracking ::place::overworld,Map // this was put in later, after the second step; the idea of being locked in requires a place to go when things are unlocked, at least in games with an overworld or hub // i may need to define a way for places to be defined later, with the assumption that the handler will shift it to the beginning and have it locked until it shows up in the linear progression ::place:🔒:town,Surf // most things that could be called a shop/vendor are not strictly necessary for production of a WHAQ, so the intent is to make it possible to format them to be off to the side and collapsed initially, opened only if the user wants to see them - hence the container methodology, separate from any actual steps // a use for the 'place' instruction, but not necessary for creation; a shop may be associated with a particular location, but one can be created in the walkthrough without requiring a location, with the assumption that in that case the location of the shop definition in the actually-required 'act' structure is sufficient to convey where the shop is located // the parameter after the instruction (I really to formally define a shorter term) is just the name of the shop; formatting should make it easily identifiable, whatever the presentation paradigm ::shop::Surf Village Shop // 'shop' is a container instruction that implements the 'items' methodology of being defined by 'fields' followed by 'entry' ::fields::Item,Cost ::entry::Heal Berry,20::entry::Antidote,50::entry::Medicine,50::entry::Violet Rose,50g::entry::Heat Salve,50g::entry::Long Knife,120g ::shop::end

// now we're getting to what's currently the most crucial and fluid part of the definition... // we're trying to strip all the color off of the original version; especially in a lot of the older FAQs, the creators were creative - or at least verbose - and it could almost turn into story telling, impressive when done well - and exactly what we're trying to avoid; we want uniformity, simplicity, even automate-ability if it gets there; everything should be boiled down to nothing but what's barely required to make sure the experience is as uniquely experienced as possible // compared to that, all the other stuff was easy-peasy; I likely could do the editing for that in my sleep, or at least just after I woke up

// the atomic bit of a walkthrough is going to be defined as a 'step' instruction; it will be followed by a sequence of keywords, or keyword/parameter pairs (comma separated), a sequence whose final entry is defined by when a keyword isn't there - so maybe we visualize it as '::step(::keyword|keyword,parameter...)::associated text' if we use a bastardized form of regex representation // the keywords for a 'step' should be structurally definitive - a 'step' might be though of as being an attempt to reverse engineer a madlib or something; the ideal language wouldn't even need the 'associated text' except for debugging - it would be able to build a formulated instruction from what was given by the keywords // there needs, i think, to be a layering substructure defined in the 'step' instruction, used like this - ::step(::[keyword sequence])::stepdown(::[keyword sequence])*::[lower text]::[primary text] // 'stepdown' is used when the primary text may, depending on the player and situation, not be as specific as is necessary - like in a puzzle situation; it follows the same structure and uses the same keywords for situational definition as 'step', but it is intended to be formatted to be hidden or otherwise indicated to be more information than some players might want, even if some might need it // as a pseudo-coded example, if there was a relatively simple puzzle, it might look like - ::step::[puzzle indicators]::stepdown::[any additional indicators]::Push the red button, then the blue button.::Use the command console.

// one key thing as we're developing the language is to be specific about what the player should get when from where and who; a lot of walkthroughs are tied to making sure you pick up everything, or at least know they're there, or hit ever chest or whatever // my initial impulse is to have a 'collect' keyword - implement in a way such as ::collect(::category)?(::location::[location specifics])?::[descriptor] // so an example would be - ::collect::coins::location::Above the entrance portal::500; or if specifics are unnecessary in a step, ::collect::chest::5 Potions // it may need reconstruction as we take a first run at things; at the moment, I think it needs to be able to create a handler-traceable category (for stuff like special chests) and and indicator of what it is, along with the ability to add a descriptor for the stuff that is just hanging around in the overworld or otherwise a bit more specific // 'collect' should be, at least at the moment, thought of as being a 'step' related keyword - although it may be expandable to other instructions; the point is that at this point, I see no situation in which a collectible can exist without being tied to a location, act, or step // when associated with a step as a reward, items should maybe become 'result' or 'reward'... working on that in terms of syntax...

// this is going to be comment-laden and ugly as we try to build a 'keyword' structure from what we run into and generalizing... // for this practice run, I'll be leaving some form of the content of the original FAQ, then trying to construct a new step from it depending on what's already established, expanding or refining as necessary; that means there might be a bit of ugliness or inconsistency, keep that in mind when re-reading or testing; if something is introduced, I'll explain what's going on as best I can

// side note - trophies; this is, I believe, a direct port - but it -does- have trophies; other games will as well - and WHAQs are supposed to handle those too, especially the ones that have ridiculously specific requirements // proposal - 'trophy' keyword, complete semantics TBD because the trigger/causality can vary from a specific act to a complete game completion to an ongoing count; initial descriptor is - ::trophy(::system::[what system(s)]::[what trophy value])?(::[keywords/parameters])*::[trophy name] // the mechanics will parallel what's developed for the 'collect' instruction - that is, it'll be able to attached to a parent instruction; the difference is that some of the more vague trophies might require an independent existence, such as a 'beat the game on Hard' trophy; a WAQ should not necessarily try to be canonical about trophies, though - only specific enough to deal with situation specific trophies, not body counts or playthrough counts

// i'm not sure how i want to handle cutscenes; they should be indicated, but aren't exactly a 'step' ::cutscene::The player character is tending horses. // --Your boss comes over to tell you it's quitting time, and he asks your name (Select any name you wish, but I will be using the default name Rudy). /You get a Heal Berry as payment for your work, and your boss tells you to go talk to the mayor. // first minor note: the guy actually stands still; this is a demonstrable example of how old FAQs sometimes went for prose over accuracy to tell a story; again, admirable but not what we're doing here // so I haven't formalized it mentally, but I think that most narrative sequences in games can be defined by a maximum of, like, three categorical adjectives; so i'll be trying to formalize that on the fly // note spawned from previous line: remember that in some games what is 'default' is itself contingent on what's going on in the game - like when an RPG pops up a battle screen and the controls change; this needs to be handled if the terminology indicates it's necessary to be clear // in this case, you can run around a fenced in area and do anything you want (tho with very few options) with complete game level control (as opposed to some games which will eliminate or filter various functions); in theory, if there were a way to kill yourself, you could do it before the game began; I mention this bit because I would call it as a descriptor adjective 'full', but I'm going to call 'game full' the default state of a situation - any subtraction (or maybe even addition) is a modification from this; only noting it in case it actually becomes necessary to use explicitly // so control ability might be one category; another might be 'area restriction' - right now it's complete freedom in a restricted area, but other times it might be limits/lock-offs in an otherwise complete map // we're going to initially look at things as being a narrative bottleneck; in a more broadly described sense, you could say the game world has a door that can only be opened by interacting, and/but the interaction moves the narrative forward, defining a new game section (in narrative terms, not the walkthrough's 'act' structure); that means that the step would need to indicate a game world state change, a narrative door, a conversation, and a direct item reward... oh, and a special case of 'renaming' which is up for semantic grabs - it happens often enough that it shouldn't open up the idea of a 'one-off' instruction, but rarely enough that refining it isn't possible with a sample size of one // another side note: 'narrative time' is importantly separate from 'walkthrough time' because they are affiliated but not qualitatively the same; it needs to be acknowledged and track because, for instance, a particular trigger may not change the way the player is shown the game, but could easily alter the NPC conversations available - indicating that track it is important; ...as I think about it, maybe the two could be mixed - but I -choose- not to because the 'act' structure is important no matter how you play the game, while the 'narrative time' is more connected to optional items; in terms of constructing the WHAQ, the acts are needed for formatting, while the narrative stuff can be tacked on // ::place::area::Stable // new bits of language - ::convo::[name/identifier] // ::reward::item[,item2,item3...] // instruction placement is important both for clarity and proper formatting; for example, the 'reward' is directly connected to finishing the conversation - if it had been given before the conversation, the 'convo' should have come after some form of indication that approaching/interacting with the character was the trigger, not the completion of the conversation; it's quibbling, but it's the kind of accuracy that will make the product look trustworthy and not glitchy // ...having said that, this -is- the first try and first pass - so be sure to review this if we ever finish // observation - a WAQ formatting handler could use any 'place' nesting with the 'convo' name to build a character list if/when a game needs it; that should be kept in mind for the other narrative containers, like 'act', particularly if uniqueness of identifiers become crucial - although maybe as an attribute instead of a label element depending on the circumstances // the 'reward' is not included explicitly in the description because the formatting should place this both separately from the actual guidance and optionally as a hidden item; future items will prompt reevaluation in details if not in nature, because we've still got key items and collectibles and other stuff whose display priority might be different to deal with... // building a language dictionary will be interesting, between the words that are keywords only in context, and the specificity required once a keyword has been identified, and the instructions which are kind of heterogenous in nature... whoof // ::place::area::Stable // ::step::convo::Employer::reward::Heal Berry::stepdown::Run around as much as you want - get to know the Menu and Pause Menu, fix the controllers and mapping, etc. - but in terms of the game, this is just a starting point.::Talk to the man by the barn door to register your name and proceed. (The default, 'Rudy', will be used to refer to this character through the WAQ.) // locations can be useful, but are often contextual and should be able to be locally defined // i can think of two paradigms off the top: screen based (north is up) and map based (north is fixed but the screen rotates), but more might pop up // coordinates come into play in modern games; older games need placement, and contextual indicators // i'm thinking that the place::area definition may be the baseline for a new assistant definition associated with 'place' definitions: 'placedef' // it would be attached to a place thusly - ::place(::placedef(::location::[syntax contextual and TBD])?(::[category])?::[name])(::[category])::[name] // this needs massaging; the nature of the 'step' instruction is such that finishing everything off with a variable text is okay, but this might need an endcap or the sub-places bleed into the final name/category combination; maybe something like ::([category],)*[name] for each place naming instance // the reason i'm thinking of this now is because the whole 'place' concept can be crucial for defining where stuff is, but difficult to apply // NPCs are a location specific special category... but maybe needs broadening as a concept... like, there's places you walk and stuff you walk to, and that would include NPCs... but NPCs sometimes wander, so maybe it is a subclass // thought - special place 'overworld' defined as being the highest hub/global map/whatever; it can be limited or segmented or otherwise split due to narrative location gating, but should not overlap; in theory it should be singular, though some games might break this, but from the WHAQ perspective it should be easily identified because we know all and know where the highest surface is that all the other locations live in // gonna rewrite the first stab at things... this might take a while to develop, huhn // i'm seeing a couple things; the handler needs to be able to able to understand that in terms of building a 'place tree' for any reason, that 'placedef' is contextually equivalent to any 'place' container; also, if an area is returned to, the handler/language needs to know that each structure must be unique in its full name - so in this case, there might be another town containing a Stable, but there can't be two Surf.Stable entries; and multiple references to the same location at different times should be understood to mean the same place (and time, for those games like Chrono Trigger where time becomes important) - labels should/must take this into account to be grammatically correct (although with the time stuff, it may be necessary to introduce parentheticals or a 3-tuple CSV to specify time periods when talking about the same place, instead of forcing parenthesis in a way that reduces user clarity) // not every tile needs to be incorporated or specified or located - just the areas that need guiding to; like an RPG like this doesn't need to clearly indicate every house, but in one where talking to everybody is required for a trophy it may become necessary to do so // locations should be able to handle appropriate keywords like 'wandering' or 'random' or 'limited random'; meaning that some NPCs might follow a route, or be found in a particular area but unpredictable, or randomly at one of five places, et cetera... the language doesn't need to be explicit about that right now - just aware it's coming and ready to handle it ::place::placedef::location::NE::npc,Employer::area,Stable ::step::convo::Employer::reward::Heal Berry::stepdown::Run around as much as you want - get to know the Menu and Pause Menu, fix the controllers and mapping, etc. - but in terms of the game, this is just a starting point.::Talk to the man by the barn door to register your name and proceed. (The default, 'Rudy', will be used to refer to this character through the WAQ.) ::place::exit // compass location is working fine in this instance, but there needs to be gradation or relative placement possible... like, in this case, 'east of the Stable' or '1/4 of the distance from the west of town, halfway from the north', or more easily interpreted but less user friendly, '.25W.5N'; this might be something to be incorporated later, once more examples are available to filter into a usable pattern // at the moment, 'convo' should only refer to an essential/trigger conversation // let's move on to the second step; at this point, the player has expanded from Stable to Surf... the default will be that leaving an area doesn't mean inaccessibility of the old place, but it should be indicated when exiting does close an area - i'm thinking the syntax should be - place::lockdown::exit - and if it's temporary, reopening can either be implicit by it being referenced in the WHAQ or explicitly with the instruction 'reopen'

// --Before you do that, explore town and talk with the people here. / Inspect barrels and throw small crates to find three Heal Berries, a Power Apple, Hardy Apple, and 28g. / Also take some time to check out the shop so you can buy some handy healing items. / Then head over to the mayor's house in the center of town, go upstairs, and talk to him. He'll reward you for a job well done with the Bombs tool. // we're going to say that the 'item' keyword (singular, not plural) is, at the moment at least, a placeholder keyword - it implies that this information would be moved into the actual 'items' list by the editor or handler, but for the moment that would be a derailing hassle; if it works smoothly, it may become officially part of the language, but for now it's a hack; its CSV format is parallel to the official 'items' structure ::item::Power Apple,Consumable,+1 Strength::item::Hardy Apple,Consumable,+1 Vitality // okay, i'm going to use 'placedef' independently here; a fully grammatically correct WHAQ might not use this grammar, but since i'm rewriting on the fly we'll allow it; maybe it would be better to allow this in the formal definition, with the understanding that if 'placedef' doesn't occur in a sequence beginning with 'place', it is referring to the furthest branch of the 'place' tree that it currently occupies; so in this instance it refers to Surf // i'd have to replay the game to correctly locate and associate each item with its container, which i'm not currently willing to do - so we'll be using a vague definition; but it should be acknowledged that if that information were explicitly given by the original FAQ, i'd be incorporating it somehow ::placedef::item,Heal Berry ::placedef::item,Heal Berry ::placedef::item,Heal Berry ::placedef::item,Power Apple ::placedef::item,Hardy Apple ::placedef::money,28 // as a note to self, one possibility for the final format of the WHAQ would be, instead of having a sub-entry for each step below its parent, instead make it so that if you click the step, the more explicit version -replaces- the original version // ideally, the final formal language would have a way to avoid being explicit in the step; that's for later, though, or for GPT to figure out // the item collection can happen up until the point that you leave the town; indicating this will be fun to figure out // i've been told that this game particularly has lots of script shifts and situations gated by narrative timing; not now, but once this walkthough has been handled, it might behoove the development process to look at the specific FAQs to see if the timing could be incorporated for the purpose of development/refinement/stress testing ::placedef::location::E::area,Mayor's House ::placedef::location::Mayor's House::level,2nd Floor ::placedef::location::Mayor's House.2nd Floor::npc,Mayor // currently understood that a 'Tool' is infinitely reusable; might need to get explicit at some point // i'm getting to the point where i'm understanding my syntax a bit more than i might record ::item::Bomb,Tool,Explosions ::step::convo::Mayor::reward::Tool.Bomb::result::Surf.unlock::stepdown::stepdown::You can break crates and search barrels to find 3 Heal Berrys, 1 Power Apple, 1 Hardy Apple, and 28g, up until the point you leave town; you also can visit the Shop for healing items. The next step in the story comes when you talk to the Mayor; he'll give you the Bomb tool.::Explore around town if you want to find some useful items; otherwise, talk to the Mayor in a house east of the stables.::Talk to the Mayor in a house to the East. // i'd like to find a usable terminology for the instruction that doesn't give too much away that indicates when i mean that something is imperative, or when it's like this case where the narrative requires the conversation but it's not as crucial to get it done as the current phrasing might imply. // this is where the whole idea of 'place' important starts getting fleshed out; the interaction is in a definite place, right, and the interaction opens the gate to the outside world... so that needs to be indicated somehow; but in terms of the WAQ to trace the player location, the limitation is different than the Employer interaction, the movement limitations aren't involved, so no explicit placement is required for the player themselves // i've inserted a new keyword, 'result'; rewards are what a player gets, results are the indirect stuff; i was going to say the previous conversation needed modification, but reflection says it doesn't - the Employer stands in the way of the exit, so the lock status of the Stable is moot; this method might allow narrative timing unlocks, we'll see // i think a fully developed language might allow non-linear additions of thing that maybe aren't ever directly referenced; i'm thinking of optional/side quests or easter eggs, where a conversation could be recorded at the end of the WHAQ but still be incorporated by the handler

// --Now, walk over to the stairs and someone comes barging in with news that a child has gone into the Berry Cave, which is full of monsters. / Knowing the right thing to do, exit the village, head south on the world map, and enter the Berry Cave. // okay, so this was location based - you try and leave, and instead it goes into a cutscene; we haven't handled cutscenes yet // if a cutscene changes venues or locks access, it should be possible to indicate using the established terminology; if it doesn't, it shouldn't be a concern, even if there is a localized shift, like going out of a house - unless the door locks behind you or something similar; point is, if you can easily return it shouldn't be necessary to trace the location (though later versions might allow for that) ::step::move::stairs::result::cutscene::A villager reports to the Mayor that a child has gone to Berry Cave::stepdown::When you try to go downstairs, a villager will report that a child has gone to the Berry Cave to the south::Go down the stairs to start a cutscene.

// this is where a trophy can happen in the PS5 version; you have to bomb the parrot; even in the original it still would have been funny to know attacking the parrot cause it to sic the chickens on you, so it's not meaningless; i'll worry about the syntax later, but it needs a placeholder :🏆:optional::ps5::Bomb the parrot. // i have a feeling that part of this development process will be getting GPT to pull together some enumerated sets and subsets // this is likely where at least one NPC conversation changes // i backtracked to add this - it gets explained later ::placedef::location::S::door,Leave ::step::move::Leave::Leave Surf. // now we exit and everything is wonderful ::place::exit

::place::location::Surf->S::dungeon,Berry Cave // this has me address a larger issue - most dungeons have separate rooms, so that's a given and the placement will have to be indicated in some way, but some town houses and areas also have that and should be addressed; it's why i used the term 'area' for the Mayor's House, because it's a softer definition instead of a hard shift of where the systems thinks we are // exits to each area need placement and linkage // so each room is a subject of Berry Cave and must be entered/exited; however, if there is backtracking it will be assumed that intermediate rooms will not need explicit specification and we just assume that the player will understand that as long as the step is explicit enough // i'm capitalizing the place names out of habit - it's choice, not requirement // 'door' is a variable category; it indicates anywhere that there's an actual shifting of place; its name is explicitly the place it will take the player to, with 'Leave' explicitly meaning an exit from the dungeon // --First pass through the entranceway of the cave past the guard. ::place::placedef::location::S::door,Leave::placedef::location::N::door,Room2::placedef::npc,Guard::room,Entrance ::step::move::Room2::stepdown::Go north, past the guard.::Go through the entrance. // --Head up a little ways and use your bombs to blow up the big crate to the right of the sign to get a Heal Berry. / Head up the path left of the sign and follow it around and through the next passageway. // the first time there's a definite chest/item relationship... i'm not sure what to do with that; sorry if the syntax is weird, i'm tired and winging it ::place::placedef::location::s::door,Entrance::placedef Hit the switch on the right to make the statue move out of the way and continue down the path past the bunch of small crates. Pick up the 50g in the chest to the left and continue down the path. Go right and get the 50g in the next chest along the path. Follow the path up and blow up the small sign that's blocking your way. Keep heading up and destroy the big crate at the end of the path. Then hit the switch to the southwest to move the statue blocking the path. Continue through the next cavern. From here, go southeast down this path (don't dash, because you might get into a random battle with bats which curse you). Continue all the way down and get the Heal Berry at the left end of the path and the Holy Symbol near the sign. Keep going southeast and then north. Follow this path to a bunch of crates and blow them up to get a Heal Berry. Go down the stairs and head north to find a pile of rocks blocking a cave. Blow them up and head inside to find a Hardy Apple, Power Apple, and Agile Apple. Then exit this room the way you came in and head back south. Destroy the crate along the path to get another Heal Berry and continue south to two switches. Hit the left one first and then the right to move the two statues out of your way. Follow the path down to the next area. Pick up the Bullet Clip along the path and go down to the crest on the floor. This is a save point, so use it as needed. When you're done here head left and up the narrow path to find Tony, the child who came in here. He says that he came here to retrieve some berries to help his sick father, but some rocks are blocking his path. Dispose of them with your bombs and head inside. Go north and pick up the Bandanna in the chest to the right and continue north to get the berries Tony needs. You'll then leave the cave with Tony, but the earth will start to shake. When you meet with the townspeople near the cave's entrance, an awakened monster will come out. It's time for a battle.

Boss fight: ZOMBIE

HP: 800 Exp- 100 Gella- 200 Recommended level- 2

This guy isn't that tough. The attack it uses most often is Rotten Breath, which can hit you for a good amount of damage. Just be sure to watch how much damage it's doing to you so you'll know when to heal yourself. Attack it normally until you build up enough force to use ARM Lock On with Hand Cannon. Hand Cannon should do well over 100 damage every time so you should be able to take the Zombie down quickly. After the battle the people will be shocked to see that you wield the forbidden Arm. They decide to bring you back to the village to pass judgment on you. Once you get back to the village and regain control, go downstairs to hear that the people have decided to exile you. They believe that you're the one who has caused all the recent problems that have unfolded, and they don't want you around causing anymore trouble for them. So the mayor kindly asks you to leave and never return. Now, leave the mayor's house and try to leave the village. Tony will come over to thank you for what you've done for him, and then he'll run off. Then exit Surf Village and pick a new mission. ::act1a::end

M: neat. what do you think of the language so far in terms of what's working and what need work

M: the one bit i didn' communicate fully, it seems, is that the double colon is a... maybe it'd be called a 'unary separator'? it's not a set; the language is supposed to be structured so that every instruction or whatever (still haven't pinned down a broad enough accurate label) is preceded by a double colon and continues until - but not including - the second set. hypothetically, an interpreter could read the entire thing as a single line - the newlines are for my benefit, not structurally necessary. the intent is that there are certain words that are in fact keywords in the right spot, but that define what can be a keyword afterwards. this is gross from computer coding, perhaps - but for rewriting language for processing, i think it can be made acceptable. now, some of your examples are just undefined as of yet - like the ps5 thing, i want to be specific about the 'system' keyword when i get to it - but at the moment, they are usable placeholders. perhaps as i develop it will start conforming to more rigid situations, but right now i want to include as much as possible so the rigid sets are clear. predefining them will lead to my attempting to wedge stuff in rather than realizing that what's needed is a new separation/priority paradigm. i think that part of the problem is that i only gave part of the stuff (semi)formal definitions, so the presented concept looks even more unfinished/unpolished than it is. like, i have a mental picture of the syntax that's sufficient that i can mostly recreate it and refine it on the fly - but that doesn't do you much good when you're having to figure it out in reverse. so stuff that i think of as being part of an incomplete enumerated set looks to you like a placeholder, or a tuple variation that i have at least a partial grasp of looks to you like a potential brain fart or inconsistency. and some things i just don't have the right descriptors for. like the entity-class category words aren't supposed to be completely fixed; after further development, i may predefine some things for usage that show up regularly, like Door or Town, but games are such a broad idea that a little extra effort in creating malleable category terminology interpretation seems like a better idea than limiting future uses. as far as 'placedef' goes, i may have explained it incompletely. it's doing exactly what it's supposed to, mostly, in your examples: all of them are supposed to indicate to a hypothetical handler that some item exists and, dependent upon the 'place' namespace it's created in, where it falls in a tree structure. the creation method is currently sporadic because each new entry i've been testing with translation seems to pop up a new item - but if i define it correctly, it should indicate the placement of anything that requires some interaction by the player. (the only bit that isn't in the 'mostly' is where you say it indicates player position; i don't think that was what is in there and if it is, i'll fix it cuz that should never come into play - the walkthrough is supposed to leave the player free to move. even if there's a teleportation or something like that, the player's position wouldn't use a placedef; it would indicate that the player had been moved to a point defined by another object that had been defined prior by a placedef.) your attempt to finish things was a noble effort - particularly the boss fight, i haven't thought about how to handle that yet, it's kind of like the shop bit in that the information should be available but it shouldn't be there to tempt the user unless they choose to reveal it - but it shows that my definition didn't give you quite enough. not just in the partial defined stuff, but the regularly repeating stuff, like the placedef items. lemme try to formally get it here, or at least semiformally and a bit casually: ::place(::placedef::[stuff to define an object in the place, like an item, door, or NPC])::[area category name, creating a new category if it's the first instance],[formal name of the place, which should either be added to the "location and object" map/hierarchy if that name is not already there, or indicating that at this point the character is in a place that has already been defined] ::placedef(::[when used alone, follows previously established rules as though it were part of a formal '::place' sequence involving the current 'place' namespace, allowing new entries if the player returns to a place and new stuff is available in the narrative timeline])+ // this is a specific case that i'm thinking needs formal definition that supercedes the flexibility i've been talking about ::placedef(::[whatever])::door,[previously defined item on the 'place' hierarchy | 'Leave', which means that it connects to the place on the hierarchy one level up, leaving the current place] // collect is currently in the nebulous, hypothetical realm; 'Bomb' is a literal item, defined as a Tool - i'm not surprised you're uncertain about some of these, the sample set is too small to make highly informed guesses // this version either defines or adds to the subcategory of 'room' in the overarching category tracking, creating an object as a child of the currently occupied 'place' namespace an object named 'Closet' - it can be identified as being a member of 'room', but its actual location is at '[namespace].Closet', and anything added to it as a child might be understood by the context/interpreter of the WHAQ as being 'inside' of Closet, but in structural terms -anything- can be a child of Closet - it's treated like a room by the WHAQ not as a predefined idea of what a room can do, but because of the choices made in this particular WHAQ; constructing an entire new Town inside of Closet is only subjectively absurd, not a technical error as far as the language is concerned placedef::room,Closet

... anyway, getting back to normal typing, there are a couple more things that aren't coming across for you. one, there should never be a 'focus' or anything like that. if the user is looking at point P, it's because they are either at point P or want to know what to do in a couple moves. and the reason why 'place' keeps getting used is to say where they are when certain things happen. the namespace of 'place' would give the interpreter or handler or whatever enough information to do so. i think that's part of what you haven't gotten or been given: this isn't meant for human consumption - it's meant for human editing and machine processing before reaching a human consumption level. it's like a complicated markdown language: markdown can be converted to HTML with a fairly straightforward search/replace regimen - but this would require at least two passes, one to collect everything into hierarchies to allow appropriate construction, then another to format everything properly. that's why i had both 'item' AND 'items' - because the conversion process is largely linear to the point that, for a human, building the appropriate list would be at best ridiculously time consuming, while a first pass by an appropriate script could collect everything, provided the syntax is properly defined. redundant stuff in this like the Heal Berrys (although admittedly i'd like to account for repetition at some point) is only redundant to humans - for a machine it's just being explicit. and, in that case, representative of a placeholder for if i were to go back and find (or find in a separate FAQ) the exact placement of each item; i haven't nailed down even a prototype of how i'd do that, mind you, but the finished language i'm working towards would allow for those locations to be separately identified explicitly, so that they -weren't- redundant; and any situation where, say, a Chest contained 3 Berrys at once would have the actual collapse to prevent spam that you're talking about. and until then, keeping them separate indicated another reason for the explicit creation of the things - because one feature that's worth considering implementation of would be item tracking, as an actual checklist or just as an aggregated list. so explicit tracking has more future potential than the information collapse would be worth. i didn't mind the idea of a 'scavenge' instruction - but proper implementation would require the type of explicit definition of and assignment of item placement that i've been talking about. although i'd like to find a different term, because 'scavenge' sounds like it would be better applied to random encounter drops. i haven't faced that part yet because i think, because of its nature, it would be simple to overlay it (in terms of information storage, at least) onto what's already being worked on. although the pre-scripted encounters like the boss would need to follow the same format. ... that's why i appreciated your effort there; even if i completely change what you gave, it'll still be because it gave me something to compare what comes next to. the cutscene definition -is- sparse, but i'm not sure it needs much expansion. steps use stepdowns to make sure that the effort is made to get everyone where they need to go - but all the effort is being made because i want others to be able to experience on their own both the content of the game AND the happy feeling of getting there mostly on their own; particularly now when, between the amount of games coming out, their easy accessibility, and the ever-growing backlog of games worth giving a try, there's a tension between wanting to enjoy a game and knowing that it's not like the 90s when a game that took 30 hours in a speed run was a good entertainment, not a time hurdle. i want to be able to let people (and if i define the language well enough for you to understand and reproduce my work, maybe even myself) complete something like Chrono Cross in a way that's enjoyable but shaves off the potential hours of wandering necessary to figure things out by oneself, but without having to pay so much attention that you find out that one of your teammates is going to be sacrificed when you were just skimming in an effort to figure out why the damn cave door keeps chiming without opening. ...the trophy thing is another placeholder. it's connected to why i'm having such problems pinning down the terminology associated with describing this language's syntax. hypothetically, if i do things right, what i've been intermittently calling 'instructions' or 'commands' will be syntactically just a bunch of keyboards that a flowchart would be able to parse appropriately in terms of what can be expected next - so that 'trophy' can be appended onto whatever specific action or trigger it needs, instead of having to be explicitly dealt with depending on what preceded it or what sequence contains it. i think that might be a place to start nailing down definitively syntax/terminology, for your benefit and my own: we're gonna say that any keyword, whether it's 'step' or 'trophy' or 'placedef', starts a sequence. for the purposes of this definition, we'll assume a complete keyword interpretation rubric has been usably defined. sequences start after a double colon (let's try calling it 'ducol', see if that sticks in my head). sequences can contain sequences. the shortest sequence would be a single keyword which definitively has no followers (dunno if i have one yet). any non-singular sequence will be ended with what we'll call an endcap; this can be another explicit keyword, but will largely be some variable string (due to the nature of the project, there's a lot of human-facing text; practice shows that, in that case, it's best have that kind of massively variable parameter at the end). it's important to note this because it means that any sequence containing text outside of the endcap will need careful syntactical formatting or should be broken up into separate sequences, because multiple texts in a row would allow for inadvertent closing of sequences as text was misinterpreted as endcaps in nested sequences. we're going to call any entries in a sequence a param; that's because they can be considered in english to be equivalent to parameters, but i don't want them conflated with the kind of parameters used in formation of function like in C or python. an endcap can be considered a param; even a keyword can be considered a param, although it should rarely be thought of as that in actual use, to prevent unnecessary confusion. the rubric of interpreting a sequence will involve identifying the keyword, then what core form its sequence takes by looking at the params that follow it. each core form must be a detectably distinct combination of lokeys (locally defined keywords that are distinct from keywords whose presence would necessarily define a new nested sequence) and information for a variable. lokeys are distinct from keywords because a keyword will start a self-contained subsequence anywhere. the nature of the product means that there will be no need for returned information; this is repeatable direction, no feedback is called for. incorrect placement may result in nonsensical or vacuous output - but it will not break the system itself. in contrast, lokeys create parasequences (new name suggestions welcome) which operate similarly to regular sequences - params, endcaps, variables, representation in the rubric - but if attempts are made to call on them outside of a true sequence, they will not accomplish anything. on the other hand, lokeys can be interchanged between keywords: the same implementation of, for instance, a 'location' lokey core form will be used for any keyword which can implement 'location'. lokeys should, at this point at least, not be nested; a true sequence can start and end within a lokey without breaking the syntax, but lokeys should currently be treated as serial, not nested. a core form is distinct (now that i've got everything defined, i think) it uniquely combines lokeys (measured independently of their params), variables, and param quantities. variables should all be considered text strings for the purposes of writing; an interpreter might be told to detect or interpret, for example, a particular variable as a number for formatting purposes - but the ducol language has no reason to distinguish. for the purposes of the language, any param that cannot be read as a keyword/lokey is assumed to be a variable. the core form does not take sequential lokeys into consideration as multiple entries in its form; that is, there is no core form that can be defined as keyword,lokey,lokey,variable. the rubric interprets each lokey individually to determine what they do - but the core form collapses, for the purpose of defining itself as unique, a series of parasequences into a single parasequence. this is not the case for variables. so two generic sequences that read as being keyword,variable,variable,lokey and keyword,variable,lokey are valid and distinct - but two sequences of keyword,lokey,lokey,variable and keyword,lokey,variable would be considered to be using the same core form. i haven't cover the relatively special cases of when a lokey is a single-param parasequence, but that's because it has already been mostly covered right at the beginning, when i talked about a single-param sequence even before i had defined 'param'. i said that i didn't think i'd defined any single-param sequences - but i -had- used single-param parasequences. and the same idea applies - for core form purposes they are lokeys, and they should not give an interpreter any pause. As long as it doesn't contain a ducol, a variable can contain anything - pages of content, if the situation calls for it. but there is an extended variable we'll identify as a CSV param - but it will only come into play if the keyword rubric tells the interpreter to use it thusly. if a CSV param is expected, the text will be treated as a comma-separated value; a lack of commas won't create an error, but it will leave whatever tuple it was intended to fill with all field empty except the first. so for these definitions it doesn't matter, i guess - only in terms of later construction of an interpreter.

... i have a minor/major concern only in that i'm not sure if i've got enough to work with or if i need to get creative and expand things when dealing with the idea of triggers. i mean, the whole of the structure, the entire sequence thing, can be considered to be a series of potential flags or triggers; each step exists -because- it's, in essence, a trigger - just one that the WHAQ is defining as critical outside of the game, whether the game thinks of it that way or not. so my concern is less overhauling the entire language than it is making sure that i define usage clearly enough that i don't start to drift and end up contaminating things through an unintentional early variance.

M: nonononononono; the ducol distinguishes each param, including the initial keyword. so for ::placedef::location::Mayor's House::level,2nd Floor the params are the keyword 'placedef', the lokey 'location', the parasequence param "Mayor's House", and the CSV variable "level,2nd Floor". the sequence - defined in the examples using newlines - starts with the keyword 'placedef' and is ended by the variable 'level,2nd Floor'. the core form an interpreter for this would use would be "'placedef',lokey,variable" - because as was defined, the actual identity of the lokey, the existence of other lokeys, and any parasequence params are discarded when considering the core form.

M: this is supposed to be a rigidly linear structure: the interpreter is intended to read forward from its current point in order to determine how to proceed from the current point, but once it has proceeded it should have no reason to look back. i don't know why this particular style was complicated to grasp, but you can see why you were more critical than i thought necessary about the syntax itself. of course, this was the first draft with a lot of inline development even in the first couple lines. but i did find it odd how off base you were, considering that usually you get an immediate grasp on parsing code, even if you've never seen it before. the lokey collapse in the core form is because, depending on the keyword, there may be multiple practical or serial combinations an interpreter could find useful - but in practice, that will essentially be defining what settings, formatting functions the interpreter uses, which can all be considered a single entity for the syntax of what's being done. one of the challenges i've been having is likely more of a human thing than an actual problem in the language. what's being done is odd just in terms of english verb tenses: to properly shape and describe the structure of the game, i have to act as though this is a static four-dimensional structure - one where each moment is 'now' and eternal. but then the human bits, the endcaps of the step commands and other text bits, demand the perspective of it all being a sequence. i agree about the keyword/lokey distinction. and i haven't entirely defined the idea of the container classes sufficiently; i think the structure is there, but i haven't got it formally rounded out. the lokey definition helped me because it locked in something i hadn't really completely held before: i think most of what i've got so far is, in the end, a very short core form. the parasequences bulk things up - but in the end they're visually inflationary but not able to complicate outside of their own little domicile. what you're noting, or at least were noting, as a bunch of placedef variables are, in core form, a single lokey. something we both need to keep in mind - me for prototyping and you for prototype analysis - is that the language just needs to be consistent; it'll be up to the interpreter to make hay out of what the language gives. so the -language- doesn't need to provide a definition of how to deal with, for instance "Tool.Bomb" properly - that'll be the interpreter's job (and mine again, to debug the methodology). so in the following parasequence - "::result::Surf.unlock" - i might be introducing a complexity the -interpreter- needs to deal with - but the -language- has been sufficiently defined that it can deal with that consistently, whether it makes the interpreter throw up or not. the 'stepdown' idea needs to be dealt with. it's critical in what's being done, at least at this point - giving different levels of information - but syntactically it's irregular. not sure whether to make it a special case or attempt to modify the definitions. ... it's a lokey, so i think it'll be a special case for parasequences, in that it's (currently) the only one allowed to violate the guideline preventing parasequence nesting. the clarity between language and interpreter could be the in-road to fixing the trigger idea, once i've pinned down the keyword syntax. as i've defined it, a 'trig' keyword (i want to move away from 'trigger', it's awkward and has societal baggage) would define an independent, self-contained sequence wherever it started - meaning that all that is necessary is a robust lokey set to allow for flexible (or expandable as new games are prototyped) labeling for the interpreter exactly what the hell is going on. (yeah... that's -all-. whuf.)

M: i want to clarify because i'm uncertain from your recap: interpretation will involve reading ahead a few params, potentially in a recursive way, for the purpose of identifying the path the interpreter should take. so moving on the tape will always be definite and forward - because looking back shouldn't be necessary - but will involve holding a pointer at 'now' AND the future params. ... i think i might be worried over nothing, because that might be exactly what you said... i just want to be sure. trigs i've resolved in my own mind; i didn't define sequences with them in mind, and you'll remember i cautioned against using random sequences in the construction of the game sequences (and still do) - but they're defined as being able to start and finish at any point without creating any kind of disturbance in what was being dealt with at that point. so being in the middle of another sequence wouldn't matter - once the trig was dealt with, interpretation would return to whatever sequence it had been dealing with before it sprang up, no mess. you're not looking at what i'm calling the 'container classes' in 6. i'm talking about how keywords like 'shop' or 'place' are dealt with. i've got an internal notion, but i'm not sure how to formalize the definition. the idea is basically: some keywords define where an interpreter should form or modify a more complex structure. some, like 'shop' and 'items', are self contained even as written, if with a few modifications: "::shop::[name]::fields::[csv structure/names](::entry::[csv tuple])+::shop::end" almost works as the definitions stand, in terms of following the grammatical rules - and the only exception i see, the second 'shop', is more for my readability than structural necessity. hell, all i have to do is modify the definition a bit so that any keyword described as initiating a container class necessarily has as a lokey itself - that is, removing the possibility of nesting shops which is largely uncalled for - and the necessary alteration are done. 'place', though, is another kettle of crap. it is -intended- to be nested, as a structural guide for the interpreter to use in building the core heirarchy tree i've talked about. AND it is intended to be used for navigation guidance. so it's an equivocation: it literally places places, and i don't believe the noun form and verb form can be disentangled without creating serious semantic complexity in a core concept. ... it's like, it -functions- fine, but describing how that works is eluding me. tho i'm a bid tired after doing this for a ridiculous amount of time, so i'm not harshly gonna judge.

M: i still would call 'fields' and 'entry' lokeys, even IF i thought 'shop' and 'items' needed redefinition - they may be a bit different, but they still seem to have the parasequence structure. the repetition of 'entry' really is the primary differentiation - and even then, the original syntax definition doesn't deny the ability to repeat lokeys. ...i think i've got a fix. or see where i went off course, like i said i might do before. 'place' is for putting/referencing something ON the... to avoid linguistic equivocation, i'll call it the -site- hierarchy tree. 'placedef' is for putting/referencing something IN something on the site hierarchy tree. the difference being that the game keeps track of where the player is ON the tree, then displays whats IN that place for the player to interact with, some of which lets them change where they are ON the tree. a 'Door' type item is what you put IN a place on the tree to let the player signal they are ready to move somewhere else ON the tree. i've been writing the language as though those two separate concepts were the same thing - to the point that my syntax was using 'placedef' as though it were a lokey, instead of a keyword. an funnily enough, like with the trig stuff, i actually was okay syntactically - or, at least almost - in doing so, because the placedef keyword would have created an independent sequence interpretation branch without breaking the grammar. the 'almost' comes because, since the new 'place' opening sequence wasn't completed, the new locations would have been built in the previous 'place'. i think from that perspective, i can use it properly now, provided that the syntactical rule allowing/requiring container classes to have themselves a lokey is properly defined. i'm thinking that it will have to be something like: an keyword defined to have the special property of 'container' is allowed and required to have as a special lokey/parasequence its own name, combined with a single param of 'end'/'exit' (or something else contextually appropriate), which indicates the closure of that container; any other instance -besides-that "::[self]::[end|exit|etc.]" for will revert to original grammar rule interpretation, treating the [self] param as indicating a keyword (allowing sequence nesting to still occur). we're going to add as a part of the formal definition that letter case matters; lowercase and uppercase are two distinct forms, so 'door' and 'Door' would be two distinct params. i'm going to define one more special case, for the editor's sake, not the interpreter. the keyword 'act' is special in that, when detecting keywords, -anything- beginning with the letters 'act' is considered to be an instance of the 'act' keyword. (it may be necessary to modify the letters from 'act' for practical purpose later to something less ubiquitous, but the principle will remain the same in terms of being greedy.) this is so that anything after the letters 'act' can be used by the editor as a label. (so 'act1b' is interpreted as the keyword 'act'; the '1b' is editor-specific and tossed by the interpreter.) the 'items' container keyword is a special case, but not necessarily functionally unique; that is, it defines the operation of possible WHAQ defined container keywords, provided the syntax is properly used. here are the rules: the area in a file before the first 'act' occurs is a place for definitions which must follow syntactic rules but are understood to be primarily for the interpreter and thus are to be afforded more flexibility in terms of core form requirements, as it assumed that anything there was placed with particular care for the interpreter to deal with. for example, the 'form' keyword - which should -only- be a keyword in this pre-act area - is exempt from the core form restriction because it's understood that the interpreter will know how to deal with params, in a manner which doesn't need to accommodate the formation rules. the 'items' keyword should also only be accepted in the pre-act area, to define a simple table using the established lokeys of 'fields' and 'entry' as desired; if no 'items' keyword is present in the pre-act area, the interpreter will automatically create a minimal associated structure using the assumption of "::fields::Name" and no "entry" parasequences, creating a placeholder. the keyword 'item' is associated with the structure created by 'items'; it has one form, "::item::[variable]", which the interpreter is intended to read as appending an entry to the 'items' structure. the keyword "XXX" is predefined as being a null command/cache cleaner/brick wall, intended (at the moment) to be valid only in the pre-act area as an explicit indicator that a sequence is over. this is a backup concept, related to the current topic because in the pre-act area, the lack of adherence to the core form rules means editors will feel better knowing they have a keyword that can prevent errors from cascading into further syntactical errors, or be certain that what they are trying won't fail because they didn't account for a grammatical deviancy or quirk of the interpreter. when the interpreter is expecting a keyword in the pre-act area - for example, as the param after a "::XXX" keyword - and encounters a word ending in 's' that is not currently a keyword, instead of ignoring or otherwise dealing with it as usual, the interpreter will consider it a request to create a new global table in the style of the 'items' keyword, and will use those rules to build the table. importantly, it will also add to the standard dictionary of keywords a keyword associated with this defined table that is the instigating without the 's' - so if in the pre-act area is the text "::XXX::styles::Fighting Styles::fields::Name,Power,Speed::styles::end", the interpreter will create an internal global table during processing with the label 'Fighting Styles', the fields Name, Power, and Speed, and will add to the dictionary the keyword 'style' which can be used in the manner of the keyword 'item' to add entries to the global 'styles' table. ... none of that truly matters to the grammar rules of the language, except to explain why/how a keyword can be created and used in a syntactically correct way without explicitly being part of the formal language.

M: okay, you're saying it's coherent - so let's see it. please give me the current form of the language, as you understand it, as a formal definition. in a code box, please.