Correct behavior of this predicate

[leledumbo]

For instance, this predicate:

test :- between(0,1,X),writeln(X).

involves X in the body but not used in the head. What's the correct behavior if I call test?

Under 5.6.17: it stops after printing 0
Under 5.7.14: it waits for action, thus pressing ; prints 1, pressing it again gives false

[Nicolas Pelletier-2]

Hello,

On Tue, Sep 29, 2009 at 11:57, leledumbo <leledumbo_cool@...> wrote:
>
> test :- between(0,1,X),writeln(X).
>
> involves X in the body but not used in the head. What's the correct behavior
> if I call test?
>
> Under 5.6.17: it stops after printing 0
> Under 5.7.14: it waits for action, thus pressing ; prints 1, pressing it
> again gives false

FYI, 5.6.58, which is the version packaged in Debian 5.0 (the current
stable version of Debian), also answers 0, then 1 on backtracking. So
you are stumbling on an old bug. If you can choose which version to
use, I would suggest going with the 5.7.x branch (e.g. 5.7.15).

Regards,

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

[leledumbo]

> So you are stumbling on an old bug. If you can choose which version to use, I would suggest going with
> the 5.7.x branch (e.g. 5.7.15)

I'm using it already, but my campus has the older 5.6.17. Guess I'll tell the lab operator to upgrade it, at least to 5.6.64 (I bet they don't want to install development version).

[Ulrich Neumerkel]

>test :- between(0,1,X),writeln(X).
>
>involves X in the body but not used in the head. What's the correct behavior
>if I call test?
>
>Under 5.6.17: it stops after printing 0
>Under 5.7.14: it waits for action, thus pressing ; prints 1, pressing it
>again gives false

This has something to do with the changed toplevel.  In older
versions, the toplevel only showed one solution for ground goals.

Now, the toplevel asks always for alternatives - provided the system
is not sure that there are none.

In this manner, there is much less interaction than it used to be.
Take X = 1.  Now, we get the answer without any further questions
because the system knows there is no alternative.

Of course, the system does not know everything - nor does it some
lookahead, so:

?- X = 1 ; false.

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

[Jan Wielemaker-3]

On Tue, 2009-09-29 at 20:01 +0900, Nicolas Pelletier wrote:

> Hello,
>
> On Tue, Sep 29, 2009 at 11:57, leledumbo <leledumbo_cool@...> wrote:
> >
> > test :- between(0,1,X),writeln(X).
> >
> > involves X in the body but not used in the head. What's the correct behavior
> > if I call test?
> >
> > Under 5.6.17: it stops after printing 0
> > Under 5.7.14: it waits for action, thus pressing ; prints 1, pressing it
> > again gives false
>
> FYI, 5.6.58, which is the version packaged in Debian 5.0 (the current
> stable version of Debian), also answers 0, then 1 on backtracking. So
> you are stumbling on an old bug. If you can choose which version to
> use, I would suggest going with the 5.7.x branch (e.g. 5.7.15).

Its not a bug.  Its how the toplevel of many traditional Prolog systems
used to work.  The new toplevel is much more elegant though (thanks to
many discussions in this group and with Ulrich and Markus in
particular).

     Cheers --- Jan

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

[Ulrich Neumerkel]

Günter_Kniesel:
>Modules in Prolog are not an encapsulation mechanism, just a
>namespace mechanism. They prevent accidental name clashes but
>do not prevent deliberate access to the internals of a module
>(one can always use the explicit module prefix to access also
>predicates that are not exported). There is no information
>hiding promise, just the promise not to overwhelm you with
>everything that you don't want to see. ;)

There are good reasons to see things that way, but you can see it also
differently.  Please note that that kind of notion of encapsulation
you are after is rarely implemented anywhere.  There is always a
certain level where you can access hidden things.  It is rather a
question how things are officially defined: Are they part of the
language or not?

But if you stay within a language you can chose two directions, either

o opt for complete safety and very restricted functionality, or

o almost no safety but lots of flexibility.

If you consider a big system only the second option is practical.  So
you start with a system that runs - at the expense of certain
encapsulation properties.  Now you can identify safe (w.r.t. some
notion of safety) subsets with your desired properties for certain
programs.

In a system that is too restricted in the beginning, it is unclear how
to proceed: Essentially, you have to be an implementor of the system
to consider extensions rapidly.

>I'd like to understand better your point about the dangers of
>module_transparent raised above. Where did you insert the setof
>call? Do you mean
>
>p(Goal,R) :-
>    Goal,
>    setof(t, f(R),_).

Yes.

>is dynamically bound and what isn't binding. The only way to
>avoid bad surprises is to state your intention explicitly,
>like this:
>
>p(Goal,R) :-
>    Goal,
>    m:setof(t, f(R),_).

Only setof(t, m:f(R),_) would work - at least in 5.7.15.  Or you can
wrap it around call: So call(m:setof(t, f(R),_)).  would work as well.

Your discussion shows again that the intuition isn't very strong with
(module_transparent)/1 declarations.

I strongly suggest that you rather consider (meta_predicate)/1 based
approaches only.  Jan has made quite a decent implementation - in
fact, the only one that can work together with make/0 (which is really
a blessing!).

>?- listing(p).
>m:p(A, B) :-
> call(A),
> setof(t, f(B), _).
>
>Could it be that m:setof(...) is translated to setof(...)
>  as an optimization forgetting that this is only correct
>  for statically bound non-metapredicates?

Yes.  With a call/1 wrapped around, you can "fix" it.  But better
don't!  Think of it how difficult many transformations are in such a
context!  You will more than once fall prey to this.  A single
additional argument seems a pretty economical remedy.
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Stiffler]

