Optional Static Typing

[bearophileHUGS]

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Boo (http://boo.codehaus.org/) is a different language, but I like its
"as" instead of ":" and "->", to have:
def min(a as iterable(T)) as T:
Instead of:
def min(a: iterable(T)) -> T:
Sometimes it can be useful to mix parts with static typing and parts
without it in the same module (because dynamic typing is very useful
sometimes), but some other times you want to be sure to have a full
typed and checked module. So maybe a kind of compiler directive (like
the # used to define encoding) can be used to define a module fully
typed and fully checked by a pychecker-like. (A module with static
typing can be very useful for a "true" python compiler too.)
Bear hugs,
bearophile

[Doug Holton]

be************@lycos.com wrote:

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
Thanks for pointing out that article by Guido van Rossum. Looks like it
just came out today. It is something that may be added to Python 3.0:
http://www.python.org/moin/Python3.0
Sometimes it can be useful to mix parts with static typing and parts
without it in the same module (because dynamic typing is very useful
sometimes), but some other times you want to be sure to have a full
typed and checked module.
The closest option right now in CPython is to use Pyrex.
http://nz.cosc.canterbury.ac.nz/~greg/python/Pyrex/

Boo (http://boo.codehaus.org/) is a different language, but I like its
"as" instead of ":" and "->", to have:
def min(a as iterable(T)) as T:
Instead of:
def min(a: iterable(T)) -> T:

Right, you're first example is how Boo does it, and the 2nd is how Guido
proposed to do it in Python 3.0.

Boo flips the problem around. Instead of optional static typing,
everything is statically typed by default (but with type inference so
you do not always need to explicitly declare the type), and it has
optional runtime typing that works like python's ("duck typing").
http://svn.boo.codehaus.org/trunk/te....boo?view=auto
http://svn.boo.codehaus.org/trunk/ex....boo?view=auto
http://svn.boo.codehaus.org/trunk/te....boo?view=auto
http://boo.codehaus.org/Duck+Typing

And there are some disadvantages to doing it this way. It means Python
is more flexible to use than Boo, as I stated a couple months back:
http://groups-beta.google.com/group/...51cdc9ffecbc72

[John Roth]

<be************@lycos.com> wrote in message
news:11**********************@c13g2000cwb.googlegr oups.com...

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551
One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.

I'm not convinced that it's all that effective at either objective.
My viewpoint on this is
that of someone who generally uses test first programming
(as in Test Driven Development or Extreme Programming).
Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more.

Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

This isn't to say TDD is the be-all and end-all of
correctness. Formal methods and formal inspections
both have very good reputations. In fact, the technique
with the best reputation is embodied in a sign that was
on the wall of every office of the old IBM: Think!

So let's look a bit deeper. As far as I remember, static
typing came out of the formal methods work in the '70s
by people like Djikstra, Hoar and Wirth (to name only
a few.) The thing is, if you properly use the formal program
derivation methods they advocated, then you don't need
it: your program will be as correct as it's possible to get
short of your being promoted to godhood.

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place. This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

So if the problem is reducing errors, then maybe
we should be working on the places where errors
show up.

Another point that's sometimes raised is that it's
useful to provide type information via reflection.
I used to think that was a valid concern until I
started work on PyFit. I had to put a rather
simplistic metadata facility into the program to
substitute for not having type information, and
I found that it was incredibly useful for other
things that you can't get from reflection on
type data.

John Roth
Bear hugs,
bearophile

[Rocco Moretti]

John Roth wrote:

One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.
<shrug> It might just be me, but I thought it was to simplify code
analysis and compilation. (That is, for the use of static typing in
general, not for Python in particular.)

Looking at C, it's doubtful error prevention and program clarification
was a serious objective in the static typing system. It's more
reasonable to conclude that C is statically typed because it allows the
compiler to more easily allocate 1 vs 2 vs 8 bytes for a particular
variable, and to make sure the proper addition opcodes get put down.

Now whether this would be useful for Python is an open question.
Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more. .... This isn't to say TDD is the be-all and end-all of
correctness.
Right. And unit tests don't do anything for people who don't use them.
The question is, should Guido state "TDD is the one true way to program
in Python.", or should concessions be made in the language design for
those who don't "drink the TDD Kool-aide".
So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place.

I rebut it thusly: "elitist bastard." <wink and a half>

One of the draws of Python is that it's welcoming to newcomers and
programmers of all talents. You don't have to be an "uber-programmer" to
use it and use it well. Should we hobble it to suit poor programmers?
No. But that's no reason why it can't be made to be easier and safer to
use for the hobbyist when it doesn't compromise usefulness for the
power-programmer. (My opinion) Python shouldn't have a sign on the door
saying: "You must be this 'leet to enter."

Will static typing be a boon for Python? Is it necessary? Or is it the
trailhead on the road to Hades? <shrug> Only time will tell.

[bearophileHUGS]

Doug Holton:

And there are some disadvantages to doing it this way.
It means Python is more flexible to use than Boo,

I've just suggested the *syntax* that I like more.

Bye,
Bearophile

[John Roth]

"Rocco Moretti" <ro**********@hotpop.com> wrote in message
news:cq**********@news.doit.wisc.edu...

John Roth wrote:

One of the comments on Artima asks a rather profound
question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.
<shrug> It might just be me, but I thought it was to simplify code
analysis and compilation. (That is, for the use of static typing in
general, not for Python in particular.)

Looking at C, it's doubtful error prevention and program clarification was
a serious objective in the static typing system. It's more reasonable to
conclude that C is statically typed because it allows the compiler to more
easily allocate 1 vs 2 vs 8 bytes for a particular variable, and to make
sure the proper addition opcodes get put down.

The C language does not have strong typing in the sense
that most people use the term today.

Now whether this would be useful for Python is an open question.

Many of the supposed advantages simply aren't there
when you go to the discipline of writing a test and then
writing exactly the code needed to make the test pass, and
not one keystroke more. ...

This isn't to say TDD is the be-all and end-all of
correctness.

Right. And unit tests don't do anything for people who don't use them.

Absolutely correct.
The question is, should Guido state "TDD is the one true way to program in
Python.", or should concessions be made in the language design for those
who don't "drink the TDD Kool-aide".
Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place.

I rebut it thusly: "elitist bastard." <wink and a half>

Bullshit. Where did you get your certificate in mind reading?

Remember that all of the people who started this were
computer science professors, and most of their experiance was
with computer science students. They were also European
computer science professors with a strong mathematical
tendency; we have since learned that mathematicians and
software developers think differently (see some comments
by Don Knuth to that effect - don't have the reference handy.)

They're the ones who were elitist: they strongly believed
that you had to be a mathematician to be able to properly
program, and that they were doing something good for
the people who weren't fortunate enough to have a
rigorous mathematical background by forcing them into
the strait-jacket of static typing.

Competent professional programmers are a different group,
and need different facilities.
One of the draws of Python is that it's welcoming to newcomers and
programmers of all talents. You don't have to be an "uber-programmer" to
use it and use it well. Should we hobble it to suit poor programmers? No.
But that's no reason why it can't be made to be easier and safer to use
for the hobbyist when it doesn't compromise usefulness for the
power-programmer. (My opinion) Python shouldn't have a sign on the door
saying: "You must be this 'leet to enter."
And it won't. Python has always had the "consenting adults"
philosophy.
Will static typing be a boon for Python? Is it necessary? Or is it the
trailhead on the road to Hades? <shrug> Only time will tell.

Since it won't happen, I'm not particularly worried about it.
If it does, I'll find another language.

John Roth

[Rocco Moretti]

John Roth wrote:

"Rocco Moretti" <ro**********@hotpop.com> wrote

Looking at C, it's doubtful error prevention and program clarification
was a serious objective in the static typing system. It's more
reasonable to conclude that C is statically typed because it allows
the compiler to more easily allocate 1 vs 2 vs 8 bytes for a
particular variable, and to make sure the proper addition opcodes get
put down.

The C language does not have strong typing in the sense
that most people use the term today.

Strong != Static

As I understand it, strong typing means an object (variable) is what it
is, and can't be changed to a different type without explicit conversion
- weak typing being that an object can be any type, depending on which
functions you use to look at it.

Static typing is that a variable has a specific type, and can't hold a
variable of a different type. This is opposed to dynamic typing, where
the type of an (object in a) variable is flexible and determined at run
time.

Python - Strong, Dynamic
C - Weak, Static
Perl - Weak, Dynamic

This is how I understand it. Could be wrong - wouldn't be surprised if I
was, as it's a rather confusing issue at times.

The question is, should Guido state "TDD is the one true way to
program in Python.", or should concessions be made in the language
design for those who don't "drink the TDD Kool-aide".

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

The irony didn't travel well. All I meant is that in all the advocacy,
it may get ignored that reasonable people might disagree about the value
of TDD, that TDD is not a "be-all, end-all" for all people.

"Concessions" also probably wasn't the right choice of word, as it
implies the TDD people are giving something up. My point was, if Python
is not going to be solely targeted at TDD, facilities that make other
ways of doing things easier are likely (should) be included, as long as
they don't negatively affect how the majority of the people who use
Python do things.

So the conclusion here is that static typing is an attempt
to make programming safe for people that shouldn't be
programming in the first place.

I rebut it thusly: "elitist bastard." <wink and a half>

Bullshit. Where did you get your certificate in mind reading?

Sorry. I didn't mean to imply that *you* were an elitist bastard. I
merely meant that someone who would dismiss something as for "people
that shouldn't be doing X in the first place" is likely biased by
snobbery. You were merely restating someone else's opinion, and if I
accidentally accused you of also holding it, I'm sorry.

From the rest of your post, it seems we pretty much agree on the key
point - different people have different ways of doing things, none of
which are necessarily "wrong" in and of themselves. Python tries to be
open and inclusive towards all who want to program, without sacrificing
power for it's core users.

Is there a group of people for whom static typing truly helps? I don't
know. What I do know is that saying that you don't need static typing if
you use TDD doesn't say anything about the helpfulness of static typing
for those who don't use TDD. Whether the latter group is worth Python
worrying about is a philosophical question on the future direction of
Python best left to Guido.

[Peter Hansen]

John Roth wrote:

"Rocco Moretti" <ro**********@hotpop.com> wrote:

The question is, should Guido state "TDD is the one true way to
program in Python.", or should concessions be made in the language
design for those who don't "drink the TDD Kool-aide".

Neither one. I hope you didn't mean that people
who advocate TDD are suicidal fanatics, because
that's exactly what "drink the kool-aid" means.

I always thought the connotation was more that those who
"drank the Kool-Aid" were unthinking drones, following what
others told them to do.

Reading Wikipedia's account of Jonestown, it seems
that the truth is a mix of both the blind loyalty thing
and the suicidal fanatic thing.

I've heard this applied most often in recent years
to XML, and while I can imagine some people who apply
the phrase to those overusing XML might think they
are effectively committing suicide, I'm pretty sure
most times it is just used to mean "you are blindly
doing what everybody else does without thinking about
whether it's the right thing to do".

-Peter

P.S.: The ironic thing about all this is that it was
actually something called "Flavor Aid", made by a
company called Jel Sert (http://www.jelsert.com),
and not Kool-Aid at all. What would be even funnier
is if the expression doesn't derive from the Jonestown
suicides and I've always just assumed it did...

[Alex Martelli]

<be************@lycos.com> wrote:

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Guido doesn't read this group; if you want him to read your notes, post
them as comments to Artima.

_My_ personal note is that I'm now even gladder I got myself Van Roy's
and Haridi's excellent "Concepts, Techniques and Models of Computer
Programming" book as a Christmas self-gift, and my motivation for
studying it in depth is renewed and refreshed...
Alex

[Alex Martelli]

John Roth <ne********@jhrothjr.com> wrote:
...

question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program. ... Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

....which is exactly the point of the famous post by Robert ("Uncle Bob")
Martin on another artima blog,
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .
Alex

[Mike Meyer]

"John Roth" <ne********@jhrothjr.com> writes:

<be************@lycos.com> wrote in message
This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

LISP has type declarations. Everybody I know doing production work in
LISP uses them. It's the only way to get reasonable performance out of
LISP compiled code.

Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

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

[Neal D. Becker]

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

[Rahul]

Hi.
Well i am a newbie to python and maybe not qualified enough to make a
comment on proposals to changes in python. My previous programming
experience has been in Java and C. So maybe you will forgive me if i
make any outlandish comments.

But anyway here goes:

I think instead what should be done is:

1.def gcd(a,b) expects (int,int)

Here the function is not enforcing type checking. The compiler should
only generate warning when someone passes something which is not an int
and should not generate an error.Maybe the person calling the function
knows what he is doing and wants to pass the unexpected type.

2.Another possibility is to let the function decide if the type is not
what it is expecting. Maybe the function recvs some kind of flag which
tells it that the type passed is not what it was expecting. So it can
throw an error if it is really critical.

3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes
this clear.

Rahul Garg

[Alex Martelli]

Neal D. Becker <nd*******@verizon.net> wrote:

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

Haskell's a great language, but beware: its static typing is NOT
optional -- it's rigorous. It can INFER types for you (just like, say,
boo), that's a different issue. It also allows bounded genericity at
compile time (like, say, C++'s templates without the hassles), and
that's yet another (typeclasses are a great mechanism, btw).

Languages with really optional static typing can be found; I think the
premier example is still Dylan -- a kind of commonlisp without infix
notation, unfortunately very out of fashion nowadays but still available
(some good books, too).

I love the explanations of Van Roy and Haridi, p. 104-106 of their book,
though I may or may not agree with their conclusions (which are
basically that the intrinsic difference is tiny -- they point to Oz and
Alice as interoperable languages without and with static typing,
respectively), all the points they make are good. Most importantly, I
believe, the way dynamic typing allows real modularity (harder with
static typing, since type discipline must be enforced across module
boundaries), and "exploratory computing in a computation model that
integrates several programming paradigms".

"Dynamic typing is recommended", they conclude, "when programs must be
as flexible as possible". I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most real-world
application programming -- and therefore why, in said real world rather
than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
dynamic typing is generally preferable, and not such a tiny issue as
they make the difference to be. Still, they at least show more
awareness of the issues, in devoting 3 excellent pages of discussion
about it, pros and cons, than almost any other book I've seen -- most
books have clearly delineated and preformed precedence one way or the
other, so the discussion is rarely as balanced as that;).
Alex

[Nick Coghlan]

Mike Meyer wrote:

Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

I had some thoughts along the same lines, so I dug up PEP 246 and looked at how
it could be enhanced to potentially support compile time code optimisation
through static type declarations.

The write up is here:
http://boredomandlaziness.skystorm.n...in-python.html

Cheers,
Nick.

--
Nick Coghlan | nc******@email.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net

[Michael Sparks]

Rocco Moretti wrote:
....

Is there a group of people for whom static typing truly helps?

Yes. Python doesn't at present compile down to a binary executable. (Py2exe
don't really count since that's "just" tacking on a VM on the side (he says
dimissively regarding something he thinks is cool :) )

The closest I can get to this at present is pyrex - which essentially
performs a translation from a very python like language to C, which you
then compile, and if you do things right can produce standalone modules.
Type declarations there are optional, and if omitted falls back to a python
object. If they are included however, you can gain performance boosts for
certain kinds of work. (Most often though you're simply interfacing to C
code.)

ie the groups that could benefit are those that currently go to C/C++
extensions for performance boosts. (and of course those who just want
binary executables :) (In the absence of Starkiller being released that
is...)

Regards,
Michael.

[Tim Jarman]

In article <Zs********************@powergate.ca>,
Peter Hansen <pe***@engcorp.com> wrote:

P.S.: The ironic thing about all this is that it was
actually something called "Flavor Aid", made by a
company called Jel Sert (http://www.jelsert.com),
and not Kool-Aid at all. What would be even funnier
is if the expression doesn't derive from the Jonestown
suicides and I've always just assumed it did...

I always thought it was a reference to the Illuminatus! trilogy
(http://tinyurl.com/5uhrz) by Robert Shea & Robert Anton Wilson. At
least, I'm pretty sure that's where I came across it. Maybe they were
referencing Jamestown?

Now if only I could think of a connection between this and Python...

--
Remove luncheon meat to reply.

[Donn Cave]

Quoth al*****@yahoo.com (Alex Martelli):
....
| Haskell's a great language, but beware: its static typing is NOT
| optional -- it's rigorous. It can INFER types for you (just like, say,
| boo), that's a different issue. It also allows bounded genericity at
| compile time (like, say, C++'s templates without the hassles), and
| that's yet another (typeclasses are a great mechanism, btw).

He didn't dwell much on it, but there was some mention of type
inference, kind of as though that could be taken for granted.
I guess this would necessarily be much more limited in scope
than what Haskell et al. do.

Donn Cave, do**@drizzle.com
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----

[Alex Martelli]

Donn Cave <do**@drizzle.com> wrote:

Quoth al*****@yahoo.com (Alex Martelli):
...
| Haskell's a great language, but beware: its static typing is NOT
| optional -- it's rigorous. It can INFER types for you (just like, say,
| boo), that's a different issue. It also allows bounded genericity at
| compile time (like, say, C++'s templates without the hassles), and
| that's yet another (typeclasses are a great mechanism, btw).

He didn't dwell much on it, but there was some mention of type
inference, kind of as though that could be taken for granted.
I guess this would necessarily be much more limited in scope
than what Haskell et al. do.

Assuming that by "he" you mean GvR, I think I saw that too, yes. And
yes, a language and particularly a typesystem never designed to
facilitate inferencing are hard-to-impossible to retrofit with it in as
thorough a way as one that's designed around the idea. (Conversely,
making a really modular system work with static typing and inferencing
is probably impossible; in practice, the type inferencer must examine
all code, or a rather copious summary of it... it can't really work
module by module in a nice, fully encapsulated way...).
Alex

[Scott David Daniels]

Rahul wrote:

1.def gcd(a,b) expects (int,int)
I presume by this syntax you mean something like:
def gcd(a, b) expects (int, int):
if b > a:
a, b = b, a
while a > b > 0:
a, b = b, a % b
return a
Here the function is not enforcing type checking. The compiler should
only generate warning when someone passes something which is not an int
and should not generate an error.Maybe the person calling the function
knows what he is doing and wants to pass the unexpected type.
But if this is the case, why is it different from?:
def gcd(a, b): # expects (int, int)
return a * b
2.Another possibility is to let the function decide if the type is not
what it is expecting. Maybe the function recvs some kind of flag which
tells it that the type passed is not what it was expecting. So it can
throw an error if it is really critical.
Again, why make the test at all if you don't want to act on it?
assert <boolexp> aborts if it is checked at all, but with __debug__
defined as 1, it passes. Perhaps you are proposing that expects be
used in that context.
3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes
this clear.

You need to explain why anyone would want to write expects at all.
If you are expecting the code generation to change, you'd better
enforce, rather than advise, unless you are defining points at which
to do code specialization on types.

--Scott David Daniels
Sc***********@Acm.Org

[Donn Cave]

Quoth al*****@yahoo.com (Alex Martelli):
| Donn Cave <do**@drizzle.com> wrote:
....
| > He didn't dwell much on it, but there was some mention of type
| > inference, kind of as though that could be taken for granted.
| > I guess this would necessarily be much more limited in scope
| > than what Haskell et al. do.
|
| Assuming that by "he" you mean GvR, I think I saw that too, yes. And
| yes, a language and particularly a typesystem never designed to
| facilitate inferencing are hard-to-impossible to retrofit with it in as
| thorough a way as one that's designed around the idea. (Conversely,
| making a really modular system work with static typing and inferencing
| is probably impossible; in practice, the type inferencer must examine
| all code, or a rather copious summary of it... it can't really work
| module by module in a nice, fully encapsulated way...).

Well, I would assume that a modules in a static system would present
a typed external interface, and inference would apply only within the
module being compiled.

for example, Objective CAML revised syntax -

$ cat mod.ml
module T =
struct
type op = [On | Off];
value print t a = match t with
[ On -> print_string a | Off -> () ];
value decide t a b = match t with
[ On -> a | Off -> b ];
end;

$ ocamlc -i -pp camlp4r mod.ml
module T :
sig
type op = [ On | Off ];
value print : op -> string -> unit;
value decide : op -> 'a -> 'a -> 'a;
end;

This is fairly obvious, so I'm probably missing the point,
but the compiler here infers types and produces an interface
definition. The interface definition must be available to
any other modules that rely on this one, so they are relieved
of any need to examine code within this module.

There might be tricky spots, but I imagine the Objective CAML
folks would object to an assertion like "making a really modular
system work with static typing and inferencing is probably
impossible"!

Donn Cave, do**@drizzle.com

[Luis M. Gonzalez]

I don't understand why this discussion on optional static typing came
up right at this moment.
As far as I know, it has been discussed many times in the past, and
there even was a SIG that simply died... but it seems that it never was
something of much interest to python developers (that's my impression,
I might be wrong).

Now, that the Pypy project is steadily advancing (and which is aimed at
making Python faster while keeping it dynamic and simple), why has this
topyc been raised?

Also there's starkiller, which deals with agressive type inference and
compilation to native code. If these projects are serious and are well
headed, then I don't know why we are talking now of static typing.

Lets say that Pypy and/or Starkiller end up as succesful projects, what
would be the advantage of having static typing in Python?

[Stephen Thorne]

On 24 Dec 2004 21:35:24 -0800, Luis M. Gonzalez <lu*****@gmail.com> wrote:

I don't understand why this discussion on optional static typing came
up right at this moment.

Because Guido made some notes on it.

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

merry christmas.
Stephen.

[Alex Martelli]

Donn Cave <do**@drizzle.com> wrote:
...

| making a really modular system work with static typing and inferencing
| is probably impossible; in practice, the type inferencer must examine
| all code, or a rather copious summary of it... it can't really work
| module by module in a nice, fully encapsulated way...).

Well, I would assume that a modules in a static system would present
a typed external interface, and inference would apply only within the
module being compiled. ... There might be tricky spots, but I imagine the Objective CAML
folks would object to an assertion like "making a really modular
system work with static typing and inferencing is probably
impossible"!

It seems to me that you just restated in the first part I quoted what
you say in the second part OCAML folks would object to. If you give up
on type inferencing across modules, and only have type inferencing
inside each module, then you're getting little mileage out of the
inferencing if your modules are many and small.

But let me quote Van Roy and Haridi, rather than paraphrasing them, lest
I fail to do them justice -- I think quoting 8 lines out of a book of
over 800 pages is "fair use" (anecdote: my Xmas gift is said book, my
wife's a real-bargain Powerbook 15" Titanium laptop -- yesterday we
weighed them against each other and determined the book's heavier;-)...

"""
Dynamic typing makes it a trivial matter to do separate compilation,
i.e. modules can be compiled without knowing anything about each other.
This allows truly open programming, in which independently written
modules can come together at runtime and interact with each other. It
also makes program development scalable, i.e., extremely large programs
can be divided into modules that can be recompiled individually without
recompiling other modules. This is harder to do with static typing
because the type discipline must be enforced across module boundaries.
"""

I see that by paraphrasing and summarizing by heart I was changing their
argument a bit, from 'enforcing the type discipline' (which is what
they're discussing, and is obviously mandatory if you want to talk about
static typing) to 'type inferencing' (which they don't discuss in this
specific paragraph). Nor do they claim 'probably impossible', since
they're only discussing enforcement, not inferencing -- just 'harder'.

Essentially, to compile a module under static typing you need full type
information for other modules -- the "without knowing anything about
each other" condition of fully separate compilation can't hold, and thus
neither can the "truly open programming" and "scalable development"
consequences. Mind you, I personally _like_ the concept of describing
an interface separately, even in a different language (Corba's IDL, say)
that's specialized for the task. But it doesn't seem to be all that
popular... without such separation, modularity plus static checking
appears to imply bottom->up coding: you need to compile modules in some
topologically sorted order compatible with the "X uses Y" relation.
Alex

[gabriele renzi]

Mike Meyer ha scritto:

"John Roth" <ne********@jhrothjr.com> writes:

<be************@lycos.com> wrote in message
This may sound a bit
cynical, but most real uber-programmers have either
Lisp or Smalltalk in their backgrounds, and
frequently both one. Neither of those languages
have static typing, and they simply don't need it.

LISP has type declarations. Everybody I know doing production work in
LISP uses them. It's the only way to get reasonable performance out of
LISP compiled code.

I also think some smalltalk allow you to tag stuff with type hints for
performance.
Which raises what, to me, is the central question. If we have optional
static typing, can I get a performance enhancement out of it? If not,
why bother?

for documentation and 'crash early' purposes, I'd say.
Btw, why don't we rip out the approach of CL and some schemes that offer
optional typing ? (not that I understand how those work, anyway)

[moma]

be************@lycos.com wrote:

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I have just a couple of notes:

Boo (http://boo.codehaus.org/) is a different language, but I like its
"as" instead of ":" and "->", to have:
def min(a as iterable(T)) as T:
Instead of:
def min(a: iterable(T)) -> T:

I want to introduce a shorter syntax form:

Declare variables
a'int
a'int = 13
s'string = "Santana"
d'float

def min(a'int, b'int)'int:
c'int # Declare a local variable c of type int
c = a
...
*************************************

The (template) notation is very useful.
def min(a'T, b'T)'T:
c'T
c = a
....

f'float = min(1.2, 2.2)
i'int = min(9, f) ## of course: comiler adds int(f) type conversion
*************************************

But these 2 should be syntactically wrong. The type of T is not obvious.

def max(a'int, b'int)'T:
....
def max(a, b)'T:
....
*************************************

The big question is how to handle combound data types (container
objects) ? lists, tuples, maps...

Can a list contain various data types?

h=['abc', 13, (9,8)]
# Declare h as list of ints
h'int[] = [1, 8, 991]

# These declarations produce syntax errors
h'int = [1, 8, 991]
error: h is a scalar not container

h'int[] = ['abc', 13, (9,8)]
^^
error: expecting int value
*************************************

Tuples

A general sequence
t = 1, 3, 4,

A tuple of ints
t'int() = 1, 3, 4,

What about this?
u'int() = t, 6, 7,

Yes, it's OK. because the basic_scalar_values are ALL ints.
print u

((1,3,4), 6,7)
Maps
......

*************************************

I think the compiler should allow typeless containers even you compile
with --strict option. Apply --strict (strictly) to scalar types only.

*************************************
class A:
pass
def func1(h'A)
# Expects (instance) A or any subclass of A
....
*************************************
// moma
http://www.futuredesktop.org/OpenOffice.html

[Just]

In article <d3******************@news4.e.nsc.no>,
moma <mo**@example.net> wrote:

What about this?
u'int() = t, 6, 7,

What about this?

u'int() = t, 6, 7,'

....which is valid Python today.

Just

[Rahul]

I am assuming that optional type checking is being added for easier
debugging only. So if 'expects' are turned on , python raises
warnings(which do not halt the system) but not when they are turned
off. These will enable easier debugging for new people while not
affecting masters. Also,perhaps, it will be easier to accomodate till
type checking mechanism is perfected(if it is implemented at all that
is) so that python does not stop you when it is in fact python which
might be making some mistake.(This last statement is a guess only...)

It is similar to assert and __debug__=1 in a way.

So the crux is :
1.Expects is only a bridge between type checking and dynamic typing.
2.Type checking is done only as a tool which you are free to override
if you want to.
3.The objective of type checking here is only to make debugging easier
and not speed/optimization.
4.The point is not that 'expects' be a additional keyword.You can go
like this also :
def (int a,int b): or whatever you like. Only that expects make it a
bit clearer IMHO.

sincerely.,
rahul

Scott David Daniels wrote:

Rahul wrote:

1.def gcd(a,b) expects (int,int)

I presume by this syntax you mean something like:
def gcd(a, b) expects (int, int):
if b > a:
a, b = b, a
while a > b > 0:
a, b = b, a % b
return a

Here the function is not enforcing type checking. The compiler should only generate warning when someone passes something which is not an int and should not generate an error.Maybe the person calling the function knows what he is doing and wants to pass the unexpected type.

But if this is the case, why is it different from?:
def gcd(a, b): # expects (int, int)
return a * b

2.Another possibility is to let the function decide if the type is not what it is expecting. Maybe the function recvs some kind of flag which tells it that the type passed is not what it was expecting. So it can throw an error if it is really critical.

Again, why make the test at all if you don't want to act on it?
assert <boolexp> aborts if it is checked at all, but with __debug__
defined as 1, it passes. Perhaps you are proposing that expects be
used in that context.

3.In my post i am not stressing on adding 'expects' as keyword or
something. Only that type should not be enforced and 'expects' makes this clear.

You need to explain why anyone would want to write expects at all.
If you are expecting the code generation to change, you'd better
enforce, rather than advise, unless you are defining points at which
to do code specialization on types.

--Scott David Daniels
Sc***********@Acm.Org

[Luis M. Gonzalez]

> > I don't understand why this discussion on optional static typing
came

up right at this moment.

Because Guido made some notes on it.

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

merry christmas.
Stephen.

Yes, I know Guido did it.
But I wonder why at this moment, just when things seem to be directed
in a complete opposite way and with good chance of success (as I said:
Pypy, Starkiller, etc).

[Mike Meyer]

al*****@yahoo.com (Alex Martelli) writes:

Mind you, I personally _like_ the concept of describing
an interface separately, even in a different language (Corba's IDL, say)
that's specialized for the task. But it doesn't seem to be all that
popular... without such separation, modularity plus static checking
appears to imply bottom->up coding: you need to compile modules in some
topologically sorted order compatible with the "X uses Y" relation.

Personally, I hate declaring the interface separately, whether in the
same language or another language. On the other hand, generating the
interface information from the code for type checking (and
documentation) purposes makes an incredible amount of sense. A type
inferencing engine to generate that information from Python code -
with possible a bit of human assistance - would make it possible to
use pychecker to catch duck typing errors without having to import an
entire module.

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

[Robert Kern]

Luis M. Gonzalez wrote:

I don't understand why this discussion on optional static typing came
up right at this moment.
As far as I know, it has been discussed many times in the past, and
there even was a SIG that simply died... but it seems that it never was
something of much interest to python developers (that's my impression,
I might be wrong).

Now, that the Pypy project is steadily advancing (and which is aimed at
making Python faster while keeping it dynamic and simple), why has this
topyc been raised?

Also there's starkiller, which deals with agressive type inference and
compilation to native code. If these projects are serious and are well
headed, then I don't know why we are talking now of static typing.

Lets say that Pypy and/or Starkiller end up as succesful projects, what
would be the advantage of having static typing in Python?

Starkiller would *love* type declarations. In Michael Salib's words (to
my recollection), "every piece of type information helps." I'm sure that
PyPy's code generator(s) could use this information to good effect, too.

Automatic type inferencing is great, but sometimes the inference is
"object". Being able to supply more information about types helps
Starkiller keep the inferences tight and specific.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Alex Martelli]

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

Mind you, I personally _like_ the concept of describing
an interface separately, even in a different language (Corba's IDL, say)
that's specialized for the task. But it doesn't seem to be all that
popular... without such separation, modularity plus static checking
appears to imply bottom->up coding: you need to compile modules in some
topologically sorted order compatible with the "X uses Y" relation.
Personally, I hate declaring the interface separately, whether in the
same language or another language.

Yeah, so do many people -- as I mentioned, it's not all that popular.
Personally, I don't see _why_, but there's no doubt that the market is
speaking quite loudly in this respect; the concept of using IDL is seen
as a handicap of (e.g.) Corba and pure COM (while I agree with Don Box's
lavish _praise_ for that concept in a COM context!), and the concept of
not having an interface separate from the implementation is touted as a
plus of (e.g.) Java vs C++.

But then, the above criticism applies: if interface and implementation
of a module are tightly coupled, you can't really do fully modular
programming AND static typing (forget type inferencing...).

On the other hand, generating the
interface information from the code for type checking (and
documentation) purposes makes an incredible amount of sense. A type
inferencing engine to generate that information from Python code -
with possible a bit of human assistance - would make it possible to
use pychecker to catch duck typing errors without having to import an
entire module.

And why should it be a problem to "import an entire module", pray? I
just fail to see any BIG advantage here. Sure, you could extend pydoc
to generate a bit more docs than it already does -- big deal. How much
would that augment your overall productivity? 5%? 10%? Some tiny
incremental amount, anyway. If it prompts you to do less unit testing,
it might even have a negative lifecycle-productivity impact;-).
Alex

[Luis M. Gonzalez]

Robert Kern wrote:

Automatic type inferencing is great, but sometimes the inference is
"object". Being able to supply more information about types helps
Starkiller keep the inferences tight and specific.

Hmm... I'm not an expert in this subject at all, but I think that when
the inference is "object", as you said, is because the type couldn't
be inferred so it defaults to object, which is the more general type of
all.
For example, this is what happens in Boo, which is the only language I
know (a little bit) that uses type inference.

[Mike Meyer]

al*****@yahoo.com (Alex Martelli) writes:

Mike Meyer <mw*@mired.org> wrote:

al*****@yahoo.com (Alex Martelli) writes:

> Mind you, I personally _like_ the concept of describing
> an interface separately, even in a different language (Corba's IDL, say)
> that's specialized for the task. But it doesn't seem to be all that
> popular... without such separation, modularity plus static checking
> appears to imply bottom->up coding: you need to compile modules in some
> topologically sorted order compatible with the "X uses Y" relation. Personally, I hate declaring the interface separately, whether in the
same language or another language.

Yeah, so do many people -- as I mentioned, it's not all that popular.
Personally, I don't see _why_

Because it violates the principle of "Once and only once". If the
interface is described in two places, that means it's possible to
update one and forget to update the other. That's not possible if the
interface is defined once and only once. I've forgotten to update my
IDL more than once.
But then, the above criticism applies: if interface and implementation
of a module are tightly coupled, you can't really do fully modular
programming AND static typing (forget type inferencing...).

I beg to differ. Eiffel manages to do this quite well. Then again,
every Eiffel environment comes with tools to extract the interface
information from the code. With SmartEiffel, it's a command called
"short". Doing "short CLASSNAME" is like doing "pydoc modulename",
except that it pulls routine headers and DbC expression from the code,
and not just from comments.

On the other hand, generating the
interface information from the code for type checking (and
documentation) purposes makes an incredible amount of sense. A type
inferencing engine to generate that information from Python code -
with possible a bit of human assistance - would make it possible to
use pychecker to catch duck typing errors without having to import an
entire module.

And why should it be a problem to "import an entire module", pray?

It isn't. I was just thinking out loud. If you had a type inferencing
engine that created the type signatures of everything in a module,
that would let you do type checking without importing the module. It's
actually more interesting for compiled languages than for interpreted
ones.

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

[Robert Kern]

Luis M. Gonzalez wrote:

Robert Kern wrote:

Automatic type inferencing is great, but sometimes the inference is
"object". Being able to supply more information about types helps
Starkiller keep the inferences tight and specific.

Hmm... I'm not an expert in this subject at all, but I think that when
the inference is "object", as you said, is because the type couldn't
be inferred so it defaults to object, which is the more general type of
all.
For example, this is what happens in Boo, which is the only language I
know (a little bit) that uses type inference.

Starkiller, at least, can deal with cases where a variable might be one
of a set of types and generates code for each of this set. Explicit type
declarations can help keep these sets small and reduces the number of
times that Starkiller needs to fall back to PyObject_* calls.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Donn Cave]

Quoth Mike Meyer <mw*@mired.org>:
| al*****@yahoo.com (Alex Martelli) writes:
....
|> But then, the above criticism applies: if interface and implementation
|> of a module are tightly coupled, you can't really do fully modular
|> programming AND static typing (forget type inferencing...).
|
| I beg to differ. Eiffel manages to do this quite well. Then again,
| every Eiffel environment comes with tools to extract the interface
| information from the code. With SmartEiffel, it's a command called
| "short". Doing "short CLASSNAME" is like doing "pydoc modulename",
| except that it pulls routine headers and DbC expression from the code,
| and not just from comments.

And you probably think Eiffel supports fully modular programming, as
I thought Objective CAML did. But Alex seems not to agree.

The way I understand it, his criteria go beyond language level semantics
to implementation details, like whether a change to a module may require
dependent modules to be recompiled when they don't need to be rewritten.
I don't know whether it's a reasonable standard, but at any rate hopefully
he will explain it better than I did and you can decide for oneself whether
it's an important one.

Donn Cave, do**@drizzle.com

[Alex Martelli]

Donn Cave <do**@drizzle.com> wrote:
...

And you probably think Eiffel supports fully modular programming, as
I thought Objective CAML did. But Alex seems not to agree.
Rather, I would say it's Dr Van Roy and Dr Haridi who do not agree;
their definition of "truly open programming" being quite strict, based
on modules "not having to know anything about each other". BTW, while I
have looked into Alice yet, some people posting on this thread
apparently have -- I know the Alice whitepaper claims Alice adds to ML
just what is needed to support "truly open programming" -- features that
OCAML doesn't have, so, if the Alice researchers are right, your
assessment of OCAML is wrong; OTOH, since Alice _is_ statically typed
like any other ML dialect, they'd appear to rebut Van Roy and Haridi's
contention, too. VR & H do mention Alice at the end of their pages
about static vs dynamic typing but they don't appear to acknowledge the
claim. Maybe it all boils down to both Oz and Alice being still open
research efforts, making it difficult to assess fully what results they
can eventually achieve.

The way I understand it, his criteria go beyond language level semantics
to implementation details, like whether a change to a module may require
dependent modules to be recompiled when they don't need to be rewritten.
Ah yes, definitely: Lakos' "Large Scale C++ Software Design" was the
first place where I met a thorough exposition of the evil effects that
come from modules "just needing to be recompiled, not rewritten" as soon
as the number of modules becomes interestingly large, at least with the
kind of dependency graphs that naturally emerge when designers are
focused on all other important issues of software design rather than
dependency control.

Basically, what emerges from Lakos' analysis, and gets formalized in
Robert Martin's precious "dependency inversion principle", is the
equivalent of the interface/implementation separation that you always
get e.g. in Corba, by writing the interface in IDL and the
implementation in whatever language you wish: both implementation and
client modules depend on an abstract-interface module, so the dependency
arrows go the "right" way (concrete depends on abstract) and the cycle
is more tractable. But if you proceed by extracting the abstract
interface from a concrete implementation, that's a dependency too
(albeit for a tool that's not the compiler), and it's the wrong way
around... abstract depends on concrete. (Main hope being that the
abstract part changes VERY rarely -- when it DOES change, the rebuild
cost is still potentially out of control).

You may use a separate language to express the interface (IDL,
whatever), you may use a subset of the implementation language with
strict constraints, but one way or another, if you want to control your
dependency graph and avoid the ills Lakos points out so clearly,
dependency inversion is an indispensable (perhaps not sufficient) tool.

Mike points out this breaks "once and only once", but then that same
principle is broken in any language where you express the type of a
variable twice -- in declaring AND in using it -- as is typical of most
statically-typed languages (even where the language does not mandate the
redundancy, as in *ML or Haskell, typical style in such languages is to
have the redundancy anyway; and AFAIK Eiffel _does_ mandate the
redundancy, just like C++ or Java do).

Dynamic languages have dependencies too, maybe not "reified" but
conceptually, _operationally_ there. For example, if you consider the
contract (as in DbC) to be part of a type, that's how Eiffel works: it
diagnoses the type violation (breach of contract) dynamically, at
runtime. And that's how's Oz, Python, Ruby, Erlang, etc etc, work too:
no type (signature, contract, ...) violation along any dependency arrow
need pass silently, they're diagnosed dynamically just like DbC
violations in Eiffel or more generally violations of other constraints
which a given language chooses not to consider "type-related" (e.g., if
the positive-reals are a separate type from general reals, sqrt(x) with
x<0 is a type violation -- if there's only a general reals type, it's
not -- hopefully, it's diagnosed at runtime, though).

Robert Martin's "Dynamic Visitor" design pattern is, I believe, an
instructive case. The classic "Visitor", per se, has intractable
dependency problems and cannot possibly respect fully the open/closed
principle; Dynamic Visitor uses the escapes to dynamic typing allowed by
such tools as C++'s dynamic_cast (and Java's own casts, which work quite
similarly) to ensure a sane dependency structure. If you don't have or
don't allow any escape from static typing, Visitor is somewhat of a
nightmare DP as soon as the kinds of visitors and visitees start
multiplying -- at the very least it's a build-time nightmare, even if
your language has tricks to save the need to change the code. Martin
does a much more thorough job of exploring these issues and I'll point
to his essays rather than trying to expand this summary further.

I don't know whether it's a reasonable standard, but at any rate hopefully
he will explain it better than I did and you can decide for oneself whether
it's an important one.

If you're building reasonably small systems, so that "recompiling the
world" is no big deal, dependency control may be considered a marginal
consideration -- some things such as dependency cycles you probably want
to eradicate anyway (so Visitor can still be thought of as nasty;-), but
there are no doubt many more important software development issues to
deal with than dependency control. But build times suffer from typical
combinatorial explosions with the growth of number of modules and
complications in the dependency graphs, so, if you're building large
systems, this isn't the kind of efficiency problem that goes away in two
or three years thanks to Moore's Law.
Alex

[Luis M. Gonzalez]

Robert Kern wrote:

Starkiller, at least, can deal with cases where a variable might be one of a set of types and generates code for each of this set. Explicit type declarations can help keep these sets small and reduces the number of times that Starkiller needs to fall back to PyObject_* calls.

Will we be able to see it anytime soon?
I'm eagerly waiting for its release.

[Mike Meyer]

"Donn Cave" <do**@drizzle.com> writes:

Quoth Mike Meyer <mw*@mired.org>:
| al*****@yahoo.com (Alex Martelli) writes:
...
|> But then, the above criticism applies: if interface and implementation
|> of a module are tightly coupled, you can't really do fully modular
|> programming AND static typing (forget type inferencing...).
|
| I beg to differ. Eiffel manages to do this quite well. Then again,
| every Eiffel environment comes with tools to extract the interface
| information from the code. With SmartEiffel, it's a command called
| "short". Doing "short CLASSNAME" is like doing "pydoc modulename",
| except that it pulls routine headers and DbC expression from the code,
| and not just from comments.

And you probably think Eiffel supports fully modular programming, as
I thought Objective CAML did. But Alex seems not to agree.

The way I understand it, his criteria go beyond language level semantics
to implementation details, like whether a change to a module may require
dependent modules to be recompiled when they don't need to be rewritten.
I don't know whether it's a reasonable standard, but at any rate hopefully
he will explain it better than I did and you can decide for oneself whether
it's an important one.

I read through his explanation. And the answer for Eiffel is, of
course, "it depends".

There's an optimization that embeds a class data directly in the
cilent class - the expanded keyword. If you have an expanded variable
or type in your client class, then changing the implementation of the
provider may require recompilation of the client. On the other hand,
that's pretty much an optimization, and so you shouldn't run into it
during development.

SmartEiffel, on the other hand, always does full-source analysis. It
drops class features that aren't used by any client, so changing the
client can cause the provider to be recompiled.

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

[Michael Hobbs]

Rahul <co********@gmail.com> wrote:

I am assuming that optional type checking is being added for easier
debugging only. So if 'expects' are turned on , python raises
warnings(which do not halt the system) but not when they are turned
off. These will enable easier debugging for new people while not
affecting masters. Also,perhaps, it will be easier to accomodate till
type checking mechanism is perfected(if it is implemented at all that
is) so that python does not stop you when it is in fact python which
might be making some mistake.(This last statement is a guess only...)

It is similar to assert and __debug__=1 in a way.

So the crux is :
1.Expects is only a bridge between type checking and dynamic typing.
2.Type checking is done only as a tool which you are free to override
if you want to.
3.The objective of type checking here is only to make debugging easier
and not speed/optimization.
4.The point is not that 'expects' be a additional keyword.You can go
like this also :
def (int a,int b): or whatever you like. Only that expects make it a
bit clearer IMHO.

sincerely.,
rahul

Your proposition reminds me very much of Design by Contract, which is
a prominent feature of the Eiffel programming language. Considering
that Python is an interpreted language where type checking would
naturally occur at runtime, I think Design by Contract would be more
appropriate than static typing.

In a function's contract, not only could it state that its parameter
must be an integer, but also that it must be > 50 and be divisible by
7. If a value is passed to the function that violates the contract,
it raises an exception.

In Eiffel, contract checking can be turned on or off based on a
compiler flag or a runtime switch.

- Mike

[Michael Hobbs]

Neal D. Becker <nd*******@verizon.net> wrote:

I've just started learning about Haskell. I suggest looking at this for an
example.

A good intro: http://www.haskell.org/tutorial

I've always found that with Haskell, if I can get my program to
compile without error, it usually runs flawlessly. (Except for the
occasional off-by-one error. :-) I don't know if that's due to the
fact that Haskell enforces pure functional programming, or if it's
due to Haskell's strict static typing, or the combination of the
two. But if anyone ever demanded that I wrote code that absolutely
positively has to work, no matter the cost, I would probably choose
Haskell.

Tying Haskell back to Python, if static type checking ever is
grafted on to Python, I would propose that it uses type inference,
a la Haskell or O'Caml, and raise an Error only when it detects a
truly unmistakable type error. This may be easier said than done,
however, given Python's dynamic nature. For example, a class's
method may be re-bound to any other function at runtime, which would
wreak havoc on any static type checker.

- Mike

[Donn Cave]

In article <1g**************************@yahoo.com>,
al*****@yahoo.com (Alex Martelli) wrote:

John Roth <ne********@jhrothjr.com> wrote:
...

question: static typing is an answer. What's the question?
(That's a paraphrase.)

The answer that everyone seems to give is that it
prevents errors and clarifies the program.

...

Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.

...which is exactly the point of the famous post by Robert ("Uncle Bob")
Martin on another artima blog,
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .

Wait a minute, isn't he same fellow whose precious
dependency inversion principle shows us the way to
support fully modular programming? What would he
say about unit testing to catch up with changes in
dependent modules, do you think? Do we have a
combinatorial explosion potential here?

Donn Cave, do**@u.washington.edu

[Alex Martelli]

Donn Cave <do**@u.washington.edu> wrote:
...

Most of the kinds of error that static typing is supposed
to catch simply don't persist for more than a minute when
you do test driven development.
...which is exactly the point of the famous post by Robert ("Uncle Bob")
Martin on another artima blog,
http://www.artima.com/weblogs/viewpost.jsp?thread=4639 .

Wait a minute, isn't he same fellow whose precious
dependency inversion principle shows us the way to
support fully modular programming? What would he

Yep, just the same guy (also responsible for Dynamic Visitor, et al).
say about unit testing to catch up with changes in
dependent modules, do you think? Do we have a
combinatorial explosion potential here?

I can't do justice to all he has to say about these issues, and many
others related to Agile development methods -- you should really get his
book (he's written several, but, in my opinion, it's his masterpiece --
<http://www.amazon.com/exec/obidos/tg...002-8057003-10
74462?v=glance>), or, failing that, at least read his essays at
<http://www.objectmentor.com/resource...thor&author=Ro
bert%20C.%20Martin> (I would skip all of the silly 'craftsman'
fictionalization he's writing for 'Software Development', but I guess
_some_ people must be into that...).
Alex

[Alex Martelli]

Michael Hobbs <mi**@hobbshouse.org> wrote:

Your proposition reminds me very much of Design by Contract, which is
a prominent feature of the Eiffel programming language. Considering
that Python is an interpreted language where type checking would
naturally occur at runtime, I think Design by Contract would be more
appropriate than static typing.
I entirely agree with this opinion.
In a function's contract, not only could it state that its parameter
must be an integer,
I'd like to be able to state something about the *INTERFACE* of the
parameter, to the rigorous exclusion of its *TYPE* (which is an
"implementation detail"). I doubt it's really feasible, but, in Haskell
terms, I'd love for such assertions to be always and necessarily about
_typeclasses_ rather than _types_...
but also that it must be > 50 and be divisible by
7. If a value is passed to the function that violates the contract,
it raises an exception.

In Eiffel, contract checking can be turned on or off based on a
compiler flag or a runtime switch.

I've always liked the (theoretical) idea that assertions (including of
course contracts) could be used as axioms used to optimize generated
code, rather than (necessarily) as a runtime burden. E.g. (and I don't
know of any implementation of this concept, mind you), inferring (e.g.
from such assertions) that x>=0, and that y<0, the compiler could simply
cut away a branch of dead code guarded by "if x<y:" (maybe with a
warning, in this case;-)...
Alex

[Scott David Daniels]

Michael Hobbs wrote:

I've always found that with Haskell, if I can get my program to
compile without error, it usually runs flawlessly. (Except for the
occasional off-by-one error. :-)

Then you need "Scott and Dave's Programming Language" -- SAD/PL.
By providing separate data types for even and odd numbers, you can
avoid off-by-one errors ;-)

--Tongue-in-cheek-ily-yours,
Scott David Daniels
Sc***********@Acm.Org

[Robert Kern]

Luis M. Gonzalez wrote:

Robert Kern wrote:

Starkiller, at least, can deal with cases where a variable might be one
of a set of types and generates code for each of this set. Explicit type
declarations can help keep these sets small and reduces the number of
times that Starkiller needs to fall back to PyObject_* calls.

Will we be able to see it anytime soon?
I'm eagerly waiting for its release.

It's been "about a month away" for at least 4 months now. I don't know
what the holdup has been. I know that Michael has graduated and so he's
probably been busy with a new job.

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Ville Vainio]

>>>>> "Alex" == Alex Martelli <al*****@yahoo.com> writes:

Alex> I've always liked the (theoretical) idea that assertions
Alex> (including of course contracts) could be used as axioms used
Alex> to optimize generated code, rather than (necessarily) as a
Alex> runtime burden. E.g. (and I don't know of any
Alex> implementation of this concept, mind you), inferring (e.g.
Alex> from such assertions) that x>=0, and that y<0, the compiler
Alex> could simply cut away a branch of dead code guarded by "if
Alex> x<y:" (maybe with a warning, in this case;-)...

I realize that your example is theoretical, but efficiency impact of
such optimizations would be dwarfed (speedwise) by optimization on
type, so that "if x < y" yields native object code for integer
comparison. Also, to get real benefits the functions called would need
to be inline-expanded so that the implications of x < y are taken in
account deeper in the call chain; a programmer that does

def f(x,y):
assert x > y
if x < y:
blah(y,x)

needs a slap on the wrists anyway. Doing "if x < y" in blah() would
make sense, but then there would need to be a special version of
blah()...

I could think of one worthwhile example as well:

def foo(l):
assert issorted(l)
if "hi" in l: # in does a bsearch because the list is sorted
blah()

but things like this probably belong to languages like Lisp where the
user gets to expand and mess with the compiler.

--
Ville Vainio http://tinyurl.com/2prnb

[Robin Becker]

Scott David Daniels wrote:
.....

Then you need "Scott and Dave's Programming Language" -- SAD/PL.
By providing separate data types for even and odd numbers, you can
avoid off-by-one errors ;-)

mmmhhh off by two-licious
--
Robin Becker

[Ryan Paul]

On Thu, 23 Dec 2004 01:49:35 -0800, bearophileHUGS wrote:

Adding Optional Static Typing to Python looks like a quite complex
thing, but useful too:
http://www.artima.com/weblogs/viewpost.jsp?thread=85551

I wrote a blog post this morning in which I briefly argue using DbC and
predicate based argument constraints instead of static typing. Take a look
if you are interested. It also contains a link to a wiki page where I have
been producing a more refined specification complete with good examples:

http://www.cixar.com/segphault/pytype.html

I would appreciate some feedback, I want to know what other python
programmers think about DbC and arg constraints.

-- SegPhault

[Jacek Generowicz]

al*****@yahoo.com (Alex Martelli) writes:

I've always liked the (theoretical) idea that assertions (including of
course contracts) could be used as axioms used to optimize generated
code, rather than (necessarily) as a runtime burden. E.g. (and I don't
know of any implementation of this concept, mind you), inferring (e.g.
from such assertions) that x>=0, and that y<0, the compiler could simply
cut away a branch of dead code guarded by "if x<y:" (maybe with a
warning, in this case;-)...

A few months ago, a troll challenged the denizens of comp.lang.lisp to
write a Lisp implementation of some some code which he posted in C++,
which would be competitive in terms of speed with his C++
version. The c.l.lers duly obliged, and, IIRC, it so happened that the
improvement that made the Lisp version overtake the C++ one was the
declaration of some variable to be of type "floating point number in
the range 0 to two Pi".

Of course, in CL type declarations are not contracts, but promises to
the compiler ... but it's still an examlpe of a situation where more
specific type information allowed the compiler to produce more
efficient code, in practice.