🚀 go-pugleaf

Victor Yodaiken writes:
>>[Raul:] For example, if you have a function which is defined over the
>>domain of numbers (take addition, for example), then you usually see
>>a dynamic typing system faithfully providing that functionality for
>>a variety of machine implementations of numeric types.

>Your explanation is confusing me even more.

sorry..

>Most of  the programming languages that I know do something like this.
>For example, x +y works fine in "C" for floating and integer types,
>and can also be extended to other types in C++  I believe. 

But in C, you have to go through some red tape if you need to store
both integer and floating types in the same variable.  You also have
to go through this red tape to define a function that takes more than
one type as an argument (for example, functions which manage a
run-time symbol table).  C++ allows you a little more abstraction, but
still requires quite a bit of paper work.

>Maybe a precise definition of "dynamic typing" would be useful. 

See Darren New's article (5 April, I think, same Subject: as this
article). 

>From previous postings, I had the impression that "dynamic typing"
>involved compiler/run-time inferences about the type of a function or
>variable from the context and use of the variable or function.  On
>the other hand, "static typing" requires the programmer to indicate
>exactly the type of the object. Is this incorrect?

Dynamic typing requires compiler type inferences (though these are
trivial in the presence of declarations, or well-conditioned code).
There is no requirement for run-time type inferences.  Type
information is always available at run-time.

If a compiler can not infer type, it will provide for run-time type
checking as well--it's fairly trivial to implement.

>>[Me (Raul) again:] ...  In a dynamically typed language, where
>>practically all functions have type checks to ensure their
>>arguments' validity, more is usually checked than just the
>>"wordsize" or the "typetag" of the arguments.

>Again, I'm not following you here. Is this extra type checking in
>dynamic languages part of the language or a coding style?

For language primitives, it's part of the language.  For user defined
functions, it is both [the programmer must provide any necessary type
checking that is not implicit in the primitives].

Raul Rockwell