Search
Friday, 17th of November 2017, 0:17:28 UTC
0:17:29
stassats
what i really want is for (find "abc" x) to issue a note
0:17:39
stassats
"hey, dummy, you forgot :test #'equal)
0:18:11
karlosz
and the result of (find "abc" x) derives to nil
0:18:20
stassats
even though technically it's not incorrect and might return something
0:19:18
stassats
checking if a constant is shared with anything could be possible, but macros make things harder
0:19:37
stassats
so, maybe (optimize -Wpedantic) or (optimize -Whelpful)
0:20:28
karlosz
it should be at least safe in the case of (find (cons 1 2) x)
0:20:46
stassats
but who does that?
0:20:52
stassats
"hey, dummy, stop consing"
0:21:32
stassats
i do (find "abc" x) all the time
0:21:42
karlosz
even in the case of (find (cons x y) z)
0:22:07
karlosz
instead of what (find (cons x y) z #'test #'equal)
0:22:21
karlosz
that sounds more plausible
0:23:00
stassats
i'll just always start with (find-if (lambda () car-equal cdr-equal) ...)
0:23:17
stassats
no gratuitous consing
0:24:05
karlosz
true, but at least in that case it can be proven that there is no structure sharing
0:24:11
karlosz
the lambda would cons in your ex
0:24:44
stassats
yeah, but this is low target little incentive thing to spend time on
0:24:51
stassats
karlosz: not really
0:25:26
karlosz
right, its not a closure
0:25:41
stassats
but closures, these will be auto-dxed
0:25:57
stassats
the auto part is trivial
0:26:24
stassats
dxing of lambda has been proven to be possible
0:27:07
karlosz
there are some compilers out there that do enough closure analysis to stack allocate
0:27:44
stassats
no need to analyse anything, (function-designator ((nth-arg 1 :sequence t :key key)) * :dx t)
0:28:25
karlosz
ah, so not for user code
0:28:37
karlosz
unless you have plans to export function-designator
0:29:00
stassats
users can do (let (fun) (declare (dynamic-extent fun)))
0:29:09
stassats
you can do that right now, but with FLET
0:29:32
karlosz
right, but sbcl can't figure that out by itself without the declaration
0:29:53
stassats
which is generally not possible
0:30:34
stassats
now where is my (let (fun) (declare (dynamic-extent fun))) diff
0:33:13
stassats
somewhere on paste.lisp.org
0:33:21
stassats
google is hopeless
0:33:26
stassats
maybe i can grep my way to it
0:36:57
stassats
rgrep lvar-good-for did the job
0:36:58
stassats
http://paste.lisp.org/display/337807
0:37:17
stassats
need to make sens of it
0:40:31
nyef``
That way lies madness!
0:42:14
stassats
nah, looks simpler than i remember
0:42:30
stassats
and it had nine months to gestate
0:42:46
nyef``
stassats: SBCL's DX implementation, while not necessarily *wrong*, is brain-damaged. It treats DX as an LVAR property, which it really, really isn't.
0:44:04
stassats
if all you have is an lvar..
0:46:34
nyef``
Here's a simple one: you have an LVAR where the DEST is a variable declared DX, so it's a "DX LVAR". But it has multiple USEs, and only SOME of those uses are DXable.
0:47:00
stassats
yes, we've been through that problem
0:47:05
nyef``
Because DXness is treated as an LVAR property, *none* of the USEs are permitted to stack allocate.
0:47:37
nyef``
The other one is that CLAMBDAs are an odd parallel to LAMBDA-VARs, but are treated very differently.
0:49:08
stassats
but it's not often you want to dx multiple-used lvars
0:50:57
nyef``
True, it's not often that you DX LET bind the result of an IF, one branch of which causes allocation.
0:51:38
nyef``
But it's a valid enough use-case that we've actually had a bug from someone trying it.
Friday, 17th of November 2017, 12:17:28 UTC