The Artima Developer Community
Sponsored Link

Weblogs Forum
Optional Static Typing -- Stop the Flames!

79 replies on 6 pages. Most recent reply: Feb 4, 2008 9:52 AM by Wolfgang Lipp

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 79 replies on 6 pages [ « | 1 ... 3 4 5 6 ]
Richard Prosser

Posts: 3
Nickname: rprosser
Registered: Jul, 2005

Re: Optional Static Typing -- Stop the Flames! Posted: Jul 18, 2005 4:04 AM
Reply to this message Reply
Advertisement
I may be naive but I am surprised by the complexity of the debate here. To my mind, what is required in essence is a text pre-processor ('macro definition language'), applied before run-time. Decorators appear to be heading in that direction, but I confess that I don't really understand them yet.

A pre-processor would also permit 'conditional compilation' in the manner of C, to cater for different host environments perhaps. In such cases you do not want to check the OS type or whatever every time that you run your program. So if you had a statement like '#IF OS == "Unix":, then the relevant code could be included in the main text (or not, as the case may be).

Coming from a C background, I find Static Typing to be useful, but I also have strong scripting experience and I appreciate that enforcement of ST can be a real burden for a programmer, and doesn't always deliver the promised benefits in terms of reduced development/testing effort. So I definitely favour the Optional flavour, but perhaps the pre-processor could issue Warnings rather than reject particular constructs, to permit a 'strong' implementation.

As for particular ST use cases, my inclination would be to cater for the specific rather than the generic. In other words, if min() is defined for an 'int' type then it should *not* accept a 'long'; rather, a new type would need to be delared - 'Natural' in this case perhaps? Intuitively, a similar argument applies to the min() sequence examples: as these (appear to have) different behaviours, they should be different types. If you really need a generic min() function, then write the type checker yourself, or persuade the Python developers to do so.

Finally, the syntax that I prefer is along the lines of C - i.e., declare the type first on the same line as the variable or function, such as 'Integer a=0'. If a text pre-processor is employed as I suggest, then it could easily (?) convert such syntactic sugar to decorators or whatever.

I'm not an expert in such matters, so I hope that these ideas are taken in the spirit of Guido's blog as a whole - i.e. "brainstorming" topics that could be used as stepping-stones to better/stronger proposals.


Cheers ...

Richard Prosser

Richard Prosser

Posts: 3
Nickname: rprosser
Registered: Jul, 2005

Re: Optional Static Typing -- Stop the Flames! Posted: Jul 18, 2005 5:02 AM
Reply to this message Reply
Apologies for commenting on my own post, but I feel that some clarification would be desirable.

If min() - for example - is currently defined to accept an 'int' type rather than a 'long', then it should obviously be modified to accept the latter. This is because these are essentially the same types, but simply of different sizes. Indeed, 'int' and 'long' are articifical to a large extent, included for historical or (perhaps) performance reasons, rather than being natural constructs that people normally use.

On the other hand, a min() function that compares strings is clearly a different beast - i.e. the characteristics differ from numbers in this case - and so should be considered as a separate implementation. Given a declaration of the form 'String s = min('a', 'b'), the compiler/pre-processor would employ the String version of min() rather than the "Numeric" one. This could be implemented as 'if ... elif' statements as described elsewhere, but there is no need for a generic type min() function as such - just a collection of particular types.

Finally, I note that min(a, b) applies to a sub-set of a sequence; it is a special case of min(a, b, c, ...).


Richard

Ernesto Posse

Posts: 1
Nickname: eposse
Registered: Nov, 2005

Call signatures Posted: Nov 4, 2005 11:16 AM
Reply to this message Reply
I was wondering what is the proposed syntax for call signatures?

Guido mentioned some alternatives:

1) x: def(int, int) -> str
2) x: def(a: int, b: int) -> str
3) x: def(:int, :int) -> str
4) x: def(_: int, _: int) -> str
5) x: lambda(int, int) -> str
6) x: (int, int) -> str

I like all except 3 and 4.

I suppose other alternatives along the same line could use "function" or "fun" instead of "def" or "lambda".


What is Guido's preference these days?

Brantley Harris

Posts: 3
Nickname: brantley
Registered: Jan, 2006

Re: Call signatures Posted: Jan 27, 2006 2:46 PM
Reply to this message Reply
I guess I don't get it.

I mean I know Python is trying to get away from C/Java, but come on...

Why not this?
def int foo(int a, list b):
int something = 5

Your changing syntax anyway, might as well.
And since you're messing with some of the core concepts of Python anyway, just drop the other shoe and do:
__strict__ = True
At the module, class, heck function level.

And interfaces could be handled perfectly well with class @decorators:

class Interface:
yadda yadda...

@Interface
class Whatever:
yadda yadda...

Wolfgang Lipp

Posts: 17
Nickname: wolf2005
Registered: Sep, 2005

Re: Optional Static Typing -- Stop the Flames! Posted: Feb 4, 2008 9:52 AM
Reply to this message Reply
i have found that the cobra language deals with the problem of optional static typing and programming by contract in a very nice and unified way: http://cobra-language.com/docs/quality/

the big deal that i see here is that within cobra blocks you can use all of the language without having to introduce arcane constructs:


class Customer

var _contacts as List<of Contact>

get contacts from var

def addContact(contact as Contact)
require
contact not in .contacts
contact.name
contact.customer is nil
ensure
contact.customer == this
.contacts.count = old .contacts.count + 1
body
contact.customer = this
_contacts.add(contact)



while not all of the above can or should be readily implemented in python, maybe it’s possible to do something very similar this way:


@contract
def f( x, y ):
def require():
isinstance( x, int )
isinstance( y, float )
x > y
...



so there is only a single decorator and pre- and postconditions can use full-fledged python. testing could be integrated, too. of course, method definitions would suffer a slight bloat.

Flat View: This topic has 79 replies on 6 pages [ « | 3  4  5  6 ]
Topic: Optional Static Typing -- Stop the Flames! Previous Topic   Next Topic Topic: Setting Up for Emulation

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use