06.05.10
Posted in logtalk at 3:21 am by Paulo Moura
Step 1. Work using an alias. Why expose your identity?
Step 2. Spend years asking the Logtalk open-source developer to implement everything except the proverbial kitchen sink, while at the same time politely declining to make any significant code contribution to all those features you find critical. After all, you’re a commercial user, with serious business to attend to. No time to fool around. In our example, the wish list includes:
- an IDE
- a type-checker
- a cross-referencer
- automatic dependency generation
- a bootstrapped implementation
- a code coverage tool
- a web server
- a sockets interface
- unit test support (ignoring the existing one)
- new documenting tools (as the existing ones don’t fit your commercial development requirements)
- a revamped debugger
- …
Step 3. Score hundreds of hours of free support, including on-line and in-situ, from the Logtalk developer. Besides saving you precious development time, you’re also learning the fine details of the Logtalk implementation, which will be quite handy in later steps.
Step 4. Plan your moves carefully. For example, make a peanuts donation to the Logtalk hosting expenses. It’s one less burger and cola, which in itself is not a bad idea. Who knows? It might become handy in the future to claim that you had gone as far as contributing financially to the original project.
Step 5. Try to dictate the Logtalk roadmap in a public Logtalk wiki. Users write wish lists; developers write roadmaps. But who cares about these fine distinctions? The important bit is that you may now argue that your “collaboration” attempts got shut down by the ungrateful Logtalk developer.
Step 6. Fork Logtalk. Forks can be a fantastic tool for collaborative development. So much that Logtalk is available not only from an open-access Subversion server but also from a git repository in a convenient public place. Of course, a fork starts as being an exact copy of the existing software.
Step 7. Take a page from Microsoft and name your fork OpenLogtalk. This will make it easier for new users to peek the most open alternative. Is dead simple: just choose the one with “open” in its name. Duh!
Step 8. Present your work as an upcoming professional alternative to the original academic and amateur one. Sprinkle the description of your fork with concepts from Software Engineering 101. Talk how you’re going to provide “high reliability” and “comprehensive documentation”. Talk is cheap; you can afford it.
Step 9. Present your work as a new implementation, while kindly acknowledging the first and original implementation. For example, write:
OpenLogtalk is an implementation of the “Logtalk language”.
The first implementation of Logtalk was by Paulo Moura.
The article “an” is a good choice as it nicely suggests “another” and “alternative”. Don’t let the little fact that the first implementation is also the only existing one, that you forked, spoil your message. Deception, after all, is an art that requires practice.
Step 10. Make cosmetic changes to your fork. Change tabs into spaces, put a tab before comment text, split files in smaller files (nothing rhymes more with “modular” than a lot of small files, even if you just end up loading all of them), remove a prefix from internal names, never mind that is there for sound technical reasons as already explained to you.
These changes are very important as they (1) make the code in your fork look different in a quick glance; (2) make the code fit your programming style (coding guidelines of the original developer be damned; it’s your fork!); (3) make it next to impossible for the original developer to pull and include your changes without lots of rewriting work; (4) reinforce the reality distortion field that you jump-started in the previous steps. As a bonus, you may get to claim later on the road the the original developer is not playing nice as he is not picking up your “contributions”.
Step 11. Innocently ask the original developer for help in understanding the source code. Put his mail replies in new files in your fork. It helps in product differentiation.
Step 12. There is no step 12. You’re already using a fork, not for collaborating, but to split. The best thing that can happen to a young programming community. Just let it roll.
P.S. If you care about Logtalk, help to spread this post and expose the troll.
Logtalk is the result of more than 12 years of hard work. Logtalk is, always have been, and always will be open for collaborations. Is not open, however, for abuse from disgruntled commercial users.
Permalink
05.25.10
Posted in logtalk at 12:05 am by Paulo Moura
Recently I came across two open-source tools for visualization of the commit history of source code: codeswarm and gource. Both tools support Subversion, the version control software currently used for Logtalk. Before that I used CVS. Unfortunately, the Logtalk Subversion repository only covers development from October 29, 2001 onwards (Logtalk 2.x development started on January, 1998). Even so, using the above tools provide interesting insight into the history of Logtalk for the past eight and a half years. The resulting videos are encoding using the MPEG-4 H264 video codec. I tried to upload the videos to YouTube but the apparently mandatory reconversion produced awful results.
The first video shows the Logtalk code swarm between October 29, 2001 and May 4, 2010 (the date of the latest Logtalk stable release, version 2.39.2):
http://logtalk.org/files/logtalk_code_swarm.mp4
You will notice that the red color, representing commits related to the Prolog config files, often dominates. This is consequence of the lack of strong Prolog standards, which result in spending an inordinate amount of time working around portability issues.
The second video was produced by gource and covers the same time period:
http://logtalk.org/files/logtalk_gource.mp4
This video excels at illustrating all aspects of Logtalk development work other than the Logtalk compiler/runtime itself. The “flashes” where the little green guy seems to touch most files happen when a new Logtalk version is released and I increment the version number in order to begin working on the next release.
A special thanks to the developers of the codeswarm and gource tools.
Permalink
02.17.10
Posted in logtalk, prolog at 4:10 pm by Paulo Moura
The development of the current generation of Logtalk, 2.x, began on January of 1998. At that time, the ISO Prolog Standard (Part 1: General Core) was only three years old. Thus, accepting and dealing with the lack of compliance of most Prolog compilers with the standard was a sensible choice.
Back to the present. The ISO Prolog Standard is now 15 years old. Compliance with the standard greatly improved for some but not all Prolog compilers. Trying to keep minimal Logtalk compatibility with some of the existing Prolog compilers is no longer feasible. In fact, keeping compatibility with the most problematic Prolog compilers (as far as standard-compliance goes) is working as an anchor, slowing Logtalk development and preventing improvements and implementation of new features.
Some of the most problematic Prolog compilers (again, from the point-of-view of standards compliance) are (to the best of my knowledge) no longer being developed. Other Prolog compilers, actively maintained today, decided to ignore the current official and de facto standards. A few, such as IF/Prolog, provided good standard compliance but have been apparently discontinued by their developers.
I plan to ditch Logtalk compatibility with the following Prolog compilers in the upcoming 2.39.0 release: ALS Prolog, Amzi! Prolog, BinProlog, GNU Prolog, IF/Prolog, JIProlog, K-Prolog, LPA MacProlog, LPA WinProlog, Open Prolog, MasterProlog, PrologII+, Quintus Prolog. This may seem like a long list but I suspect this decision will have no consequence for most (if not all) Logtalk users. If If you think it is still worth to support some compiler in this list please contact me as soon as possible.
UPDATE: added GNU Prolog to the list of no longer supported compilers. Support for this compiler will be restored as soon as it implements the ISO Prolog standard directive multifile/1.
Permalink
12.08.09
Posted in logtalk, prolog at 4:16 pm by Paulo Moura
Logtalk 2.38.0, released earlier this month, adds support for lambda expressions. A simple example of a lambda expression is:
| ?- meta::map([X,Y]>>(Y is 2*X), [1,2,3], Ys).
Ys = [2,4,6]
yes
In this example, a lambda expression, [X,Y]>>(Y is 2*X), is used as an argument to the map/3 list mapping predicate, defined in the library object meta, in order to double the elements of a list of integers. Using a lambda expression avoids writing an auxiliary predicate for the sole purpose of doubling the list elements. The lambda parameters are represented by the list [X,Y], which is connected to the lambda goal, (Y is 2*X), by the (>>)/2 operator.
Currying is supported. I.e. it is possible to write a lambda expression whose goal is another lambda expression. The above example can be rewritten as:
| ?- meta::map([X]>>([Y]>>(Y is 2*X)), [1,2,3], Ys).
Ys = [2,4,6]
yes
Lambda expressions may also contain lambda free variables. I.e. variables that are global to the lambda expression. For example, using GNU Prolog as the back-end compiler, we can write:
| ?- meta::map({Z}/[X,Y]>>(Z#=X+Y), [1,2,3], Zs).
Z = _#22(3..268435455)
Zs = [_#3(2..268435454),_#66(1..268435453),_#110(0..268435452)]
yes
Logtalk uses the ISO Prolog construct {}/1 for representing the lambda free variables as this representation is often associated with set representation. Note that the order of the free variables is of no consequence (on the other hand, a list is used for the lambda parameters as their order does matter).
Both lambda free variables and lambda parameters can be any Prolog term. Consider the following example by Markus Triska:
| ?- meta::map([A-B,B-A]>>true, [1-a,2-b,3-c], Zs).
Zs = [a-1,b-2,c-3]
yes
Lambda expressions can be used, as expected, in non-deterministic queries as in the following example using SWI-Prolog as the back-end compiler and Markus Triska’s CLP(FD) library:
| ?- meta::map({Z}/[X,Y]>>(clpfd:(Z#=X+Y)), Xs, Ys).
Xs = [],
Ys = [] ;
Xs = [_G1369],
Ys = [_G1378],
_G1369+_G1378#=Z ;
Xs = [_G1579, _G1582],
Ys = [_G1591, _G1594],
_G1582+_G1594#=Z,
_G1579+_G1591#=Z ;
Xs = [_G1789, _G1792, _G1795],
Ys = [_G1804, _G1807, _G1810],
_G1795+_G1810#=Z,
_G1792+_G1807#=Z,
_G1789+_G1804#=Z ;
...
As illustrated by the above examples, Logtalk lambda expression syntax reuses the ISO Prolog construct {}/1 and the standard operators (/)/2 and (>>)/2, thus avoiding defining new operators, which is always tricky for a portable system such as Logtalk. The operator (>>)/2 was chosen as it suggests an arrow, similar to the syntax used in other languages such as OCaml and Haskell to connect lambda parameters with lambda functions. This syntax was also chosen in order to simplify parsing, error checking, and, eventually, compilation of lambda expressions. The specification of the Logtalk lambda expression syntax can be found in the Logtalk reference manual. The current Logtalk version also includes an example, lambdas, of using lambda expressions with a fair number of sample queries.
Although the first, experimental implementation of lambda expressions in Logtalk followed Ulrich Neumerkel’s proposal for lambda expression syntax in Prolog, that representation was dropped and replaced by the current one in order to avoid some of the questions raised by the Ulrich’s proposed syntax. In his proposal, lambda expressions start with the (\)/1 prefix operator, which can be seen as an approximation to the greek letter lambda (λ). However, the backslash character is usually associated in Prolog with negation as found e.g. in the standard operators (\+)/1, (=\=)/2, (\=)/2, and (\==)/2. Another issue with this operator is that users must be careful when the first lambda parameter is enclosed in parentheses. Consider the following example by Markus (using SWI-Prolog with Ulrich’s lambda library):
| ?- maplist(\(A-B)^(B-A)^true, [1-a,2-b,3-c], Zs).
false.
The goal fails because there is a missing space between the (\)/1 prefix operator and the opening parenthesis that follows. A likely trap for beginners. Ulrich’s syntax for lambda free variables requires adding a new infix operator, (+\)/1, to the base language, something that I prefer to avoid. Not to mention that this operator is too similar to the Prolog negation operator, (\+)/1. Parsing lambda parameters also needs to be careful to avoid calling a non-existing (^)/2 predicate when the lambda expression is misformed. Parsing lambda parameters is arguably simpler in Logtalk due to the use of a list plus using the (>>)/2 operator to connect the parameters with the lambda goal.
The Logtalk implementation of lambda expressions is still evolving. The current development version features improved error-checking and adds support for using a (>>)/2 lambda expression as a goal (besides as a meta-predicate closure). No optimizations are yet in-place. Thus, be aware of possible performance issues if you plan to use lambda expressions heavily in your applications. But don’t let that stop you from having fun playing with Lambda expressions in Logtalk. As always, your feedback is appreciated. Thanks to Ulrich Neumerkel, Richard O’Keefe, and Markus Triska for their lambda expression examples.
Permalink
10.11.09
Posted in logtalk, prolog at 6:27 pm by Paulo Moura
A recurring question on the comp.lang.prolog newsgroup is how to work with different data sets, usually loading them from different files, without mixing the data in the plain Prolog database. Unfortunately, these questions often lack enough details for making an informed choice between several potential programming solutions. Two possible solutions are (1) load the data into suitable data structures instead of using the database and (2) use clauses to represent the data but encapsulate each data set in its own Prolog module or Logtalk object. Some combination of both solutions may also be possible. In this post, however, we’re going to sketch the second solution using Logtalk objects. For an alternative but also Logtalk-based solution please see this previous post.
Assuming all data sets are described using the same predicates, the first step is to declare these predicates. The predicate declarations can be encapsulated either in an object or in a protocol (interface). Using a protocol we could write:
:- protocol(data_set).
:- public(datum_1/3). % data set description predicates
:- public(datum_2/5).
...
:- end_protocol.
We can now represent each data set using its own object (possibly stored in its own file). Each data set object implements the data_set protocol defined above. For example:
:- object(data_set_1,
implements(data_set)).
datum_1(a, b, c).
...
datum_2(1, 2, 3, 4, 5).
...
:- end_object.
Assuming we have the required memory, we can load some of all of our data sets without mixing their data. But that’s not all. We can also encapsulated our data set processing code in its own object (or set of objects, or hierarchy of objects, or whatever is suitable to the complexity of our application). This object, let’s name it processor, will perform its magic by sending messages to the specific data set that we want to process. For example:
:- object(processor).
:- public(compute/2).
...
compute(DataSet, Computation) :-
DataSet::datum_1(A, B, C),
...
:- end_object.
If the computations we wish to perform make sense as questions sent to the data sets themselves, an alternative is to move the data set predicate declarations from the data_set protocol to the processor object and make the data set objects extend the resulting object, below renamed as data_set. For example:
:- object(data_set).
:- public(datum_1/3). % data set description predicates
:- public(datum_2/5).
...
:- public(compute/1). % computing predicates
...
datum_3(abc, def). % default value for datum_3/2
compute(Computation) :-
::datum_1(A, B, C),
...
:- end_object.
:- object(data_set_1,
extends(data_set)).
datum_1(a, b, c).
...
datum_2(1, 2, 3, 4, 5).
...
:- end_object.
An advantage of this solution is that the object data_set can contain default values for the data set description predicates. The ::/1 operator used above is the Logtalk operator for sending a message to self, i.e. to the data set object that received the message compute/1. If the information requested is not found in the data set object, then it will be looked for in its ancestor, where the default values are defined.
The best and most elegant solution will, of course, depend on the details on the data set processing application. For example, above we could have defined the object data_set as a class and the individual data sets as instances of this class (technically, the solution above uses prototypes).
Note that all code above is static. Individual data set description predicates may be declared dynamic (using the predicate directive dynamic/1) if we need to update them during processing of the data sets. If our application requires being able to delete data sets from memory, is simply a question of declaring the data set objects dynamic using the Logtalk object directive dynamic/0 and to use the Logtalk built-in predicate abolish_object/1 when a data set object is no longer needed.
We have only scratched the surface of the Logtalk features that we could make use in our implementation but, hopefully, it’s enough as a starting guide. Feel free to stop by the Logtalk discussion forums to further discuss this programming pattern.
Permalink
10.09.09
Posted in prolog at 2:25 pm by Paulo Moura
Currently, there are two approved ISO Prolog standards: ISO/IEC 13211-1: General core (first edition published in 1995-06-01; an errata was published recently) and ISO/IEC 13211-1: Modules (first edition published in 2000-06-01). There are also five standardization proposals being discussed: Core Revision, Definite Clause Grammars (DCGs), Globals, Threads, and Portable Operating-System Interface (POSI).
While I was a member of the WG17 standardization group (see my previous post), I always stand for a mandatory core standard, making all other standards optional when talking about ISO compliance of a specific Prolog compiler. This means that a Prolog implementer would only need to comply with the core standard in order to claim conformance to the ISO Prolog specification. The Prolog implementer could also freely chose to implement e.g. DCGs and POSI, disregarding Module, Globals, and Threads.
This view of mandatory and optional Prolog standards was shared by some but not all members of the WG17 standardization group. Some of them want to make the Module standard mandatory and pushed for making some of the other standardization proposals dependent (or at least making reference to) the approved Module standard. I find this a recipe for disaster and for ISO Prolog standards irrelevance. A standard should stand on its own merits. Despite the hard work done on the Module standard, the proposed module system is (rightfully) ignored by most Prolog implementers. Other standard proposals should not be used as a leverage for forcing implementers to implemented a flawed standard.
Why is the current Module standard flawed?
First, it specifies a new module system instead of trying to standardize current practice. Instead of helping existing module implementations to converge, the standard choses to specify a new, and therefore incompatible, module system. For example, the standard introduces a new concept of module interface (which can only be implemented by a single module!) that is not found elsewhere, even today.
Second, it specifies two different and incompatible ways of dealing with meta-predicates (the infamous colon_sets_calling_context flag). This means that two Prolog compilers can comply with this standard and still be incompatible!
Third, specifies a meta-predicate directive that prevents the specification of the number of missing arguments when working with closures. One of the consequences is that only the Prolog implementer knows how to parse and make use of meta-predicate directive for built-in predicates! But check what the inventor of the meta-predicate directive have to say about the flaws on the meta-predicate directive as specified in the Module standard.
Fourth, it makes some poor choices regarding built-in predicates and built-in directives. For example, the specification of the predicate_property/2 predicate defines the properties public and private as stating if clause/2 can be used on the predicate clauses. Thus, the properties public and private cannot be used to infer about predicate scope, which would be a much better match for most programmer expectations. Another example is the meta-predicate directive, which is ugly named metapredicate/1 (while existing module systems use, of course, a meta_predicate/1 directive!).
Fifth, the standard fails to specify a solution for renaming predicates when importing. The consequence is that library developers need to be aware of the predicate names used by other library developers in order to avoid conflicts. So much for the idea that modules provide an encapsulation mechanism. Of course, the standard also states that any module predicate (including not exported ones) can be called using explicit qualification and leaves as “an allowable extension to provide a mechanism that hides certain procedures (…)”.
Other problems with the current module standard could be described here but the ones stated above are hopefully enough to convince you that the standard needs to be thoroughly revised.
You may think that my critics of the current module standard (and WG17 policies) are mostly motivated by my work in Logtalk, which provides an alternative to the use of modules. You are wrong. True, Logtalk objects subsume module functionality and the Logtalk compiler is able to compile most modules as objects. But the Logtalk compiler also goes to great lengths to allow programmers to use both modules and objects in the same applications. Case in point: the fact that Logtalk can compile most modules as objects clearly show that there is enough common core functionality in today’s module systems to warrant a new module standard focused in current practice. But any new or revised module standard should also pay due attention to the advanced modules found on some Prolog systems such as ECLiPSe and Ciao.
In its current state, making the current module standard mandatory or required for implementing other standard proposals will either delay standardization efforts or will tie implementations to a limited and flawed module system for years to come.
Permalink
10.04.09
Posted in logtalk at 1:20 pm by Paulo Moura
Recent Logtalk releases include a shell script, logtalk_select, which allows easy switching between installed Logtalk versions. It’s an experimental script, loosely based on the python_select script, with two major limitations: it doesn’t update the Logtalk user folder and it’s POSIX-only. Nevertheless, it’s useful whenever you want to test your application with a new Logtalk release. Usage is quite simple. In order to list all installed versions type:
$ logtalk_select -l
Available versions: lgt2372 lgt2373 lgt2374 lgt2375
The current installed version can be checked by typing:
pmmbp:~ pmoura$ logtalk_select -s
Current version: lgt2375
In order to switch to another installed version type:
$ sudo logtalk_select lgt2374
Using sudo may or may not be needed depending on your Logtalk installation prefix and on the administrative privileges of your user account. Typing the script name without arguments prints a help script:
$ logtalk_select
This script allows switching between installed Logtalk versions
Usage:
logtalk_select [-vlsh] version
Optional arguments:
-v print version of logtalk_select
-l list available versions
-s show the currently selected version
-h help
If you’re a shell scripting wizard and able to improve the logtalk_select script, please mail me. As always, feedback and contributions are most welcome.
Permalink
10.01.09
Posted in prolog at 11:48 am by Paulo Moura
I’m stepping down as editor of ISO Prolog standardization proposals. In recent years, I found myself responsible for four different draft proposals: Core Revision, DCGs, Threads, and POSI (Portable Operating-System Interface). My fault really. With the exception of the DCGs proposal, all the other proposals are born from my initiative. Recently I have been unable to fulfill my duties as editor of the DCGs proposal, failing to meet the deadline for its next revision. This resulted both from the proverbial lack of time and from being weary of the ISO standardization process. This process is mostly broken, unable to meet the needs of the Prolog community. I tried to fix it from within. I failed.
The last straw that resulted in my decision to end my standardization work was the lame events at the WG17 meeting at Pasadena. Tired of the lack of sensible priorities in the discussion of the standardization proposals, I succeeded I changing the meeting’s agenda, convincing the others participants to discuss the Core Revision proposal instead of spending another annual meeting discussing DCGs and Globals. Nothing wrong, of course, with DCGs and Globals. Both are worthy subjects for standardization. But fixing and improving the Core Prolog standard is the most important and urgent task. We discussed the Core Revision proposal in the morning, going from A to Z, making decisions and identifying contention aspects that would merit further discussion for the next revision of the proposal. At the end of the morning, I was pretty satisfied with the results and leaved to catch my flight back home, thus unable to attend the WG17 meeting in the afternoon. The remaining participants decided, without me as the editor of the Core Revision proposal being present, to go back and change the decisions made in the morning. I found this behavior regrettable and disrespectful. I also found some of the afternoon decisions will informed and resulting from an apparent lack of knowledge of the current, published standards. Moreover when most of participants aren’t aware that a Core Revision proposal even existed before this meeting and never participated in previous discussions about this proposal.
I still believe that standardization is vital for the future of Prolog as a programming language. But the current ISO process is the wrong way to do it. Case in point. Standardization proposals are voted by countries, instead of being voted by implementers and users groups. Implementers always decided if a proposal is worthy, by implementing it, or if is worthless, by ignoring it (think ISO Prolog Part 2: Modules). Users are the ones using and claiming for a better language.
A saddening aspect of the ISO standardization process is the lack of perception from outsiders that people working on proposals and participating in meetings are volunteers and not necessarily experts on the matters being discussed. I can understand that outsiders find some aspects of the proposals poorly formulated or completely wrong. I cannot understand that, instead of criticizing the proposals and suggesting alternatives, outsiders choose to insult the volunteers that are doing their best to improve the current standards.
Visibility and openness of the standardization work is also a problem. There are standardization discussion forums and a mailing list. Both are mostly ignored. Neither is listed in the official WG17 web site. It gets tiresome quickly to keep explaining and repeating arguments because people either want to remain anonymous when giving feedback to the current proposals or have no knowledge of the reasoning and previous discussions behind the proposals.
Improving the current, published Prolog standards, requires the courage to recognize past errors and fix them, even if that results in revoking and replacing them with hopefully better specifications. Some people refuse this path and desperately cling to the past, painting the whole standardization process in a corner. I have no patience left for this nonsense.
More could be said about the problems in the current ISO standardization process but I hope that the few ones described above are enough for you to understand my decision. Many thanks to all the people that contributed to get this far in my standardization efforts. Hopefully others with more time and energy will continue from here. My only advice, if I may give one, is: throw away the current ISO standardization process and start a new, grassroots movement that brings together implementers and user groups. Some good examples can be found in the recent web standardization processes and in other programming language communities.
Permalink
07.23.09
Posted in logtalk at 4:42 am by Paulo Moura
The slides I used on my ICLP 2009 invited talk on Logtalk are available at:
http://logtalk.org/papers/iclp2009/logtalk_iclp2009.pdf
My thanks to Patricia Hill and David S. Warren for the invitation. A special thanks for all of you that attended the invited talk. Hope you enjoyed it. I had a great time at Pasadena, meeting old friends and making new ones. The only puzzling thing was people complains about the temperature in the conference rooms, which I found quite comfortable. But that was just me 
There are some interesting news from the ISO Prolog standardization meeting but that’s a topic for another post.
Permalink
07.03.09
Posted in prolog at 3:16 am by Paulo Moura
Recently, I posted some rumblings about my experience compiling Prolog modules as Logtalk objects. One of my pet peeves with Prolog module systems and Prolog module code is the unfortunate mix up between loading and importing. Is quite simple really, repeat after me:
Loading is not importing!
If a user wants to load a module, the ensure_loaded/1 directive shall be used. If the user want to import the public predicates of a module, the use_module/1-2 directives shall be used. Sadly, this basic distinction between these two orthogonal operations is not enforced by most Prolog compilers with a module system (despite some advice found in Prolog user manuals). Moreover, the ensure_loaded/1 directive shall only be used outside modules. Its semantics should simply be: load a file if not already loaded. There is no need for this directive to be the jack-of-all-trades. A simple test: if your Prolog compiler complains when you load two Prolog source files defining two different modules exporting the same predicate, then your Prolog compiler is broken. Complaining about conflicting imports only makes sense when importing. Otherwise a library developer would need to be omniscient about every other library developer work. Module encapsulation purpose is to avoid predicate name conflicts in the first place. Auto-importing public predicates when loading is equivalent to putting holes in module encapsulation. For what purpose? Is really that much trouble to use the use_module/1-2 directives for importing? Sure, these directives also load a file if not already loaded. They must. After all, we are saying that we want to use a module! That doesn’t mean that the ensure_loaded/1 directive should work in retribution as a use_module/1-2 directive in disguise!
As the bible says, why complicate implementation, complicate documentation, complicate semantics? In order to perpetuate mix-ups? To ruin encapsulation goals? Just to cope with sloppy user programming?
Permalink
« Previous entries Next Page » Next Page »
