bugMIT/GNU Scheme - Bugs: bug #15180, char=? equal? results are...

 
 

bug #15180: char=? equal? results are (possibly) incorrect after string-set!.

Submitted by:  None
Submitted on:  Fri 09 Dec 2005 10:25:59 PM UTC  
 
Category: runtimeSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Suboptimal behavior
Status: InvalidPrivacy: Public
Assigned to: NoneOriginator Name: Charles Moss
Originator Email: -unavailable-Open/Closed: Closed
Keywords: 

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 09 Dec 2005 11:24:45 PM UTC, comment #4:

This isn't a bug. You're confused about order of evaluation of procedure arguments.

The arguments to a procedure like char=? or equal? are evaluated in an unspecified order. For interpreted code in MIT/GNU Scheme, they are currently evaluated right to left. For compiled code, the order is determined by an optimizer in the compiler.

What you are seeing is that the side effect you're performing is happening prior to both accesses, so of course the results are equal.

If you want to force evaluation order, use something like this:

(let ((c1 (string-ref string 6)))
(string-set! string 6 #\j)
(char=? c1 (string-ref string 6)))

Chris Hanson <cph>
Project Administrator
Fri 09 Dec 2005 10:58:08 PM UTC, comment #3:

You pinned it down with the order of operations. I thought while I was writing up the ``bug'' description that it may actually be a case of order of evaluation; I guess I should have let that thought come the the front of my head.

Charles Moss <czm>
Fri 09 Dec 2005 10:49:33 PM UTC, comment #2:

...actually, on further consideration: can you explain more specifically what difference you expected to see between EQUAL?, EQV?, and CHAR=? ? They are all defined to have the same semantics on character arguments.

Taylor R. Campbell <riastradh>
Project Member
Fri 09 Dec 2005 10:47:21 PM UTC, comment #1:

You are getting tripped up by the order in which operands are evaluated, which the Scheme standard does not specify: you should not rely on it. In the MIT Scheme interpreter, it happens to go right-to-left, not left-to-right. In all of your examples, the second operand to EQUAL? &c. is that in which you call STRING-SET!, so the update is reflected when the first operand, a simple STRING-REF, is evaluated afterward. You should fetch the original character first, and save it with LET, before updating the string and fetching the new character to compare the two. This might clear up your confusion.

Taylor R. Campbell <riastradh>
Project Member
Fri 09 Dec 2005 10:25:59 PM UTC, original submission:

I have attached a transcript from one of my recent Edwin sessions.

I had just read the first couple of paragraphs of the section of R5RS entitled "Storage Model" and thought I'd test out eqv? to see if the results were as described in the standard (they were). I then thought equal?, and then char=?, would produce the opposite result, but they did not. The results that they produced seem, to me, incorrect. Perhaps I do not know enough about Scheme, having only VERY casually used it for about six years, but, not only does this seem wrong to me, I can't find anything in the standard to justify the above behaviour.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #2455:  transcript.scm added by None (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 5 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 09 Dec 2005 11:24:45 PM UTCcphCategoryNone=>runtime
  StatusNone=>Invalid
  Open/ClosedOpen=>Closed
Fri 09 Dec 2005 10:25:59 PM UTCNoneAttached File-=>Added transcript.scm, #3176
  Carbon-Copy-=>Added czmoss --AT-- gmail --DOT-- com

Back to the top


Powered by Savane 3.1-cleanup1