Re: Pointers to "why C behaves like that ?"

"Roman Shaposhnick" <vugluskr@unicorn.math.spbu.ru> writes:


> On 1 Dec 2002 22:44:23 -0500, Tony Finch wrote:
>>"Roman Shaposhnick" <vugluskr@unicorn.math.spbu.ru> wrote:
>>>On 24 Nov 2002 18:38:19 -0500, Joachim Durchholz wrote:
>>>>
>>>>No. Hindley-Milner typing is simple and efficient.
>>>
>>> But I suppose they require all pieces of code that has anything
>>> to do with "a" to be available at once.
>>
>>No, only the signatures of the functions called within f that have
>>anything to do with a are needed.
>
> So what happens when all the signatures have the most general types in
> them ? My concern is -- how big the runtime hit will be.


If the type is fully general, then the function absolutely does not
look at the data items and instead just copies the pointers around.
If the type is more specific, then, due to the type checking, the
function will know for certain that the data items have the proper
type, and thus that they can access the data directly with no run-time
type check.


Overall it's the same situation as in C. Specific types are
efficient, and abstract types (void pointers plus functions or even
function pointers) are less efficient--but the inefficiency is not due
to run-time type checks.


One final note. H-M types or not, no one forces the programmer to use
polymorphic functions. If you run into a performance problem, then
you always have the option of writing specific versions of a function
for specific types that are of interest.








Now, please forgive me for philosophizing a moment on a few things.


First, the type system is different from the runtime. Most features
are available in most reasonably high-level languages, and their
implementations simply look different. Different type systems simply
make different things visible to the compiler (and to the programmer!)




Second, historically, chasing execution speed has seriously hampered
the acceptance of all kinds of programming features, up to and
including the use of compilers at all. It's important not to place
execution speed at too high of a priority, especially when one
considers that most high-level languages have some efficient subset
that can you can restrict yourself whenever speed becomes a problem.
It seems better to have a nice general-purpose language with optimized
components, than to have an optimized but painful language with
general-purpose stuff tacked onto it.


Finally, notice that automation of any kind is more important for
larger programs. With small programs, humans can easily beat the
compiler+environment on just about any criterion you name. With
larger programs, though, the programmers become pressed to get
functioning code at all, and they have little time left for extra
improvements. Has everyone noticed that big C programs seem to end up
with a lot of manual polymorphism, anyway, such as opaque pointers,
callbacks, abstract datastructures, registries, shared-library
plugins, etc.? These things surely negate the general performance
gain that C initially gives a program.


Lex

Return to the comp.compilers page.
Search the comp.compilers archives again.