Re: [coders] run-on dereferencing + nil object

[André Pang]

On 15/01/2009, at 11:28 AM, Daniel Pittman wrote:

strong vs weak typing is actually more interesting: C is statically

to another, such as:

   int a = 12;
   float *f = (float*)&a;
   printf("%f\n", *f);


interpret an integer value as any other type without going through an
appropriate conversion routine.
[..]
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))


are what they are declared to be: generate code as fast as possible,
with as little safety as possible.

typed, but weak: you can transform the data type in memory from one type A strongly typed language like Perl, though, won't allow that: you can't That tells the compiler to omit type checking and just assume the values

Right, I tend to view both static/dynamic the strong/weak comparison as a continuous scale these days rather than a black or white definition, rather than being completely in the one camp: languages like Objective-C and Perl fuzz the barrier a lot. And, as your example demonstrates, a language can support all four parts of the spectrum.

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?
[..]
In many cases it is the strong vs weak split that determines
performance, much more than static vs dynamic typing.
[..]

in terms of performance, gains much of this ability from the same
feature: the strong typing means that they can do good type inference

[..]
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.

OCaml, which runs somewhere between just below and significantly above C and generate efficient code without needing type annotations everywhere.

Re your OCaml quote above, I'd argue that it's static typing, not strong typing, that's required for type inference. However, all the statements above really depends on your own definition of static typing vs dynamic typing and strong vs weak; even Benjamin Pierce, who wrote _the_ book on types and programming languages[1], acknowledges that it's difficult to come up with proper definitions of the terms. We can keep banging our head for hours about this and get nowhere :). You and I don't really agree with Wikipedia's definition of weak typing, for instance, which is that "a language implicitly converts (or casts) types when used" <http://xrl.us/becktd>. That's a different definition from those that are widely used in the type theory community.

Efficient compilers[2] for dynamic languages can associate type in a

varying efficiency, using tagged pointers, inference from variable
storage or region allocation among other techniques.

range of ways other than the traditional box/unbox representation, with

Sure, I didn't mean to imply that all dynamic languages use boxing/ tags. However, it's a ton more effort for dynamic languages to generate compiled code that's as efficient as a static language. Writing a JIT engine that surpasses the speed of a ahead-of-time compiler is quite a large effort[2], and really, not very many language do this. So, I still stand by both my statements that static typing goes hand-in-hand with fast performance -- because it's much easier to obtain fast performance if you have static typing -- and that most compiled languages are statically typed (if you consider my personal definition of static typing, which is that types are known at compile-time -- I wrote my original message with that definition in mind). 1. Google Books link for Types and Programming Languages: http://xrl.us/beckse (Link to books.google.com)

2. Interesting paper about the design & implementation of Java 6's HotSpot VM: http://www.ssw.uni-linz.ac.at/Research/Papers/Ko08/.

--
% Andre Pang : trust.in.love.to.save  <http://www.algorithm.com.au/>

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
coders mailing list
coders@slug.org.au
http://lists.slug.org.au/listinfo/coders