Re: term_expansion/2 with DCG clauses
Paulo Moura <[email protected]>
| Newsgroups | gmane.comp.ai.prolog.swi |
|---|---|
| Message-ID | <[email protected]> |
On 13/08/2013, at 16:44, Jan Wielemaker <[email protected]> wrote: > On 08/13/2013 05:19 PM, Paulo Moura wrote: >> 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? > > Looks like it. I've forgotten the history. SWI-Prolog uses a layered > translation model, first working in the current module, then feeding the > result to the rules in user, then to the rules in system and finally to > the DCG translator. Each step may produce a term or lists of terms. If > it produces a list, the terms are handed one-by-one to the next layer. It's a sensible model. We discussed before some of its pros and cons. In abstract terms, some of the interesting design decisions are (1) where is defined the layered model, (2) if the model is fixed or just a default, and (3) how the user can define and use a different model. > This seems a logical way to access DCG expansion. The only price is that > you cannot created rules for -->/2 (nor for []/0 and ./2). Do these > systems have an agreed way to creates DCGs from expansion rules? I don't think so (Logtalk uses its own expansion mechanism and DCGs code across all supported Prolog compilers for full portability and compatibility). > I guess > Richard will know the rationale for not doing DCG after user expansion. > I can't think of one right now. > > Cheers --- Jan > > P.s. Note that having the DCG translation at the end doesn't stop > writing your own. Cheers, Paulo ----------------------------------------------------------------- Paulo Moura Logtalk developer Email: <mailto:[email protected]> Web: <http://logtalk.org/> -----------------------------------------------------------------