iamfromspace / haskell-spanish-conjugation Goto Github PK

Better to associate meaning to the words, rather than it just be a text exercise.

The core/nucleus can have 'h's between semi-vowels, that have absolutely no impact on the mechanics of the core/nucleus--just the spelling.

The only way to know if we should add a 'h' to the spelling, is of course to parse it and store it in the Core, which complicates an already complicated structure. Probably each semi-vowel needs to be a Maybe (HighVowel, Bool) where the Bool represents if an 'h' exists.

This also complicates the parser, as H will be valid in both the Core and a consonant cluster.

Unit testing was a must before this, and a bunch of other words should be added to verify this behavior.

This is troublesome, because it complicates rules for Onsets. Onset didn't allow a double "ll" to force the two 'l's to split between the Coda + Onset, which eliminated a bunch of illegal clusters with a bunch of random "ll"s all over the place. This will need some thinking on a good solve that doesn't shake everything up (like re-defining Onset would).

Each time a new deck is built, all previous data about usage is lost, which is a bummer. If instead cards were update and only insert if new, that would save usage data.

Only a very small subset of strings are valid Spanish words, so very few will be worth our time to test. Instead, we should be generating strings that are likely to be parse-able, while still making sure that parse-able words are a subset of our generated words (every parse-able word could be generated).

Vowels can repeat indefinitely, including accents and ü (though the latter should often fail to parse). While consonant groups could never be longer than 4 characters in the middle of a word, and no longer than two at the beginning or the end. Something like /consonant{0,2}(vowel+consonant{1,4})*consonant{0,2}/ as a pseudo regex, should be a super set of parse-able words without too much waste.

The positive and negative Tu can be different, which is useful to learn. New images would be needed.

These were less practically useful when implemented in the JS version, but should be done eventually none the less.

By making random strings for the property testing, many will be invalid. Currently for those, they're just counted as passes, but that means that the property is considered a pass without probably every hitting any valid parses.

QuickCheck has the (==>) operator, which means discard the following property if the previous predicate is false. This would help QuickCheck ignore results that aren't actually meaningful.