Re: goal_expansion

On 02/10/2014 05:38 PM, Jonathon Doran wrote:
> My thanks to everyone for your comments.  I was overthinking things.  I
> messed
> around with goal_expansion and have something I like:
>
> goal_expansion(optional_param(Tag:Value, Parameters, Generator), Y) :-
>      Y = (
>              member(Tag:Value, Parameters) ->
>                  true
>              ;
>                  Generator
>      ).
>
> It is possible that one or more of the list members find this offensive.

Offensive code is MUCH worse :-)

> It is hard not to fall back upon old habits when one doesn't know better.
> But I find it much easier to read/write
>     optional_param(color:Color, Parameter_List,
>        (
>           random_color(Color)
>        )),
>
> than to have the full expansion appear in the source.
>
> This saves me from duplicating a couple of hundred predicates, and makes
> some upcoming tasks a lot easier.

There is little wrong with this usage, although I wonder why you are not
using a nice meta predicate:

:- meta_predicate
	optional_param(+,+,0).

optional_param(Tag:Value, Parameters, _Generator) :-
	memberchk(Tag:Parameters), !.
optional_param(_, _, Generator) :-
	call(Generator).

This is a little slower if Generator is known as your version will not 
do meta-calling in that case.  It is also incorrect because a ! in
Generator will cut the whole predicate if Generator is known at
compile time and be local to Generator if this results in a meta
call.

	Cheers --- Jan

P.s.	At some time, I'd like to see :- inline optional_param/3.
	ECLiPSe already has that (don't know if it deals with the
	above).

>
> Quoting Jan Wielemaker <[email protected]>:
>
>> On 02/10/2014 04:19 PM, Carlo Capelli wrote:
>>> Hi Jonathon
>>>
>>>  From my self-learner experience (mainly
>>> lifter<https://github.com/CapelliC/prolog-snippets/blob/master/lifter.pl>)
>>>
>>> I have an hint - maybe useful only if you use XPCE IDE - or anything
>>> similar...
>>> I think you'll need to place near bottom of source a condition
>>>
>>> :- multifile user:goal_expansion/2.
>>> user:goal_expansion(X, Y) :-
>>>     \+ current_prolog_flag(xref, true),
>>>     ... your_code
>>>
>>> Indeed, I experienced IDE freezing with a 'cross-referencing buffers'
>>> message before I discovered that trick - in library(clpfd), if I recall
>>> rightly.
>>
>> For simple cases this is typically not needed, but some of these
>> goal expansion rules either have side effects (dubious) or are
>> anticipate a particular structure of the source being processed.
>> The IDE will call these things in a rather arbitrary order and
>> assume they are pure relations without side effects.  If that
>> is not the case, you need this extra condition.
>>
>>     Cheers --- Jan
>>
>> P.s.    It seems though that Jonathon wants to rewrite source
>>     files.  If this is the case, goal_expansion/2 is not
>>     for you.  It is there, such that you can write human
>>     readable code that actually needs to be something hard
>>     to read and write.  To me, that is the opposite, but
>>     perhaps I didn't understand the OP.
>>
>>>
>>> bye Carlo
>>>
>>>
>>>
>>> 2014-02-09 1:46 GMT+01:00 Jonathon Doran <[email protected]>:
>>>
>>>> I would very much like to see a simple example of the use of
>>>> goal_expansion.
>>>>
>>>> I have a large program, and I would like to make a series of
>>>> changes.  I
>>>> see that I am following the same pattern each time, and if I were
>>>> writing
>>>> in another language I would consider creating a macro.
>>>>
>>>> This may be the wrong technique to use in Prolog, but I'm curious if it
>>>> would be possible.
>>>>
>>>> For example:  A list is passed to a predicate, and the list is
>>>> checked for
>>>> an optional member (may or may not be there).  If the member is in the
>>>> list, we use it.  If not, a default value is used.
>>>>
>>>> Writing the code by hand I might do:
>>>>
>>>>     (
>>>>        \+ member(color:Color, List) ->
>>>>               random_color(Color)
>>>>         ;
>>>>               true
>>>>     ),
>>>>
>>>>
>>>> I am wondering if I can clean that up to something more readable via
>>>> goal expansion.
>>>>
>>>> (This may be a dumb way to go about things, but I would rather not
>>>> rewrite
>>>>   a huge chunk of existing code)
>>>>
>>>> Thanks,
>>>> Jonathon Doran
>>>> _______________________________________________
>>>> SWI-Prolog mailing list
>>>> [email protected]
>>>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>>>
>>> -------------- next part --------------
>>> HTML attachment scrubbed and removed
>>> _______________________________________________
>>> SWI-Prolog mailing list
>>> [email protected]
>>> https://lists.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog
>>>
>>
>>
>