2015-10-14 1 views
2

J'essaie d'utiliser hint paquet de hackage pour créer un environnement simple où l'utilisateur peut émettre des lignes de code pour l'évaluation (comme dans ghci). Je m'attends à ce que certaines des lignes d'entrée soient erronées (eval mettrait fin à la session avec une erreur). Comment puis-je créer une session robuste qui ignore une entrée erronée (ou mieux: elle signale une erreur mais peut accepter une autre entrée) et conserve l'état précédemment cohérent?Est-il possible de récupérer à partir d'un eval erroné dans l'indice?

En outre, je voudrais l'utiliser dans le style do, c'est-à-dire let a = 3 car une ligne d'entrée autonome est logique. Pour clarifier les choses: Je n'ai aucun problème avec un seul eval. Ce que je voudrais faire, c'est permettre une évaluation continue même après l'échec d'une étape. Aussi je voudrais étendre progressivement une chaîne monadique (comme vous le faites dans ghci je suppose). En d'autres termes: Je veux quelque chose comme ceci, sauf que je peux évaluer 3 et ne pas arrêter à undefined avec l'erreur.

runInterpreter $ setImports [ "Prelude" ] >> eval "undefined" >> eval "3" 

Plus précisément, je voudrais quelque chose comme cela soit possible:

runInterpreter $ setImports ... >> eval' "let a = (1, 2)" -- modifying context 
           >> typeOf "b" -- error but not breaking the chain 
           >> typeOf "a" -- (Num a, Num b) => (a, b) 

Je ne m'y attendais pas à travailler ce sans détour, cela est juste pour montrer l'idée. Je voudrais fondamentalement construire un contexte (comme vous le faites dans ghci) et chaque ajout au contexte le modifierait seulement s'il n'y a pas d'échec, les échecs pourraient être consignés ou explicitement récupérés après chaque tentative de modification du contexte.

Répondre

1

Vous n'avez montré aucun code, donc je ne connais pas le problème. La façon la plus droite avant que j'utilise pointe gère les erreurs bien:

import Language.Haskell.Interpreter 
let doEval s = runInterpreter $ setImports ["Prelude"] >> eval s 

a donné lieu à la sortie bien pour moi ...

Prelude Language.Haskell.Interpreter> doEval "1 + 2" 
Right "3" 
Prelude Language.Haskell.Interpreter> doEval "1 + 'c'" 

ghc: panic! (the 'impossible' happened) 
    (GHC version 7.10.2 for x86_64-apple-darwin): 
     nameModule doEval_a43r 

... Sauf que maintenant l'impossible arrive ... c'est un bug. Notez que vous êtes censé recevoir Left someError dans des cas comme ceux-ci:

data InterpreterError 
    = UnknownError String 
    | WontCompile [GhcError] 
    | NotAllowed String 
    | GhcException String 
     -- Defined in ‘hint-0.4.2.3:Hint.Base’ 

Avez-vous regardé la liste des bogues de ghchq et/ou présenté une question?

EDIT:

Et la fonctionnalité correcte est de retour, au moins de GHC 7.10.3 64 bits sur Mac OS X avec la version 0.4.2.3 pointe. En d'autres termes, il semble que le virus soit passé de 7.10.2 à 7.10.3

La sortie est:

gauche (WontCompile [GhcError {errMsg = « : 3: 3: \ n Aucun cas de (Nb Char) résultant d'une utilisation de \ 8216+ \ 8217 \ n Dans l'expression: 1 + 'c' \ n Dans une équation pour \ 8216e_11 \ 8217: e_11 = 1 + 'c' \ n Dans le premier argument de \ 8216show_M439719814875238119360034 \ 8217, à savoir \ n \ 8216 (let e_11 = 1 + 'c' dans e_11) \ 8217" }])

Bien que l'exécution de la ligne doEvaldeux fois dans GHCi ne provoque une panique, les choses semblent fonctionner une fois dans l'inter Preter et correctement indépendamment quand compilé.

+0

J'ai modifié la question, j'espère que cela clarifie mes intentions. – jakubdaniel