Inconsistent behaviour of assert/2

[Günter Kniesel]

Dear all,

my students were confused by the following, arguably undesired behaviour
of assert/2. Expecting that assert mirrors clause(Head,Body) they
tried to use it as assert(Head,Body) and where surprised to get
the following:

17 ?- assert(a,b).
false.

18 ?- listing(a).
:- dynamic user:a/0.

user:a.

true.

The above behaviour (claiming assertion failed but nevertheless asserting
the clause) is highly confusing.

I would suggest that the implementation of assert/2 should be
changed so that if the second argument (the clause reference)
is not a free variable, then the assertion is not performed.

However, that would only partly remove the cause of the confusion,
which, in the first place, is the non-uniform semantics of the
arguments to assert and clause. So I'm curious to know why
there isn't an assert(Head,Body) that mirrors clause(Head,Body)?

Why does "clause" hide the nature of clauses as :-/2 terms whereas
"assert" cannot even be used without understanding that clauses are
:-/2 terms?

This might have historical reasons but, in hindsight, is it a good
design that one should pursue further? Uniformity and consistency
in a language design have many advantages. Easier learning by novices
is just one of them.

Note that, with a symmetric behaviour of clause/2 and assert/3 their
versions with an additional clause reference argument would also
mirror each other:
   - clause(Head,Body,Reference) and
   - assert(Head,Body,Reference)

Looking forward to your opinions,
Günter

--------------------------------------------------------------------
Dr. Günter Kniesel                    http://www.cs.uni-bonn.de/~gk/
Institut für Informatik III                        gk@...
Universität Bonn
Römerstr. 164 (Raum A107)                      Tel [phone]
D-53117 Bonn                                   Fax [phone]
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Jan Wielemaker-3]

Hi Günter,

On Saturday 27 June 2009 20:20:27 Günter Kniesel wrote:

> my students were confused by the following, arguably undesired behaviour
> of assert/2. Expecting that assert mirrors clause(Head,Body) they
> tried to use it as assert(Head,Body) and where surprised to get
> the following:
>
> 17 ?- assert(a,b).
> false.
>
> 18 ?- listing(a).
>
> :- dynamic user:a/0.
>
> user:a.
>
> true.
>
> The above behaviour (claiming assertion failed but nevertheless asserting
> the clause) is highly confusing.
>
> I would suggest that the implementation of assert/2 should be
> changed so that if the second argument (the clause reference)
> is not a free variable, then the assertion is not performed.

Done.

> However, that would only partly remove the cause of the confusion,
> which, in the first place, is the non-uniform semantics of the
> arguments to assert and clause. So I'm curious to know why
> there isn't an assert(Head,Body) that mirrors clause(Head,Body)?
>
> Why does "clause" hide the nature of clauses as :-/2 terms whereas
> "assert" cannot even be used without understanding that clauses are
>
> :-/2 terms?
>
> This might have historical reasons but, in hindsight, is it a good
> design that one should pursue further? Uniformity and consistency
> in a language design have many advantages. Easier learning by novices
> is just one of them.
>
> Note that, with a symmetric behaviour of clause/2 and assert/3 their
> versions with an additional clause reference argument would also
> mirror each other:
>    - clause(Head,Body,Reference) and
>    - assert(Head,Body,Reference)

I guess this makes sense, but changing that would break a lot of old
code because assert/2 gets a different meaning. Although assert/2 is not
part of ISO (AFAIK), it has been along for a long time and is probably
still actively used.

        Cheers --- Jan


_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Ulrich Neumerkel]

Sun, 28 Jun 2009 16:18:41 +0200, Jan Wielemaker writes:

>On Saturday 27 June 2009 20:20:27 Günter Kniesel wrote:
>
>> However, that would only partly remove the cause of the confusion,
>> which, in the first place, is the non-uniform semantics of the
>> arguments to assert and clause. So I'm curious to know why
>> there isn't an assert(Head,Body) that mirrors clause(Head,Body)?
>>
>> Why does "clause" hide the nature of clauses as :-/2 terms whereas
>> "assert" cannot even be used without understanding that clauses are
>>
>> :-/2 terms?
>>
>> This might have historical reasons but, in hindsight, is it a good
>> design that one should pursue further? Uniformity and consistency
>> in a language design have many advantages. Easier learning by novices
>> is just one of them.

There are more fundamental problems with Prolog's term representation.
In particular the defaulty role of control constructs like (',')/2
which makes writing meta-interpreters and other meta-programs
unnecessarily complex and impure.

The original representation of Prolog programs, using a prefix + for
heads and - for goals led itself more naturally to a clean
representation.

It is often preferable to transform clauses into a more appropriate
representation.  In partiuclar in the context of programming courses.


Markus Triska has compiled a discussion related to this under
http://stud4.tuwien.ac.at/~e0225855/acomip/acomip.html

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Richard O'Keefe]

Why isn't there an assert(Head, Body)
to mirror clause(Head, Body)?

Because there is an assert(+Clause, -DbRef) in DEC-10
Prolog, an (almost unusable)
assert(+Clause, +Integer_Position) in Arity Prolog,
and so on.

Of course, that's no explanation of why there isn't
a command with the same interface and effect but a
different name.  I guess the answer is that nobody
ever wanted one all that badly:

        my_assert(Head, Body) :-
            assert(( Head :- Body )).

will do the job.  The absence of

        retract(Head, Body) :-
            clause(Head, Body, DbRef),
            erase(DbRef).

is much more of a nuisance, but given clause/3 and erase/3
not _that_ much of a nuisance.  That one _could_ be added
without too much pain.

On Jun 29, 2009, at 12:41 PM, Ulrich Neumerkel wrote:
> There are more fundamental problems with Prolog's term representation.
> In particular the defaulty role of control constructs like (',')/2
> which makes writing meta-interpreters and other meta-programs
> unnecessarily complex and impure.

