freenode/#lisp - IRC Chatlog
Search
18:03:27
ecraven
which part of the CLHS should I look at to understand when a redefinition of a function is allowed? (interactively via SLIME on a running image)
18:04:45
anamorphic
genhash and annoyingly register-test-designator throws an error if a designator is already registered. Is there any reason why it couldn't provide a restart? I know it's a CDR2 an all, so had wondered if it's a spec thing
18:08:27
ecraven
well, can I just redefine existing any function in any package at any time, and it will work?
18:10:53
djeis[m]
On some implementations redefining functions in the CL packages triggers an error, and by the spec the consequences of those redefinitions are undefined. Otherwise, technically, yes.
18:11:25
ecraven
so if an implementation inlines some functions, it has to take care to recompile everything depending on a function if it is redefined?
18:12:36
djeis[m]
And those functions still can be redefined, you just have to recompile everything which uses those functions for the update to propogate.
18:13:34
djeis[m]
It's a bit of a pedantic distinction, but I'd say an important one- redefinition means something very specific in the case of functions, and it doesn't include things like inlined functions.
18:14:38
djeis[m]
The same thing is true of macros, really- if you redefine a macro you still have to recompile everything which uses the macro.
18:16:40
djeis[m]
Another place where that shows up is when you use 'func vs #'func. Redefinition updates the symbol, so if you call 'func it'll get updated. #'func, on the other hand, captures the actual function object and that does not get modified in-place.
18:28:14
p_l
Automatic recompile of inlining functions requires a who-calls database and most implementations don't provide one
19:19:52
stylewarning
I would be fearful of re-compiling functions I didn’t explicitly ask for, esp. if I’m developing them.
19:20:54
specbot
Constraints on the COMMON-LISP Package for Conforming Programs: http://www.lispworks.com/reference/HyperSpec/Body/11_abab.htm
19:24:43
|3b|
and redefining a function generally won't affect any running instances of that function (including those waiting on a call to some other function)
19:27:19
|3b|
also unspecified when standard functions look up function bindings from symbols, so a running (mapcar 'foo ...) might see a redefined FOO on next iteration, or not at all. next call to (mapcar 'foo ...) would see new definition though
19:28:32
|3b|
(and i doubt most user functions specify that either, but probably tend to do the lazy thing and let funcall resolve it so would see redefinitions)
19:32:31
on_ion
stylewarning: i may have been thinking of JIT in general; ie. in julia if you call a function for specialized types that has not been yet required/compiled, it will do so
19:39:34
jcowan
The question is, are running functions decompiled when they are changed out from under you?
19:54:23
on_ion
ah. julia keeps around generic versions and type-dispatched versions and etc., likely it would have the least-optimized version as the most generic
19:58:53
jcowan
explains how the Graal compiler (the latest JIT engine in Oracle JVM) dynamically deoptimizes code when its assumptions are violated.
20:00:12
jcowan
The primordial JIT (HP APL, 1977) already did this, first assuming that the rank and shape of all variables was fixed, and checking this at the beginning of a line of APL. If the assumptions were false, it deoptimized the code to assume only rank constancy, and then recompiled only if a variable changed rank (which hardly ever happens)