Haskell créant de nouvelles données

Question

{- P A R T 2 : Implementation of a parser for Łukasiewicz expressions 
--TODO Define the type LExpTree, using the constructors L, V, N, Q, S, K, A, O, E, I 
L for Lukasiewicz literals (i.e. C, I or U) 
V for Variables (string) 
N for a node representing the prefix neg 
Q for a node representing the prefix pos 
S for a node representing the prefix cer 
K for a node representing the prefix unk 
A for a node representing the infix And 
O for a node representing the infix Or 
E for a node representing the infix Equivalence 
M for a node representing the infix Implication 
It will be convenient to have the new type derive from the classes Show and Eq 
-} 
data LExpTree a = L a 
       | V [Char] 
       | N (LExpTree a) 
       | Q (LExpTree a) 
       | S (LExpTree a) 
       | K (LExpTree a) 
       | A (LExpTree a) (LExpTree a) 
       | O (LExpTree a) (LExpTree a) 
       | E (LExpTree a) (LExpTree a) 
       | M (LExpTree a) (LExpTree a) 
       deriving (Show, Eq) 

Ceci est mon projet Haskell. Je l'ai essayé pendant 4 jours. Je veux juste vérifier si mes données LExpTree sont correctes?

Je ne pense pas que ..

Après cela, je dois créer une série de parseurs comme la grammaire

Ceci est 3 d'entre eux.

{- 
lukExp :: lukOpd ('<->' lukExp | '-->' lukExp| e) 
lukVar :: lowercase (Alphanumeric)* 
lukLit :: C | I | U 
-} 
lukExp :: Parser LExpTree 
lukExp = do o <- lukOpd 
      (do { symbol "<->"; 
        e <- lukExp; 
        return (E (o <-> e)); } 
      +++ do { symbol "-->"; 
         e <- lukExp; 
         return (E (o --> e)); } 
      +++ return (E o)) 

lukVar :: Parser LExpTree 
lukVar = ident 

lukLit :: Parser LExpTree 
lukLit = do { symbol "C"; 
       return (L C); } 
     +++ do { symbol "I"; 
        return (L I); } 
     +++ do { symbol "U"; 
        return (L U); } 

Et je reçois ces erreurs.

proj.hs:131:18: 
    Expecting one more argument to `LExpTree' 
    The first argument of `Parser' should have kind `*', 
     but `LExpTree' has kind `* -> *' 
    In the type signature for `lukExp': lukExp :: Parser LExpTree 

proj.hs:184:18: 
    Expecting one more argument to `LExpTree' 
    The first argument of `Parser' should have kind `*', 
     but `LExpTree' has kind `* -> *' 
    In the type signature for `lukVar': lukVar :: Parser LExpTree 

proj.hs:187:18: 
    Expecting one more argument to `LExpTree' 
    The first argument of `Parser' should have kind `*', 
     but `LExpTree' has kind `* -> *' 
    In the type signature for `lukLit': lukLit :: Parser LExpTree 
Failed, modules loaded: Parser. 

Le projet est de créer des expressions Łukasiewicz C pour certains, U incertain et I pour impossible.

Et j'ai déjà un Parser.hs chargé et il a tous les types Parser et parse et ses fonctions associées. Je comprends que c'est un projet d'école et supposé essayer de mon mieux. J'ai encore 2 parties et c'est supposé être une partie facile.

J'apprécierais que quelqu'un puisse m'aider.

Merci.

Answer 1

Le principal problème est que le type LExpTree nécessite un paramètre de type supplémentaire pour devenir un type concret. Ceci est, je crois, est une version correcte de lukVar:

lukVar :: Parser (LExpTree a) 
lukVar = do i <- ident; return (V i) 
     -- alternatively: V <$> ident 

Notez que ceci est un analyseur syntaxique pour LExpTree a pour tout type a.

Maintenant dans lukLit vous essayez de retourner des choses comme L C. Je ne vois pas où C est défini, mais supposons que le type de C est MyLits. Puis la signature de lukLit est:

lukLit :: Parser (LExpTree MyLits) 

De toute évidence le paramètre de type a dans LExpTree a est le type des littéraux que vous souhaitez utiliser.

Notez la différence entre lukVar et lukLit - votre code pour lukVar fonctionnera avec tout type littéral où la a variable dans la signature de type. Le code pour lukLit renvoie des littéraux de MyLits et renvoie ainsi un LExpTree MyLits.

Maintenant, vous devriez pouvoir corriger lukExp. Je pense que ce sera la signature

lukExp :: Parser (LExpTree a) 

Je parie que vous pouvez simplement supprimer les signatures de type et de laisser GHC les déduire. Dans ces cas, des signatures de type incorrectes provoquent les erreurs.