Re: term_expansion/2 with DCG clauses

I'm still digesting the mailing list thread from the archives, but a couple
comments, below, still seem relevant:

On Wed, Aug 14, 2013 at 10:10 AM, Paulo Moura <[email protected]> wrote:

> On 14/08/2013, at 15:09, Michael Hendricks <[email protected]> wrote:
> > Is there a reason why macro expansions are not all iterated until a fixed
> > point is reached?  expand_goal/2 behaves that way and I find it quite
> > practical.  It seems to eliminate some of the problems we get from doing
> > one kind of expansion always before another.
>
> You may want or need to control which expansions are applied and the order
> they are applied ...


By tracking a little state under recursive expansion, one can control both
order and macro selection.  So the two approaches seem equivalent to me, in
this case.

Also, having any (third-party) library that you load being able to
> contribute term_expansion/2 (and goal_expansion/2) clauses to "user" and
> "system" and have them used by default can be practical but can also be a
> recipe for trouble.


It is unfortunate that the global nature of term_expansion/2 requires all
participants to play nicely together.  In my macro modules, I typically
export a "sentinel" predicate and only apply my macros to those modules
which contain my sentinel, checked via predicate_property(Sentinel,
imported_from(Me)).


> A simple example:
>
> $ swipl
> % /Users/pmoura/.plrc compiled 0.00 sec, 1 clauses
> Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version
> 6.5.1-15-g72a7b72-DIRTY)
> Copyright (c) 1990-2013 University of Amsterdam, VU Amsterdam
> SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software,
> and you are welcome to redistribute it under certain conditions.
> Please visit http://www.swi-prolog.org for details.
>
> For help, use ?- help(Topic). or ?- apropos(Word).
>
> ?- assertz(system:term_expansion(end_of_file, end_of_file)).
> true.
>
> ?- use_module(library(chr)).
> % library(chr) compiled into chr 0.49 sec, 6,527 clauses
> true.
>
> ?- ['~/Documents/Prolog/pl-devel/packages/chr/Examples/gcd.chr'].
> % /Users/pmoura/Documents/Prolog/pl-devel/packages/chr/Examples/gcd.chr
> compiled into gcd 0.00 sec, 5 clauses
> true.
>
> ?- gcd:gcd(2), gcd:gcd(3).
> ERROR: toplevel: Undefined procedure: (:)/2
> ERROR:   However, there are definitions for:
> ERROR:         (:)/2
> ERROR:  (DWIM could not correct goal)
>
> And now using a different order:
>
> pmmbp:~ pmoura$ swipl
> % /Users/pmoura/.plrc compiled 0.00 sec, 1 clauses
> Welcome to SWI-Prolog (Multi-threaded, 64 bits, Version
> 6.5.1-15-g72a7b72-DIRTY)
> Copyright (c) 1990-2013 University of Amsterdam, VU Amsterdam
> SWI-Prolog comes with ABSOLUTELY NO WARRANTY. This is free software,
> and you are welcome to redistribute it under certain conditions.
> Please visit http://www.swi-prolog.org for details.
>
> For help, use ?- help(Topic). or ?- apropos(Word).
>
> ?- use_module(library(chr)).
> % library(chr) compiled into chr 0.48 sec, 6,527 clauses
> true.
>
> ?- assertz(system:term_expansion(end_of_file, end_of_file)).
> true.
>
> ?- ['~/Documents/Prolog/pl-devel/packages/chr/Examples/gcd.chr'].
>
> ================================================================================
> CHR compiler WARNING: deprecated syntax      :-constraints gcd/1.
>     `--> Instead use :- chr_constraint gcd/1.
>     Support for deprecated syntax will be discontinued in the near future!
>
> ================================================================================
> % /Users/pmoura/Documents/Prolog/pl-devel/packages/chr/Examples/gcd.chr
> compiled into gcd 0.01 sec, 41 clauses
> true.
>
> ?- gcd:gcd(2), gcd:gcd(3).
> gcd(1)
> true .
> gcd(1)
>

Iterating to a fixed point would fix this example by making
term_expansion/2 clause order irrelevant.  The problem demonstrated above
is that a misbehaving term_expansion/2 clause can prevent all other clauses
from playing the game.  Under recursive expansion, everyone gets a turn.

Of course, with recursive expansion, a misbehaving clause can cause
infinite expansion loops.  But it's nothing new that programming systems
can be ruined by bad code.

I'm not suggesting that we change existing macro mechanisms.  Developers
expect them to behave as they do and there are compatibility concerns.
 However, it seems to me that iterating expansions until a fixed point
allows macros to operate without know how other macros will behave.  The
current arrangement reminds me of cooperative multitasking where each
process must yield to its peers.

-- 
Michael
-------------- next part --------------
HTML attachment scrubbed and removed