Afficher et demander avec show / ask

show et ask sont les primitives Touba d’interaction utilisateur.

Elles ressemblent à print et scanf, mais avec une différence importante : l’interaction passe par l’hôte et reste observable par le runtime.

show

show demande à l’hôte d’afficher un texte.

Forme :

source.tb

show
    with message as <Text expression>

Exemple :

source.tb

show
    with message as "Touba ready"

Avec une valeur primitive :

source.tb

show
    with message as "age is: " ++ text(age)

Avec le mode par défaut de touba run, ce message apparaît dans le terminal :

Sortie

Touba ready

Touba ne convertit pas automatiquement un Int, un Float ou un Boolean en texte. Utilisez text(expr) pour rendre explicitement une valeur primitive dans une chaîne. Une interpolation comme "age is: [age]" n’est pas la syntaxe documentée. Les types structurés, listes, objets runtime, secrets et mémoires ne sont pas rendus par text(expr).

Le runtime trace aussi qu’un affichage a été demandé. Le message ne doit pas contenir de valeur secrète résolue.

ask

ask demande une entrée utilisateur.

Forme :

source.tb

ask
    with prompt as <Text expression>
    into binding

Exemple :

source.tb

ask
    with prompt as "Search query?"
    into query

Dans Touba, le runtime ne lit pas automatiquement le terminal. Sur un chemin séquentiel sans entrée explicite, l'exécution se met en pause ; le cas parallèle ci-dessous exige une réponse pour chaque occurrence.

Terminal

touba run program.air.json \
  --user-inputs user-inputs.json \
  --trace-out trace.json

Le fichier user-inputs.json associe les références d’interaction aux réponses fournies par l’hôte.

Pour un essai manuel, le CLI peut demander la réponse dans le terminal avec une option explicite :

Terminal

touba run program.air.json --interactive-user-inputs

Cette option appartient au runner CLI. Elle ne change pas la sémantique du langage : l’AIR ne contient toujours pas de lecture stdin, et l’événement ask ne trace pas la valeur saisie.

Si le programme affiche cette valeur avec show, elle apparaît dans les messages utilisateur. La trace enregistre user_interaction_shown avec ses références, sans copier le texte du message.

Dans VS Code, le bouton Touba: Run Current File joue le même rôle d’hôte explicite : lorsqu’un ask est rencontré, VS Code ouvre une boîte de saisie, puis relance le run avec la réponse fournie.

show n’est pas give

show affiche un texte pendant l’exécution.

give retourne la valeur finale du chemin courant et termine ce chemin. Une instruction placée après give ou stop est refusée comme inatteignable.

Pour afficher plusieurs valeurs :

source.tb

show
    with message as "Query: " ++ query

show
    with message as "Test: " ++ test

give query ++ " / " ++ test

Il doit y avoir un seul give par chemin d’exécution. Un if/else peut avoir un give dans chaque branche si aucune instruction ne suit ce if dans la même séquence.

Pourquoi pas dans function

Une function Touba doit rester pure.

Si une valeur doit être formatée puis affichée, utilisez :

1. une function pour calculer ou formater ;
2. une skill ou une strategy pour appeler show.

source.tb

function FormatDatasetTitle
    takes title as Text
    gives Text
    do
        give "Dataset: " ++ title

skill PresentDatasetTitle
    takes title as Text
    gives Text
    do
        FormatDatasetTitle
            with title as title
            into message

        show
            with message as message

        give message

Sécurité

• L’événement ask ne trace pas la valeur exacte de réponse.
• Une valeur saisie peut devenir une sortie métier si le programme l’affiche avec show ou la retourne avec give ; contrôlez ces sorties séparément de la trace.
• show et ask ne doivent pas recevoir de valeur secrète résolue.
• Ces contrôles s’inscrivent dans une politique plus large de classification et de traitement des données sensibles.

Interactions dans un groupe parallèle

Les messages show sont conservés dans l'ordre propre à chaque branche et rendus dans l'ordre d'entrée à la jointure. Dans le serveur projet, ils sont exposés par les résultats et sessions via messages et messages_truncated, séparément de la valeur retournée par give. Les événements SSE de progression ne transportent pas ces messages bruts.

Un ask parallèle exige une réponse hôte pour sa référence d'occurrence, via userInputs dans Engine ou --user-inputs-json dans la CLI. Un hôte intégrant le runtime peut fournir un userInputProvider asynchrone. La réponse est copiée, journalisée et réutilisée à la reprise, jamais partagée avec une autre branche. Une question ask sans réponse suspend le groupe avec user_input_pending. L’hôte lit pendingInteractions (JavaScript) ou pending_interactions (Python), conserve le checkpoint parallèle et fournit une réponse par référence avec userInputs / user_inputs. La reprise conserve les branches terminées et les budgets consommés. Chaque réponse concerne une seule occurrence. Voir SDK et Validation humaine.