DCGs with single-sided unification?

[jan]

@peter.ludemann

However, single-sided unification allows “guards” to the left of the => , and I’m wondering how to represent guards with DCGs. (We can’t put them as-is on the left of the ==> (the way => does guard notation) because that syntax is already used for pushback lists or right-hand context .)
Any suggestions? Maybe something like this:

first_n_rev(0) ==> [].
first_n_rev(N), ?{N>0} ==> % N>0 is a guard
    [N],
    {N1 is N-1},
    first_n_rev(N1).

I’m reconsidering this. I’m working on code where both SSU and DCGs are quite useful. This uses DCGs in generative mode, i.e., producing a list rather than consuming one.

For the pushback list we have no ambiguity as far as I can tell, as this must be a list and, although lists are a goal (hence ?- [file]. works), DCGs already interpret them differently. We do have various problems though. For example, when parsing we might want to write e.g.

 ast(Statement), keyword(while) ==> ...

where keyword(while) is interpreted as a non-terminal. While generating we’d like to write

ast(while(Cond, Action)), atom(Cond) ==> ...

where Cond is a guard on the term. We can solve this ambiguity using {}, as in

ast(while(Cond, Action)), {atom(Cond)} ==> ...

Now we interpret the rule as “PlainHead, DCGBody1 ==> DCGBody2.” This makes sense. Now we have a problem with lists that may either be a pushback list or a normal DCG terminal

I see the point for SSU generative DCG rules: they allow for simple code acting on an input term that may contain variables anywhere and as a bonus you get a precise error if you forgot a rule for a specific input rather than getting a silent failure. That is what I need

I do not yet see the point for parsing rules. It merely forces you to leave the head variables unbound and bind them in the body. It also replaces the cut with ==>, which seems a good idea because I have the impression people tend to place => correctly while many people are struggling with placing the cut in the right place. Unifying the output variable in the body is, considering steadfastness. a good idea. It is IMO a step back when considering readability though.

Do I miss advantages using SSU for parsing? If SSU DCGs have no value for parsing we can tailor the choices we need to make on generative DCGs.

P.s. I’ve pushed a patch that stops the DCG compiler moving unifications resulting from a literal as first element in the DCG body into the head. Since the compiler moves these unifications we no longer need to do so in the DCG compiler. This should make it easy to layer an SSU DCG on top of dcg_translate_rule/2.