Agreed.
>
>
> The original representation of Prolog programs, using a prefix + for
> heads and - for goals led itself more naturally to a clean
> representation.

Edinburgh used that syntax for a while, but switched over
to the Prolog syntax we now know for several reasons, top
among them readability.  It is worth noting that the
"defaulty" representation was NEVER the actual internal
representation in DEC-10 Prolog or Quintus Prolog:
assert/1 always converted it to something much more convenient
for interpretation.
>
>
> It is often preferable to transform clauses into a more appropriate
> representation.

100% agreement on that.  In fact I've come across very few
input representations, in Prolog or Lisp, that should NOT
be transformed to something else for processing.

_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Richard O'Keefe]

On Jun 28, 2009, at 6:20 AM, Günter Kniesel wrote:
> 17 ?- assert(a,b).
> false.
>
> 18 ?- listing(a).
> :- dynamic user:a/0.
>
> user:a.
>
> true.

For what it's worth, I tried this in two other Prolog
systems and got the same result.

What really puzzles me is why the students came up with
this misconception in the first place.  I mean, they'd have
seen examples of assert/1, but not examples of assert/2.

PLT Scheme has an interesting approach.  They've divided
the language into levels, and the initial teaching level
doesn't have very much.  You have to explicitly move to
a richer level.  If you are an expert coming to PLT Scheme
for the first time, expecting everything you know to be there,
it's a nuisance, but it sounds like a good way to protect
beginners from (some) accidents.


_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Günter Kniesel]

Richard O'Keefe schrieb:

>
> On Jun 28, 2009, at 6:20 AM, Günter Kniesel wrote:
>> 17 ?- assert(a,b).
>> false.
>>
>> 18 ?- listing(a).
>> :- dynamic user:a/0.
>>
>> user:a.
>>
>> true.
>
> For what it's worth, I tried this in two other Prolog
> systems and got the same result.
>
> What really puzzles me is why the students came up with
> this misconception in the first place.  I mean, they'd have
> seen examples of assert/1, but not examples of assert/2.

Richard, Ulrich,

thank you for your comments and suggestions. Actually, the problem
is not one of those students who dumbly follow your instructions but
one of the students who use their mind to think ahead and do their
own experiments. The type of students that one really wants to have ;)

In particular, some students who saw assert/1 but also saw clause/2 simply
deduced that it would have been a consistent design to have an assert/2 and
immediately tried it out without bothering to consult a manual first.

So I don't think that staged introductions to Prolog would have really
prevented this happening. People like these guys will simply try out
their ideas and, I must say, I am happy they do.

Regards,
Günter
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Richard O'Keefe]

I'm not being picky.  I have a lot that I need to learn
about how students think.

On Jul 1, 2009, at 4:22 AM, Günter Kniesel wrote:
> In particular, some students who saw assert/1 but also saw clause/2  
> simply
> deduced that it would have been a consistent design to have an  
> assert/2 and

But how would it be consistent?  There isn't any
clause/1!  This is like saying "I see a bathtub with two
taps and one plughole, so I expect to find a second plughole
if I look hard enough."

Since
?- help(clause).
?- help(assert).
would have told them instantly what versions of clause/N
and assert/N were available, this should have been cleared
up pretty quickly.

These students who go and try things, do they try SWI's
very nice on-line documentation as part of their exploration?
If not, what could be done to make it more attractive to them?

By the way, I use R a lot.  And the on-line help in R
is done by typing, for example,
        ?lm
to get help about the lm function.  So I find myself
typing things like
        ?open
at Prolog a lot.  That doesn't work because there's a missing
full stop, but I can fix that on the next line.  Or I could
if ? were suitably defined.  So my ~/.plrc contains these
two lines:

        :- op(999, fy, ?).
        ?(Topic) :- help(Topic).

after which
        ?clause.
        ?assert.
work.

If you don't use R (or S) much, this may not do anything
for you, but it has saved me a lot of frustration.

>
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Alan Baljeu]

My take:

Many good prolog predicates are of the form abc_def(Abc, Def), where the idea is that abc and def are corresponding concepts.  This is particularly so in introductory examples like parent, sibling, and ancestor.

So naturally when it comes to predicates, I also think head_body(add(X,Y,Z), Z is X + Y).  Therefore the natural-feeling predicates are

record_head_body(Head, Body)
delete_head_body(Head, Body)
lookup_head_body(Head, Body)

These sort the ideas I feel are behind assert, retract, and clause, and that is why assert seems to want 2 arguments.



 Alan Baljeu




----- Original Message ----
From: Richard O'Keefe <ok@...>
To: Günter Kniesel <gk@...>
Cc: SWI-Prolog mailing list <swi-prolog@...>
Sent: Sunday, June 28, 2009 9:51:15 PM
Subject: Re: [SWIPL] Inconsistent behaviour of assert/2


On Jun 28, 2009, at 6:20 AM, Günter Kniesel wrote:
> 17 ?- assert(a,b).
> false.
>
> 18 ?- listing(a).
> :- dynamic user:a/0.
>
> user:a.
>
> true.

For what it's worth, I tried this in two other Prolog
systems and got the same result.

What really puzzles me is why the students came up with
this misconception in the first place.  I mean, they'd have
seen examples of assert/1, but not examples of assert/2.

PLT Scheme has an interesting approach.  They've divided
the language into levels, and the initial teaching level
doesn't have very much.  You have to explicitly move to
a richer level.  If you are an expert coming to PLT Scheme
for the first time, expecting everything you know to be there,
it's a nuisance, but it sounds like a good way to protect
beginners from (some) accidents.


_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog



      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now
http://ca.toolbar.yahoo.com.
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog