On 09/26/2015 04:42 PM,
amic...@ulg.ac.be wrote:
> The answer lies in the new behaviour of atom([]), which now returns false.
>
> The easiest fix, I suppose, is through a definition of my_atom, and
> replacement of calls to atom by calls to my_atom.
>
> my_atom(Atom) :- atom(Atom).
> my_atom([]).
That of course works. The fun thing is that the change is there
to make dynamic type checks between lists and atoms possible. So,
if you have something that is -for example- either a token or a list
of tokens, the token '[]' can be distinguished from the empty list
of tokens.
I briefly glanced through your code. I have little clue about the
purpose of the atom/1 tests in there. Of course, in classical Prolog
you can check that a list is empty using atom(List). List == [] seems
a better choice.
I think your code gets more readable if you sort out why [] is supposed
to be an atom and either replace this [] by something else or use
a different test. Of the 4 atom/1 portability problems I've analysed, 3
turned out to have been bugs from the start and 1 was just very bad
style but no real bug.
Cheers --- Jan
>
> Archie
>
>
> Le samedi 26 septembre 2015 10:36:42 UTC+2,
amic...@ulg.ac.be a écrit :
>
> Updating from version 6.6.6 to 7.2.3 I get additional, spurious
> results when running a parser designed to deal with multi-word units
> in English. The progam loads without any warning - it's only the
> results that differ. Has anybody experienced a similar misadventure.
> If anybody would care to look at the program and tell me where the
> problem lies, I would be grateful.
>
> Archie
>
> --
> You received this message because you are subscribed to the Google
> Groups "SWI-Prolog" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to
swi-prolog+...@googlegroups.com
> <mailto:
swi-prolog+...@googlegroups.com>.
> Visit this group at
http://groups.google.com/group/swi-prolog.
> For more options, visit
https://groups.google.com/d/optout.