Closed Bug 332432 Opened 14 years ago Closed 14 years ago
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20060226 Debian/1.5.dfsg+22.214.171.124-3 Firefox/126.96.36.199 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20060226 Debian/1.5.dfsg+184.108.40.206-3 Firefox/220.127.116.11 In a few words, a number of components of Mozilla are half-way Prolog. It would probably be interesting to make them fully accessible and scriptable in Prolog. Let's consider the current preference API, for instance. Clearly, pref(...,...) and user_pref(...,...) are the exact same thing as Prolog predicates pref/2 and user_pref/2, without the power of querying from the second argument or incomplete expressions. Similarly, the current implementation of RDF management is essentially a less graceful manner of querying and/or updating /3 predicates. What takes about 15 lines of JS and a little more in C++, with a number of possibilities for mistakes, is essentially a less powerful version of Prolog one-liner requests. This is even more visible when applying templates to RDF dags, as the power of filters is largely inferior to that of Prolog requests. Much in the same manner, a sensible implementation of Prolog could replace SQLite and BDB everywhere in the system, in an economic manner, and provied uniform access to all data. There are numerous other places where Prolog could prove useful, from the build system to dependency management of XPCom components. But the true power of Prolog becomes visible when you compare it to XBL. Not only is Prolog more concise and broader than XBL, but it can also kill German tourists as well as babies at least twice faster, with ten times less loc. No, frankly, Mozilla needs Prolog. How people have managed to do without it for so long is an amazement for me. Reproducible: Always
http://ioctl.org/logic/prolog1 My hope is that JS2 will support metaprogramming well enough that Prolog could be implemented even more efficiently, and without hybrid syntax if we get a powerful enough macro system. I don't think anyone should implement Prolog in C or C++ and try to wedge it into default builds as a required part of the platform. That's not good use of time, wise addition to the trusted computing base, or particularly appealing to the users of the Mozilla platform, who know web content languages better than '80s logic programming languages ;-). /be
(In reply to comment #1) > I don't think anyone should implement Prolog in C or C++ and try to wedge it > into default builds as a required part of the platform. That's not good use of > time, wise addition to the trusted computing base, or particularly appealing to > the users of the Mozilla platform, who know web content languages better than > '80s logic programming languages ;-). > > /be Well, Prolog is still taught in AI courses across the globe, and used quite a lot in that area - so it definitely has its uses still :-). Also, instead of implementing our own fully-fledged prolog implementation, wouldn't it be better to reuse existing things? SWI-Prolog (http://www.swi-prolog.org/) has C++ bindings - would those be of any use?
Develop an extension. It is highly unlikely that new C++-implemented Prolog will ever become a standard part of the Mozilla platform. There is no call for it, and plenty of code/feature bloat and security hazard avoidance reasons not to. /be
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Gasp. To think that I was already hoping that we could rewrite extension management based on Prolog. And perhaps a C++ interpreter on top of swi-prolog, too.
You need to log in before you can comment on or make changes to this bug.