Note that there are some explanatory texts on larger screens.

plurals
  1. PORecursive data structures in haskell: prolog-like terms
    primarykey
    data
    text
    <p>I have a question about recursive data structures in Haskell (language that I'm currently trying to learn).</p> <p>I would like to encode in Haskell Prolog-like terms, but every solution I came up with has different drawbacks that I would really like to avoid. I would like to find a cheap and elegant way of encoding a BNF grammar in Haskell types, if you wish to see my problem from this perspective.</p> <p>Just as a reminder, some prolog terms could be <code>male</code>, <code>sum(2, 3.1, 5.1)</code>, <code>btree(btree(0, 1), Variable)</code>.</p> <h3>Solution 1</h3> <pre><code>data Term = SConst String | IConst Integer | FConst Double | Var String | Predicate {predName :: String, predArgs :: [Term]} </code></pre> <p>With this solution I can have nested predicates (since <code>predArgs</code> are <code>Term</code>), but I can't distinguish predicates from other terms in type signatures.</p> <h3>Solution 2</h3> <pre><code>data Term = SConst String | IConst Integer | FConst Double | Var String data Predicate = Predicate {predName :: String, predArgs ::[Either Term Predicate} </code></pre> <p>In this variant I can clearly distinguish predicates from basic terms, but the <code>Either</code> type in the <code>predArgs</code> list can be quite a nuisance to manage later in the code (I think... I'm new to Haskell).</p> <h3>Solution 3</h3> <pre><code>data Term = SConst String | IConst Integer | FConst Double | Var String | Struct String [Term] data Predicate = Predicate String [Term] </code></pre> <p>With this last solution, I split terms in two different types as before, but this time I avoid <code>Either Term Predicate</code> adding a <code>Struct</code> constructor in <code>Term</code> with basically the same semantics as <code>Predicate</code>.</p> <p>It's just like solution 1 with two predicate constructors for terms. One is recursion-enabled, <code>Struct</code>, and the other one, <code>Predicate</code> is to be able to distinguish between predicates and regular terms.</p> <p>The problem with this try is that <code>Struct</code> and <code>Predicate</code> are structurally equivalent and have almost the same meaning, but I will not be able to write functions that works - in example - both on <code>(Predicate "p" [])</code> and <code>(Struct "p" [])</code>.</p> <p>So again my question is: please, is there a better way to encode my predicates and terms such that:</p> <ol> <li>I'm able to distinguish between predicate and terms in type signatures;</li> <li>nested predicates like <code>p(q(1), r(q(3), q(4)))</code> are supported;</li> <li>I can write functions that will work uniformly on predicates, without any distinction like the one in solution #3?</li> </ol> <p>Please feel free to ask me for further clarifications should you need any.</p> <p>Thank you very much.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload