Opened 6 months ago

Last modified 8 weeks ago

#1363 new defect

when compiled, set! will clobber previous lambda-info's

Reported by: kristianlm Owned by:
Priority: minor Milestone: 5.1
Component: unknown Version:
Keywords: Cc:
Estimated difficulty: medium


I don't really know what's going on, but set! alters the previous ##sys#lambda-info structure:

1442 klm@kth ~/chicken-5-klm ➤ cat /tmp/klm.scm
(define (foo a b c) 0)         (print foo)
(set! foo (lambda (x y z) 1))  (print foo)

1444 klm@kth ~/chicken-5-klm ➤ csc /tmp/klm.scm && /tmp/klm
#<procedure (f_218 a1 b2 c3)> ;; bad
#<procedure (foo x4 y5 z6)>   ;; good

1444 klm@kth ~/chicken-5-klm ➤ csi -s /tmp/klm.scm 
#<procedure (foo a b c)>      ;; good
#<procedure (foo x y z)>      ;; good

Change History (3)

comment:1 Changed 6 months ago by kristianlm

Note that I think it's a good idea to fix this, so that we can remove the explicitly-defined getter-with-setter info-strings of caar, caaar, cadar and all friends:

(set! caaar (getter-with-setter caaar (lambda (x y) (set-car! (caar x) y)) "(caaar p)"))

With this fix, it could just use the info-string from the getter. As of now, we can't just remove the info-strings because of this strange set! behaviour.

comment:2 Changed 4 months ago by LemonBoy

What happens here is that when we walk trough the database containing the informations gathered by the first analysis pass we only have the latest value that's been assigned to a given variable, hence set-real-name! "wires" the second lambda to the name 'foo but not the first one.
This may be fixed by calling set-real-name! in assign so that all the lambda ids are correctly associated to the variable it is bound to. This may have some adverse side effects so take this suggestion with a grain of salt.

comment:3 Changed 8 weeks ago by sjamaan

  • Estimated difficulty set to medium
  • Milestone changed from someday to 5.1
Note: See TracTickets for help on using tickets.