Re: term_expansion/2 with DCG clauses

Paulo Moura <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
Hi Jan,

Sorry to somehow hijack the thread but...

On 13/08/2013, at 15:12, Jan Wielemaker <[email protected]> wrote:

> It is still not very clear what you want.  If you want to
> produce DCG's from term-expansion, this is just fine.  DCG
> expansion is done automatically if term-expansion produces
> (Head --> Body) terms.

... the above behavior come as a surprise to me. A simple example:

$ swipl
...
?- assertz(term_expansion(a(X), (X --> []))).
true.

?- expand_term(a(z), T).
T = (z(_G2260, _G2260):-true).

I would expect T = (z-->[]). GNU Prolog, XSB, YAP, Logtalk all produce T = (z-->[]). The Quintus Prolog 3.5 manual states (pp 1315) that:

"expand_term/2 calls term_expansion/2 first; if it succeeds, the standard grammar rule expansion is not tried."

Is SWI-Prolog the only one deviating from the original Quintus definition?

Cheers,

Paulo


> Maybe your use of =.. explains some of the misconceptions.
> Just write
> 
> user:term_expansion((abnf(Atom) :- _), DCGS) :-
> 	...
> 
> And you create your DCG simply using (Head --> Body).  Note
> the additional (), wich you need to put these beasts in a
> normal Prolog argument.
> 
> Of course, this is really ugly.  Since we have quasy quotations,
> you can make your source
> 
> {|abnf||
> repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)
> |}.
> 
> See http://www.swi-prolog.org/pldoc/man?section=quasiquotations
> 
> This would be cool to have.  Be aware it is not always simple.
> Some DCGs are left-recursive and will loop.  Others are for various
> reasons very poorly structured for naive translation info DCGs.  There
> are ways to fix this automatically ...
> 
> 	Cheers --- Jan
> 
> 
> 
> On 08/13/2013 03:49 PM, Wouter Beek wrote:
>> Hi Feliks,
>> 
>> My specific use case is that I want to generate DCGs based on ABNF (a
>> variant of BNF). Most RFC standards define their syntax in ABNF and
>> having them converted into DCGs seems convenient.
>> 
>> Here is my use of term_expansion/2. The conversion from ABNF to DCGs
>> is done in rule//1.
>> ~~~{.pl}
>> system:term_expansion(ABNF, DCGs):-
>>   ABNF =.. [:-,abnf(Atom),_],
>>   atom_codes(Atom, Codes),
>>   once(phrase(rule(DCGs), Codes)),
>> abnf('repeat         =  1*DIGIT / (*DIGIT "*" *DIGIT)'):- true.
>> ~~~
>> 
>> ---
>> Cheers!,
>> Wouter.
>> 
>> E-mail: [email protected]
>> WWW: www.wouterbeek.com
>> Tel.: 0647674624
>> 
>> 
>> On Tue, Aug 13, 2013 at 3:15 PM, Feliks Kluzniak
>> <[email protected]> wrote:
>>> Hi,
>>> 
>>> I find your question hard to understand.  Could you please give an example of what it is that you are after?
>>> 
>>> Thanks,
>>> -- Feliks
>>> 
>>> On Aug 13, 2013, at 14:02, Wouter Beek <[email protected]> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> What would be the recommended way for replacing regular Prolog
>>>> predicates with DCG rules? I would be nice if I could use the
>>>> syntactic sugar / `-->`-notation in formulating the replacing rules.
>>>> 
>>>> I was thinking of using term_expansion/2, but `ResultTerm =..
>>>> [-->,Head,Body]` would not be correct since `-->` is not the name of
>>>> the predicate.
>>>> 
>>>> ---
>>>> Cheers!,
>>>> Wouter.
>>>> 
>>>> E-mail: [email protected]
>>>> WWW: www.wouterbeek.com
>>>> Tel.: 0647674624
>>>> _______________________________________________
>>>> SWI-Prolog mailing list
>>>> [email protected]
>>>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>> 
>>> 
>> _______________________________________________
>> SWI-Prolog mailing list
>> [email protected]
>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>> 
> 
> _______________________________________________
> SWI-Prolog mailing list
> [email protected]
> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

-----------------------------------------------------------------
Paulo Moura
Logtalk developer

Email: <mailto:[email protected]>
Web:   <http://logtalk.org/>
-----------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.