"no variable or argument declarations are necessary."

[Diez B. Roggisch]

> > You just said "let's
> > introduce something like any". I showed you existing implementations of
> > such a concept that have problems.
>
> But as far as I can see that is a problem of the implementation
> not necessarily of the concept.

Without any concept, sure there can't be problems with that concept.

> > You say "thats not what _I_ have in
> > mind, so your criticism doesn't apply." Guess what, I can't read your
> > mind. But you did not tell me in what your idea is different from
> > existing concepts.
>
> Indeed you can't read my mind, but what pops up in your mind shows
> your preconceptions. You could have just answered the question
> as it was posed, instead of filling in the details yourself, maybe
> remarking that you didn't see how it would work with current
> type systems you know off.

How can one answer a question without what he knows? Sure I fill in the
context. If I wouldn't know that this whole NG is about python, I
wouldn't know how to answer most of the questions that arise here.
Which is a general thing about communication.

But I certainly have had more contact with type systems than you had -
so my "filling-out" was by no means unreasonable - as you imply.
Without further details, one can only guess. And debuking guesswork by
saying "but _that_ wasn't what I meant" as you permanently do is easy -
but doesn't make _your_ point valid.

> Sure I'm reluctant to give details. I consider this a hostile
> environment, for this kind of proposals. I'm sure people will
> be able to come up with all kind of problems my idea won't solve
> and will see this as a reason to think the idea is useless.

Why hostile? Because people will possibly destroy your wishful thinking
by providing counter examples - if they exist? I doubt that a serious
proposal would get suppressed here - as the static compilers that have
shown up recently prove, as they have been greeted and met with
reasonable criticism where it was in order.

You didn't come up with an Idea so far, as I'm concerned. Just some
random thoughts.

But then again, here we go:

> The main idea is that type information would be available at two places.
>
> 1) The names, which carry the declared type.

 JAVA.

> 2) The objects which carry the type/class they belong too.

That already is the case.

> When an object is bound to a name, a check is made that the type of the
> object is compatible with the declared type of the name.

JAVA exactly does that.

> A name with type ANY, would be just like any python variable or
> instance now. Python could implement this by instead of storing its
> variables in dictionaries as (name, value) tuples, by storing them
> as (name, declaration, value) tuples and making the necesarry checks
> at (re)bind time. Variables that are not declared would get the
> ANY declaration so that current scripts would just remain working
> as they do now.

So far, this is exactly what java does - plus a more dynamic approach
to method/function invocation on ANY. So it seems my assumptions about
what you had in mind weren't so false after all, eh?

>But as the compiler got more sophisticated some
> of these checks might be doable at compile time instead of at
> run time.

Well, that exactly is the point where we make the transition from "this
is how things work" to pure speculation. Can't say that there won't be
a solution someday - but certainly it requires much more, and from
above nobody can say that this would solve _any_ problem.

What you propose above is what JAVA does - plus more dynamicity. Well,
given that even the  "non-dynamic, everything has to be annotated" JAVA
fails to deal with ANY (called Object there), I can't see how a more
dynamic environment will do _better_ in that respect. So unless you lay
out some more detailed ideas how that works, this surely won't do much
if any better than JAVA does today - and JAVA sucks _precisely_ because
of the half-static-half-dynamic nature. It gives you both troubles -
runtime errors like in python, together with compile-time limitations.

Let's face it: you don't know much about type-systems. I do know a bit
more - but don't claim to possess the holy grail. And I don't say that
more powerful analyzing isn't possible. However, all you do so far is
fantasizing and "fail to see why not". Well, that failure might be
because of limited sight on your side - not necessarily on our, which
you constantly claim.

Visions are a nice thing - but actually, in the scientific domain not
so much a vision, but proofs are what is needed. And if you consider it
hostile that nobody buys your ideas because so far they aren't more
than marketing/whishful thinking, I'm sorry that I can't help you.

Diez