에 커먼 리스프의 비판 1984 년 로드니 A. 브룩스와 스탠포드에서 리처드 P. 가브리엘에 의해 작성, 커먼 리스프의 정규화위원회에 의해 유지 몇 가지 디자인 결정이 논의된다. 대부분의 논의는 유효하지만 현재 사용 가능한 기술을 언급하는 두 가지 진술이 있으며 오늘날에는 틀릴 수도 있습니다.
이 두 문장은 다음과 같습니다.
'모든 좋은 컴파일러'가 처리 할 수 있다는 훈계로 언어 비용이 너무 많이 들었다. 아직까지도 많은 노력을 기울이지 않았을 것으로 예상되는 트릭의 일부를 수행하는 컴파일러는 아직 아무도 작성하지 않았습니다.
나는 일반적인 Lisp 초보자이거나 심지어 견습생이기 때문에 저자보다 더 구체적 일 수는 없습니다. 그들은 언어의 여러 측면에 큰 일반 성과 유연성이 내장되어있어 좋은 컴파일러를 작성하는 것이 매우 어렵다고 말합니다.
COMMON LISP에서는 부동 소수점 산술에 대해 너무 많은 제어가 이루어졌습니다. 부동 소수점 집약적 프로그램의 올바른 동작을 달성 할 수는 있지만 성능은 크게 다를 수 있습니다.
내가 아는 한, Common Lisp에서 효율적인 숫자 코드를 작성하는 것이 가능하지만 이전보다 더 어려운 것으로 보입니다.
이것은 30 년 전이었습니다. 일반적인 자유 소프트웨어 구현 중 하나 (CLISP, SBCL et al.)에 대해 Common Lisp 프로그램을 작성하려는 경우 오늘이 진술을 어떻게 고려해야합니까?
좋은 질문입니다! 이 주제에 대해 Common Lisp에 대해 잘 아는 사람의 의견을 듣고 싶습니다. 내 두려움은 요즘 커먼 리스프의 상대적 인기도에 따라 여전히 적용된다는 것입니다.
부동 소수점을 얻기가 어렵습니다. 일부 언어는 엄격한 모델을 지정하고 성능을 저하 시키며 다른 언어는 느슨한 모델을 사용하므로 추론하기가 어렵습니다. 예를 들어 C #의 간단한 부동 소수점 프로그램에 대한 추론은 너무 어렵습니다. 따라서 나는 성능에 비용이 들더라도 부동 소수점에 엄격한 언어 설계자들과 함께하는 경향이 있습니다.
—
코드 InChaos
반면에, 현대 하드웨어는 일반적으로 IEEE 부동 소수점을 구현하므로 아마도 1984 년에 제공되는 구현보다 동작에서 훨씬 더 예측 가능할 것입니다.
—
microtherion