| Do My Homework and Mainstreaming Prolog
I am new to prolog and struggling with lists now. What is the best way to remove the largest number from the list? (remove the one at the front most only if it occurs more than once in the list). I know how to find the largest item from the list but do not know how to remove it. How to write "helper" predicates? E.g., remove_largest([1,3,5,9,7,4,5],X)? %largest item is 9 X=[1,3,5,7,4,5] :remove_largest([1,9,5,9,7,4,5],X)? %largest item is 9 in position 2 X=[1,5,9,7,4,5] % note that the second occurence of the largest number remains. |
You need to use something like this :
remove_nine([9|T], T).
You need to write a predicate that searches through the whole list, and when
it finds a nine, it removes it using something like the line above.
I won't tell you the whole answer, because you are learning prolog, and it will
be good for you to solve the rest of it yourself.
Quoting Martin Sondergaard in comp.lang.prolog:
> I won't tell you the whole answer, because you are learning prolog,
> and it will be good for you to solve the rest of it yourself.
>
Which is better:
I don't understand your point. Are you saying that it is better both for the individual and for the Prolog community to do this individual's homework from A to Z instead giving him a hint?...
Quoting Andrzej Lewandowski in comp.lang.prolog:
> I don't understand your point. Are you saying that it is better both
> for the individual and for the Prolog community to do this
> individual's homework from A to Z instead giving him a hint?...
My point is really a general one.
I am saying that in general there is very little Prolog entry level help to find compared with for instance Java and C/C++.
You can find numerous implementations of almost any algorithm or even smaller programs in the latter languages, wheras in Prolog it seems all you get is "invent the wheel again". Implied is "we learnt the hard way, so shall you".
Perhaps I am being too harsh on the Prolog Community, but my feeling is that it is a relatively closed one, in general.
My main question still stands: Is there really a desire within the Prolog Community to increase Prolog's popularity and usage?
> Quoting Andrzej Lewandowski in comp.lang.prolog:
>
>> I don't understand your point. Are you saying that it is better both
>> for the individual and for the Prolog community to do this
>> individual's homework from A to Z instead giving him a hint?...
>
> My point is really a general one.
>
> I am saying that in general there is very little Prolog entry level help
to
> find compared with for instance Java and C/C++.
>
> You can find numerous implementations of almost any algorithm or even
> smaller programs in the latter languages, wheras in Prolog it seems all
you
> get is "invent the wheel again". Implied is "we learnt the hard way, so
> shall you".
There are enough educational materials, both printed and on-line. Majority of Prolog books are still in print and can be purchased. There are books available on-line. Vendors have on-line tutorials. Google works perfectly if you want to find sample Prolog programs. Agree, not that many books are about Prolog as about Java and not that many Prolog materials exist as C# materials. However, taking into account the size of "Prolog niche", the amount of materials is quite substantial. The only problem, you have to invest some energy if you want to find these materials.
If somebody asks such questions as: "where I can find a tutorial", "what is the best book", "why my program doesn't work", then he/she gets immediate answer and sometimes question triggers long discussion. However, this is somehow a tradition of "Prolog community" not to answer such questions as "how to do my homework". In other words, if you want to get intelligent answer, you must ask intelligent question. "Prolog community" is not different in this respect than "C++ community" or "Java community". Check how "C++ community" reacts to "do my homework" question.
> Perhaps I am being too harsh on the Prolog Community, but my feeling
is
> that it is a relatively closed one, in general.
>
> My main question still stands:
>
> Is there really a desire within the Prolog Community to increase Prolog's
> popularity and usage?
Yes, but not by doing somebody's homework.
Quoting Andrzej Lewandowski in comp.lang.prolog:
> There are enough educational materials, both printed and on-line.
> Majority of Prolog books are still in print and can be purchased.
> There are books available on-line. Vendors have on-line tutorials.
> Google works perfectly if you want to find sample Prolog programs.
> Agree, not that many books are about Prolog as about Java and not
> that many Prolog materials exist as C# materials. However, taking
> into account the size of "Prolog niche", the amount of materials is
> quite substantial. The only problem, you have to invest some energy
> if you want to find these materials.
I can't see that there is enough. Not enough as in as in clear descriptions of a broad set of general algorithms and useful little programs that really describes the workings. All books and all sites take you just so long and not any longer.
> If somebody asks such questions as: "where I can find a tutorial",
> "what is the best book", "why my program doesn't work", then he/she
> gets immediate answer and sometimes question triggers long
> discussion. However, this is somehow a tradition of "Prolog
> community" not to answer such questions as "how to do my homework".
> In other words, if you want to get intelligent answer, you must ask
> intelligent question. "Prolog community" is not different in this
> respect than "C++ community" or "Java community". Check how "C++
> community" reacts to "do my homework" question.
The problem is that many of us who "must" learn Prolog will have only a few weeks to learn (and learn to like!) a completely new language (and most often a completely new paradigm). We encounter the language in a more or less compulsory course (often also including entry level theoretical AI which consumes education time!) in parallel with other tight courses.
We just don't have the time to invent the wheel again, to fiddle around and play with Prolog. Like it or not but Prolog is to many of us an anomaly in the education path, or becomes, because of the real (or perceived) high threshold. We just don't see what the payback will be from whatever time we allocate to try to learn the language during those few weeks.
>Yes, but not by doing somebody's homework.
I hope you understand at least in part where I'm coming from here.
Put another way:
Why don't the Prolog people/AI people (often the same, no?) use the 6-7 weeks they have with thousands and thousands of students to buy them over to their paradigm by helping them over that threshold? That would enable more of the students to drive deeper into Prolog and possibly finish the course with a desire to take that vital "2nd course".
Again (yeah I'm today's parrot... :-) ): Is there really a desire within the Prolog Community to increase Prolog's popularity and usage?
On Sat, 13 Mar 2004 20:17:45 +0100, anders t wrote:
> Quoting Andrzej Lewandowski in comp.lang.prolog:
>
>> There are enough educational materials, both printed and on-line.
>> Majority of Prolog books are still in print and can be purchased.
[...]
>> if you want to find these materials.
>
> I can't see that there is enough. Not enough as in as in clear descriptions
> of a broad set of general algorithms and useful little programs that really
> describes the workings. All books and all sites take you just so long and
> not any longer.
>
I don't buy the argument. Examples:
Ivan Bratko, Prolog Programming for Artificial Intelligence. Over 100 programs available from book web site, starting from sorting, searching, trees and such, ending with some quite advanced problems as expert systems, machine learning and inductive programming,
T. van Le, Techniques of Prolog Programming with Implementation of Logical Negation and Quantified Goals. Same as above - a lot of programs covering basic algorithms and advanced topics - expert ssystems, simulation, natural language. Programs not available on line but on attached diskette,
Michael Covington and others, Prolog programming in Depth. As above, over 100 programs from basics to advanced. All programs available on author's FTP server.
In addition, last 2 books are good for people doing "paradigm shift" - there is a comparison of "conventional" (i.e. procedural) and logical approach.
There is also older book, Helder Coehlo, Jose C. Cotta, Prolog by Example: How to Learn Teach and Use it. Available only in libraries this book has ONLY examples - sample problems with solutions. Over 400 pages of sample programs.
Finally, web sites, such as the following:
http://www.hta-bi.bfh.ch/~hew/informatik3/prolog/p-99/"P-99: Ninety-Nine Prolog Problems... The purpose of this problem collection is to give you the opportunity to practice your skills in logic programming. [...] The problems have different levels of difficulty. Those marked with a single asterisk (*) are easy. If you have successfully solved the preceeding problems you should be able to solve them within a few (say 15) minutes. Problems marked with two asterisks (**) are of intermediate difficulty. If you are a skilled Prolog programmer it shouldn't take you more than 30-60 minutes to solve them. Problems marked with three asterisks (***) are more difficult. You may need more time (i.e. a few hours) to find a good solution..." Do you need more?
> The problem is that many of us who "must" learn Prolog will have only
a few
> weeks to learn (and learn to like!) a completely new language (and most
> often a completely new paradigm). We encounter the language in a more or
> less compulsory course (often also including entry level theoretical AI
> which consumes education time!) in parallel with other tight courses.
You "must" learn calculus, circuit theory, computational complexity. Do you complain about these topics as you complain about Prolog?...
> We just don't have the time to invent the wheel again, to fiddle around
and
> play with Prolog. Like it or not but Prolog is to many of us an anomaly
in
> the education path, or becomes, because of the real (or perceived) high
> threshold. We just don't see what the payback will be from whatever time
we
> allocate to try to learn the language during those few weeks.
Do you have any "payback" for whatever time you allocate to learn calculus or linear algebra?...
> Put another way: > > Why don't the Prolog people/AI people (often
the same, no?) use the 6-7
> weeks they have with thousands and thousands of students to buy them over
> to their paradigm by helping them over that threshold? That would enable
> more of the students to drive deeper into Prolog and possibly finish the
> course with a desire to take that vital "2nd course".
Consider my posting a "help". What other "help" you are expecting?...
> Again (yeah I'm today's parrot... :-) ): Is there really a desire within
> the Prolog Community to increase Prolog's popularity and usage?
What is "Prolog community"?... What regards me, I consider myself a member of "Prolog community" to the same extent as a member of "Black&Decker electric drill community". I am using Prolog as a tool and electric drill as a tool. I really don't care whether they are popular or not. And I don' develop emotional attachment towards tools.
Andrzej Lewandowski wrote:
> On Sat, 13 Mar 2004 20:17:45 +0100, anders t wrote:
>
>> The problem is that many of us who "must" learn Prolog will have only
a few
>> weeks to learn (and learn to like!) a completely new language (and
most
>> often a completely new paradigm). We encounter the language in a more
or
>> less compulsory course (often also including entry level theoretical
AI
>> which consumes education time!) in parallel with other tight courses.
>>
> You "must" learn calculus, circuit theory, computational complexity.
> Do you complain about these topics as you complain about Prolog?...
This is not a very good argument. I think it is a valid argument to state that a proffesional computer scientist should be familiar with all major paradigms and not with the few that happen to be the most popular in the commercial world today. Being proffesional means you can reason about what you are doing and that requires a broader view. Each day I'm programming (quite often :-) it helps me to think about the problem at hand in the most suitable paradigm, even if other requirements force me to implement it in a less suitable paradigm. Likewise it is useful to know about logic, even though you can not/hardly use it for programming.
I think that problem is that students don't want to study any more, they just want quickly acquire skills that they can sell immediately on the job marked.
Tell me what's wrong with that...?
Perhaps you really wanted to say something else, Andrzej?
anders t wrote:
> Quoting Andrzej Lewandowski in comp.lang.prolog:
>
>> I think that problem is that students don't want to study any more,
>> they just want quickly acquire skills that they can sell immediately
>> on the job marked.
>
> Tell me what's wrong with that...?
> Perhaps you really wanted to say something else, Andrzej?
This is exactly what I wanted to say. Some students don't see the difference between the university and vocational school.
Forgive me but your interpretation of what you said does not match with mine. In my interpretation you said that "it is wrong to aquire sufficient skills, while using as little resources and time as possible, to gain maximum profit from the aquired skills".
I think what you really want to say is that you dislike cheating, no.
anders t wrote:
> The problem is that many of us who "must" learn Prolog will have only a
> few weeks to learn (and learn to like!) a completely new language (and
> most often a completely new paradigm). We encounter the language
> in a more or less compulsory course (often also including entry level
> theoretical AI which consumes education time!) in parallel with other
> tight courses.
> [...]
> We just don't have the time to invent the wheel again, to fiddle around
> and play with Prolog.
If you don't have time to play with Prolog, then you will never enjoy Prolog.
If you do not have time to write simple Prolog code, then you will not learn to write Prolog code without difficulty. Instead, you will only have Prolog assignments that are hard for you, you will never have the pleasure of writing Prolog code that you can get working easily.
Is there any point in "being taught" Prolog and only having assignments that you struggle with? If this is your only experience of Prolog, then of course you will not want to use Prolog again.
The only way to learn to write Prolog code is to practice using Prolog. Write simple Prolog code until you have the hang of it. Then you will enjoy Prolog, and will want to learn more.
> Like it or not but Prolog is to many of us an anomaly in
> the education path, or becomes, because of the real (or perceived) high
> threshold. We just don't see what the payback will be from whatever time
> we allocate to try to learn the language during those few weeks.
If sounds like your experiences of Prolog have not been good ones.
I taught myself Prolog, using Ivan Bratko's excellent book, and using a free Prolog interpreter that I downloaded. I mostly enjoyed the experience.
Perhaps when you have finished your course, if you have the time, you can teach yourself Prolog in the same way. Or instead of using Ivan Bratko's book, you can try working your way through the Prolog tutorial called "Learn Prolog Now!", this is good too.
But I suspect that the experiences that you have had with Prolog so far have not encouraged you.
(Details of the book by Ivan Bratko and the tutorial are in the FAQ for this newsgroup, if you want them.)
> Why don't the Prolog people/AI people (often the same, no?) use the 6-7
> weeks they have with thousands and thousands of students to buy them over
> to their paradigm by helping them over that threshold?
When you refer to "Prolog people", are you referring to University lecturers ?
I'm not a University person. I'm an amateur programmer using my home computer.
Should you be addressing your question to University lecturers who teach Prolog ?
> That would enable
> more of the students to drive deeper into Prolog and possibly finish the
> course with a desire to take that vital "2nd course".
Yes, if I was teaching an introductory course in Prolog at a University, I would try to give students a good introduction to the basics only. In an introductory course, I would not use Prolog lists at all, I would leave that for a second course, a more advanced course in Prolog.
> Again (yeah I'm today's parrot... :-) ): Is there really a desire within
> the Prolog Community to increase Prolog's popularity and usage?
I don't think that the Prolog Community as a whole has any desires.
I am an individual, not a community.
As an individual, I sometimes like to help people who send in questions to this discussion group. But I don't think that I have any way to increase Prolog's popularity. If I could increase Prolog's popularity, I would, but I don't know any way of doing that. So just think of me as someone who occasionally looks at this Prolog discussion group, and who answers questions here.
I'm not even sure if there really is a "Prolog community".
Now for a change of subject.
If someone sends in an easy Prolog question to this discussion group, I could send in the whole answer to his problem, and sometimes I have done that.
But if we do that for someone learning Prolog, for us to write the whole answer if not really a way to do a favour to a Prolog novice. All Prolog novices have to write Prolog code themselves, until they can do it without much difficulty, or they will never learn how to use Prolog, and they will never want to use Prolog.
I wasn't sure if the clue I gave to Yupar Nyo was enough for him to solve the problem. If he still can't solve the problem, that's OK, he can ask us again, and I can give him more clues. Or perhaps if he asks again, someone will send him the whole answer. My reply to Yupar was not meant to be final : if my clue was not enough to help him then I hope he will ask again.
anders t wrote:
> Quoting Andrzej Lewandowski in comp.lang.prolog:
>> Yes, but not by doing somebody's homework.
>
> I hope you understand at least in part where I'm coming from here.
>
> Put another way:
>
> Why don't the Prolog people/AI people (often the same, no?) use the 6-7
> weeks they have with thousands and thousands of students to buy them over
> to their paradigm by helping them over that threshold? That would enable
> more of the students to drive deeper into Prolog and possibly finish the
> course with a desire to take that vital "2nd course".
So are you suggesting that the "thousands and thousands of students" who are learning Prolog should swamp this newsgroup with trivial questions?
Or are you suggesting that people who teach Prolog do so in a way different from people who teach other sorts of programming? If so, I don't see any evidence of that. My experience of teaching any sort of programming is that students need to be encouraged to think through it themselves and that sometimes if they are show answers too early they never properly learn how to program.
Right now I am teaching a course in programming (not in Prolog however) and as an experiment I interviewed those stuents on the course who did badly on the mid-term test. I found a common feature of these students was an over-readiness to jump to model answers or to seek help without thinking it through first. When I asked these students to demonstrate their lab work, they showed me model answers they'd copied, and sometimes trivially modified and said "Oh, I looked through the answers and now I understand it". They didn't understand it - these are people who after a term and a half of learning to program (in Java actually) couldn't string together half a dozen lines of syntactically correct code that resembled a correct solution.
Quoting Matthew Huntbach in comp.lang.prolog:
> So are you suggesting that the "thousands and thousands of students" who
are >learning Prolog should swamp this newsgroup with trivial questions?
No.
> Or are you suggesting that people who teach Prolog do so in a way different
> from people who teach other sorts of programming? If so, I don't see any
> evidence of that. My experience of teaching any sort of programming is
that
> students need to be encouraged to think through it themselves and that
> sometimes if they are show answers too early they never properly learn
how
> to program.
>
> Right now I am teaching a course in programming (not in Prolog however)
and
> as an experiment I interviewed those stuents on the course who did badly
on
> the mid-term test. I found a common feature of these students was an
> over-readiness to jump to model answers or to seek help without thinking
it
> through first. When I asked these students to demonstrate their lab work,
> they showed me model answers they'd copied, and sometimes trivially modified
> and said "Oh, I looked through the answers and now I understand it". They
> didn't understand it - these are people who after a term and a half of
> learning to program (in Java actually) couldn't string together half a
> dozen lines of syntactically correct code that resembled a correct solution.
Generally, the guys who have responded to my various posts here, present thoughtful arguments and insights for which I thank.
While I, also in general, certainly agree that practical assignments is must in order to really learn, I must still highlight that the problem is that Prolog really is something new to anyone who has never dealt with declarative programming or, for that matter, heavy list programming.
We don't seem to get the time to let things mature. Especially in a combined AI/Prolog course we get 3-6 hours to learn how Prolog (I guess generally, declarative programming) works and then we are supposed to be off with solving (simpler) AI problems.
How many students start solving (simpler) AI problems or equivalents in OO programming after three hours of learning Java as a first OO language? There will of course always be geniuses who handle this perfectly, but geniuses alone can't support the Software market with the manpower needed.
Perhaps our brains are indeed destroyed by functional programming, but that's just another incentive to be more gentle with us students, in order to not repel us from Prolog/Declarative programming.
Also, it isn't helping us students that Prolog is diversified between (competing(??) implementations.
Noone has still not really answered my now (in)famous question (a bit rephrased):
Is there a true interest among Prolog theoreticists and practitioners to popularize Prolog and perhaps make it a mainstream language, like Java, C++, C#, or is there a desire to protect a territory? (I'm not necessarily saying that the latter would be something bad, I just want to establish an understanding.)
anders t wrote:
> Is there a true interest among Prolog theoreticists and practitioners to
> popularize Prolog and perhaps make it a mainstream language, like Java,
> C++, C#,
There's no consensus on how to "mainstream" Prolog, and no evidence that Prologists would devote significant effort to a common path rather than pursuing individual interests which tend to fragment, rather than strengthen, Prolog as a whole.
I find the Prolog FAQ depressing, with its list of proprietary and idiosyncratic implementations and extensions of Prolog, many of them dormant or defunct, with no viable way of combining their innovations. Indeed I doubt that any of them were developed with much regard to this: Prolog is currently much less than the sum of its parts.
Sadly, most of the creative Prologists are associated with exactly one (or other) of these implementations; perhaps we need some other focus, e.g. a neutral working group to develop APIs for embedding Prolog in other languages, in IDEs, in web app servers etc. Any nominations?
If we look at what has made RDBMSs so widely used and usable, a lot of it is not very sexy or theoretical, but mundane and necessary stuff for transactions, recovery, APIs for programmatic use etc, and it's not surprising that few want to contribute such work to Prolog while there is neither consensus on how this sort of stuff should be structured, nor even consensus on it being worth having at all.
Nevertheless, I haven't quite given up hope :-)
Paul Singleton wrote:
> anders t wrote:
>
>> Is there a true interest among Prolog theoreticists and practitioners
to
>> popularize Prolog and perhaps make it a mainstream language, like Java,
>> C++, C#,
>
> There's no consensus on how to "mainstream" Prolog, and
> no evidence that Prologists would devote significant effort
> to a common path rather than pursuing individual interests
> which tend to fragment, rather than strengthen, Prolog as
> a whole.
This is a difficult topic with lots of different interrests. Commercial vendors have an interest to lock users into their system and non-commercial `vendors' have an interest in moving forward in terms of scientific contribution and/or pure functionality. Despite the clear common interrest of all maintainers of some implementation of the Prolog language it is a very hard task to get anything going.
Possibly one problem is that realisation of a simple implementation of the language is too easy, which let to too many of them :-)
I've tried to coordinate two attempts, but it turns out this really requires a fulltime job which I, like many of us, cannot affort as well as skills I do not posses. Standardisation should be at the top of our priority list, but it requires either a very strong partner (like W3C for the semantic web) or some sort of functioning decentralised infrastructure.
> Nevertheless, I haven't quite given up hope :-)
Good!
I think you should refer to the ISO standard for Prolog. All "mainstream" Prologs: IF/Prolog, SICStus Prolog etc do conform to this standard. There are a couple of industry exceptions PDC Prolog and LPA Prolog (please correct me if latest versions are now ISO conforming.)
The standard is a good one, it makes excellent definition of errors be they type or runtime errors. It also defines a good subset of predicates that provide all that you need.
Since the standard was completed there has been little or no need to modify it. Extending it to include modules and constraints was on the agenda, but never came to fruition.
Andrew R. Verden wrote:
> I think you should refer to the ISO standard for Prolog.
It would have been nice to quote some text, so we know to what you are refering.
> All "mainstream" Prologs: IF/Prolog, SICStus Prolog etc do
> conform to this standard. There are a couple of industry exceptions
> PDC Prolog and LPA Prolog (please correct me if latest versions are
> now ISO conforming.)
>
> The standard is a good one, it makes excellent definition of errors
> be they type or runtime errors. It also defines a good subset of
> predicates that provide all that you need.
There are many valid complaints on this standard. Nevertheless it is indeed adopted by almost all todays implementations which is a very good thing in itself. The trouble however is that its far too limited and it is still extremely hard to write even a very trivial program that runs on all these ISO compliant Prolog systems. What about a language without an accepted module system? Without a standard library? Without a standard interface to the outside world?
> Since the standard was completed there has been little or no need
> to modify it. Extending it to include modules and constraints was
> on the agenda, but never came to fruition.
Sadly ...
For the ISO Standard definition to Prolog please see www.iso.org search for Prolog.
There is also a modules definition which I think is very close to what IF/Prolog implements, but I am not 100% sure on this as I have not read the document. I also think this modules document has largely been ignored by the Prolog implementors and suppliers!
Overall though I do not believe Prolog is good as a mainstream language. It is very very good at modelling problems in a declaratve way and search strategies and compilers and parsing... In these areas it has been successful to a certain mainstream extent and is still used for all of these, even after some 20 years since the first commercial Prologs became available.
Many products also support Java APIs through easy interface definition or through auto-discovery. In any application development it is worth separating the GUI from the engine, and foreign API componenents should not be too deeply embedded into an application. Clear interfaces and modules help an application migrate through different platforms and GUIs and customers existing software.
This ease of compatibility is what makes it worth buying a decent Prolog system, in the same way one might buy a decent database. The decent vendor (us especially :-)) will continue to supply the future interfaces and try to stay one step ahead of what the users require.
It is not fair though to blame the Prolog langauge for its lack of interfacability into mainstream applications. The problem of finding a compatible set of componenets on compatible operating systems remains, regardless of whether or not Prolog is in the equation.
The computer industry as a whole has moved away from standardisation, at the expense of quality, and the benefit of speed to market. The ISO Prolog standard took more than 10 years to formulate and is one of the better standards, it actually re-used other standards usually standards have their own definition of an integer... see the C/C++ standard in comparison.
anders t wrote:
> Quoting Matthew Huntbach in comp.lang.prolog:
>> Or are you suggesting that people who teach Prolog do so in a way different
>> from people who teach other sorts of programming? If so, I don't see
any
>> evidence of that. My experience of teaching any sort of programming
is that
>> students need to be encouraged to think through it themselves and that
>> sometimes if they are show answers too early they never properly learn
how
>> to program.
>
> While I, also in general, certainly agree that practical assignments is
> must in order to really learn, I must still highlight that the problem
is
> that Prolog really is something new to anyone who has never dealt with
> declarative programming or, for that matter, heavy list programming.
>
> We don't seem to get the time to let things mature. Especially in a
> combined AI/Prolog course we get 3-6 hours to learn how Prolog (I guess
> generally, declarative programming) works and then we are supposed to be
> off with solving (simpler) AI problems.
>
> How many students start solving (simpler) AI problems or equivalents in
OO
> programming after three hours of learning Java as a first OO language?
> There will of course always be geniuses who handle this perfectly, but
> geniuses alone can't support the Software market with the manpower needed.
Prolog is a very simple language. There isn't a huge amount of syntactical constructs to master. The basics of Prolog programming *can* be put across very simply in a few hours. After that, what else is there to do but to go through examples, and my experience is that going through examples by doing them yourself is the only way to really learn. In a language like Java there are a lot more constructs to learn - you have to explain variables, then the procedural structures, then methods, then objects, them inheritance. Obviously this is going to take longer than it takes to explain the little bit of syntax and operatonal behaviour that is all Prolog is. So I think learning Prolog is better compared to learning just one aspect of Java. For example, the basic control flow aspects of Java should certainly be learnable to the point where students would be expected to solve siple problems in them in the space of 3-6 hours.
> Perhaps our brains are indeed destroyed by functional programming, but
> that's just another incentive to be more gentle with us students, in order
> to not repel us from Prolog/Declarative programming.
When you say "functional programming" I assume you actually mean "procedural programming", since functional programming is another form of declarative programming. Perhaps it depends on how you have been taught programming previously. Many people seem to find recursion incredibly difficult to handle, and this is the basis for them finding Prolog difficult since in Prolog you can't escape from using recursion. But recursion can be taught in other languages. When I teach Java, I give my students a simple list abstract data type, and get them to write simple-list handling programs similar to those one would write in Prolog. I'd expect them to be able to do this after a few hours teaching them about lists and recursion, so I don't see that as much different to what you say about learning Prolog.
> Also, it isn't helping us students that Prolog is diversified between
> (competing(??) implementations.
In what way? The basics of Prolog do not alter between the various implementations, and surely its these basics that a novice Prolog programmer is going to be dealing with. I would not expect the sort of programs a novice Prolog programmer would write to be any different no matter what implementation is being used.
> Noone has still not really answered my now (in)famous question (a bit
> rephrased):
>
> Is there a true interest among Prolog theoreticists and practitioners to
> popularize Prolog and perhaps make it a mainstream language, like Java,
> C++, C#, or is there a desire to protect a territory? (I'm not necessarily
> saying that the latter would be something bad, I just want to establish
an
> understanding.)
No, clearly not. How on earth would it serve anyone who wants to promote a language to deliberately try and put people off it? What a ridiculous point you are making here.
I don't think Prolog is competing to be a mainstream language because I think it has flaws that mean it can't be. It has been around a long time, and it's a tribute to its very simple elegant design that it hasn't changed much since first introduced and all attempts to introduce more complex but "better" logic languages haven't really succeeded. However, I don't think it really scales up to what is required to produce large scale software for modern computing systems. So I think it's something best taught as an interesting idea that helps get you thinking and is worth a few hours on the curriculum, rather than as a major topic you are going to need to become a real expert in and spend many long hours learning.
Matthew Huntbach wrote:
> I don't think Prolog is competing to be a mainstream language
> because I think it has flaws that mean it can't be.
Could you please explain which flaws? Because I can't see them...
Such things as the lack of a type system, lack of a module system, poor handling of interaction ...
| Is there an N-solutions predicate in Mercury?
Does Mercury have a predicate that finds no more than N solutions
to a goal? I didn't see one in the docs, but perhaps I'm not looking
in the right place.
/* n_solutions.pl by Tom Breton, 27 Feb 2004, Copylefted under terms
of the Gnu Public License. */
%%Impure, non-declarative, but gets the job done.
%%Find no more than N solutions of the predicate Goal.
%%Since standard Prolog has no lambda, we use `Var' + `Goal' form.
n_solutions(Var,Goal,All_sols,N) :-
gensym(found,Key),
limited_try(Var,Goal,Key,N),
%%Collect the recorded solutions into `All_sols'.
findall(Solution, recorded(Key,Solution), All_sols),
%%Clean up the database.
eraseall(Key).
%%Solution is a variable in `Goal' that one wants to store.
%%Since standard Prolog has no lambda, we use `Var' + `Goal' form.
%%`Key' must be suitable for recordz/2.
%%Solutions are returned in the database as
%%`recorded(Key,A_solution)'.
limited_try(Solution,Goal,Key,N) :-
%%Probably no reason for caller to use N = 0 etc, but catch it
%%anyways.
(N =< 0) -> true
;
((
%%The engine.
Goal,
%%Record the solution. `Goal' and `Solution' had to be
%%linked together by caller.
recordz(Key,Solution),
(
%%If there's already a surfeit of solutions, stop searching
%%and discard Goal's remaining choice-points.
(num_keyed_records(Key,Num_sols), (Num_sols >= N)) -> !
;
%%Otherwise keep looking, by failure-driven loop
fail))
;
%%Use of failure-driven loop risks making success/failure confusing to
%%the caller. So a final branch always succeeds and allows no
%%choice-point.
!).
num_keyed_records(Key,Num_sols) :-
findall([], recorded(Key,_), All_sols),
length(All_sols, Num_sols).
eraseall(Key) :-
(recorded(Key, _, Reference), erase(Reference)) ->
eraseall(Key)
;
true.
|
You can do that using the `do_while' predicate in the `std_util' module. That
predicate lets you use any condition you like to decide when to stop finding
solutions -- for example you can decide to stop based on the number of solutions
found so far, based on user input, or even based on the time of day.
I have enclosed an example below.
%------------------------------------------------------------%
% An example program to illustrate the use of the `do_while'
% predicate in Mercury. This program calls a nondeterministic
% predicate hello/1, and prints the first N solutions it finds
% (in this case for N = 2).
:- module n_solutions.
:- interface.
:- import_module io.
:- pred main(io__state::di, io__state::uo) is cc_multi.
:- implementation.
:- import_module std_util, bool, int.
main(!IO) :-
N = 2,
do_while(hello, get_next, {!.IO, N}, {!:IO, _}),
print("Done\n", !IO).
:- pred hello(string::out) is multi.
hello("Hello, world\n").
hello("Good day, world\n").
hello("Greetings, world\n").
:- pred get_next(string::in, bool::out, {io, int}::di, {io, int}::uo)
is det.
get_next(String, More, {IO0, Max0}, {IO, Max}) :-
print(String, IO0, IO),
More = (Max0 > 1 -> yes ; no),
Max = Max0 - 1.
Isn't this rather, er, non-logical for Mercury? And, at the risk of getting flamed :-), doesn't this mean that you can simulate the effect of the Prolog "cut" in Mercury? I thought that Mercury was striving to be more logical than that.
I think the term you're looking for is "referentially transparent" or "pure".
If I understand right, no, the call to `do_while/4' can be replaced by its results (ie, the unifications that result) and the behavior will be the same.
Fergus Henderson wrote:
> You can do that using the `do_while' predicate in the `std_util' module.
> That predicate lets you use any condition you like to decide when to
> stop finding solutions -- for example you can decide to stop based on the
> number of solutions found so far, based on user input, or even based on
> the time of day.
Jamie Andrews writes:
> Isn't this rather, er, non-logical for Mercury? And, at
> the risk of getting flamed :-), doesn't this mean that you can
> simulate the effect of the Prolog "cut" in Mercury? I thought
> that Mercury was striving to be more logical than that.
Mercury strives to be practical as well as referentially transparent, which is why we have developed mechanisms that often allow us to achieve both objectives at the same time. Do_while is declared to be cc_multi, which means that its declarative semantics says that it may have many solutions, but its operational semantics will compute just one. The comment at the start of do_while's definition in the Mercury standard library describes both semantics:
% This is a generalization of unsorted_aggregate which allows the
% iteration to stop before all solutions have been found.
% Declaratively, the specification is as follows:
%
% do_while(Generator, Filter) -->
% { unsorted_solutions(Generator, Solutions) },
% do_while_2(Solutions, Filter).
%
% do_while_2([], _) --> [].
% do_while_2([X|Xs], Filter) -->
% Filter(X, More),
% (if { More = yes } then
% do_while_2(Xs, Filter)
% else
% { true }
% ).
%
% Operationally, however, do_while/4 will call the Filter
% predicate for each solution as it is obtained, rather than
% first building a list of all the solutions.
Since do_while is cc_multi (as is unsorted_solutions), it can only be called in a committed choice context ("cc" means "committed choice"), i.e. a context in which a goal may have more than one solution to choose from, but the execution will commit to one of those solutions. There are only three ways you can create a committed choice context.
The first way is if main is also cc_multi. In this case, the declarative semantics of the program as a whole may have more than one solution, while operationally, an execution of the program will return one of these. There are compiler options that allow programmers to control which solution this is.
The second way is a goal that may have more than one solution has all its output variables existentially quantified away; the usual case where this occurs is when the condition of an if-then-else checks whether a collection (list, set, etc) has an element with a specific property. In this case, all we care about is whether a solution exists or not; the bindings associated with the solution are immaterial.
The third way is explicit use of a builtin predicate such as promise_only_solution, which is effectively a determinism cast that allows the rest of the program to treat a cc_multi computation as if it were a deterministic (det) computation.
The first two ways preserve the declarative semantics of the program. The third is basically an assertion by the programmer that he/she is relying on the operational semantics, and wishes to build the declarative semantics of the surrounding code on the operational semantics, not the declarative semantics, of the code inside the determinism cast.
Determinism casts are intended to be used only by experts, and only when necessary. The Mercury compiler has roughly ten thousand predicates, and only ten occurrences of promise_only_solution. I don't have hard data on the frequency of cuts in large-scale Prolog programs, but it is safe to bet that it is a lot more than one per thousand predicates.
Tom Breton writes:
> If I understand right, no, the call to `do_while/4' can be replaced by
> its results (ie, the unifications that result) and the behavior will
> be the same.
That is correct, but that is not by itself sufficient to give do_while a declarative semantics.
Zoltan Somogyi wrote:
> Since do_while is cc_multi (as is unsorted_solutions), it can only be called
> in a committed choice context ("cc" means "committed choice"), i.e. a context
> in which a goal may have more than one solution to choose from, but the
> execution will commit to one of those solutions. There are only three ways
> you can create a committed choice context.
> The first way is if main is also cc_multi. In this case, the declarative
> semantics of the program as a whole may have more than one solution,
> while operationally, an execution of the program will return one of these....
> The second way is a goal that may have more than one solution has all its
> output variables existentially quantified away; ...
I don't think that either of these is what the original poster (Tom Breton) wanted; he seemed to want something that would return no more than N solutions, and then go on computing as if those were the only solutions. For instance, if p(X) returned first X=a, then X=b, then X=c on backtracking, he seemed to want a construct "foo" such that foo(p(X), 2) would return just X=a and X=b; so that the goal "foo(p(X), 2), X=c" would fail even though "p(X), X=c" is true declaratively. But I could have misinterpreted what he wanted.
> The third way is explicit use of a builtin predicate such as
> promise_only_solution, which is effectively a determinism cast
> that allows the rest of the program to treat a cc_multi computation
> as if it were a deterministic (det) computation....
> Determinism casts are intended to be used only by experts, and only when
> necessary.
Hmm... I say the same thing about assert and retract... that doesn't seem to stop Prolog learners from jumping to the conclusion that theirs is the one case in a million where they really need assert/retract... but I take your point that this is flagged in the documentation as a "bad thing" that shouldn't have to be used by anyone for most ordinary applications. Still, I find it interesting that you came to the conclusion that this equivalent of a "red cut" is necessary for practical purposes in some cases.
> The Mercury compiler has roughly ten thousand predicates,
> and only ten occurrences of promise_only_solution. I don't have hard data
> on the frequency of cuts in large-scale Prolog programs, but it is safe
> to bet that it is a lot more than one per thousand predicates.
A closer comparison would be to cuts that are not negation-replacement cuts (put in in order to avoid calling a predicate again in a later clause with "not" in front of the call), but which still alter the solutions returned. It's safe to bet that this also is more than one per thousand predicates, but it could be lower than one per 100 predicates. A careful Prolog programmer will have as little reason to do this in most cases as a Mercury programmer. The difference between one in 100 and one in 1000 is probably due to errors on the part of the Prolog programmer.
The value of the Mercury mode and determinism system is that we are able to enlist the help of the compiler in finding such errors. The Prolog programmer is totally on their own (well, with their trusty copy of O'Keefe by their side), and probably often fails to find them.
However, it seems that no pragmatic language can achieve the goal of being 100% declarative. Prolog systems, having been designed in the late 70s and early 80s, set the bar lower than Mercury, but Mercury still doesn't set the bar at 100%.
I wrote:
> The first way is if main is also cc_multi. In this case, the declarative
> semantics of the program as a whole may have more than one solution,
> while operationally, an execution of the program will return one of these....
> The second way is a goal that may have more than one solution has all its
> output variables existentially quantified away; ...
Jamie Andrews writes:
> I don't think that either of these is what the original
> poster (Tom Breton) wanted;
I don't think so either. I just mentioned them as part of my "thorough response" to show that committed choice contexts are always declarative unless the programmer says he/she explicitly wants to use them in an operational manner.
> The value of the Mercury mode and determinism system is
> that we are able to enlist the help of the compiler in finding
> such errors.
Yes, exactly. When Mercury was new, lots of people were impressed by its speed, but few seemed to believe us when we said that the type, mode and determinism systems were there more to help programmers find bugs than to help the compiler generate fast code.
> However, it seems that no pragmatic language can achieve
> the goal of being 100% declarative. Prolog systems, having been
> designed in the late 70s and early 80s, set the bar lower than
> Mercury, but Mercury still doesn't set the bar at 100%.
I don't think you can set the bar to 100% and still get performance comparable to imperative languages on today's von Neumann architectures, except for some specialized domains (e.g. number crunching in Sisal). Relaxing the target from 100% to 99% can make a significant difference in performance (for example, it is a lot easier to build a fast ML implementation than a fast implementation of Haskell). As long as the impure parts are hidden behind abstraction barriers with declarative interfaces, you don't lose the benefits of being purely logical in the rest of the system.
Jamie Andrews wrote:
> I don't think that either of these is what the original
> poster (Tom Breton) wanted; he seemed to want something that
> would return no more than N solutions, and then go on computing
> as if those were the only solutions.
Correct, but when Fergus described the `do_while' predicate, that gave me what I wanted.
Jamie Andrews wrote:
> Isn't this rather, er, non-logical for Mercury? And, at
> the risk of getting flamed :-), doesn't this mean that you can
> simulate the effect of the Prolog "cut" in Mercury? I thought
> that Mercury was striving to be more logical than that.
Not at all! Mercury supports committed choice nondeterminism wherein you only get *one* of the possible solutions to a nondeterministic goal. In order to ensure the declarative semantics of the program are preserved, you are not allowed to backtrack into a committed choice procedure, which in practice makes their use somewhat restrictive. However, there are situations such as with do_while where the alternative (in this case enumerating all solutions, sorting them, then choosing a prefix of the resulting list to process) is unacceptably costly.
This is quite different to Prolog's cut operator which really can (and usually does) destroy the declarative reading of a program.