Implement Multiple-Choice Reading Option about iris HOT 3 OPEN

@initial-mockingbird Thanks for putting so much time into the design specification! I'll need some time to think if it's possible to come up with a simpler design 🤔

Another few points that need refinement:

1. How do you decide which value to put in [] in the prompt here?

   Are you sure? [y]/n

   If it's the default value, it doesn't have a function to print it to string. Also, not only it can be different from the value returned by the parsing function, it might be different from the first element in the NonEmpty list entirely!
2. Sometimes it's desirable to avoid the default value entirely and force users to select an option specifically.

Also, this can be done separately but I needed in the past the ability to specify several values by the multiple-choice option. Would be nice if this can be easily supported by a single representation but I also see the value in keeping the interface simple for users.

from iris.

@chshersh Thank you for taking the time to review everything so thoughtfully!

1. How do you decide which value to put in [] in the prompt here?

   Are you sure? [y]/n

The value between the [] would be the displayName from the head of the Non-Empty list (that is, the default value will always be the head of the list).

2. Sometimes it's desirable to avoid the default value entirely and force users to select an option specifically.

You are right! maybe a quick fix would be to turn the default :: a (which represents the default value that should be returned in case an empty/whitespaced string is input) field into a default :: Maybe a.

Also, this can be done separately but I needed in the past the ability to specify several values by the multiple-choice option.
Would be nice if this can be easily supported by a single representation but I also see the value in keeping the interface simple for users

Sadly, I don't really see how to incorporate this into the current proposal :( (how would the user input multiple choices?). Nevertheless, maybe a better design than the one I proposed would fall along the lines of the GHCUP TUI menu? i.e:

┌──────────────────────────────────────────────────────────────────────────────┐
│  Multiple Choice Questions?                                                  │
│       > [✔️] yay                                                             │
│       > [❌] Not this one!                                                   │
│       > [✔️] This too!                                                       │
└──────────────────────────────────────────────────────────────────────────────┘


┌──────────────────────────────────────────────────────────────────────────────┐
│  Single Choice Question with default?                                        │
│       > [✔️] yay                                                             │
│       > [❌] No Sir!                                                         │
│       > [❌]  Only one check can be marked at a time                         │
└──────────────────────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────────────────────┐
│  Single Choice Question with no default?                                     │
│       > [❌] Initially all disabled                                          │
│       > [❌] No Sir!                                                         │
│       > [❌]  Only one check can be marked at a time                         │
└──────────────────────────────────────────────────────────────────────────────┘

This means that:

• We don't need to ask for parsing functions
• We no longer need the default field.
• The multipleChoiceQuestion function always succeeds (no need to return a maybe).

Thus, the design would end up being:

-- tag in case one wants to receive multiple answes
data Mode = SingleAnswer | MultipleAnswer

data MultipleChoiceOption a = MultipleChoiceOption
    { displayName   :: ByteString  
    , initiallyActive   :: Bool -- which options should be active by default?
    , value                :: a -- no more parsing!
    }

data MultipleChoicePrompt a = MultipleChoicePrompt
    { promptMessage  :: ByteString  
    , promptOptions  :: NonEmpty (MultipleChoiceOption a) 
    , mode  :: Mode
    }

multipleChoiceQuestion
    ::  MonadIO m
    => MultipleChoicePrompt a
    -> m (NonEmpty a)

And then we can expose things like Yes/No questions, as partial application of multipleChoice:

As a final note, I think this would benefit from the ncurses library.

Caveats:

• The initiallyActive may conflict with the Mode (many initiallyActives against a SingleAnswer), in those cases, the single default value can be the first one on the list.
• I'm not really sure how portable ncurses is (does it work on every terminal? what about windows terminal?).
• Maybe multipleChoiceQuestion should also get an additional argument for aesthetic options? (Should the question be boxed? should the options have the check and cross or other characters?)

from iris.

Iris focuses only on CLI, not TUI. So TUI-inspired interfaces are out of scope for this project. And we won't benefit from ncurses either.

And then we can expose things like Yes/No questions, as partial application of multipleChoice:

I would be pretty happy to have a separate data Answer = No | Yes type and specialised functions for yes-no prompts. No need to scaffold a bigger machinery for a simple case 🙂 Especially, because I imagine, the yes/no questions would be a more common use case.

As for the design of this feature, I'm still not satisfied. But I need to think about the better design 🤔

from iris.