"no variable or argument declarations are necessary."

[Mike Meyer]

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.

>>> 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.

>>> I think language matters shouldn't be setlled by personal preferences.
>> I have to agree with that. For whether or not a feature should be
>> included, there should either be a solid reason dealing with the
>> functionality of the language - meaning you should have a set of use
>> cases showing what a feature enables in the language that couldn't be
>> done at all, or could only be done clumsily, without the feature.
> I think this is too strict. Decorators would IMO never made it.

>From the impressions I get here, a lot of people would have been happy
with that result.

> I think that a feature that could be helpfull in reduction
> errors, should be a candidate even if it has no other merrits.

Yes, but that doesn't mean it should be accepted. Otherwise, every
language would be Eiffel. You have to weigh the cost of a feature
against the benefit you get from it - and different people come to
different conclusions. Which is why different languages provide
different levels of bondage.

>> 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. And that's the only change you need to get writable variables -
some way to indicate that a variable should be checked for up the
scope. There are more lightweight ways to do that than tagging every
*other* variable. Those have been proposed - and rejected.

>> 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.

>> Antoon, at a guess I'd say that Python is the first time you've
>> encountered a dynamnic language. Being "horrified" at not having
>> variable declarations, which is a standard feature of such languages
>> dating back to the 1950s, is one such indication.
> No I'm not horrified at not having variable declarations. I'm in
> general very practical with regard to programming, and use what
> features a language offers me. However that doesn't stop me from
> thinking: Hey if language X would have feature F from language Y,
> that could be helpfull.

I'm sorry - I thought you were the OP, who said he was horrified by
that lack.

>> 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. 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.

> 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.

>> Given these kinds of differences, prior experience is *not* a valid
>> reason for thinking that some difference must be wrong. Until you have
>> experience with the language in question, you can't really decide that
>> some feature being missing is intolerable. You're in the same position
>> as the guy who told me that a language without a goto would be
>> unusable based on his experience with old BASIC, FORTRAN IV and
>> assembler.
> There seems to be some misunderstanding, I don't remember stating that
> missing declarations are intolerable, I certainly dont think so. I
> wouldn't be programming in python for over five years now if I
> thought so. But that doesn't mean having the possibilty to
> declare is useless.

Again, I was apparently confusing you and the OP. My apologies.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.