Some parts of this message have been removed. Learn more about Nabble's security policy.

> >Modules in Prolog are not an encapsulation mechanism, just a
> >namespace mechanism. They prevent accidental name clashes but
> >do not prevent deliberate access to the internals of a module
> >(one can always use the explicit module prefix to access also
> >predicates that are not exported). There is no information
> >hiding promise, just the promise not to overwhelm you with
> >everything that you don't want to see. ;)
>
> There are good reasons to see things that way, but you can see it also
> differently. Please note that that kind of notion of encapsulation
> you are after is rarely implemented anywhere. There is always a
> certain level where you can access hidden things. It is rather a
> question how things are officially defined: Are they part of the
> language or not?
>
> But if you stay within a language you can chose two directions, either
>
> o opt for complete safety and very restricted functionality, or
>
> o almost no safety but lots of flexibility.
>
> If you consider a big system only the second option is practical. So
> you start with a system that runs - at the expense of certain
> encapsulation properties. Now you can identify safe (w.r.t. some
> notion of safety) subsets with your desired properties for certain
> programs.

Generally speaking, when it comes to module interfaces I believe it is more important to encourage their use rather than enforcement.  Encapsulation is a recommended practice for software engineering.  (Are there any modern languages that don't encourage encapsulation?)  Yet Prolog provides little support (such as compile-time warnings) to encourage the use of module interfaces.  In my experience, interfaces were inadvertently circumvented through code evolution rather than through deviousness.
I think it is important to encourage the developer to use the interface and less important to try to block the determined circumventer.

Cheers,
Parker

PS Does the ISO standard on Prolog modules have anything to say about what to do when the interface is ignored (even if that part of the standard isn't very popular)?

---

Check on MSN NZ Money for a hand Feeling the financial pinch?

[Ulrich Neumerkel]

>In my experience interfaces were inadvertently circumvented through
>code evolution rather than through deviousness.  I think it is
>important to encourage the developer to use the interface and less
>important to try to block the determined circumventer.

One further reason for circumventing the module system by explicit
qualification is simply lack of understanding by both the user but
also the implementor.  When the Quintus system was adopted by other
systems it took some years to get those systems right.  Under pressure
adding a prefix is so much easier than reproducing, minimizing and
filing a precise report.

>PS Does the ISO standard on Prolog modules have anything to say about what
>to do when the interface is ignored (even if that part of the standard
>isn't very popular)?

I consider a significant subset of SWI's module conformant to 13211-2.
Although it is not completely straight forward.  But this is true only
for a subset, and explicit qualification isn't part of that.


Here the relevant parts concerning ignoring or circumventing the
interfaces:

6.2.2 Procedure Visibility

 All procedures defined in a module are accessible from any
 module by use of explicit module qualification. It shall be an
 allowable extension to provide a mechanism that hides certain
 procedures defined in a module M so that they cannot be
 activated, inspected or modified except from within a body of the
 module M.

A reference to 4.5.2 might help:

4.5.2 Inaccessible Procedures

 A Prolog processor may support additional features whose effect
 is to make certain procedures defined in the body of a module
 not accessible from outside the module.

For such general statements the module standard is fine.  But for the
details, it leaves a lot implementation defined.  At least to my
current understanding.

The best way would be if implementors with closely compatible module
systems would agree on one implementation definition that still fits
into 13211-2.  Should not be too difficult, but there needs to be some
interest also by other systems...

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

[Stiffler]

Some parts of this message have been removed. Learn more about Nabble's security policy.

> >In my experience interfaces were inadvertently circumvented through
> >code evolution rather than through deviousness. I think it is
> >important to encourage the developer to use the interface and less
> >important to try to block the determined circumventer.
>
> One further reason for circumventing the module system by explicit
> qualification is simply lack of understanding by both the user but
> also the implementor. When the Quintus system was adopted by other
> systems it took some years to get those systems right. Under pressure
> adding a prefix is so much easier than reproducing, minimizing and
> filing a precise report.

Not necessarily, explicit module qualification is both very natural and very common.  Please see below.

> >PS Does the ISO standard on Prolog modules have anything to say about what
> >to do when the interface is ignored (even if that part of the standard
> >isn't very popular)?

[snip]
 

> Here the relevant parts concerning ignoring or circumventing the
> interfaces:
>
> 6.2.2 Procedure Visibility
>
> All procedures defined in a module are accessible from any
> module by use of explicit module qualification. It shall be an
> allowable extension to provide a mechanism that hides certain
> procedures defined in a module M so that they cannot be
> activated, inspected or modified except from within a body of the
> module M.

This is wrong in my humble opinion.

Explicit module qualification should be encouraged and should not be a "dirty" circumvention mechanism.

Consider this common situation:
Modules m1 and m2 both export a predicate p/0.  To call p/0 unambiguously it's very natural to write m1:p or m2:p.  But then that's using the circumvention mechanism, which wasn't the intention of the programmer.  I vaguely remember import preventing any ambiguity, but I haven't used modules for a number of years so I don't remember.

Take for instance the Ada language which is geared to large application development and reliable software.  It encourages explicit qualification:  the compiler will complain if any procedure is not qualified (unless the 'use' keyword overrides the feature).  Many object oriented languages encourage/require explicit qualification for methods.

Perhaps Prolog could learn from languages that are widely used in large-scale software development.

Cheers,
Parker

---

Explore the new Windows Live Looking for a place to manage all your online stuff?

[Feliks Kluzniak-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Another language that encourages explicit qualification is Oberon.  If Niklaus Wirth believes it’s right, I would have to think very hard before I disagree. ;-)

I think there are two issues here:  (1) safety  (2) readability.  (I will ignore “reflection” for the present.)

Safety is achieved by specifying, in each module, which entities are to be exported and which are to be hidden.  This is complemented by the ability to import stuff selectively.  (Yes, I agree that well-defined interfaces are very important.)

Readability is achieved by making it clear what an identifier refers to, and in particular where it originated.  Explicit qualification is an attempt to make this crystal clear.  There is a certain tension here with the natural need for brevity.  One solution is to allow the user to import module “a_very_important_module” _as_ “m”, and then write “m:id”.

I agree that most Prolog systems do not support real modules: the mechanism is there mostly to help avoid inadvertent name clashes.  Sometimes the mechanism is so simple that it has unfortunate consequences: e.g., the module mechanism of SICStus Prolog tends to get in the way of a metainterpreter even when the programmer wants to ignore the module feature.  (I am happy to say that SWI Prolog avoids that problem.)

For anyone interested in the question I would recommend looking at the module system of Eclipse (www.eclipse-clp.org), which seems to me to be pretty advanced.

Just my two cents.

-- Feliks

 

…...…………………………………  Parker Jones wrote:

. . .

Explicit module qualification should be encouraged and should not be a "dirty" circumvention mechanism.

Consider this common situation:
Modules m1 and m2 both export a predicate p/0.  To call p/0 unambiguously it's very natural to write m1:p or m2:p.  But then that's using the circumvention mechanism, which wasn't the intention of the programmer.  I vaguely remember import preventing any ambiguity, but I haven't used modules for a number of years so I don't remember.

Take for instance the Ada language which is geared to large application development and reliable software.  It encourages explicit qualification:  the compiler will complain if any procedure is not qualified (unless the 'use' keyword overrides the feature).  Many object oriented languages encourage/require explicit qualification for methods.

Perhaps Prolog could learn from languages that are widely used in large-scale software development.

. . .

 

[Ulrich Neumerkel]

Feliks Kluzniak:
>Another language that encourages explicit qualification is Oberon.  If
>Niklaus Wirth believes it's right, I would have to think very hard before I
>disagree. ;-)

What about: Variables of procedure types can transfer the pointer of
an internal procedure ouf a module.  In this manner another module can
now call an unexported procedure.  (Maybe that has changed in the
meantime.  But at least in the beginning, and also in Modula-2 it was
like that.)

>I think there are two issues here:  (1) safety  (2) readability.  (I will
>ignore "reflection" for the present.)

Reflection is what distinguished Prolog (or CL) from traditional
languages.

>Safety is achieved by specifying, in each module, which entities are to be
>exported and which are to be hidden.  This is complemented by the ability to
>import stuff selectively.  (Yes, I agree that well-defined interfaces are
>very important.)
>
>Readability is achieved by making it clear what an identifier refers to, and
>in particular where it originated.  Explicit qualification is an attempt to
>make this crystal clear.  There is a certain tension here with the natural
>need for brevity.  One solution is to allow the user to import module
>"a_very_important_module" _as_ "m", and then write "m:id".

That's what is done in Oberon as well and I did like that feature.  In
this manner also the code in a module gets independent of the precise
module name.  You might e.g. replace one "driver-module" by another
one, only by changing 2 header lines.

It seems that abbreviation of the module name is preferable to
renaming of the conflicting procedure.  Currently in SWI, renaming is
offered on a predicate-by-predicate basis with (as)/2.  That means,
you will give up the original name and possibly replace it by
something less readable. Maybe referring to a short name would be a
solution.

However, there is still the conflict between explicit qualification
and meta-predicates...
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Jan Wielemaker-3]

Hi,

Prolog module systems appear to be almost religious.   I've written
quite a bit of Prolog code and been involved in quite a few larger
projects.  The biggest hurdle appears that people do not get
meta-predicates right.  This was particularly the case using the
module_transparent mechanism.  The meta-predicate mechanism is
a bit easier to understand and more widely known, so my hope is
that this gets better.

One way to use the system is to give public predicates a reasonable
descriptive name and allow for brevity for local predicates.  Next,
use non-qualified names for using imported predicates.  SWI-Prolog
complains if you try to import the same predicate from two places
into the same target.  Not sure about other systems.  This doesn't
happen very often though :-)  If it does, it generally means you
violated the idea of reasonable descriptive names.  If all fails,
there is the notion of `import as'.

Note that if you use non-qualified names, the module name itself
only needs to be written once and can thus be long.  This is actually of
some practical importance because quite a few projects have a module
`utils' :-)

This schema doesn't give too many problems.   Actually, many
projects rely on demand-loading, which is far more dangerous
and still rarely gives problems :-)

