[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: arithmetic issues
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.