Reasons for sticking with SWI, as opposed to Mercury

I’m an enthusiastic amateur and I like SWI very much. I’ve often been tempted, however, to put my energies into Mercury instead because of its promises of smarter compile-time checks etc. I only write medium-sized programs (10000 lines max); I do find I spend a heck of a long time debugging my code so I just wonder if- anecdotally and empirically - there’s people who have experience in both and know the real upsides to each. Thanks!

Without really answering your question, did you discover the SSU rules (Head => Body) and det/1? Since I use those, debugging time has been reduced a lot. Other recent goodies are trap/1 and gtrap/1 to quickly get the debugger at an exception. And of course, there is check/0 to do some static analysis, be it a lot less than mercury. And, last but not least the new “sweeprolog” mode for GNU emacs or the built-in Emacs clone save you a lot of work.

3 Likes

I’ve kept an eye on posts about => and I’ve dabbled with BProlog which, I think, has a similar feature. Thanks for all those suggestions as I’d be very happy to stick with SWI + new debugging aids.

I have used Mercury in the past (~10 years ago) but don’t at present, mostly because getting support was not easy but that is slowly changing.

One post of note from the creator of Mercury (Zoltan Somogyi) that has since become a key deciding factor for me was in this StackOverflow answer.

HTH

I got it from Picat. As that is a successor of BProlog, it could well come from there. Note that I made an important change though: if no rule matches it is an error. It you want that to fail you need a final clause Head => fail. The idea is the you use => typically for “functions” and no matching rule is typically a mistake. In the rare case it is not you have to make this explicit. There is also no ?=>. There is Head, Guard => Body

1 Like

6 posts were split to a new topic: Idea for SSU debugging feature