Note SWI-Prolog (and I understand ISO and most Quintus derived
systems except for Ciao) allows for calling any predicate using
a qualified call.  This is fine for some well-understood
design patterns (using modules more or less as a simple-minded
form of Logtalk objects), but it fails miserably otherwise,
except for debugging and very temporary hacks.  I have really
seen programs break because one of the programmers changed
interfaces between the public predicates and internals while
others were calling the internals.

The lack of a standard module system is a big issue for the
Prolog community.  The module systems themselves may not be
perfect, but they are usable.

Prolog without a module system however is unusable.  Its need
for many helper-predicates makes it really hard to avoid clashes
and the module header is enormously valuable in grasping the
idea behind a module.  Using the schema above also allows to
quickly assess what code is unused and which definitions are
missing (only requires scanning the module headers of the
used modules and the module itself).

Keeping it simple is in my view more important than making it perfect.


        Cheers --- Jan


On Tue, 2009-09-29 at 12:16 -0500, Feliks Kluzniak wrote:

> Another language that encourages explicit qualification is Oberon.  If
> Niklaus Wirth believes it’s right, I would have to think very hard
> before I disagree. ;-)
>
> I think there are two issues here:  (1) safety  (2) readability.  (I
> will ignore “reflection” for the present.)
>
> Safety is achieved by specifying, in each module, which entities are
> to be exported and which are to be hidden.  This is complemented by
> the ability to import stuff selectively.  (Yes, I agree that
> well-defined interfaces are very important.)
>
> Readability is achieved by making it clear what an identifier refers
> to, and in particular where it originated.  Explicit qualification is
> an attempt to make this crystal clear.  There is a certain tension
> here with the natural need for brevity.  One solution is to allow the
> user to import module “a_very_important_module” _as_ “m”, and then
> write “m:id”.
>
> I agree that most Prolog systems do not support real modules: the
> mechanism is there mostly to help avoid inadvertent name clashes.
> Sometimes the mechanism is so simple that it has unfortunate
> consequences: e.g., the module mechanism of SICStus Prolog tends to
> get in the way of a metainterpreter even when the programmer wants to
> ignore the module feature.  (I am happy to say that SWI Prolog avoids
> that problem.)
>
> For anyone interested in the question I would recommend looking at the
> module system of Eclipse (www.eclipse-clp.org), which seems to me to
> be pretty advanced.
>
> Just my two cents.
>
> -- Feliks
>
>  
>
> …...…………………………………  Parker Jones wrote:
>
> . . .
>
> Explicit module qualification should be encouraged and should not be a
> "dirty" circumvention mechanism.
>
> Consider this common situation:
> Modules m1 and m2 both export a predicate p/0.  To call p/0
> unambiguously it's very natural to write m1:p or m2:p.  But then
> that's using the circumvention mechanism, which wasn't the intention
> of the programmer.  I vaguely remember import preventing any
> ambiguity, but I haven't used modules for a number of years so I don't
> remember.
>
> Take for instance the Ada language which is geared to large
> application development and reliable software.  It encourages explicit
> qualification:  the compiler will complain if any procedure is not
> qualified (unless the 'use' keyword overrides the feature).  Many
> object oriented languages encourage/require explicit qualification for
> methods.
>
> Perhaps Prolog could learn from languages that are widely used in
> large-scale software development.
>
> . . .
>
>  
>
>

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

