Re: RAD vs. performance

No. The performance cost of abstraction in OCaml has nothing to do with
inference.

First, yes it does.

In what way? I'm thinking of lack of inlining across functors and the cost
of run-time type dispatch when using parametric polymorphism. These reasons
certainly have nothing to do with inference.
The standard library is a prime example. It's completely conceivable
for the compiler to eliminate the dynamic dispatch 99% of the time
through code analysis and inference.

Second, I mistated that. I meant to say something
along the lines of:

it would've been possible to completely negate the cost most of the
time through proper inference in the compiler. It's completely possible
to infer when variants are and aren't needed most of the time;

ML programmers don't use variants when they're not needed.
Which is why the standard library is so rigid.

when
it's not possible, e.g. in circumstances in which complete compilation
would be necessary to find it, the generic case would be used. If it
turns out to be a bottleneck, the language could allow the programmer
to force a specific case, e.g. with a type declaration.

You'll need a more expressive type system if you want to express the use of
a subset of a variant type. Even then, why not just get rid of the boxing
in the ML implementation? You're not going to work to box everything
unnecessarily only to declare that you didn't need to.
Who says I'm using ML?

Unfortunately, rather than doing this, the
compiler writers and language designers simply pushed it off onto the
programmer to do, manually.

What are you talking about? What does the programmer have to do
manually?

Pick the correct function/operator to use.

You always have to pick the correct function/operator to use in any
language. Or are you going back to the numeric tower and saying that if you
have a smaller choice (e.g. if you overload / for int and float division)
then your life is somehow easier.
How is removing code repetition not a benefit? Honestly, I don't get
your point. You've already stated that the standard library is like
that for speed. Are you trying to say it's somehow "better" now, too?
Hehe.

.

Relevant Pages

  • Re: RAD vs. performance
    ... would've been possible to completely negate the cost through proper ... inference in the compiler. ... time through proper inference in the compiler. ... turns out to be a bottleneck, the language could allow the programmer ...
    (comp.lang.misc)
  • Re: random sorting a collection
    ... you'll get the same type inference problem - it can't infer the TKey ... lambda expression is simply not an appropriate input. ... It's not an appropriate input when the compiler needs to do type ... Just to be clear for any other readers - it's not "var" that creates ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: random sorting a collection
    ... you'll get the same type inference problem - it can't infer the TKey ... lambda expression is simply not an appropriate input. ... It's not an appropriate input when the compiler needs to do type ... Just to be clear for any other readers - it's not "var" that creates ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: RAD vs. performance
    ... inferencer can inference the correct types. ... (which is special and applies to both ints and floats). ... If you want an efficient compiler there's type inference;) A well ... written compiler for a dynamic language isn't inherently slower than ...
    (comp.lang.misc)
  • Re: random sorting a collection
    ... The "this isn't actually true" that I was referring to was the question of whether the compiler can just make up a type for the purpose of inference. ... While the lambda expression I wrote itself contains enough information for _it_ to be converted to a type by inference, once it's wrapped in yet another lambda expression, that information isn't available/relevant to the compiler. ... posted is the final "" that actually _calls_ the delegate. ...
    (microsoft.public.dotnet.languages.csharp)