Re:How to write Common Lisp in 2017 – an initiation manual
by lispm on Wednesday March 29, 2017 @02:44AM
(#13983961)
One disadvantage: you can't inline the code for such a vector reference, unless the compiler knows at compile time that this is a vector reference.
[ Parent
| on HN ]
Re:How to write Common Lisp in 2017 – an initiation manual
by int_19h on Wednesday March 29, 2017 @04:50AM
(#13984439)
But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.
Re:How to write Common Lisp in 2017 – an initiation manual
by lispm on Wednesday March 29, 2017 @05:39AM
(#13984607)
if a Common Lisp compiler sees a call to cl:aref then it can inline it, without using static flow analysis or similar...
Re:How to write Common Lisp in 2017 – an initiation manual
by int_19h on Wednesday March 29, 2017 @03:51PM
(#13989930)
I was under the impression that CL compilers already had to do a lot of fairly complicated static analysis to achieve acceptable performance, because of dynamic typing.
Re:How to write Common Lisp in 2017 – an initiation manual
by lispm on Wednesday March 29, 2017 @04:59PM
(#13990545)
Depends. Since the developer can use low-level functions and provide type declarations, a compiler can generate usefully fast code without too much work. More advanced compilers need less declarations, since they do some amount of type inference. One of the costs: the compiler then usually is quite a bit slower.