[Feliks Kluzniak-2]

>> I think there are two issues here:  (1) safety  (2) readability.  (I will
>> ignore "reflection" for the present.)

> Reflection is what distinguished Prolog (or CL) from traditional
> languages.

This is one of the distinguishing factors, yes, but perhaps not the only
one?  As far as I remember, Haskell provides very few "reflection"
capabilities, yet it is a very powerful symbolic language.

It is certainly possible to write an application that benefits from the
power of Prolog, but uses no "reflection", e.g., a compiler.  It would be
nice if one could do such things with the same degree of safety and ease of
structuring in-the-large as in those few modern imperative languages that
provide proper modularization mechanisms. (Java or C++ do not qualify, but
please, let no one mistake this for a troll. ;-))

I ignored "reflection" for the present, because --- alas! --- I do not have
all the answers. :-)

-- Feliks


-----Original Message-----
From: Ulrich Neumerkel [mailto:ulrich@...]
Sent: Tuesday, September 29, 2009 12:42 PM
To: feliks.kluzniak@...; ulrich@...;
zoubidoo@...
Cc: swi-prolog@...
Subject: RE: [SWIPL] Correct behavior of this predicate


Feliks Kluzniak:
>Another language that encourages explicit qualification is Oberon.  If
>Niklaus Wirth believes it's right, I would have to think very hard before I
>disagree. ;-)

