<apteryx>Hello Guilers! I'm trying to define a 'define-with-source' macro that'd expand to a procedure definition and also a directive to set the source to the newly defined procedure: https://paste.debian.net/1202204/. For some reason the 'set-procedure-property!' doesn't work as intended; (procedure-source PROC) returns #f.
<leoprikler>apteryx: If I put the entire thing into (eval-when (load) ...) and load the compiled go, it also works
<apteryx>I think it's safe to do the define at expansion time, but the set-procedure-property! needs the procedure object to exist, which not being a top level syntax is not guaranteed to be at expansion time, IIUC.
<leoprikler>oh, so you mean it breaks if you have a procedure-local define?
<apteryx>What do you mean by procedure-local define?
<rlb>wingo: I'm don't yet completely understand the code that was changed, but I wondered if guarding it so that it only operates on EOL, not nil, would still accomplish what was needed. It does appear to fix the problems with lokke:
<taylan>IMO pragmatism above semantic purity is preferable whenever it won't cause (more) headaches down the line. there's already some headaches #nil will invariably cause, but I think making it equal? to '() will actually reduce them.
<leoprikler>making #f equal to '() will cause more headaches
<leoprikler>Even if that is true, I don't think that gives us the right to make some "equalities" more equal than others
<taylan>basically, (equal? '() #nil) => #f means that any use of equal? involving lists will "break" when an Elisp list is involved. OTOH (equal? '() #f) => #f will only "break" when an Elisp #nil intended as a Boolean involved.
<leoprikler>what if you have a procedure, that returns a list, including the empty list on success and #f for failure?
<taylan>we're assuming this is a Scheme procedure, and is called from Scheme, right? in that case you have to check (eq? result #f) anyway because (if result ...) will also break.
<leoprikler>of course emacs lisp and clojure interop will not be given, so that's one problem
<leoprikler>there will be more depending on what you decide to do with equal?
<taylan>well it has to be a Scheme procedure (otherwise it can't distinguish between empty-list and false in its return), and when called from Scheme it won't pose any problem. both 'if' and 'equal?' on its result will do the expected thing.
<taylan>unless I suppose it just so happens to return #nil when it meant empty list, because an Elisp list got in there somehow... but in that case (equal? '() #nil) and (not (equal? #nil #f)) is exactly what you want.
<taylan>values that are both true don't have to be equal? so values that are both false don't necessarily have to be equal? either...
<taylan>however, in standard Scheme, values that are both false are equal? because there is only one false value...
<leoprikler>that is true, if you take "only one value for #f" as an axiom, then Guile violates the RnRS
<taylan>in that case I think it's two different layers of "breakage" at least with respect to standard Scheme. the first being, breaking the assumption that two false values are equal? this is already the case. my proposal would add a second layer: that a true and a false value can be equal?.
<taylan>however, I would dispute that this makes the semantics of 'if' broken, because equal? isn't eqv?...
<leoprikler>taylan: (if (not (equal? a b)) (not (equal? (not a) (not b)))) <- how about this one? this one at least works for pure booleans, but not much else I guess
<taylan>leoprikler: I mulled it over a bit while driving. I would posit that (equal? #nil '()) doesn't break 'if' because for every other equality predicate EP, "iff (EP a b) then (EP (if a 1 0) (if b 1 0))" continues to hold. so we just "break" equal? so to say.