Re: RAD vs. performance

You are also aware that if a language has the same types and operations
as Ocaml (e.g. ints and floats using + and +.), then doing type
inference (for purposes of generating efficient code) is going to be
exactly the same for a dynamically typed language as it is for Ocaml?

To the extent that your statement is true, it is meaningless.

On the contrary. This is the heart of the issue. You keep claiming that
type inference can't be done both efficiently and effectively in dynamic
languages; my statement asserts that it can be done using the exact same
methods that are used for statically typed languages, with the same
efficiency, and the same effectiveness.

Then you're implementing static typing.
Obviously there's some confusion here. Let's step back and look at this
from an abstract point of view: static typing is basically any type
system that completely checks all types at compile time and possibly
run time (see: incomplete pattern matches/casting). Dynamic typing is
basically the complete opposite of this: checking is done at run time
to make sure it only complains when there *is* an error. This is the
general philosophy behind dynamic typing, so it's generally safe to
assume that, as long as something is completely provable to be an
error, it doesn't matter if it complains at compile time. Now, given
these definitions, you can derive the facts that 1) a completely
inferred, static language (nonexistant) with structural subtyping is
very similar to dynamic typing and 2) the case in which it's different
is when you're dealing with *possibly* erroneous expressions, in which
case the static language requires you to acknowledge this, whereas the
dynamic language just warns you. There you go, a complete break down of
the similarities and differences of static and dynamic typing.

And that the only cases in which you wouldn't be able to infer the type,
and thus would fall back to boxing and run-time dispatch, is when Ocaml
would reject your program?

That is definitely not true. Look at rectypes, polymorphic recursion etc.

So you're saying that Ocaml accepts (some) programs for which it cannot
infer the types?

No, I am saying that you have incorrectly assumed that OCaml can't
infer more because it is not "smart" enough. In fact, OCaml can infer
more but chooses not to because it weakens the type system and allows
significantly more bugs to creep in. You can control the amount of
inference in OCaml and good OCaml programmers deliberately choose not
to infer everything because it slows development and makes for less
reliable software.
Do you have an example of this?

Common Lisp would be a different story, because Common Lisp does mandate
that you have a full numeric tower. So if the compiler cannot prove that
you will only ever need fixnums, it will need to emit less efficient
code.

Even if you litter the source with type declarations to evade that
problem, SBCL and CMUCL still produce much slower code. IIRC, a slow GC
was a major reason but even with lots more code to alleviate the GC,
Lisp was still much slower than the statically-typed languages and
Stalin-compiled Scheme.
Circumstantial evidence. That's obviously a deficiency in the
implementation.

I have run Stalin on many programs and it is always orders of magnitude
slower than any other compiler that I have seen.

Yes, and you suggest that this is because of the language it compiles. I
contend it may also be an implementation issue.

You think that someone can write a Scheme compiler that generates code
that is almost as efficient whilst taking a reasonable time to compile?
I certainly do. It might require slightly more work from the programmer
compared to a baseline, unoptimized version, but it'll still probably
be shorter than the statically typed version or at most equivalent in
size.

(2) you'd rather
have the programmer do a little extra work each time he needs dynamic
typing, than have the compiler do extra work to generate efficient code
from a higher level language.

Dynamic typing is not "higher level". It is a special case of static
typing.
Dynamic typing is not a "special case" of static typing--they're both
two different ways to implement a type system. One does more checking
at compile time, the other doesn't.

You can argue for a more powerful type system. I'd like type classes
and performance...
Ironically, the general coding style in OCaml is probably so incredibly
rigid because of the "shunning" of type classes and their equivalents
(OCaml modules, classes).

.

Relevant Pages

  • Re: Statically AND Dynamically Typed Language ??
    ... Linux compared to Windows. ... many other individuals are earning a living from their own language ... I have only limited knowledge about OCaml. ... if you compile a non-trivial program to native ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... All of the implementations are either slow to compile ... exactly the same for a dynamically typed language as it is for Ocaml? ... Then you're implementing static typing. ... course, I think you must), then it follows that dynamic typing does NOT ...
    (comp.lang.misc)
  • Re: RAD vs. performance
    ... I simply implemented dynamic typing for this ... This is how OCaml programmers solve such problems, ... compilers, all these folks working on compilers for Python and Ruby, ... language is statically or dynamically typed. ...
    (comp.lang.misc)
  • Re: GoTo in Java
    ... >> far fewer bugs - in OCaml. ... >written in a dozen different programming languages, ... >the language of your choice. ... compile" to a different language. ...
    (comp.lang.cobol)
  • Re: beginning with ML
    ... developers just ignored the patch. ... Except OCaml brings a considerable user base, ... designed and engineered aspects of the O'Caml language. ... compile it to a not-easily-invertible form (like ...
    (comp.lang.functional)