What about: Variables of procedure types can transfer the pointer of
an internal procedure ouf a module.  In this manner another module can
now call an unexported procedure.  (Maybe that has changed in the
meantime.  But at least in the beginning, and also in Modula-2 it was
like that.)

>I think there are two issues here:  (1) safety  (2) readability.  (I will
>ignore "reflection" for the present.)

Reflection is what distinguished Prolog (or CL) from traditional
languages.

>Safety is achieved by specifying, in each module, which entities are to be
>exported and which are to be hidden.  This is complemented by the ability
to
>import stuff selectively.  (Yes, I agree that well-defined interfaces are
>very important.)
>
>Readability is achieved by making it clear what an identifier refers to,
and
>in particular where it originated.  Explicit qualification is an attempt to
>make this crystal clear.  There is a certain tension here with the natural
>need for brevity.  One solution is to allow the user to import module
>"a_very_important_module" _as_ "m", and then write "m:id".

That's what is done in Oberon as well and I did like that feature.  In
this manner also the code in a module gets independent of the precise
module name.  You might e.g. replace one "driver-module" by another
one, only by changing 2 header lines.

It seems that abbreviation of the module name is preferable to
renaming of the conflicting procedure.  Currently in SWI, renaming is
offered on a predicate-by-predicate basis with (as)/2.  That means,
you will give up the original name and possibly replace it by
something less readable. Maybe referring to a short name would be a
solution.

