How can I do this without cuts?
Robert Oschler
xmatch(X^Y^Pred).
xmatch(X^Pred).
So the first clause is intended to match terms preceded by two lambda
arguments and the second clause is intended to match terms preceded by only
one argument. This works almost exactly as I want except there still is the
potential for an unwanted match with the second predicate due to
backtracking. "X^Y^frog(X, Y)" will unify with either clause and I only
want it to unify with the first clause. I can do:
xmatch(X^Y^Pred) :- !.
xmatch(X^Pred) :- !.
but I am trying to follow the principle of "green cuts" only; those that
don't change the program logic but only trim unnecessary computations.
How can I do this without using cuts?
thx
--
Robert Oschler
Matthew Purver
by using negation to check that Pred doesn't have a lambda argument in
(i.e. can't be unified with _Arg^_NewPred)
xmatch( X^Pred ) :-
Pred \= _^_.
--
Matthew Purver - matt at purver dot org
Nick Wedd
Oschler <no_replies@fake_email_address.invalid> writes
xmatch(X^Y^Pred).
xmatch(X^Pred):-
not( Pred = _^_ ).
Nick
--
Nick Wedd ni...@maproom.co.uk
Robert Oschler
From: "Matthew Purver" <lo...@my.sig>
Newsgroups: comp.lang.prolog
Sent: Thursday, October 09, 2003 11:41 AM
Subject: Re: How can I do this without cuts?
>
> by using negation to check that Pred doesn't have a lambda argument in
> (i.e. can't be unified with _Arg^_NewPred)
>
> xmatch( X^Pred ) :-
> Pred \= _^_.
>
> --
> Matthew Purver - matt at purver dot org
Matthew,
Your use of the underscore character that surrounds the hat ("^") operator
is unfamiliar to me, and I don't seem to see an underscore ("_") operator in
the list of Win-Prolog predicates. I'm not saying it isn't there, just that
I can't see it. Can you elaborate on it?
thx
Nick Wedd
Oschler <no_replies@fake_email_address.invalid> writes
>Matthew,
>
>Your use of the underscore character that surrounds the hat ("^") operator
>is unfamiliar to me, and I don't seem to see an underscore ("_") operator in
>the list of Win-Prolog predicates. I'm not saying it isn't there, just that
>I can't see it. Can you elaborate on it?
_ is not an operator. It is a variable. In fact it is a special
variable, the "anonymous variable", which is different every time you
mention it. So
Pred \= _^_.
means the same as
Pred \= MeaninglessName ^ AnotherMeaninglessName.
You use the anonymous variable when you want to specify that there is a
variable there, but you don't care what its value is; and you want
readers of your code to know that you don't care what its value is.
Fergus Henderson
>xmatch(X^Y^Pred) :- !.
>
>xmatch(X^Pred) :- !.
...
>How can I do this without using cuts?
xmatch(Term) :-
( Term = X^Y^Pred -> true
; Term = X^Pred
).
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson
>Robert Oschler wrote:
>
>> How can I do this without using cuts?
>
>by using negation to check that Pred doesn't have a lambda argument in
>(i.e. can't be unified with _Arg^_NewPred)
>
>xmatch( X^Pred ) :-
> Pred \= _^_.
This solution is worse that the solution using if-then-else or cut,
because (on most Prolog implementations) it leaves behind unnecessary
choice points, which can prevent garbage collection and tail recursion
optimization.
Dr Andrew R. Verden
xmatch(Term) :-
once(( Term = X^Y^Pred
; Term = X^Pred
)).
is better and is equivielant to
xmatch(Term) :-
( ( Term = X^Y^Pred
; Term = X^Pred
)
-> true
).
but this is only a minor point and no doubt we can discuss all
night about program style...
Incidently, IF/Prolog is able to compile out if-then-elses in the
generation of code where many Prologs still interpret the goals
P,Q,R inside ( P -> Q ; R), first building them as structures.
You pays your money and takes your choice....
visit www.ifcomputer.de for more on IF/Prolog
Robert Oschler
news:BZzTbhNcjeh$EA...@maproom.demon.co.uk...
Nick,
I do know what the anonymous variable is, I just never saw it used that way
so I figured it was something else. That is wild and very useful, glad I
asked.
Thanks!
Robert Oschler
news:3f8661b9$1...@news.unimelb.edu.au...
Fergus,
Very interesting use of a disjunction. I wonder how hard it would be to
expand this to a variable number of preceding arguments. I use the
preceding "lambda" arguments to reference the arguments in a predicate and
make them available for unification. For example:
X^Y^frog(X, Y), or X^Y^Z^bird(X, Y, Z).
I'll have to experiment with this.
thx
Bart Demoen
> Incidently, IF/Prolog is able to compile out if-then-elses in the
> generation of code where many Prologs still interpret the goals
> P,Q,R inside ( P -> Q ; R), first building them as structures.
>
> You pays your money and takes your choice....
>
> visit www.ifcomputer.de for more on IF/Prolog
I think you are extremely unfair - at the edge of lying - or else you
have no clue about what is current practice in Prolog implementation (*):
can you please name the (commercial) Prolog implementations that do
NOT "compile out' the if, the then and the else of a -> ; ?
Or else just shut up ?
I know for sure that SICStus Prolog does not interpret ,Q,R inside ( P -> Q ; R),
and neither does MasterProlog (formerly BIM-Prolog and compiling such
P,Q and R since 1985 - I implemented it myself), and neither does BinProlog.
Even most non-commercial Prolog systems do NOT interprete P,Q and R:
XSB, SWI, GNU, Yap - you name it, they don't interprete those goals in an
if-then-else.
So, will you tell us you were wrong, or will you tell us about these oodles of
implementations that you know about who get if-then-else wrong ?
I will definitely take silence as admitting that you were wrong here.
And I hope other readers of comp.lang.prolog will do the same.
Bart Demoen
(*) does your employer know you send such messages to comp.lang.prolog ?
he should be informed about your incompetence 1
Fergus Henderson
>"Fergus Henderson" <f...@cs.mu.oz.au> wrote:
>> "Robert Oschler" <no_replies@fake_email_address.invalid> writes:
>>
>> >xmatch(X^Y^Pred) :- !.
>> >
>> >xmatch(X^Pred) :- !.
>> ...
>> >How can I do this without using cuts?
>>
>> xmatch(Term) :-
>> ( Term = X^Y^Pred -> true
>> ; Term = X^Pred
>> ).
>
Actually there's no disjunction in that code, just an if-then-else.
In Prolog the syntax for if-then-else and disjunction are confusingly
similar, since they both use infix ';', but they are really quite
separate constructs: if the first operand of the ';'/2 term
is an '->'/2 term, then it's an if-then-else, not a disjunction.
Robert Oschler
>
> Actually there's no disjunction in that code, just an if-then-else.
>
> In Prolog the syntax for if-then-else and disjunction are confusingly
> similar, since they both use infix ';', but they are really quite
> separate constructs: if the first operand of the ';'/2 term
> is an '->'/2 term, then it's an if-then-else, not a disjunction.
>
> --
> Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the
pursuit
> The University of Melbourne | of excellence is a lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Thanks Fergus, that's a good clarification.
Nick Wedd
<b...@cs.kuleuven.ac.be> writes
>"Dr Andrew R. Verden" wrote:
>
>> Incidently, IF/Prolog is able to compile out if-then-elses in the
>> generation of code where many Prologs still interpret the goals
>> P,Q,R inside ( P -> Q ; R), first building them as structures.
>>
>> You pays your money and takes your choice....
>>
>> visit www.ifcomputer.de for more on IF/Prolog
>
>I think you are extremely unfair - at the edge of lying - or else you
>have no clue about what is current practice in Prolog implementation (*):
I would bet on the latter. Does he understand the difference between a
compiler and an interpreter?
Dr Andrew R. Verden
What started out as a positive suggestion as to how you might improve
your
coding using a once/1 instead of an if-the-else has been blown up into
something else. I suggest you both take a cold shower before clicking
that send
button.
I would be interested to known what for example LPA Prolog, PDC and
Amzi do
in this case. IF/Prolog goes further than most commercial Prologs.
Especially
in terms of development environments, commercial integration with
other
systems such as VC++, ODBC, Java ... I only illustrated the plus sides
or
our system, did not say that other Prologs dont implement it also.
It is true that I personnally moved away from Prolog implementation in
1992 to work more in application development, constraints and OR where
we have focused on developing successful applications making use of
this technology rather than
just the so called Prolog advantages alone. Compiler writers are a
dying breed,
what are the major improvements in Prolog compilation that have been
achieved
in the last 10 years? I would be interested to know, assuming you are
capable
of answering in a positive sense.
I was though back then involved in the ISO standardisation and then
was somewhat frustrated that ( P -> Q ) fails if P fails, as a
readable semantic
it would be better if ( P -> Q ) succeeded if P succeeds. Now our own
code is
littered with ( P-> Q ; true) and it is very easy to forget the ; true
)
At IF Computer we concentrate heavily on code quality with Prolog and
have
several applications exceeding 20 000 lines of Prolog and an equal
amount of VC++ or Java then it certainly matters that modules and
integration work; rather than super-fast performance at the price of
stability and portability. We use object oriented specification
through Rational Rose and have to work hard using Prolog to get the
advantages object oriented programming as well.
But we have a working framework using modules and preprocessors.
Prolog offers algorithmic advantages and modelling advantages but
requires very highly qualified developers, it has and never will hit
main stream as it is only advantageous for special applications and
yet a programming language must compete as a programming language in
the main stream where decisions are based more on whether code will be
supportable in the future than whether an extra module must be
implemented or not.
Leave the acid out of the next reply.
Andrew Verden
Dr Andrew R. Verden
Your tone Bart Demoen is not appropriate for this board, and
clearly illustrates how little you know about commercial use
of Prolog and who is involved with it.
I suggest you concentrate on finding the best way to garbage
collect structures with clauses, stay in your little Belgium
ivory tower and answer questions from students.
Leave the professional use of Prolog to those you have strung more
than 1000 lines of code together.
Andrew Verden
vann...@let.rug.nl
> Your tone Bart Demoen is not appropriate for this board, and
> clearly illustrates how little you know about commercial use
> of Prolog and who is involved with it.
It would be more helpful and convincing if you answer the question.
earlier you wrote:
> Incidently, IF/Prolog is able to compile out if-then-elses in the
> generation of code where many Prologs still interpret the goals
> P,Q,R inside ( P -> Q ; R), first building them as structures.
We simply like to know which Prologs you were referring to here. If you
don't name any, then apparantly Nick and Bart were right in calling you
'extremely unfair'.
Gj
--
Gertjan van Noord Alfa-informatica, RUG, Postbus 716, 9700 AS Groningen
vannoord at let dot rug dot nl http://www.let.rug.nl/~vannoord
Bart Demoen
> What started out as a positive suggestion as to how you might improve
> your
> coding using a once/1 instead of an if-the-else has been blown up into
> something else. I suggest you both take a cold shower before clicking
> that send
> button.
(I will first answer this contribution by Dr A.R.V. and get to his later reply some other time)
In the above description of chain of events, you have missed one I consider
important. Let me give you my view:
What started out as a positive suggestion .... has been turned at some
point by DR. A.R.V. into unjustified bashing other Prolog systems and an
sloganesk advertisment for IF/Prolog.
Now, just to make sure: I have a respect for IF Computer as a company, and
also for the product IF/Prolog it distributes. I have consequentely not meant to make
any negative comment about the company, neither its products. If anything I wrote
was taken as such, I herewith apologize for that and stress once more that it was not
meant that way.
> I would be interested to known what for example LPA Prolog, PDC and
> Amzi do in this case.
So would I.
> IF/Prolog goes further than most commercial Prologs.
[and then rambling about development environments etc starts and go on and on]
All this is beside the point: nobody attacked your Prolog system, nobody claimed
it did not do the right thing for if-then-else, nobody said that your Prolog system
lacks certain features.
I have no problem with you sending a commercial ad to comp.lang.prolog. But as reply to the
current discussion "do other commercial Prolog systems treat if-then-else interpreted
or not ?" it bears no relevance.
> what are the major improvements in Prolog compilation that have been
> achieved in the last 10 years? I would be interested to know, assuming you are
> capable of answering in a positive sense.
I am not sure there were major improvements in Prolog compilation in the last
10 years - others might disagree. Within Prolog we have seen better understanding of
tradeoffs and of integration with other computational models (tabling, constraints,
bottom up compution to a smaller extent).
Looking a bit further than Prolog - but staying in Logic Programming - I would argue
that the Mercury experience is a major improvement in the field. A big part of it is about
compiler technology.
> Leave the acid out of the next reply.
Hm ... you didn't quite follow that suggestion yourself, did you :-)
Cheers
Bart Demoen
no-spam
In many cases, an alternative to using cut is to choose a ground
representation that anticipates the distinctions you wish to make.
For example, I might do something like this:
source language -> ground representation
-----------------------------------------------------------------
f(U,V^g(U,V) -> eval(f,[x(u),lambda(x(v),eval(g,[x(u),x(v)]))])
-----------------------------------------------------------------
U^V^g(W) -> lambda(x(u),lambda(x(v),eval(g,[x(w)])))
-----------------------------------------------------------------
I could then write
*/
match_eval(eval(T,EXPRS)) :-
atom(T),
match_exprs(EXPRS).
match_lambda(lambda(x(T),EXPR)) :-
atom(T),
match_expr(EXPR).
match_expr(x(T)) :-
atom(T).
match_expr(i(T)) :-
integer(T).
match_expr(eval(T,EXPRS)) :-
atom(T), % i.e., alphanumeric constant
match_exprs(EXPRS).
match_expr(lambda(x(T),EXPR)) :-
atom(T),
match_expr(EXPR).
match_exprs([]).
match_exprs([EXPR|EXPRS]) :-
match_expr(EXPR),
match_exprs(EXPRS).
test(eval(f,[x(u),lambda(x(v),eval(g,[x(u),x(v)]))])).
test(lambda(x(u),lambda(x(v),eval(g,[x(w)])))).
/*
with some assurance that neither 'match_eval/1' nor 'match_lambda/1'
would succeed more than once any time it was called.
Of course, this approach requires a tokenizer and a parser to convert
source language into ground representation, but that is a small price to
pay for the peace of mind it buys, I would say.
Fergus Henderson
>Compiler writers are a dying breed,
Do you have any evidence for that contention?
I don't see any sign that compiler writers are a dying breed. There seem
to be plenty of compiler writer jobs available at <www.compilerjobs.com>,
for example. Conferences such as CC (the International Conference on
Compiler Construction) and PLDI are still going strong.
Zoltan Somogyi
Fergus Henderson <fjh@AUTO> writes:
>I don't see any sign that compiler writers are a dying breed.
I don't think compiler writers are a dying breed, but I can see how people
can jump to that conclusion. I don't think the number of compiler writers
today is more than double or triple the number of compiler writers twenty
years ago, but in that time the number of programmers has probably increased
twenty- or thirty-fold. Those numbers are just guesstimates, but I have no
doubt that if you walked up to a randomly selected programmer and asked him
or her whether they wrote compilers, the probability of getting "yes" as
the answer was much higher twenty years ago than today. Certainly, if you
went to the computer section of a bookstore, the fraction of books related
to compilers was much higher then than now.
On top of that, I would not be surprised to find that there *are* fewer
people writing compilers for logic programming languages now than in the
mid to late eighties.
Zoltan Somogyi <z...@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne
Dr Andrew R. Verden
> I am not sure there were major improvements in Prolog compilation in the last
> 10 years - others might disagree. Within Prolog we have seen better understanding of
> tradeoffs and of integration with other computational models (tabling, constraints,
> bottom up compution to a smaller extent).
> Looking a bit further than Prolog - but staying in Logic Programming - I would argue
> that the Mercury experience is a major improvement in the field. A big part of it is about
> compiler technology.
I wish I had more time to look more into Mercury and Oz. Back in the
early 1990s we looked at the commercial viability of Gödel but trends
were and
have moved very much away from languages.
What is more important from an industry sense is the integration of
your
Prolog part-application into the application as a whole. If this goes
smoothly
then we can use Prolog in industry. In my opinion this is what makes a
good commercial Prolog system, and need I say it, where IF/Prolog is
strong.
I guess Prolog usage has dispersed into the application areas,
scheduling, rule-based systems, A.I.?, XML parsing, to name just a
few. Would it not be sensible
for us as a Prolog community to try to branch out and attach "Logic
Programming"
or "Constraint Programming" streams to the larger scheduling or XML
conferences rather than continue the "Logic Programming" conference
and hope for an industry paper stream? Assuming you are interested in
industrial usage of logic
programming.
> > Leave the acid out of the next reply.
>
> Hm ... you didn't quite follow that suggestion yourself, did you :-)
>
Nope, I generally give as good as I get. :-)
Cheers
Andrew
Bart Demoen
> > > Leave the acid out of the next reply.
> >
> > Hm ... you didn't quite follow that suggestion yourself, did you :-)
> >
>
> Nope, I generally give as good as I get. :-)
Oh, but you did much better: you tried to ridicule my research,
my home country and the size of my Prolog programs. I can't
match that.
Also, you (or someone else using your name) have privately threatened
me that you would let your lawyer lose on me if I would "humiliate"
you again "publicly". (if it was not you who send that e-mail, please
say so; I am still leaving open the possibility)
It is clear to me: you are much better at this game than I am.
I know that my temper runs high when I see public statements with
highly questionable contents from Prolog vendors, and since you
feel so vexed by the tone of my contribution that you feel I owe you
an apology (which you suggested privately), let's put that behind us:
I apologize for having suggested that you shut up: comp.lang.prolog
is an open forum and people should feel free to say what they want.
I apologize for having suggested that you kept something hidden from
your employers: the remark was off topic and your employers might
indeed be very well aware of your actions and capabilities.
But all this hanky-panky is drawing away the attention from the essence of
the discussion with you, which I assume has now come to an end because
you only wrote:
> I would be interested to known what for example LPA Prolog, PDC and
> Amzi do in this case.
Bart Demoen
marat
Sorry, that should have been
source language -> ground representation
-----------------------------------------------------------------
f(U,V^g(U,V)) -> eval(f,[x(u),lambda(x(v),eval(g,[x(u),x(v)]))])
-----------------------------------------------------------------
U^V^g(W) -> lambda(x(u),lambda(x(v),eval(g,[x(w)])))
-----------------------------------------------------------------
i.e.,
!expr -> x(!ident)
!expr -> i(!integer)
!expr -> eval(!ident,!exprs)
!expr -> lambda(!var,!expr)
!exprs -> []
!exprs -> [!expr|!exprs]
!var -> x(!ident)
!ident -> $ident % assumed to be predefined typespec
!integer -> $integer % assumed to be predefined typespec
--
Dr Andrew R. Verden
> me that you would let your lawyer lose on me if I would "humiliate"
> you again "publicly". (if it was not you who send that e-mail, please
> say so; I am still leaving open the possibility)
>
> It is clear to me: you are much better at this game than I am.
>
> I know that my temper runs high when I see public statements with
> highly questionable contents from Prolog vendors, and since you
> feel so vexed by the tone of my contribution that you feel I owe you
> an apology (which you suggested privately), let's put that behind us:
>
> I apologize for having suggested that you shut up: comp.lang.prolog
> is an open forum and people should feel free to say what they want.
>
You can be 100% certain that I sent the email. I am the only person in
Germany with the name "Andrew Verden", and you are right I am much
better
at this game than you are. :-)
People should be free to say what they want, I agree, but when the
chairman of ICLP 04 tells the CEO of IF Computer Germany (as far as I
know the only company to sponsor ICLP 02) to "shut up" then an apology
is the very least to expect.
What disappoints me most is how unprofessional your reaction was, how
negative
it is to immediately shoot down any comments from a "board stranger".
And
as to the side-kick "Nick", well he is as he says he is on his web
site.
As to the discussion, this ended as we both agreed that compiler
technology
for Prolog at least reached a plateau in the early 90s and that the
last 10 years has not seen much new. I agree that there are still
compiler jobs around but 4GLs and Java compilers are not really what
most Prolog engineers are interested in?
We are starting to see an increase in the use of tools like Rational
which
generate Java code, or at least a class hierarchy. These are
interesting areas where compiler technology: code transformation,
debugging and quality / style control offer opportunities for compiler
implementation languages like Prolog.
But compilers are also something I gave up 10 years ago was just
interested to see if I missed anything.
> > I would be interested to known what for example LPA Prolog, PDC and
> > Amzi do in this case.
I expect they will hope that this sentence will just go away! :-)
Andrew Verden
Fergus Henderson
>People should be free to say what they want, I agree, but when the
>chairman of ICLP 04 tells the CEO of IF Computer Germany (as far as I
>know the only company to sponsor ICLP 02) to "shut up" then an apology
>is the very least to expect.
Corporate sponsorship of academic conferences does NOT mean buying
the silence of the academics involved. Academics who see corporate
representives making false or misleading claims with regard to their
products (or their relationship with competing products) have not just
a right but a _duty_ to inform the public.
Bart didn't tell you to shut up, he told you to put up or shut up.
That's a completely different thing, and IMHO needs absolutely no apology.
However, I do think Bart overstepped the mark a little in referring to
your "incompetence". Regardless of whether it was or was not true,
that was an unnecessary ad hominem remark, and only served to inflame
the debate.
>What disappoints me most is how unprofessional your reaction was, how
>negative it is to immediately shoot down any comments from a "board stranger".
There is a fundamental difference between comments from some random stranger
and misleading remarks which are clearly intended to push a particular
commercial product.
At least in Australia, making false or misleading representations in order
to market a commercial product is illegal -- it is an offence under the
Trade Practices Act. I imagine it is probably also illegal in Germany.
So you should not be suprised if the reaction to such comments is different
than the reaction to ordinary posters if they make incorrect claims.
>And as to the side-kick "Nick", well he is as he says he is on his
>web site.
This seems to be some sort of thinly veiled ad hominem attack.
But I've had a look at his web site, and I find it hard to imagine
what you are getting at. Are you referring to his statement
"I am a freelance programmer."??
Describing Nick Wedd as Bart's "side-kick" is a rather grand leap.
As far as I know, they have no connection other than both being posters
to comp.lang.prolog. I would not be at all suprised if either or both
of them took offence at this remark. I suggest you retract it.
Dr Andrew R. Verden
any further, regardless of the details or who was right or wrong.
Back to the original question, we were not able to do this without any
cuts but there were also no lasting bruises.
Andrew Verden
billh
Building on Nick's insight, you might consider doing something like
matcher(P,term([],P)) :-
P \= _^_.
matcher(X^P,term([X|Vars],Q)) :-
matcher(P,term(Vars,Q)).
if that would simplify things:
| ?- matcher(frog(X,Y),TERM).
TERM = term([],frog(X,Y))
| ?- matcher(X^frog(X,Y),TERM).
TERM = term([X],frog(X,Y))
| ?- matcher(X^Y^frog(X,Y),TERM).
TERM = term([X,Y],frog(X,Y))
It should perhaps also be pointed out that
( P -> Q ; R )
involves an implicit cut in the sense that here P is simply
not allowed to succeed more than once.
<aside>
Although the principle of minimum prejudice as applied to language
design -- according to which the reader of a text must be free to
construe everything in it as narrowly as possible without thereby being
"led into error" -- would seem to me to dictate that the
jurisdiction of the cut in
( P, !, Q ; R )
should be limited to the parentheses between which it occurs,
The Founding Fathers of Prolog apparently decided early on that it
should drill right into the rule in which it occurs (so to speak).
If so, I think they might have got it wrong.
I do not know the exact historical details but I imagine their
reasoning went something like this:
"Consider the following situation
r(...) :-
( P , !, Q )
r(...) :-
... .
"/If/ we want propositions of the form
( P1, P2 , ..., Pn )
always to be equivalent to
P1, P2, ..., Pn.
then we /must/ treat the above clauses for r(....) as being equivalent to
r(...) :-
P , !, Q.
r(...) :-
in which case a cut between parentheses drills right into the rule."
I can't disagree with that but the question then becomes /should/ we
want propositions of the form
( P1, P2 , ..., Pn )
always to be equivalent to
P1, P2, ..., P
-- and I think the answer is "no".
I would argue that in general the presence or absence of a pair of
parentheses (or brackets or braces, etc) should signify a corresponding
semantic difference --.or a syntax error -- and I would therefore argue
that in this particular instance the jurisdiction of a cut that occurs
between parentheses /should/ be limited to the parenthese between which
it occurs, and that
( P1, P2 , ..., Pn )
/should/ be distinguished from
P1, P2, ..., P
for that express purpose..
For one thing, this would allow /any/ "in-line predicate" of the form
( P1 ; P2 ; ... ; Pn )
to be replaced by a call of the form
newpred( Vars )
where Vars represents the "free" variables that occur in
any of the Pj, and newpred is a newly-coined predicate name, with
corresponfomg rules
newpred( Vars ) :- P1.
newpred( Vars ) :- P2.
...
newpred( Vars ) :- Pn.
-- completely in accord with intuition
For another, it would allow
( P -> Q ; R )
to be defined as
( P, !, Q ; R )
It is easy to remember and to understand a rule like "parantheses
/delimit/ the jurisdiction of cuts" because it is easy to see why that
should be so; it is a nontrivial PITA to have to memorize a contrived
and largely fortuitous rule of thumb such as "letters block cuts:the
control structures which are transparent to cuts have no letters in
their names [a]" (let alone understand it) because the underlying
language definition that gives rise to it is counter-intuitive.
On the other hand, I must admit that even I find the possibility of
using an inline predicate as simple as
( I_want_a_cut_here = yes -> ! ; true )
in a metacircular Prolog interpreter to effectively smuggle the host
language cut into the language being interpeted -- by itself a
positively brilliant idea -- which the present understanding extends to
cuts that occur between parentheses to be /extremely/ seductive.
[a] R. O'Keefe, /Craft of Prolog/, Section 7.6, "Conditional Cuts".
-----*-----
Exhibits:
p :-
( r(X) ->
write('rule p1 succeeded with X='),write(X),nl
;
write('try next rule'),nl
).
p :-
write('rule p2 succeeded'),nl.
q :-
( r(X), !,
write('rule q1 succeeded with X='),write(X),nl
;
write('try next rule'),nl
).
q :-
write('rule q2 succeeded'),nl.
r(r1).
r(r2).
r(r3).
cut_if(X) :-
( X = cut -> !, write('rule 1 cut'),nl
;
write('rule 1 succeeded with X='),write(X),nl
).
cut_if(X) :-
write('rule 2 succeeded with X='),write(X),nl.
</aside>