libera/#sbcl - IRC Chatlog
Search
1:03:16
karlosz
i think its actually wrong to signal a full warning when doing something like (defun foo (x) (foo x y))
1:03:24
karlosz
self call argument mismatches should not signal a full warning unless its actually being compiled as a self call (i.e. speed > debug or block compilation)
1:03:58
karlosz
because it's actually possible to redefine the function before the self call happens
1:07:59
karlosz
anyway, the language allows it, and we usually pay attention to issues with late binding
1:08:52
karlosz
some insane package manuevers were found by someone doing some python to cl stuff, so i bet things like that could happen with autogenerated code anyway
1:09:46
karlosz
stassats: also true, but it has a semantic difference to the compiler: code which produces wanrings means that the compiled code doesn't work anymore
1:10:14
stassats`
python cl stuff can do (declare (notinline foo)) if they want to go crazy and not get warnings
1:10:33
karlosz
anyway, you see a bunch of comments in the system like this: https://github.com/sbcl/sbcl/blob/f14cf6277d2e96b840fad3cf02cdbef14ff4c482/src/compiler/ir1tran-lambda.lisp#L1284
1:14:31
stassats`
(defun bar (x)) (defun foo (x) (bar x y)) getting a full warning but (defun foo (x) (foo x y)) not getting a full warning does not make any sense
1:22:56
karlosz
i'd just like to rationalize style-warning vs warning in this respect since late binding has something to do with it
1:23:43
stassats`
Within a function named F, the compiler may (but is not required to) assume that an apparent recursive call to a function named F refers to the same definition of F, unless that function has been declared notinline. The consequences of redefining such a recursively defined function F while it is executing are undefined.
1:24:11
karlosz
i wanted to bring some order into this by allowing the user to make derive-function-types only propagate in the same file to conform with that ansi statement
1:24:38
karlosz
but according to that paragraph we could also just turn block compile to true by default
1:25:06
karlosz
yeah exactly the paragraph you quoted implies we could just recognize self calls always and we'd be happy
1:32:37
karlosz
maaybe consistent/inconsistent is not the right word, but it's definitely unclear how much we actually commit to the "same file means same function definitions" allowed by ANSI
1:34:15
karlosz
i thought it wouldve been nice to have *derive-function-types* to be :same-file by default because then users get more type inference across functions in a way that is standard conforming
1:37:43
karlosz
(that was supposed to be the real solution to the duplicate defun in same file type conflict problem btw)
1:38:17
karlosz
(giving derive-function-types T, :SAME-FILE, and NIL, and using NIL to turn off any kind of global type inference)
1:38:58
karlosz
stassats: i put it in the news file and updated the doc-string, so it was documented in the manuual as part of generated documentation for the exported symbol....
1:40:22
karlosz
how could yopu possibly know whether people read stuff like the manual or docstrings
1:41:55
stassats`
and i can say the same thing about myself as well, ain't no way i'm up to date on all the intricate stuff for the things i use
1:43:35
karlosz
so your response to that proposed fix is simply: "it's change, people won't nknow about it, therefore let's not do anything?"
1:46:35
karlosz
if you had brought it up first before just reverting it we probably could've found a better solution that would've also remvoed some of the annoyiingnhess of the way global types are currently propagated
1:48:56
stassats`
the only way it could reach people is via some automagic, i.e. based on SPEED or something like that
1:49:08
karlosz
by the way, the code taht it broke could've been fixed by just setting *derive-function-types* to nil which would have inhibited that kind of type propagation at all
1:50:04
stassats`
but setting *derive-function-types* to NIL would've broken existing code, and then it broke somebody's code who already used *derive-function-types*=T
1:51:43
stassats`
there would've been issues "my code is slower. what do", or no issues but "huh, i guess i'm going to use lispworks"
1:55:27
karlosz
there's also the deprecation stuff to force users to rethink the way they use a problematic api
1:56:03
stassats`
right, but at least it's for something that's used explicitly and does provide some sort of a warning
1:57:34
stassats`
not everyone is so eager to deal with our bugs or changes, some may switch to a different implementation or quit lisp altogether
1:58:40
karlosz
as many people say, its not exactly like sbcl is updating to match a moving language target
1:59:09
karlosz
people who use the monthly releases are people who generally accept that stuff can be deprecated etc
2:03:17
stassats`
i did change the default external format to utf-8 with the old way of changing it disappearing without a notice
2:06:02
karlosz
i removed sb-graph this release as well, but i was pretty confident no one would care
8:14:06
flip214
I quite like derive-function-types -- it helps to catch some problems, and when in doubt I can always touch the .asd and reload everything.
8:15:21
flip214
BTW, functions with the same name within a file are warned about -- but not defmethods with identical parameter specializers