However, there is still the conflict between explicit qualification
and meta-predicates...

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

[Paulo Moura]

On 2009/09/29, at 16:47, Ulrich Neumerkel wrote:

> The best way would be if implementors with closely compatible module
> systems would agree on one implementation definition that still fits
> into 13211-2.  Should not be too difficult, but there needs to be some
> interest also by other systems...

Here comes the 13211-2 straitjacket again... the alpha and omega of  
standard documents, the sacred text to which all systems must bow and  
convert. Is it really necessary to enumerate the problems of the  
proposed module system?

Cheers,

Paulo


-----------------------------------------------------------------
Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: [phone] Fax: [phone]
Email: <mailto:pmoura@...>

Home page: <http://www.di.ubi.pt/~pmoura>
Research:  <http://logtalk.org/> Blog: <http://blog.logtalk.org/>
-----------------------------------------------------------------







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

[Paulo Moura]

On 2009/09/29, at 15:24, Ulrich Neumerkel wrote:

> Günter_Kniesel:
>> Modules in Prolog are not an encapsulation mechanism, just a
>> namespace mechanism. They prevent accidental name clashes but
>> do not prevent deliberate access to the internals of a module
>> (one can always use the explicit module prefix to access also
>> predicates that are not exported). There is no information
>> hiding promise, just the promise not to overwhelm you with
>> everything that you don't want to see. ;)
>
> There are good reasons to see things that way, but you can see it also
> differently.  Please note that that kind of notion of encapsulation
> you are after is rarely implemented anywhere.

Well, Logtalk implements it and I'm certain is not alone in this regard.

>  There is always a
> certain level where you can access hidden things.  It is rather a
> question how things are officially defined: Are they part of the
> language or not?
>
> But if you stay within a language you can chose two directions, either
>
> o opt for complete safety and very restricted functionality, or
>
> o almost no safety but lots of flexibility.

You can have both safety and flexibility. The key, of course, is  
appropriated language constructs. Moreover, much of flexibility your  
refer is handy while developing but is best avoided when deploying.

> If you consider a big system only the second option is practical.

Or you can use or design a system that provides you with a third  
direction. Can you list the flexibility features that, in your  
opinion, are prevented by strong encapsulation?

Cheers,

Paulo


-----------------------------------------------------------------
Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: [phone] Fax: [phone]
Email: <mailto:pmoura@...>

