Add support for custom slot types

[MaxwellPayne]

User can create a slot name literal using the syntax {-|Name}, where Name is the name of a slot using a custom datatype in its skill's interaction model. This will convert the expression to {Name} and treat it as a string literal over which no combinatorics will be performed.

[MaxwellPayne]

This solution was proposed by @simplydallas in #2 to support @rickwargo's improvement on alexa-app, which without his PR only supports Amazon's LITERAL, NUMBER, DATE, TIME, and DURATION slot types.

[simplydallas]

Looks good to me. Not exactly how I added it to my code but the exact same result with the minus designating that although it is a list, it is one that should be treated as empty since Amazon has the actual list stored and only needs the {keyword} syntax to work with it.

[d0t101101]

+1
Thanks Maxwell! IMHO this is very much needed to handle the scenario wherever 'intents' are using custom slot types.

[mreinstein]

see #7 Amazon is deprecating LITERAL, so some of the functionality (esp. dictionary) is no longer needed in alexa-utterances.

[d0t101101]

But LITERAL seemingly will continue to be supported:

"Backward Compatibility
The LITERAL slot type continues to work. To continue using the old functionality, specify AMAZON.LITERAL for the slot type in the intent schema and leave the slot values within the sample utterances."

There are use cases where using AMAZON.LITERAL instead of custom slots might makes sense - for instance a Home Automation skill in which the user can customize the alexa-app's room names for their house. While specifying a custom slot doesn't limit the values that can be used, one may have better results when using LITERAL so the utterances can be created for their specific home (configured in the alexa-app itself)...

Agreed that dictionary support is however no longer needed...

[mreinstein]

@d0t101101 hmmm that's interesting. Can you send me the link with that text? I'd like to read it.

[mreinstein]

perhaps you could explain a bit what you mean when you say:

"While specifying a custom slot doesn't limit the values that can be used, one may have better results when using LITERAL so the utterances can be created for their specific home (configured in the alexa-app itself)"

Can you explain what you mean about better results? Better how?

I found that line in the document that you referenced above. But you left out the next line following it:

"Migrating to a custom slot type is recommended, as it is easier to define the sample utterances and achieve better accuracy."

The doc seems to indicate the opposite of what your comment suggests, but maybe I'm missing something or misunderstanding.

[d0t101101]

Hi,

After digging deeper I realized that it shouldn't really matter what the values in the skills ASK custom slots are, as validation (i.e. in my example above - which rooms may be controlled via HA) must still be done in the Alexa-App code anyway...

Please disregard...