Discussion: The Problems in RiveScript

[kirsle]

This issue is reserved for discussion about the problems in the current version of RiveScript.

Use a bullet list for each major point, to make it easy to scan through the comments and tally up all the problems.

---

I'll start with some that I've encountered:

• The line-delimited nature of the language feels claustrophobic.

Especially when trying to do something like have a random reply in response to a condition check. You either have to do this:

+ my name is *
* <formal> == <bot name> => {random}
^ Oh wow, we have the same name!|
^ My name is also <bot name>!|
^ We have the same name!{/random}
^ <set name=<formal>>
- <set name=<formal>>Nice to meet you, <get name>!

...or you use an {@redirect} to a different trigger. Neither is very ideal.

• You can't easily nest conditionals. You have to chain together a bunch of {@redirects} to check multiple vars for the same trigger.
• Tags can't be mixed and matched in arbitrary order. Only the get/set/bot/env/sub/add/div/mult tags work this way, but all the other tags have a fixed order in which they're called. You can't <set> based on the output of a <call> tag, for example.
• The difference in syntax where some tags have <angled> brackets and others have {curly}. Related to the above point, this made the parser harder to write for processing tags.
• %Previous is hard to work with: a trigger with a %Previous is its own "top level" trigger, disjointed from the previous trigger that it refers to. It makes it hard to keep your code straight if you're trying to design a more complicated discussion around these.
• Everything is too "text based", as the unit of knowledge transfer is the text string. This is particularly annoying with object macros, where the args passed in has to be a sentence of words (you can't easily use JSON as the input data), and the result of the macro is also a string that gets substituted in for the <call> tag. Instead it should be more data-driven, with a struct being used in all places where additional metadata can be carried throughout the bot in the replying process.

[fbatschi]

Although I understand the reason for it, somewhat problematic is the

• inability to preserve the original input or upper- and lowercase of user input for later reference

Although there are Tags like , , , to modify the user input, there is none to access the original input. Imagine asking the user for his name, and the answer is "Hans-Peter" (a German name). Inside my rive script I would only get "Hanspeter".