"no variable or argument declarations are necessary."

[Antoon Pardon]

Op 2005-10-05, Mike Meyer schreef <mwm at mired.org>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>>> They also relieve a burden from the run-time, since all variables
>>>> are declared, the runtime doesn't has to check whether or not
>>>> a variable is accesible, it knows it is.
>>> Not in a dynamic language. Python lets you delete variables at run
>>> time, so the only way to know if a variable exists at a specific
>>> point during the execution of an arbitrary program is to execute the
>>> program to that point.
>> It is not perfect, that doesn't mean it can't help. How much code
>> deletes variables.
>
> It's not perfect means it may not help. Depends on the cost of being
> wrong - which means we need to see how things would be different if
> the code was assuming that a variable existed, and then turned out to
> be wrong.
>
> Actually, I'd be interested in knowing how you would improve the
> current CPython implementation with knowledge about whether or not a
> variable existed. The current implementation just does a dictionary
> lookup on the name. The lookup fails if the variable doesn't exist. So
> checking on the existence of the variable is a byproduct of finding
> the value of the variable. So even if it was perfect, it wouldn't
> help.

Yes it would. A function with a declare statement could work
as the __slots__ attribute in a class. AFAIU each variable
would then internally be associated with a number and the
dictionary would be replace by a list. Finding the value
of the variable would just be indexing this table.

>>>> And if you provide type information with the declaration, more
>>>> efficient code can be produced.
>>> Only in a few cases. Type inferencing is a well-understood
>>> technology, and will produce code as efficient as a statically type
>>> language in most cases.
>> I thought it was more than in a few. Without some type information
>> from the coder, I don't see how you can infer type from library
>> code.
>
> There's nothing special about library code. It can be anaylyzed just
> like any other code.

Not necessarily, library code may not come with source, so there
is little to be analyzed then.

>>> Except declarations don't add functionality to the language. They
>>> effect the programing process.
>> It would be one way to get writable closures in the language.
>> That is added functionality.
>
> Except just adding declerations doesn't give you that. You have to
> change the language so that undeclared variables are looked for up the
> scope.

They already are. The only exception being when the variable is
(re)bound. This can give you 'surprising' results like the
following.

a = []
b = []
def f():
  a[:] = range(10)
  b = range(10)

f()
print a
print b

which will gibe the following result.

[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
[]


>>> And we have conflicting claims about
>>> whether that's a good effect or not, all apparently based on nothing
>>> solider than personal experience. Which means the arguments are just
>>> personal preferences.
>> Whether the good effect is good enough is certainly open for debate.
>> But the opponents seem to argue that since it is no absolute guarantee,
>> it is next to useless. Well I can't agree with that kind of argument
>> and will argue against it.
>
> You're not reading the opponents arguments carefully enough. The
> argument is that the benefit from type declerations is overstated, and
> in reality doesn't outweigh the cost of declerations.

That may be there intend, but often enough I see arguments that boil
down to the fact that declarations won't solve a particular problem
completely as if that settles it.

>>> Dynamic languages tend to express a much wider range of programming
>>> paradigms than languages that are designed to be statically
>>> compiled. Some of these paradigms do away with - or relegate to the
>>> level of "ugly performance hack" - features that someone only
>>> experienced with something like Pascal would consider
>>> essential. Assignment statements are a good example of that.
>> I think we should get rid of thinking about a language as
>> static or dynamic. It is not the language which should determine
>> a static or dynamic approach, it is the problem you are trying
>> to solve. And if the coder thinks that a static approach is
>> best for his problem, why shouldn't he solve it that way.
>
> Except that languages *are* static or dynamic.

Not in the way a lot of people seem to think here. Adding declarations
doesn't need to take away any dynamism from the language.

> They have different
> features, and different behaviors. Rather than tilting at the windmill
> of making a dynamic language suitable for static approaches, it's
> better to simply use the appropriate tool for the job. Especially if
> those changes make the tool *less* suitable for a dynamic approach.

They don't. That seems to be the big fear after a lot of resistance
but IMO it is unfounded.

If I write a module that only makes sense with floating point numbers,
declaring those variables as floats and allowing the compiler to
generate code optimised for floating point numbers, will in no
way restrict any one else from using the full dynamic features of
the language.

>> That a language allows a static approach too, doesn't contradict
>> that it can work dynamically. Everytime a static feature is
>> suggested, some dynamic folks react as if the dynamic aspect
>> of python is in perril.
>
> The problem is that such changes invariably have deep impact that
> isn't visible until you examine things carefully knowing you're
> dealing with a dynamic language. For instance, just as Python can
> delete a variable from a name space at run time, it can add a variable
> to some name spaces at run time. So the compiler can't reliably
> determine that a variable doesn't exist any more than it can reliably
> determine that one does. This means that you can't flag using
> undeclared variables in those namespaces at compile time without a
> fundamental change in the language.

Yes it can. AFAIK python doesn't allow that a variable is created
in a function scope from somewhere else. Sure it may be possible
through some hack that works in the current C implemantation,
but there is a difference between what the language allows and
what is possible in a specific implementation.

Python also has the __slots__ attribute which prohibites attributes
to be added or deleted from instances.

Python can work with C-extension. What would have been the difference
if python would have had a number of static features that would have
allowed this kind of code be written in python itself. Look at pyrex,
I don't see where it lacks in dynamism with respect to python.

-- 
Antoon Pardon