Syntax Starting With Param

[tajmone]

• Need @thoni56 confirmation that error 209 no longer applies.
  • Fix Appendix F.2. Message Explanations on compiler error 209.
• This issue might require updating sections on Syntax/Verb:
  • Check if they mention that is not possible to place parameter in first position.
  • The fact that now it's possible to place params in first position, also means that verb constructs like "> Bob, take the apple" are possible in Alan (these being common in other IF systems, authors and players might expect to find them in Alan too).
• This issue also affects TBD Manual: G.5. Word order #28 — regarding TDB contents for Appendix G.5. Localization »_ Word Order_, where it mentions the possibility of implementing "das buch nehmen" (ie. "take the book" — lit. "the book take [it])".

In Appendix F.2. Message Explanations we read:

209  First element in a SYNTAX must be a player word.

The definition of a Syntax construct may not start with a parameter. The first word must be a player word so as to distinguish it from other forms of input.

This statement seems no longer true right now. The following Alan code compiles without error and works fine, disproving the above statement:

Syntax take = (obj) take.

The kitchen IsA location
  VERB take
    DOES "You take $+1."
  END VERB take.
End the kitchen.

The apple IsA object AT kitchen.
End the apple.

Start at kitchen.

And you can actually run it and type:

> apple take
You take the apple.

[thoni56]

Confirming that 209 is no longer applicable. I've also committed a fix that removes that message.

Regarding "actor commanding" you can do

> bob jump

but not

> bob, jump

since the comma is parsed by the interpreter as a concatenation "operator" in lists of multiple parameters or between different commands ("take the apple, the chair and the box" resp. "go west, take chair".

It is a bit unfortunate that the "IF standard" form with <actor>, <command> is not supported.

[tajmone]

I've also committed a fix that removes that message.

Great!

the comma is parsed by the interpreter as a concatenation "operator" in lists of multiple parameters or between different commands

I suspected so, but anyway the syntax is very close to the intended command, regardless of the comma omission.

It is a bit unfortunate that the "IF standard" form with , is not supported.

Indeed, it would be nice to allow players to use commonly established commands conventions with Alan games too. If it was possible to implement in the parser an exception for commas which are mentioned in the Syntax definition as not being AND words it would be cool, if doesn't require a huge effort.

[tajmone]

Anyways, as soon as you approve the pending PR #55 I'll start working on some agreed upon fixes, so we start to clean up some of the (many) pending fixes, and then I can make some PRs for contents changes that are almost ready.

Any ETA for Beta7 release? (I could set the ETA on the milestone, as a deadline estimate reminder)

[thoni56]

It is a bit unfortunate that the "IF standard" form with , is not supported.

Indeed, it would be nice to allow players to use commonly established commands conventions with Alan games too. If it was possible to implement in the parser an exception for commas which are mentioned in the Syntax definition as not being AND words it would be cool, if doesn't require a huge effort.

Well, it is probably of medium effort, but it will be a break of the current structure in an "unnatural" way, which always is risky and feels uncomfortable.

[tajmone]

Just a few thoughts on this ...

Well, it is probably of medium effort, but it will be a break of the current structure in an "unnatural" way, which always is risky and feels uncomfortable.

It's worth noting that the , in syntaxes like Bob, take apple will always be the 2nd token; whereas in all other cases will always occur in 3rd position or above:

> take apple, mango and banana
> look inside box, bin and pot

Furthermore, it should only follow an actor instance — assuming that orders can only be imparted to animate things, although some real case scenarios might violate this rule (e.g. a dead NPC/actor being replaced by its corpse/object, where the player might still try to address it as if alive, and the author might want to catch that with alternative syntaxes/verbs, or via Checks).

Maybe compound actors names might introduce complexity here (e.g. evil twins), but if we consider as token a parsing unit (regardless of the number of words it's composed of) then the above rule still holds true:

> evil twins, take apple

... effectively breaks up into evil twins + , + take + apple.

I wonder if this, in conjunction with the fact that such a , would also need to be explicitly specified in the verb Syntax, could make its implementation less risky in terms of backward compatibility and/or breaking up things.

For example, the parser could have a special flag for syntaxes that contemplate a comma:

Syntax actor_take = (act), take (obj).

The flag could not just indicate the presence of an expected comma, but also its position. Basically, when the parser encounters a comma, before considering it and AND word it should check if there are any applicable syntaxes that include a comma, and if the comma matches the syntax position (or the above rule of 2nd position only).

Surely, it seems that this would introduce some complexity on the Syntax BNF rules and their code internals, beside the parsing in itself. But in terms of safety for backward compatibility and preventing things from breaking up it might be doable.

Maybe the real problem would be use of multiple parameters in first position, which could entangle things up:

> Bob, Alice and Joe go north

In the above example, we find a , in 2nd position which is actually an AND word, and no , where we'd expect the comma to appear — how many chances are there that a player would actually write Bob, Alice and Joe, go north?

So, probably the use of (param1), in a Syntax should disallow the use of the omnipotent indicator (i.e.(param1),* should not be valid) due to risks of ambiguity.

Ultimately, this could be implemented as a special case, only permissible in syntaxes where the first parameter is an actor, and no * indicator is used. After all, it would be only to allow the use of commands of the <actor>, <verb> form, so it would make sense.

I'm not sure that having this is really that important, after all. But from the player side, it's true that "habits die hard" and that most players are likely to be accustomed to its usage (after all, players don't care about IF tools, only about adventures and having fun).

[thoni56]

The syntax section is already fully updated for the "parameter first" feature. So I checked the box ;-)

So should probably add the link from "Word Order" as mentioned in #28.