Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Optional Static Typing

Reply
Thread Tools

Optional Static Typing

 
 
Donn Cave
Guest
Posts: n/a
 
      12-25-2004
Quoth http://www.velocityreviews.com/forums/(E-Mail Removed) (Alex Martelli):
| Donn Cave <(E-Mail Removed)> 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, (E-Mail Removed)
 
Reply With Quote
 
 
 
 
Luis M. Gonzalez
Guest
Posts: n/a
 
      12-25-2004
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?

 
Reply With Quote
 
 
 
 
Stephen Thorne
Guest
Posts: n/a
 
      12-25-2004
On 24 Dec 2004 21:35:24 -0800, Luis M. Gonzalez <(E-Mail Removed)> 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.
 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      12-25-2004
Donn Cave <(E-Mail Removed)> 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
 
Reply With Quote
 
gabriele renzi
Guest
Posts: n/a
 
      12-25-2004
Mike Meyer ha scritto:
> "John Roth" <(E-Mail Removed)> writes:
>
>
>><(E-Mail Removed)> 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)
 
Reply With Quote
 
moma
Guest
Posts: n/a
 
      12-25-2004
(E-Mail Removed) 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,]


# 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,]
^^
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



 
Reply With Quote
 
Just
Guest
Posts: n/a
 
      12-25-2004
In article <d3fzd.1616$(E-Mail Removed)>,
moma <(E-Mail Removed)> wrote:

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


What about this?

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

....which is valid Python today.

Just
 
Reply With Quote
 
Rahul
Guest
Posts: n/a
 
      12-25-2004
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
> (E-Mail Removed)


 
Reply With Quote
 
Luis M. Gonzalez
Guest
Posts: n/a
 
      12-25-2004
> > 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).

 
Reply With Quote
 
Mike Meyer
Guest
Posts: n/a
 
      12-26-2004
(E-Mail Removed) (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 <(E-Mail Removed)> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
optional static typing for Python Russ P. Python 39 01-30-2008 02:18 PM
Status of optional static typing in Python? Christian Convey Python 6 06-23-2006 12:22 PM
Re: Koolaid (was Re: Optional Static Typing) Tim Churches Python 2 12-24-2004 01:18 PM
Guido & Optional Static Typing Luis M. Gonzalez Python 1 12-24-2004 01:58 AM
Optional static typing (or, What can Ruby 2.0 borrow from Boo?) Daniel Berger Ruby 22 12-01-2004 09:26 PM



Advertisments