Home page: <http://www.di.ubi.pt/~pmoura>
Research:  <http://logtalk.org/> Blog: <http://blog.logtalk.org/>
-----------------------------------------------------------------

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

[Paulo Moura]

On 2009/09/29, at 17:45, Parker Jones wrote:

> > >In my experience interfaces were inadvertently circumvented through
> > >code evolution rather than through deviousness. I think it is
> > >important to encourage the developer to use the interface and less
> > >important to try to block the determined circumventer.
> >
> > One further reason for circumventing the module system by explicit
> > qualification is simply lack of understanding by both the user but
> > also the implementor. When the Quintus system was adopted by other
> > systems it took some years to get those systems right. Under  
> pressure
> > adding a prefix is so much easier than reproducing, minimizing and
> > filing a precise report.
>
> Not necessarily, explicit module qualification is both very natural  
> and very common.  Please see below.
>
> > >PS Does the ISO standard on Prolog modules have anything to say  
> about what
> > >to do when the interface is ignored (even if that part of the  
> standard
> > >isn't very popular)?
>
> [snip]
>
> > Here the relevant parts concerning ignoring or circumventing the
> > interfaces:
> >
> > 6.2.2 Procedure Visibility
> >
> > All procedures defined in a module are accessible from any
> > module by use of explicit module qualification. It shall be an
> > allowable extension to provide a mechanism that hides certain
> > procedures defined in a module M so that they cannot be
> > activated, inspected or modified except from within a body of the
> > module M.
>
> This is wrong in my humble opinion.

Amen.

> Explicit module qualification should be encouraged and should not be  
> a "dirty" circumvention mechanism.
>
> Consider this common situation:
> Modules m1 and m2 both export a predicate p/0.  To call p/0  
> unambiguously it's very natural to write m1:p or m2:p.  But then  
> that's using the circumvention mechanism, which wasn't the intention  
> of the programmer.  I vaguely remember import preventing any  
> ambiguity, but I haven't used modules for a number of years so I  
> don't remember.
>
> Take for instance the Ada language which is geared to large  
> application development and reliable software.  It encourages  
> explicit qualification:  the compiler will complain if any procedure  
> is not qualified (unless the 'use' keyword overrides the feature).  
> Many object oriented languages encourage/require explicit  
> qualification for methods.

Logtalk provides a uses/2 directive that is similar. For example, we  
could write:

  :- uses(list, [append/3, member/2]).

and simply write append(...) and member(...) in clause bodies. This  
way, the calls are explicitly qualified as far as the compiler is  
concerned but the programmer can avoid typing the "list::" prefixes.  
Sounds familiar? Most Prolog module systems already provide a  
use_module/2 directive that accomplish the same thing.

Cheers,

Paulo


-----------------------------------------------------------------
Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: [phone] Fax: [phone]
Email: <mailto:pmoura@...>

Home page: <http://www.di.ubi.pt/~pmoura>
Research:  <http://logtalk.org/> Blog: <http://blog.logtalk.org/>
-----------------------------------------------------------------

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

[Paulo Moura]

On 2009/09/29, at 18:42, Ulrich Neumerkel wrote:

> It seems that abbreviation of the module name is preferable to
> renaming of the conflicting procedure.  Currently in SWI, renaming is
> offered on a predicate-by-predicate basis with (as)/2.  That means,
> you will give up the original name and possibly replace it by
> something less readable. Maybe referring to a short name would be a
> solution.

Did you notice than writing e.g. "rb_new(...)" uses the exact same  
number of characters as "rb:new(...)"? Of course, writing e.g.  
ordsets:ord_disjoint(...) sounds silly. Plenty of similar examples.  
All because people try to solve conflicts when designing modules  
instead of conflicts being solved when importing (as it should be).

> However, there is still the conflict between explicit qualification
> and meta-predicates...


Meta-predicate semantics could easily be simpler... but that could  
break existing code.

Cheers,

Paulo


-----------------------------------------------------------------
Paulo Jorge Lopes de Moura, PhD
Assistant Professor
Dep. of Computer Science, University of Beira Interior
6201-001 Covilhã, Portugal

Office 3.18  Ext. 3276
Phone: [phone] Fax: [phone]
Email: <mailto:pmoura@...>

Home page: <http://www.di.ubi.pt/~pmoura>
Research:  <http://logtalk.org/> Blog: <http://blog.logtalk.org/>
-----------------------------------------------------------------







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

[Ulrich Neumerkel]

Paulo Moura:
>Well, Logtalk implements it and I'm certain is not alone in this regard.

Let's see.

>>  There is always a
>> certain level where you can access hidden things.  It is rather a
>> question how things are officially defined: Are they part of the
>> language or not?
>>
>> But if you stay within a language you can chose two directions, either
>>
>> o opt for complete safety and very restricted functionality, or
>>
>> o almost no safety but lots of flexibility.
>
>You can have both safety and flexibility. The key, of course, is
>appropriated language constructs. Moreover, much of flexibility your
>refer is handy while developing but is best avoided when deploying.
>
>> If you consider a big system only the second option is practical.
>
>Or you can use or design a system that provides you with a third
>direction. Can you list the flexibility features that, in your
>opinion, are prevented by strong encapsulation?

In the last months I gave two examples whose solution I cannot see in
the various module improvement proposals/implementations such as yours
but also all the cited ones:

Challenge one:

Implement library(lambda)

http://www.complang.tuwien.ac.at/ulrich/Prolog-inedit/lambda.pl

That should be trivial - with the notable exception of no_hat_call/1.
Can you define that functionality too?


Challenge two:

Implement a generalizer in a separate module.

goal_generalized(Goal, GeneralizedGoal)

Assume Goal refers to a monotonic definition.

So, for

 Goal = ( [1,2,3,4] = [1,2,e,4] )

we want to obtain

 GeneralizedGoal = ( [_,_,3|_] = [_,_,e|_] )

Since this is a generalization that still fails.

And for

 Goal = alldifferent([a,b,c,d,c])

we want something like

 GeneralizedGoal = alldifferent([_,_,X,_,X|_])

So we want a (in some sense) maximal generalization such that the goal
still fails.  Of course, Goal should not only be a built-in predicate
- but any goal that can be called in the context of the caller.
Ignore termination issues - i.e. assume the definiton terminates for
all its generalizations.

Are the problems stated well enough? Don't hesitate to ask back!
Guessing the problem statement shouldn't be the challenge :-).
_______________________________________________
SWI-Prolog mailing list
SWI-Prolog@...
https://mailbox.iai.uni-bonn.de/mailman/listinfo.cgi/swi-prolog

[Richard O'Keefe]

>> p(Goal,R) :-
>>   Goal,
>>   m:setof(t, f(R),_).
>
> Only setof(t, m:f(R),_) would work - at least in 5.7.15.

One expects, no, demands, that
        m:setof(t, f(R), _)
and setof(t, m:f(R), _)
should have the same effect (except perhaps on what you can see in
a debugger).  setof/3 is pervasive; we expect to get the same
setof/3 in every module.  It's just like
        m:(p, q) has the same effect as (m:p, m:q)
        m:(p ; q) has the same effect as (m:p ; m:q)
        m:call(p) has the same effect as call(m:p)
and so on.  Any Prolog where this is not the case is broken.


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

[Ulrich Neumerkel]

Richard O'Keefe:

>>> p(Goal,R) :-
>>>   Goal,
>>>   m:setof(t, f(R),_).
>>
>> Only setof(t, m:f(R),_) would work - at least in 5.7.15.
>
>One expects, no, demands, that
>        m:setof(t, f(R), _)
>and     setof(t, m:f(R), _)
>should have the same effect (except perhaps on what you can see in
>a debugger).  setof/3 is pervasive; we expect to get the same
>setof/3 in every module.  It's just like
>        m:(p, q)        has the same effect as (m:p, m:q)
>        m:(p ; q)       has the same effect as (m:p ; m:q)
>        m:call(p)       has the same effect as call(m:p)
>and so on.  Any Prolog where this is not the case is broken.

Absolutely!  This was a case to illustrate when (module_transparent)/1
does not behave intuitively.

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