"no variable or argument declarations are necessary."

[Barbier de Reuille]

Dans l'article <86mzlmpo5r.fsf at bhuda.mired.org>, Mike Meyer a écrit :
> Pierre Barbier de Reuille <pierre.barbier at cirad.fr> writes:
>> Mike Meyer a écrit :
>>> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>>> 
>>>>Op 2005-10-03, Steven D'Aprano schreef <steve at REMOVETHIScyber.com.au>:
>>>>
>>>>>On Mon, 03 Oct 2005 13:58:33 +0000, Antoon Pardon wrote:
>>>>
>>>>Declarations also allow easier writable closures. Since the declaration
>>>>happens at a certain scope, the run time can easily find the correct
>>>>scope when a variable is rebound.
>>> If it happens at runtime, then you can do it without declarations:
>>> they're gone by then. Come to think of it, most functional languages -
>>> which are the languages that make the heaviest use of closures - don't
>>> require variable declarations.
>> Well, can you give a single example of such language ? Because all the
>> functionnal language I know but one do need variable declaration : lisp,
>> scheme, ocaml, haskell do need variable declaration ! Erlang do not ...
> 
> Scheme and lisp don't need variable declerations. Last time I looked,
> Schemd didn't even *allow* variable declerations.

When you want local variable in lisp you do :

(let ((a 3)) (+ a 1))

For global variable you may do:

(defparameter *a* 4)

or:

(defvar *a* 4)

However, either way, variable assignment is done via :

(setf *a* 5)
(setf a 10)

This is what I call variable declaration as you have different way
to declare global variables and to assign them ... So the
two operations are well defined and different. And here there is a
difference between static language and declarative ones ... Lisp is a
dynamic language that needs variable declarations.

> 
>>> 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.
>> Type inferencing only works for statically typed languages AFAIK ! In a
>> dynamically typed languages, typing a variable is simply impossible as
>> any function may return a value of any type !
> 
> I think we're using different definitions of statically typed
> here. A language that is statically typed doesn't *need* type
> inferencing - the types are all declared! Type determines the thypes
> by inferenceing them from an examination of the program. So, for
> instance, it can determine that this function:

Well, indeed ... statically typed means only one thing : each *variable*
has a *static* type, i.e. a type determined at compile time. Once again,
OCaml and Haskell *are* statically typed but as they have type inference
you don't *need* to explicitely type your functions / variables. However
you *may* if you want ...

> 
> def foo():
>     return 1
> 
> Won't ever return anything but an integer.
> 
>>>>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.
>> Wrong argument ... with that kind of things, you would just stick with
>> plain Turing machine ... every single computation can be done with it !
> 
> "Computation" is is not the same thing as "Functionality". If you
> think otherwise, show me how to declare an object with a Turing
> machine.

Well, that was "bad spirit" from me ;) My argument here wasn't serious
in any mean ...

> 
> And there's also the issue of "clumsily". Turing machines are clumsy
> to program in.
> 
> 
>>> Except declarations don't add functionality to the language. They
>>> effect the programing process. 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.
>> Well, so why not *allow* for variable declaration ? Languages like Perl
>> does that successfully ... you don't like : you don't do ! you like :
>> you do ! A simple option at the beginning of the file tell the compilor
>> if variable declaration is mandatory or not !
> 
> Perl is a red herring. Unless it's changed radically since I last
> looked, undeclared variables in Perl have dynamic scope, not lexical
> scope. While dynamically scoped variables are a powerful feature, and
> there have been proposals to add them to Python, having them be the
> default is just *wrong*. If I were writing in Perl, I'd want
> everything declared just to avoid that. Of course, if Python behaved
> that way, I'd do what I did with Perl, and change languages.

I never said to adopt the whole Perl variable semantic. I just pointed
what I think is a good idea in Perl and that help (IMHO) precising what
I intended ...

> 
>>> 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.
>> Dynamic language and variable declaration are non-related issues ! You
>> can have statically-typed language without variable declaration (i.e.
>> BASIC) and dynamically-typed language with (i.e. Lisp) ! Please, when
>> you says something about languages, at least give 1 name of language
>> asserting what you're saying !
> 
> Declerations and typing are *also* non-related issues. See Perl. Also
> see the subject line.

That was just my point ...

> 
>>> 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.
>> Well, could you be more specific once more ? I can't that many paradigm
>> only available on dynamically typed languages ... beside duck-typing
>> (which is basically a synonym for dynamically-typed)
> 
> I said "dynamic languages", *not* "dynamically typed languages". They
> aren't the same thing. Dynamic languages let you create new functions,
> variables and attributes at run time. Python lets you delete them as
> well.  This means that simle declarations can't tell you whether or
> not a variable will exist at runtime, because it may have been added
> at run time.

Ok, I misunderstood ... however, can you still point some *usefull*
paradigm available to dynamic languages that you cannot use with static
ones ? As there are so many, it shouldn't be hard for you to show us
some !

> 
>>> 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.
>> After more than two years of Python programming, I still fill the need
>> for variable declarations. It would remove tons of bugs for little works
>> and would also clarify the scope of any single variable.
> 
> Maybe you're still writing code for a language with declerations? I
> never felt that need. Then again, I came to Python from a language
> that didn't require declerations: Scheme.
> 
>>> Pick one of the many languages that don't require declarations. Try
>>> writing a code in them, and see how much of a problem it really is in
>>> practice, rather than trying to predict that without any
>>> information. Be warned that there are *lots* of variations on how
>>> undeclared variables are treated when referenced. Python raises
>>> exceptions. Rexx gives them their print name as a value. Other
>>> languages do other things.
>> Well, IMO, worst case is silently give a default value, like PHP (or
>> apparently Rexx) does ... this can hide bugs for month if a single
>> test-case is missing !
>>
>> Well, in the end, I would really like an *option* at the beginning of a
>> module file requiring variable declaration for the module. It would
>> satisfy both the ones who want and the ones who don't want that ...
> 
> Nope. It would just change the argument from "Python should have ..."
> to "You should always use ..." or "Module foo should use ...".
> 
>    <mike


-- 
BOFH excuse #413:

Cow-tippers tipped a cow onto the server.