🚀 go-pugleaf

   To repeat: weak typing means that the language may have undefined
   behavior like infinite loops or core dumps from a type error.  Dynamic
   typing means that it is not generally possible to assign a machine
   representation to the values that will be returned by all syntactic
   expressions.  You can still get strong typing in this case by
   including type information with the data at runtime.

Conversely, you can also get dynamic typing in statically typed
languages by creating unions ("datatype" in SML). At least in a
language like SML, the static type system is an additional, very
useful facility offered by the compiler. Most people who program in
statically typed languages write dynamically typed code in some
places; they simply restrict it to particular sections of their
programs.

Unfortunately, the notation for expressing dynamic typing in many
statically typed languages is a little cumbersome, requiring explicit
tagging and untagging by the programmer. However, C++, because of
user-definable conversion operators, lets you use dynamic typing a
little more easily, and ECL (an old Lisp-like language) had an even
smoother integration of dynamic and static typing.

   It means that most programs are smaller and simpler in dynamically
   typed languages than in statically typed languages.

Dynamically typed programs are also impossible to prove type-correct,
and many trivial errors go unchecked.

   It is not all
   that hard to show this: just compare the size of all the .h files in C
   programs to the total size of the program.  As a rough approximation,
   the .h files are the extra baggage caused by static typing.  That is a
   very rough approximation though, since dynamic typing enhances
   reusability of code.  So a lot of reduncancy in the .c files should be
   eliminated also.

As in most fields of human endeavour, redundancy is something to be
aimed for, not something to be eliminated, since it helps catch
mistakes.

   >>Type inference has some nice features, but it does _not_ give you the
   >>expressive power of dynamic typing.

Dynamic typing is necessary for serious program development, since
there are some things that are simply too cumbersome to express
in a static type system.

However, dynamic typing should not be the rule. For the proverbial
"99%" of all programming tasks, static typing is more robust, and
sufficiently expressive (at least, if it is polymorphic). As a bonus,
statically typed languages tend to be easier to compile into efficient
code with current compiler technology and machine hardware.

					Thomas.

In article <2450@optima.cs.arizona.edu> gudeman@cs.arizona.edu (David Gudeman) writes:
|There is a difference between weak typing and dynamic typing.  Lack of
|understanding of this has resulted in far too much controversy,
|especially since the definitions have been posted.
|
|To repeat: weak typing means that the language may have undefined
|behavior like infinite loops or core dumps from a type error.  Dynamic
|typing means that it is not generally possible to assign a machine
|representation to the values that will be returned by all syntactic
|expressions.  You can still get strong typing in this case by
|including type information with the data at runtime.

This statement confuses the *hell* out of me. I thought I knew all
about this issue; goodness knows I've been immersed in enough of it.
But it seems to me that it is **DYNAMIC** typing that is generally
implemented with every object an (underlying) dependant product - i.e.
with every type having the SAME and thus PREDICATBLE machine
representation; and it is **STATIC** typing which permits the
representational consistency constraints to be optimised out so that
the machine representations are arbitrary and NOT interpretable except
by reference to the inductive type structure of the actual code!

DYNAMIC typing uses tags always, STATIC typing uses tags on programmer
request (i.e. in unoptimisable discriminant fields).  DYNAMIC typing
uses uniform representation, STATIC typing uses variant
representation. It's just what you'd expect: the more work the
compiler does, the more "compiled" the result.

Look at the identity function. In a dynamically typed system (assuming
strong typing throughout, here) it has "type" OBJECT -> OBJECT (i.e.,
it's a monadic function, that's the whole story). OBJECT has an
underlying representation like this:
	[TYPE T; T t]
(though maybe the tag T is moved up into the pointer in some cases),
and this is true whether the value of T is Integer, Float, List,
whatever. Conversely, in a statically typed system, I has type 
FORALL T:TYPE. T -> T, and the underlying representation of the
argument and of the result can ONLY be determined by examination of
the lexical call site (or, presumably, in the machine representation,
by the examination of the particular instance of T passed in as an
extra, hidden, parameter). In particular, while the value of the
formal argument type T may be passed in as part of the calling
convention, I don't see why it should ever be passed out again....

-very confused stephen
----------------------------------------------------------------------
stephen p spackman         Center for Information and Language Studies
systems analyst                                  University of Chicago
----------------------------------------------------------------------

stephen@estragon.uchicago.edu (Stephen P Spackman) writes:

> DYNAMIC typing uses tags always

... unless the typing can be completely determined at compile time,
and the tags can be optimized out.

	It seems to me that a language with a good type inference
algorithm and optional type constraints provided by the programmer
should be able to do this in many cases, eliminating type tags when
they aren't necessary.  If you're a static typing fan, you tell the
compiler to whine at you if it can't optimize out all type tags at
compile time, and you have to provide extra type information to get
the code to compile.

	Is there any reason why this can't be done?  Are there any
"dynamically typed" languages that do this?

Nix Thompson		nix@sgi.com		...!uunet!sgi!nix

	  follow the black valley - trail of death
		into the beautiful sunshine.

In article <NIX.91May2231654@valis.asd.sgi.com> nix@asd.sgi.com (Sold to the highest Buddha) writes:
	   It seems to me that a language with a good type inference
   algorithm and optional type constraints provided by the programmer
   should be able to do this in many cases, eliminating type tags when
   they aren't necessary.  If you're a static typing fan, you tell the
   compiler to whine at you if it can't optimize out all type tags at
   compile time, and you have to provide extra type information to get
   the code to compile.

	   Is there any reason why this can't be done?  Are there any
   "dynamically typed" languages that do this?

Your preceeding wish list sounds like a design document for CMU's
"Python" Commom Lisp compiler.  I can't vouch for it personally,
(am eagerly awaiting a SunOS version) but the user's manual and compiler
design notes (FTP-able from CMU) look promising.

   Nix Thompson		nix@sgi.com		...!uunet!sgi!nix



--
-- Steve Olson
-- MIT Lincoln Laboratory
-- olson@juliet.ll.mit.edu
--

Stephen P Spackman
> > DYNAMIC typing uses tags always

Nix Thompson		
> ... unless the typing can be completely determined at compile time,
> and the tags can be optimized out.

> Is there any reason why this can't be done?  Are there any
> "dynamically typed" languages that do this?

The compiler I use does this almost all the time.  However, it is
mostly used for compiling "leaf" functions to be used in an
interpreted environment.  Basically, its only purpose is to cut out
interpreter overhead (including type-checking) for problems that
involve a lot of little operations on the same piece of data.

The interpreter has better performance in other problem domains.
(the sort of optimizations compilers do IS a tradeoff...).

Raul Rockwell