Oops, sorry, looks like I mixed replies of two different people on different lists and coupled my answer together in gentoo-portage-dev. I am correcting this now, but first I'll repeat the same disclaimer which I think I need to do more noticable in the write-up.
As I stated in the writeup, the "design" discussed is a simplistic model only relevant for the prototype which goal was basically to demonstrate capabilities of a particular language and nothing else. Thus note, all the comments below concern this hypothetical design I used in language demonstration, but that will probably be rethought for the real design (and there was just a tiny bit more on that on gentoo-portage-dev list). Therefore > I don't see any reasoning about versions, virtuals, constraints, slots, > updates, upgrades, downgrades, ... just because there is none. Now, the next comment is the reason I did this reply, please do not take seriously the rest :). On Friday 05 December 2003 09:46, Pieter Van den Abeele wrote: > On 05 Dec 2003, at 10:58, George Shapovalov wrote: > > To reiterate them shortly, Prolog is a really esoteric language and I > > am not > > sure we will be able to find enough people to feel comfortable about > > having > > the very core of portage-ng implemented in it. Also there might be > > issues of > > portability and efficiency.. > > My biggest concern when reading your small paper is that you chose a > deterministic approach to this problem, while in fact the problem is > non-determinisitic. Could you please elaborate? I am afraid we are thinking about slightly different things here. I stay by my thought that any important to the system tool should be dumb. If there is any uncertainty it should stop and ask, unless it was designed for a very specific situation, where it can be trusted to make the choice. Package maintaince is not such area - IMHO every user that has identical configuration should get identical results (to the extent possible. So here we are talking requirements Daniel ;)). Otherwise we are facing a disasterous consequencies with many people complaining and us being unable to reproduce anything reliably. >Also, your code (which is about 1000 lines long) > does -only- a simple dfs and topological ordering, while I can do the > same in about 10 lines in prolog and have backtracking for free. I This is anecdotal. The *traversal* code is completely localized in bc-graphs-directed-bfs_traverse.adb and is about the same 10 lines :) and is completely generic. The rest of 990 lines deal with such mundane tasks as reading the (possibly misformed) ebuilds and dealing with user (inluding minimalistic help). > I don't want to start a flame war about programming languages. That > would be totally useless because the nice thing about programming > languages is that they are all somewhat equivalent but some more > expressive than the other for a given problem. > > For my thesis and apprenticeship at the Theoretical Computer science > laboratory at the free university of Brussels (tinf.vub.ac.be), I have > been looking into these issues. The techique we have developed for > reasoning about large software configurations such as a > meta-distribution will be presented on a Gentoo meeting in the future, > and can be implemented in any language you prefer. I will have a fully > functional prototype in prolog, because that language offers some > benefits, but the idea itself can be implemented in any other language > such as Ada or friends. Ok, thanks, there wasn't that much verbal info other than "there is a prototype inplementation in prolog", but fortunately Daniel yesterday put the things into a proper perspective :). In any case my goal wasn't to push for a particular language either but to increase "awareness" :), and I now completely stay by the proper procedure. George -- [EMAIL PROTECTED] mailing list
