Page 1 of 1

Construction throws Access Violation

Posted: 17 Nov 2015 13:14
by Martin Meyer
Hello Thomas,

please check the below construction. In (VIP build 7501) 32 bit mode in works out fine, but in 64 bit mode it throws an access violation.

Best regards
Martin

Code: Select all

class facts     listA : integer* := [].     listB : integer* := erroneous.   class predicates     test : (). clauses     test() :-         ListA = listA,         listB := [0 || _ in ListA],         if [Item | _] = ListA then             stdIo::write(Item)         end if.   clauses     run() :-         test(),         stdIo::write(listB).

Posted: 17 Nov 2015 21:01
by Thomas Linder Puls
Thank you. We will investigate it.

Posted: 18 Nov 2015 8:20
by Peter Muraya
Martin,
What is this line mean to achieve:-

Code: Select all

listB := [0 || _ in ListA]
..is it to set listB to as many 0's as there are items in ListA, i.e., should it have the same effect as

Code: Select all

listB := [X || _ in ListA, X=0]
?

Posted: 18 Nov 2015 14:40
by Martin Meyer
Hello Peter,

to your questions:

Is listB := [0 || _ in ListA] to set listB to as many 0's as there are items in ListA?: Yes.

Should it have the same effect as listB := [X || _ in ListA, X=0]?: Yes.

The example code with the 0's does not make any sense. It is a radically stripped down version of a "real" program of mine, in which it's not just 0's, but a lot more stuff, which I have deleted to make the example as short as possible.

Many regards
Martin

Posted: 19 Nov 2015 6:13
by Peter Muraya
Ok, Martin. Now I know that the first argument of a list comprehension can be, not just a variable but, generally any Prolog term. Without further knowledge about how Prolog implements this internally it is difficult for anyone to see why that should raise the exemption you mentioned.

Posted: 19 Nov 2015 10:35
by Martin Meyer
The Language Reference says, that the first argument of a list comprehension must be an expression of mode procedure or erroneous. In my tests modes determ and failure have been working out too.

Regards
Martin

Posted: 19 Nov 2015 23:11
by Thomas Linder Puls
I thought it was a I wrote it in the language reference manual. And I always write procedures there so I wouldn't notice that there was no error for determ, etc. Just recently I came across some code that had a determ predicate in that place, and I thought "strange I thought it was illegal" but I didn't have time to look into it.

But now you bring it up and I can see that the reqirement was relaxed back in 2005 (so initially it was correct, but has been wrong in more than 10 years). I made the change back in 2005, but I cannot recall that it was deliberate, so I will assume it was a mistake (it could look like a copy-paste-bug).

Anyways, I will revert it back to be in line with the language refernce, which seems more sensible to me.