Re: RAD vs. performance

Jon Harrop wrote:
Curtis W wrote:
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.

What dynamic dispatch? Do you mean the polymorphism in Array.map, for
example?
The pattern matching required by the variants.

ML programmers don't use variants when they're not needed.

Which is why the standard library is so rigid.

How would using variants more make OCaml's stdlib more flexible? What would
you like the stdlib to do that it doesn't do already?
Well, standard library and operators :) I'd like to be able to write:
-------
let double x = x*2;;
let xs = [1; 2; 3.0];;
let doubles = List.map double xs;;
-------
Even better, I'd like to be able to use the standard library arithmetic
functions with my custom float implementation.

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?

So you're using a dynamically typed language that is doing unnecessary
boxing and you can't tell it to stop so you want to extend the language to
allow you to tell it when boxing is unnecessary? You should be using
ML. ;-)
Well, that's better than the language forcing me to tell it whether or
not to box every. single. value.

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?

How are you proposing to remove code repetition? Overloading?
Well, using an actual object system would be better, but overloading
would be an improvement.

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.

I don't understand how OCaml's stdlib is relevant here either.
Scroll up?

.

Relevant Pages

  • Re: RAD vs. performance
    ... cost of run-time type dispatch when using parametric polymorphism. ... reasons certainly have nothing to do with inference. ... So you're using a dynamically typed language that is doing unnecessary ...
    (comp.lang.misc)
  • Re: multimethod + multiple inheritance
    ... language) then your programming level will be limited. ... context where optimization allows the object to never exists as such). ... I don't care that I could do most of the work using design ... Predicate dispatch handles logical combination of values to select the ...
    (comp.object)
  • Re: multimethod + multiple inheritance
    ... Prototype language both with dynamic dispatch and it can be simulated by ... This is a Slate example about the multimethod dispatch with protypes, ... I still don't see how this could justify need in mutating types. ...
    (comp.object)
  • Re: What is polymorphism?
    ... The language should be flexible to provide static checks ... when we talk about multimethods and multiple dispatch we should give ... implementation inheritance and subtyping, even if most statically-typed ... Single dispatch is plainly wrong. ...
    (comp.object)
  • Re: Is Procedural Paradigm a basis of OO Paradigm?
    ... of a non-OO language. ... "single dispatch") are limited when an operation to be executed is ... Paul Graham is more than aware of the facts stated in 1/2. ... Paul Graham said he does not use OOP techniques in Lisp very ...
    (comp.object)