Lambda the Ultimate

inactiveTopic static AND dynamic typing
started 11/15/2002; 1:29:54 PM - last post 11/19/2002; 8:29:07 AM
Isaac Gouy - static AND dynamic typing  blueArrow
11/15/2002; 1:29:54 PM (reads: 695, responses: 7)
Over and over the same discussion takes place in various forums: static typing (compile time) vs dynamic typing (run time). For me, these discussions seem to miss the point.

I feel the problem is that we are forced to choose between static typing and dynamic typing, whereas we would actually like to have both (and to have them whenever we choose).

Forgive the bad analogy - it's like working with metal. Heat the parts you need to change until they are malleable (fewer physical constraints), work them into the shape required, let them harden; and check that they fit into the hardened (physically constrained) pieces we've already made (and never re-heated). Reheat and rework as required.

I'd like to be able to selectively soften the type system, just for the pieces I need to work on, and then harden the type system so I can check the fit with other pieces (which kept their hardened type system throughout this process).

There are type-inferencing languages that provide some flexibility (like OCaml); but these languages don't seem to allow the developer to control when type-information is used or ignored.
Does anyone know of languages that give the developer power over the type-system?

Chris Rathman - Re: static AND dynamic typing  blueArrow
11/15/2002; 1:53:02 PM (reads: 718, responses: 0)
Dylan probably comes closest (at least for OOP languages) to being a dynamic language while providing the capability to defer type specification to the latter stages of development.

Noel Welsh - Re: static AND dynamic typing  blueArrow
11/15/2002; 4:11:49 PM (reads: 968, responses: 0)
Soft-typing is based around the idea that you statically type what you can and insert run-time checks for what can't be statically typed.

Soft-typing is introduced in this paper. Later work is here and here.

Isaac Gouy - Re: static AND dynamic typing  blueArrow
11/18/2002; 10:32:26 AM (reads: 675, responses: 0)
Thanks, the "Soft Typing" paper is interesting. I hadn't given enough thought to the advantages/disadvantages of manifest static typing.

Soft Typing addresses type safety and optimization. It doesn't seem to address type annotation as documentation, or data type abstraction.

water - Re: static AND dynamic typing  blueArrow
11/18/2002; 4:26:19 PM (reads: 661, responses: 0)
Strongtalk addressed this concern from the Smalltalk perspective, and did a novel job by keeping the optional type-declarations and inference tied solely to the IDE and not to the compiler or performance issues. Yet it still performs very quickly; much faster than any other Smalltalk, and lighter than Java. But then it was killed (bought up) to put its technology into Java.

Isaac Gouy - Re: static AND dynamic typing  blueArrow
11/18/2002; 5:29:36 PM (reads: 665, responses: 0)
Strongtalk was discussed on LtU last month.

Type documentation by-itself seems to be partly addressed by tools like SmallTyper and Analysis Browser.

Both Strongtalk and Soft Typing firm up dynamically typed languages. I was wondering about techniques for loosening statically typed languages, given that we intend to use static typing how can we locally and temporarily renege on that.

water - Re: static AND dynamic typing  blueArrow
11/19/2002; 7:52:54 AM (reads: 639, responses: 1)
Declare something to have the most generic type. I thought this was the standard solution.

Isaac Gouy - Re: static AND dynamic typing  blueArrow
11/19/2002; 8:29:07 AM (reads: 688, responses: 0)
I thought this was the standard solution
It's even the standard solution in Visual Basic! ;-)
Just hit me around the head with that wet fish.

With type inferencing that's what's going to happen anyway - I guess it really is time to start using OCaml. Now if only I can get used to the idea that stepping-debuggers don't make much sense with pure functions ;-)

And back to Scheme "Soft Interfaces: Typing Scheme At The Module Level"