This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
On Wed, 18 Jan 2006, William D Clinger wrote: > As for assumption 3, type declarations cannot address the > portability and predictability issues unless implementations > are required to interpret those declarations in a consistent > way. Given the expectations created by Common Lisp, many > Scheme programmers would make the mistake of thinking that > type declarations are for performance, and that interpreters > are free to ignore them. Some implementors might make the > same mistakes, especially when you consider that requiring > implementations to pay attention to type declarations is > likely to make interpreters slower, not faster. I'd like to point out a few things in favor of type declarations: 1) Generality: they are more general than any solution which is specifically and solely numeric. Optional declarations can apply to more than just numbers. 2) Sufficiency: Given type declarations, it is very easy to create type specific operations. The converse is not true. 3) Minimizing Namespace Pollution: I do not want a language where there are fifteen different type-specific versions of most functions, each of which has a unique name to remember. 4) Switchability: It is easy to provide "null syntax" mirroring declarations, allowing easy comparison and profiling of the code with and without declarations without requiring any modification of the code itself. This makes it easy to expose compiler bugs or declarations with unexpected effects. 5) Expressivity: Declarations can also be read as internal documentation asserting that certain things are true about the code in the declaration forms. And they are a small, consistent language with consistent meaning, not requiring me to memorize the type characteristics of hundreds or thousands of different functions. IOW, they make the type information more accessible by using fewer and more general forms to express it. 6) Optionality: Scheme systems are *NOT* required to use the information available in type declarations for optimization or checking purposes. Those that care a lot about performance will use them for optimization. Those that care a lot about correctness and a useful dev environment will generate code to check the type assertions and make sure that they are correct. Those that care a lot about both will provide modes that do both. And this is as it should be. Optional information provides implementors with a means to legally make optimizations without requiring them to make assumptions that may result in broken or risky code in the general case. 7) Abstraction Barriers: I think that implementors who care about different aspects of numeric computation ought to be free to use a different representation for numbers. What the proposed "type- specific numeric operations" intend to do is to mandate hardware ints/floats as the representation for numbers, and if you want to deal with hardware numbers, I suggest you ought to be talking about an interface to machine code rather than scheme numeric operations. For these specific reasons, and several others that mostly boil down to "aesthetics," I strongly believe that expressing type information as optional declarations is generally superior to the approach of providing type specific versions of everything -- and if type specific versions of everything are what you want after all, optional declarations provide a simple means of creating them. Bear