Python from Wise Guy's Viewpoint

[Dirk Thierbach]

Pascal Costanza <costanza at web.de> wrote:
> Dirk Thierbach wrote:

>>>According to your criteria, (real * 200) is
>>>- a certain class of values
>>>- given in a limited language describing that class

>> Yes, but you will have a hard time developing a static type checker
>> that will work with such a language.

> I am not asking for a definition of the term "static type", but for a 
> definition of the term "type".

I am happy with a definition of "type" that allows arbitrary sets of
values, but how does this apply to static typing? Or dynamic type
checking? I was talking all the time about a definition of a "static
type", because that it what is relevant here.

Philosophically, there are a lot more sensible definitions for type,
but how does one such definition relate to our discussion?

> Haskell: "An expression evaluates to a value and has a static type." 
> (http://www.haskell.org/onlinereport/intro.html#sect1.3 )
> 
> Where is the definiton for "type"? (without "static"?)

There is none, because that is not relevant.

> Let's first get our terminology right.

Maybe we should also agree on what we want to use the terminology for.

> I don't mind if you want to change that terminology. Let's just
> rephrase it: Static type systems need to reject programs that
> wouldn't necessarily fail in serious ways at runtime.

I think I already agreed with that several times, didn't I?

But then you have also to add "even if they won't necessarily fail,
nearly all of them won't be well-behaved". 

>>>But I am interested in the question why you (or others) think that 
>>>almost all software should be developed like that. 

>> I didn't say that. Please do not put up a strawman. In fact, I 
>> explicitely said "you use whatever tool you like best".

> But that was the original question that initiated this thread. If we 
> have an agreement here, that's perfect!

Finally. *Sigh*. Why do I have to repeat that multiple times?

> What about the example in 
> http://groups.google.com/groups?selm=bnf688%24esd%241%40newsreader2.netcologne.de 
> ?

> I don't think this can be done without a serious rewrite.

The problem here is that the object system of CLOS and OCaml is
quite different, and Haskell has no objects at all. So you cannot
directly transfer that example to those languages. Not because they
are statically typed, but because they are different. It probably 
wouldn't be possible to do exactly the same in another arbitrary 
dynamically typed language, either.

But you can trivially simulate the *effects* of your program once
you accept that such a simulation need not use classes.

Please don't mix the differences because of statically/dynamically
typing and because of other language features.

> Right, it comes from a more principled consideration: You can't have 
> metacircularity in a statically type language. You might be able to have 
> metacircularity if you strictly separate the stages, but as soon as you 
> want to be able to at least occasionally call base code from meta code 
> and vice versa, then you lose.

But you don't need metacircularity, because then you simply solve
your problem in a different way. 

> Metacircularity gives me the guaranntee that I can always code around 
> any unforeseeable limitations that might come up, without having to 
> start from scratch.

You can also create very subtle bugs that are difficult to find.

> I haven't said that I can do more things in a dynamically typed
> language. I have said that statically typed languages need to reject 
> well-behaved programs. That's a different claim. We are not talking 
> about Turing equivalence.

Neither am I talking about Turing equivalence. 

But if you can agree that it is not harder to express something in a
(properly) statically typed languages then to express it in a
dynamically typed language, then we can stop the discussion here.

What I want you is to give up the point of view that dynamically
languages have an *advantage* because they are dynamically typed.

- Dirk