André Pang <oz...@algorithm.com.au> writes:
> On 15/01/2009, at 1:32 AM, Adelle Hartley wrote:
[...]
>> Speaking of which, why aren't there more "mixed" strong/weak typing
>> languages that compile to native code?
Breaking languages into a one dimensional strong/weak typing paradigm is
too simple to really understand the situation, I think. In general
there are two key decisions:
static vs dynamic typing, such as C vs Perl/Python variables
strong vs weak typing, such as C (weak) vz Perl (strong)
static vs dynamic typing is about what a variable can hold: it is just
the one type, or can it contain anything? Do you need to declare that
ahead of time?
strong vs weak typing is actually more interesting: C is statically
typed, but weak: you can transform the data type in memory from one type
to another, such as:
int a = 12;
float *f = (float*)&a;
printf("%f\n", *f);
A strongly typed language like Perl, though, won't allow that: you can't
interpret an integer value as any other type without going through an
appropriate conversion routine.
(Perhaps I should have picked Java, which is strongly typed, and doesn't
supply a lot of implicit type conversions in the syntax. ;)
> Usually, the reason you compile code is for performance, and static typing
> goes hand-in-hand with fast performance.
In many cases it is the strong vs weak split that determines
performance, much more than static vs dynamic typing.
Oh, and while I agree with your statement that static type information
is helpful for fast performance, I think it is likely misleading to
people.
Hindley-Milner type inference is the current state of the art, but the
CMU Common Lisp compiler has done type inference for decades and
generates extremely efficient native machine code from a strong, dynamic
typed language.[1]
OCaml, which runs somewhere between just below and significantly above C
in terms of performance, gains much of this ability from the same
feature: the strong typing means that they can do good type inference
and generate efficient code without needing type annotations everywhere.
http://en.wikipedia.org/wiki/Type_inference
> Dynamic typing requires some sort of uniform ("boxed") representations
> of data where each object has a tag associated with it to indicate
> what type it is, along with code to check the tag is correct every
> time the object's accessed if you don't want a segfault.
That isn't even remotely true, I fear:
Efficient compilers[2] for dynamic languages can associate type in a
range of ways other than the traditional box/unbox representation, with
varying efficiency, using tagged pointers, inference from variable
storage or region allocation among other techniques.
They can also omit the boxing entirely in cases where the scope of
access is known — inside any given routine, for example, there is no
need to box/unbox values, potentially making the code as efficient as
the static typed language.
Finally, don't forget that many of the statically typed languages end up
with these same safety checks implemented by hand; isn't it a typical
C/C++ idiom to say:
void fn(struct foo *x) { if (x == NULL) { ... handle this ... }
Oh, not to mention that most good compilers for dynamically typed
languages let you tune various options in the generated code, such as
the Common Lisp:
(declare (safety 0) (speed 3))
That tells the compiler to omit type checking and just assume the values
are what they are declared to be: generate code as fast as possible,
with as little safety as possible.
> That lowers performance, which is a reason why most compiled languages
> are statically typed.
This is probably true, given that C and C++ are statically typed, and
probably represent the majority of the compiled languages in popular
use.
Objective-C is hard, but arguably statically typed, except in the object
system. Hard call, but I couldn't say it fully supported that
assertion.
Java has a statically typed syntax, but is dynamically typed underneath,
as is C# on CIL, both of which are fairly popular today, too.
Arguably, I suppose, neither a CIL language or Java are compiled in the
same way that C and friends are, but that (again) is potentially
misleading to the audience.
JIT compilation, for Java, JavaScript and C#, is often *more* efficient
than static compilation such as C, because the JIT has access to runtime
information for "trace cache" compilation and the like — interprocedure
optimization, runtime activity based operations, memory tuning and so
forth.
So, overall, I don't think I would be brave enough to assert that most
compiled languages were statically typed even if I wanted to include
only the popular, real world languages.
If you want to go beyond that we start including things like Lisp,
Scheme, SML and OCams, and things only look worse for your thesis.
Regards,
Daniel
Footnotes:
[1] As an example, the generated code does not need to box or unbox
values, and can use machine level integer instructions where it can
infer that only integer values are used — or generate an altenate
unboxed integer version as well as a type-checking "generic"
version of the same method.
[2] ...and I make no claim that all compilers are efficient here, but
they *are* out there and accessible to you and I.
_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders
