jscl-project
Replace of using redundant typecase
(typecase var (type-name action))
replace on:
(cond ((type-predicate var) action))
Reason: the function checks the object for belonging to the built-in type. Using typep - redundant.
Approximately 9 source files.
If I may interject — using typecase here is idiomatic. If I found a cond that checks a known type in each clause, I'd be inclined to change it to typecase, not the other way around.
Usually, this is also compiled to more efficient lower-level code, as there are fewer lookups necessary. If there is something in JSCL that makes typecase less efficient, that should be fixed.
Yes, you are right.
- As follows from the original code - check
(typecase (integer )(cons))is a generic type test, which is more effectively performed via a predicate -integerp,conspetc.. - Using the
typepin this case is an overhead. - And yes, The JSCL compiler does not recognize such cases, they must be prevented manually.
Something like this.
If I understand correctly, this is about rfeplacing the macro expansion of typecase itself. And not to replace typecase with cond around the code. I agree that typecase is preferable when applicable.
I think it makes sense if the macroexpansion uses typep instead of direct predicates like integerp. It is more uniform. If we want to optimize it away, it is better to do that in the compiler probably, or as a compiler-macro over typep, rather than in typecase itself.
Aren't we talking about different things?
It is a very simple and straightforward ISSUE and PR .
In some places (typecase (integer)) was removed, an explicit replacement for the predicates (integerp)/(consp). Which is what the existing typecase does.
The new typecase uses typep with all its mechanism. In my opinion, in these specific places the use of typecase is redundant.
A good example is the sequence.lisp code, where half of the functions are written with a direct call (integerp)/(consp), others half - with (typecase integer).
Where the use of typecase is semantically justified, such changes were not made (read/print/compiler).
It's all.
I 'm not a theorist, I'm a practitioner. I'm not arguing that it is preferable to write (integerp) instead of (typecase integer). It's a matter of taste.
Regarding the compiler. Yes, the compiler should optimize such cases. But there is no such compiler. And won't be soon.
Regarding the compiler. Yes, the compiler should optimize such cases. But there is no such compiler. And won't be soon.
Implementing compiler macros is trivial. No need for a fancy optimizing compiler. So performance should not really be a priority for the decision.
That being said, I don't really mind if some code uses typecast or cond. Whatever is better case by case.
Summary
Colleagues, thanks for the discussion. The discussion was helpful.
I agree with David, the macro typecase should do the job of replacing such expressions.
David, thanks for this reminder.
I believe that this Issue and PR can be closed.
V.
👍
Just to clarify, when I said compiler macros I was thinking about
http://www.lispworks.com/documentation/HyperSpec/Body/m_define.htm
This would be pretty easy win if we care about performance, while allowing typecase use typep.