freenode/#sbcl - IRC Chatlog
Search
23:40:04
karlosz
stassats: for the HOF syntax, wouldn't having something akin to ml-style type variables be more general for constraining types than (NTH-ARG 1 :SEQUENCE T)
23:44:02
karlosz
as in, the type signature for remove would be remove : 'a , sequence 'b, :test-not (function ('a 'b) boolean)
23:44:46
karlosz
'a and 'b can be anything, its just that the first argument of remove has to match the type of the first argument of the :test-not function
23:45:50
karlosz
giving the argument type names seems more general than describing them positionally
23:50:23
stassats
374 insertions(+), 679 deletions(-), i need to commit it quickly somewhere safe lest i lose it
23:56:10
stassats
nth-arg is not a new thing, it's a change from (:test (callable 2 :args (0 (sequence 1 :key 2))))
0:01:36
stassats
and function-designator now can specify result-types, so map-into can be checked, i haven't done that yet
0:02:14
stassats
i have "(defun foo (z x) (map-into (the string z) #'evenp x)) no conflict" in my notes
0:07:43
karlosz
is it possible to produce better code, in the case that the compiler can prove for (remove 97 x :key #'char-code) that 97 can be fixnum compared to the results of char-code
0:08:53
stassats
i was thinking about turning (remove-if (lambda (x) (eql (the char-code-limit x) 97)) y :key 'char-code)
0:09:51
stassats
but even without such drastic transformations, (remove-if (lambda (x) ...) "abc") X is not known to be a character
0:16:21
karlosz
if the result were derived to be null in the case of remove-if would that would result in code deletion
0:19:18
stassats
checking if a constant is shared with anything could be possible, but macros make things harder
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: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: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: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: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.