<dnhester26>
I want to overwrite a function but I want access to the original function and call that function in the new funciton. I tried doing it with a let form but the variable with the function is basically just calling the overwritten function, so how can I do it instead?
dnhester26 has quit [Client Quit]
decweb has quit [Quit: Konversation terminated!]
JuanDaugherty has joined #commonlisp
dnhester26 has joined #commonlisp
<reb>
dnhester26: I'm not exactly sure what you want ...
dnhester26 has quit [Remote host closed the connection]
<reb>
If you have a function defined like (defun foo () 10) ... you can call it with (funcall 'foo), (funcall #'foo), and (funcall (symbol-function 'foo)).
<reb>
If you take the result of (symbol-function 'foo) and save it away somewhere, you should still be able to call it after foo is redefined ...
<|3b|>
with LET specifically, there might be some issues with when it gets evaluated, since DEFUN has compile-time side effects, but the LET isn't stored until the form is evaluated (so probably after compilation)
<dnhester26>
so would flet work instead? or how can I do it?
<dnhester26>
thanks for replying
markb1 has quit [Ping timeout: 268 seconds]
<|3b|>
storing the old function in a global (defvar etc) should work as expected though
<dnhester26>
reb: thanks, my chat disconnected, I just caught up with the logs. I will try that. I was doing (let ((old #'foo)) (defun foo ...)), will try again, thanks!
<|3b|>
flet would probably be worse, since you would probably just call the function by name inside the flet
<dnhester26>
ah, so just try defvar instead
<dnhester26>
will try it now
<|3b|>
alternately, find something in the spec saying the LET should definitely see the old definition, and then convince your implementation to fix it :)
<|3b|>
or maybe use (setf symbol-value) instead of defun
decweb has joined #commonlisp
<|3b|>
actually, i guess DEFUN doesn't have to have copile-time side effects, so it would be the stuff about compilation blocks instead?
<|3b|>
compilation units i mean
<|3b|>
or maybe compile-file?
JuanDaugherty is now known as ColinRobinson
ym has joined #commonlisp
rkazak has joined #commonlisp
<dnhester26>
no, the REPL gets sstuck in a loop, still didn't work
<dnhester26>
I did it with defvar and symbol-function, but still gets stuck in a loop :(
<|3b|>
(defun foo ()1) (defparameter *foo* #'foo) (defun foo () (print (funcall *foo*))) works here
<|3b|>
make sure you use #' and make sure you didn't have a bad definition of the function still from previous testing
<dnhester26>
thanks, will try again, weird that it didn't for me
<dnhester26>
maybe that's it
<dnhester26>
I have (defvar original-parse (symbol-function 'com.inuoe.jzon:parse))
<dnhester26>
and then `(funcall original-parse`
<|3b|>
yeah, symbol-function should be fine
dra has quit [Ping timeout: 248 seconds]
<|3b|>
hmm, possibly LET with SYMBOL-FUNCTION instead of FUNCTION / #' works too
<dnhester26>
hm, I'm doing symbol-function and defvar, why would that be different than let?
decweb has quit [Quit: Konversation terminated!]
<|3b|>
defvar should work with either
<|3b|>
let might have issues in some cases because it is in a single form
<dnhester26>
Ok, maybe I should just restart the REPL and try again tomorrow since it's late... if yours worked, then maybe my image is messed up, will try again tomorrow when I'm rested, thanks again for the help!
* |3b|
somewhat thinks LET not working with FUNCTION might be a bug in at least some cases though
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 246 seconds]
markb1 has quit [Ping timeout: 244 seconds]
gnoo has quit [Ping timeout: 244 seconds]
gnoo has joined #commonlisp
decweb has joined #commonlisp
markb1 has joined #commonlisp
decweb has quit [Client Quit]
wbooze has quit [Ping timeout: 265 seconds]
Inline has quit [Ping timeout: 265 seconds]
<dnhester26>
a bug in SBCL?
dansa has joined #commonlisp
<|3b|>
yeah
<dnhester26>
ah, never expected I would run into a bug here, I just assumed it was a result of my own ignorance of CL
bjorkintosh has quit [Ping timeout: 276 seconds]
<aeth>
Bugs happen all of the time when your code isn't particularly idiomatic!
<aeth>
That's why some people try to fuzz test
* |3b|
thinks it is reasonably idiomatic, just not very common
decweb has joined #commonlisp
<aeth>
|3b|: Well, in that particular case, it can be a regression in a particular thing that used to work, but nobody uses.
<|3b|>
though possibly not the best way to do things, since you can't redefine the wrapper without recompiling the original
<aeth>
Someone has to report regressions, after all
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
<|3b|>
and also because sbcl's behavior is easier to argue in the case of COMPILE-FILE (at least i think that was the thing that might allow it, can't find in spec atm)
<|3b|>
since it allows calling functions in the same file specially in ways that interfere with redefinition
<|3b|>
which could arguably apply to an optimized (funcall (function ...) ..) as well
<aeth>
Not a _bug_ in that it complies with the spec, but it took (probably) several years (maybe up to 6) for me to notice a regression in SBCL's 2D bounds checking removal (or the lack thereof, even in the latest (2.5.1), in code that was written in an odd way specifically to remove these bounds checks, on (according to git blame) 2019-06-11).
<aeth>
(well, up to 5 < x < 6 years)
<aeth>
(although I probably wasn't on the latest-to-that-month version)
<dnhester26>
interesting, someone suggested I just avoid this redefinition altogether and just use my own function because of how unreliable the solutions seem to be, so I probably will do that and just change the places where I used that function
<dnhester26>
I'm also only on SBCL 2.4.9 I think
<|3b|>
yeah, defining your own things is better in general
<|3b|>
overwriting functions you don't control is bad style in general
<|3b|>
imagine if other libs do that too... maybe you both 'fix' the same thing, and the fixes stack making it wrong again, or maybe they save and modify separately enough that it can overwrite your changes, etc so load order randomly breaks things
<|3b|>
or maybe they 'fix' something you thought was already right
<|3b|>
(and your 'fix' breaks what they thought was right)
<aeth>
|3b|: so it's "fine" in application code, but not in library code
<|3b|>
sort of. at least better in application code
* |3b|
frequently runs multiple "applications" in one image
<aeth>
Yes, the REPL is basically the command line
<aeth>
With threads as processes
ezakimak has quit []
<aeth>
It's actually kind of funny because you can get quite far in Common Lisp without bothering to solve nonessential problems such as "how do I launch this?"
ezakimak has joined #commonlisp
alfiee has joined #commonlisp
green has joined #commonlisp
<dnhester26>
thanks. Hm, other things I did were also overwriting things because the library owner wouldn't accept a small change to allow for flexibility to customize the code for the users, so I hd made my own fork, but then I thought I may just make it into a library and overwrite the code there instead
<dnhester26>
So you think it's better to fork it than overwrite the code?
alfiee has quit [Ping timeout: 272 seconds]
<|3b|>
yeah, a fork with a new package/system name is better than a library that changes behavior of some other library
<|3b|>
or one that just exports new versions of functions and internally uses the old library
<|3b|>
as long as people have to explicitly request the new behavior
<|3b|>
which both avoids problems of it possibly breaking things for unrelated users of the original code, and avoids people accidentally depending on the new behavior if they happened to also load something unrelated that used the new lib
HER is now known as hernan604
ColinRobinson has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]