Test for incorrect cartesian product.

[dblock]

Following up on alexa-js/alexa-app#115, which turned into #16 here but didn't describe the problem quite fully I believe.

This test demonstrates the issue, but I could be missing something? The documentation states that this should be the full cartesian product of all shortcut values. So should it be identical to a full expansion in this case?

[mreinstein]

so just to add some historical context around this. exhaustiveUtterances was added was to reduce the output size. It gets large very, very quickly. Massive utterance files really slow down the app because it has to be fully parsed at several points in the skill's lifecycle. And the full combinatorial set is not needed anyway, according to amazon:

https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/migrating-to-the-improved-built-in-and-custom-slot-types

^ I really recommend reading this document carefully ^

The original PR which created exhaustiveUtterances: dd279a9

[mreinstein]

another thing to keep in mind: there is an improved slot type, which reduces/removes the need for these expansions. These are wonderful for keeping the utterances file to a minimum. Wherever possible, people should be using this, as described here: https://developer.amazon.com/public/solutions/alexa/alexa-skills-kit/docs/migrating-to-the-improved-built-in-and-custom-slot-types

[dblock]

Makes sense @mreinstein. For the purposes of this PR, are you saying the way these are expanded is correct as it stands (if so, feel free to just close this PR)? Then, is the documentation incorrect in that case as it states that a cartesian product is being built?

[mreinstein]

I haven't looked at the test cases in this PR very carefully to assert their correctness. I posted the links because the people that originally brought the exhaustiveUtterances feature into being aren't on this thread, and historical context is always good when maintaining software.

[dblock]

Looking forward to hear from you re: correctness @mreinstein when you have time ;) LMK if I can be of any help.

[mseminatore]

@mreinstein Thank you. I read the doc ref'd above and this makes sense. If I understand the documentation correctly we don't always need to generate an exhaustive set of utterances, only a representative set. Thus exhaustive can often safely default to false.

And for the new types we don't need to generate even a large representative set of examples. But given that why then don't we modify alexa-utterances to recognize the new AMAZON types and not generate permutations for them?

[dblock]

+1 on supporting well known amazon types @mseminatore, potentially exhaustiveUtterances could go away as an option even

[mreinstein]

@mseminatore @dblock this was the old discussion around removing things from the next version of alexa-utterances that has breaking changes: #7

The discussion I started was around dropping some of the stuff in alexa-utterances that is no longer very useful due to Amazon's inclusion of built-ins and custom slot types. Probably worth a read.

if you look in the 1.0 branch you'll see the work I did to trim down this module, but haven't merged it. Waiting for a time when alexa-app publishes a module version with major version bump because this would be a breaking change, and alexa-app relies on this.

Still open to discussion on this