Home > Archive > Prolog > June 2007 > Prolog OOP 0.5 available for download
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Prolog OOP 0.5 available for download
|
|
| Mauro Di Nuzzo 2007-06-21, 10:04 pm |
|
What's new in OOP0.5:
- untouched standard prolog module system;
- 2 types of inheritance: simple and taxonomic;
- hierarchical recognition of "parametric" objects;
- minor changes and bug fixes;
Please take a look at http://www.prologonlinereference.org/oop.psp
P.S.: I really dislike the following:
:- module(m, [p/1]).
:- dynamic p/1.
p(a).
user: | ?- use_module(m), retract(user:p(_)).
yes
user: | ?- m:p(a).
No
Module system needs to be less bizarre!
Cheers --
Mauro Di Nuzzo
| |
| Jan Wielemaker 2007-06-21, 10:04 pm |
| On 2007-06-21, Mauro Di Nuzzo <picorna@inwind.it> wrote:
> P.S.: I really dislike the following:
>
>:- module(m, [p/1]).
>:- dynamic p/1.
> p(a).
>
> user: | ?- use_module(m), retract(user:p(_)).
> yes
> user: | ?- m:p(a).
> No
>
> Module system needs to be less bizarre!
Its a historic fact of Quintus-like module systems that you can export
dynamic predicates just like normal predicates. The general advice
should be not to use that. Keep dynamic predicates local to a module
and provide a clean interface to update and access dynamic data.
Better yet, count to 10 before using a dynamic predicate. Still
better, count to 100, etc.
All in all this isn't the most bizarre property of Prolog modules and
the good news in this case is that you can always do it neatly.
Cheers --- Jan
| |
|
| On Thu, 21 Jun 2007 17:03:50 +0200, "Mauro Di Nuzzo"
<picorna@inwind.it> wrote:
>
>What's new in OOP0.5:
>
>- untouched standard prolog module system;
>- 2 types of inheritance: simple and taxonomic;
>- hierarchical recognition of "parametric" objects;
>- minor changes and bug fixes;
>
>Please take a look at http://www.prologonlinereference.org/oop.psp
>
Great, but... Could you change colors a bit?... Slightly dark gray
letters on light gray background make it REALLY hard to read...
A.L.
| |
| Mauro Di Nuzzo 2007-06-21, 10:04 pm |
| My site perhaps wanted it really! I hope now it is better.
M
"A.L." <fela@2005.com> ha scritto nel messaggio
news:et5l731lqajoqsjqth5in1p24pinq9abqe@
4ax.com...
> On Thu, 21 Jun 2007 17:03:50 +0200, "Mauro Di Nuzzo"
> <picorna@inwind.it> wrote:
>
>
> Great, but... Could you change colors a bit?... Slightly dark gray
> letters on light gray background make it REALLY hard to read...
>
> A.L.
| |
|
| On Thu, 21 Jun 2007 17:33:34 +0200, "Mauro Di Nuzzo"
<picorna@inwind.it> wrote:
>My site perhaps wanted it really! I hope now it is better.
>M
Much better, thanks!
A.L.
| |
| Paulo Moura 2007-06-23, 8:05 am |
| On Jun 21, 4:03 pm, "Mauro Di Nuzzo" <pico...@inwind.it> wrote:
> ...
> P.S.: I really dislike the following:
>
> :- module(m, [p/1]).
> :- dynamic p/1.
> p(a).
>
> user: | ?- use_module(m), retract(user:p(_)).
> yes
> user: | ?- m:p(a).
> No
>
> Module system needs to be less bizarre!
I can reproduce the problem in SWI-Prolog and SICStus, but not on YAP,
Ciao, or ECLiPSe. This is just another example of the portability
problems of current Prolog module systems that I talked before in this
thread.
All the best,
Paulo
| |
| Mauro Di Nuzzo 2007-06-24, 4:19 am |
| Dialects are surely a worse problem in comparison to all the other
considerations we can do.
Does anybody exist out there that can do something (for real) about this?
The so-called part 2 of the standard is outdated. Someone defined it
hopeless, other defined it premature!
It is really frustrating to write unportable code.
Sadly, I finally agree with someone who said "choose one and make it the
standard".
Cheers --
Mauro
"Paulo Moura" <pjlmoura@gmail.com> ha scritto nel messaggio
news:1182595398.315742.110690@c77g2000hse.googlegroups.com...
> On Jun 21, 4:03 pm, "Mauro Di Nuzzo" <pico...@inwind.it> wrote:
>
> I can reproduce the problem in SWI-Prolog and SICStus, but not on YAP,
> Ciao, or ECLiPSe. This is just another example of the portability
> problems of current Prolog module systems that I talked before in this
> thread.
>
> All the best,
>
> Paulo
>
>
| |
| Mauro Di Nuzzo 2007-06-24, 10:05 pm |
| When I say "one" I say SWI Prolog one, for the following reasons:
+++ 1) very useful "sugar" predicates (to name one, context_module/1);
+++ 2) the so-called reexportation is handled in the normal export list (I
really can't see why not);
+++ 3) importation is handled with simplicity by use_module/[1,2]
predicates;
+++ 4) dynamic exportation/importation can be done via import/1 and export/1
predicates;
+++ 5) meta predicates are handled with module_transparent directive;
This is all what is needed. But the following things have to be changed:
--- 6) use_module/2 could not throw neither error nor warning on the
override of a standard module export list (this is because "exportable" does
not means "public", but means "exported-by-default");
--- 7) dynamic exported predicates could be retracted ONLY in the module
they exist (i.e. explicitly), otherwise an error should be raised;
I like modules defined one-per-file using the only directive module/2. I
dont like meta_predicate/1 directive, but prefer module_transparent/1 in
which predicate indicator (rather than predicate head) is used (I am
minimalist, but not lazy... I write more than one predicate if I need that
feature).
Note: the following sentences are deliriums.
If Jan will change points 6) and 7) I will declare that I am taking the SWI
module system as the prolog standard.
In that case I will don't care if someone will point that this is not
comp.lang.swi.prolog ;-) without grudge, Paulo!
We have to simplify our lifes.
Cheers --
Mauro Di Nuzzo
| |
| Mauro Di Nuzzo 2007-06-24, 10:05 pm |
| Maybe you want to add (dealing with namespace):
--- 8) an import predicate with the same name of an already imported one
should be automatically renamed (displaying a warning) in some way (e.g.
with the 'module_' name as prefix).
M
| |
| Mauro Di Nuzzo 2007-06-24, 10:05 pm |
| About meta predicates... (just an example):
1)
:- module_transparent p/5.
p(A, B, C, D, E) :-
context_module(M),
...
versus
2)
:- meta_predicate p(:, ?, :, :, ?).
p(M:A, B, M:C, M:D, E) :-
...
I like more 1) even with the drawbacks Jan describes in SWI manual. This
also because I don't like auto-expansions.
I also suggest to change the name:
:- meta_predicate p/2.
thus abandoning the Quintus meaning.
M
| |
| Jan Wielemaker 2007-06-24, 10:05 pm |
| On 2007-06-24, Mauro Di Nuzzo <picorna@inwind.it> wrote:
> Maybe you want to add (dealing with namespace):
>
> --- 8) an import predicate with the same name of an already imported one
> should be automatically renamed (displaying a warning) in some way (e.g.
> with the 'module_' name as prefix).
Smells very dangerous. A notion importing a specific predicate with a
different local name might make sense (I have my doubts). Renaming only
if it leeds to a conflict smells like random programming :-)
Cheers --- Jan
| |
| Jan Wielemaker 2007-06-24, 10:05 pm |
| On 2007-06-24, Mauro Di Nuzzo <picorna@inwind.it> wrote:
> When I say "one" I say SWI Prolog one, for the following reasons:
> --- 6) use_module/2 could not throw neither error nor warning on the
> override of a standard module export list (this is because "exportable" does
> not means "public", but means "exported-by-default");
There is something to say for explicit cross-module calls (M:G) and only
allowing this for predicates labeled public. For now, the module export
list defines the public predicates *and* the default exports and you can
use use_module/2 if you want to load the module but import none or only
some of the public predicates. I think that is fine. You can only find
calls to non-exported predicates using M:G using the cross-referencer.
This may change in the future. M:G calls to what is supposed to be a
private predicate is fine for debugging, but a nightmare for
maintenance.
Personally I never use M:G for normal module reuse. Only for debugging
and to do something a littlebit OO-like.
> --- 7) dynamic exported predicates could be retracted ONLY in the module
> they exist (i.e. explicitly), otherwise an error should be raised;
I don't really see why this is needed. You don't need to do retract/assert
to imported predicates. Its not particulary dangerous if you know what you
are doing. I'm tempted to call it bad style, If anything, I'd introduce
a style-warning on exporting dynamic predicates.
It has no priority, as I don't encounter a lot of code that is broken
for this reason. I *do* see a lot of code using M:G to private code,
which I consider really dangerous. In generally assume I can change or
delete private code without notice.
Otherwise, the module/OO system should be as inviting as possible. I still
see too much code not using any form of structuring. Thats the real problem.
Cheers --- Jan
|
|
|
|
|