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