Philippe Fremy | 1 Feb 2005 06:26

type inference for python


	Hi,

I would like to implement something similar to the type inference of 
ocaml for the python language. I have always found it very impressive 
(although I have only used caml light).

I have no experience with the topic, it is just a project that seems 
cool to me :-)

Do you have any hints or where I could build up my knowledge (code, 
books, article, ...) to do that kind of thing.

I imagine that it works in a kind of three way pass:

1. analyse all the constraints of the code
Ex:
def f(a): a.append(1)
def g(a): a=a+1; f(a)
g('coucou')

=> a must support append
=> a must also be an int

2. cross-validate the constraints consistency
=> inconsistent assertions

3. validate the constraints against reality
=> g('coucou') will not work

(Continue reading)

skaller | 1 Feb 2005 07:58
Picon

Re: type inference for python

On Tue, 2005-02-01 at 16:26, Philippe Fremy wrote:
> 	Hi,
> 
> I would like to implement something similar to the type inference of 
> ocaml for the python language. I have always found it very impressive 
> (although I have only used caml light).
> 
> I have no experience with the topic, 

I do. I did considerable work on this. The project
was called Vyper. The key idea was to build an 
interpreter which was used to initialise all the
dictionaries, then analyse them for type information,
and generate code that used that type information.

I got as far as getting the interpreter to work very well,
running most standard pure python plus some emulations of
popular C extensions, and with reasonable performance.
In addition, I made some extensions, many of which
got into later versions of Python .. including proper
lexical scoping, garbage collection (well, my version
used Ocaml for that .. ) and a few other things.

However, the type analysis was never done, and I lost
interest in the project, primarily because it would
never support continuation passing in the style of 
Stackless Python. (And the source is lost now).

A few technical problems also got in the way:

(Continue reading)

Richard Cole | 1 Feb 2005 07:56
Picon
Picon
Favicon

Re: type inference for python

Philippe Fremy wrote:

>
>     Hi,
>
> I would like to implement something similar to the type inference of 
> ocaml for the python language. I have always found it very impressive 
> (although I have only used caml light).
>
> I have no experience with the topic, it is just a project that seems 
> cool to me :-)

Yeah me too :)

Checkout "Demand-Driven Type Inference with Subgoal Pruning: Trading 
Precision for Scalability." by Alexander Spoon. Google can finds the 
paper if you type in the title. This paper gives a nice description of 
why type inference is hard thing to do in a dynamicly typed OO language 
like Python (aka smalltalk) and gives pointers to some work in the area 
including Cecile and Squeak. There was a later paper published by the 
same author in 04 but its not on the web yet :(

I spent a little time considering adding interfaces to Ruby 
[http://kvo.itee.uq.edu.au/twiki/bin/view/Main/RjBlog39] which is pretty 
similar to Python, I guess. The main motivation for me, in adding 
interfaces to a language like Ruby, is to make the software structure 
explicit, and to give coders a place to document contracts that are 
shared by a number of classes. So I don't mind if the type inference 
isn't complete in the sense that every variable gets assigned some sort 
of minimal type.
(Continue reading)

Nicolas Cannasse | 1 Feb 2005 08:25
Picon
Favicon

Re: type inference for python

> Hi,
>
> I would like to implement something similar to the type inference of
> ocaml for the python language. I have always found it very impressive
> (although I have only used caml light).
>
> I have no experience with the topic, it is just a project that seems
> cool to me :-)
>
> Do you have any hints or where I could build up my knowledge (code,
> books, article, ...) to do that kind of thing.
>
> I imagine that it works in a kind of three way pass:
>
> 1. analyse all the constraints of the code
> Ex:
> def f(a): a.append(1)
> def g(a): a=a+1; f(a)
> g('coucou')
>
> => a must support append
> => a must also be an int
>
> 2. cross-validate the constraints consistency
> => inconsistent assertions
>
> 3. validate the constraints against reality
> => g('coucou') will not work

In fact, the ML style type inference can be done in only one pass, at first
(Continue reading)

Ville-Pertti Keinonen | 1 Feb 2005 08:50

Re: timer

On Mon, 2005-01-31 at 22:33 +0300, Anastasia Gornostaeva wrote:
> On Tue, Jan 04, 2005 at 10:11:06AM +0900, SooHyoung Oh wrote:
> 
> >  Module Timer
> >  <http://pllab.kaist.ac.kr/%7Eshoh/ocaml/libs/timer/doc/type_Timer.html>
> 
> This module does not work when is compiled for native-code mode and is linked
> with libc_r under FreeBSD 5.x 

Did you intentionally link against libc_r, or are you running a
pre-stable version of 5.x?

libpthread is the default for FreeBSD 5.x since before becoming the
stable branch and 6-current, and it should work correctly (verified for
-current).

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Frederic Loulergue | 1 Feb 2005 10:18
Picon

[HLPP 2005] Call for papers

Third International Workshop on

HIGH-LEVEL PARALLEL PROGRAMMING AND APPLICATIONS (HLPP 2005) 

July 4-5, 2005, Warwick University, Coventry, United Kingdom 

http://hlpp2005.free.fr

AIMS AND SCOPE

Parallel and distributed systems are now readily available as their
price/performance ratio continues to improve. But parallel and
distributed programming is still dominated by low-level techniques
such as send/receive message passing.

Sequential programming has long benefited from high-level programming
techniques and tools that have made today's immense range of software
economically viable. Two decades of research into high-level parallel
and distributed programming have produced methods and tools that
improve the price/performance ratio of parallel software, and broaden
the range of target applications.

Grid systems offer a tremendous computing power. Nevertheless, this
power is far from being effectively exploited. In addition to
technical problems related to portability and access, grid computing
needs new programming paradigms. Research on high level programming
for meta and grid computing is particularly relevant.

This workshop follows HLPP 2001 & HLPP 2003, and is aimed at: 

(Continue reading)

Christophe Raffalli | 1 Feb 2005 10:27
Picon
Favicon

Re: cyclic types


> 
>       let f x = x :: x
> 
> where the author of that code really intended
> 
>       let f x = x  <at>  x
> 
> With -rectypes, the wrong definition (with ::) is accepted with type
> 
> val f : ('a list as 'a) -> 'a list = <fun>
> 
> and it's only when you try to apply f to a "normal" list that the
> problem arises, with a hard-to-understand error message:
> 
> f [1;2;3];;
>    ^
> This expression has type int but is here used with type 'a list as 'a
> 

Why do you think 'a list as 'a is an <<"impossible" recursive types>> ?
It is a very nice representation of ordinals up to epsilon_0 (curious, 
see the code below)

Why not this restriction: accept a recursive type 't as 'a only if
access to 'a in t needs to expand a definition. I mean, the cyclicity 
check at the end of unification could check that one traverses 
definition. I am not sure how OCaml treat type annotation, this will 
work only if the compiler does its best to use all type annotation.

(Continue reading)

Christophe TROESTLER | 1 Feb 2005 11:07
Picon

[WISH] Unix.fstat and symlinks for win32

Hi,

Just a small note to tell that I think it would be nice to have
support for Unix.*stat on win32.  Not all characteristics may make
sense but [file_kind], [st_size], [st_perm], [st_*time] do.

Also, why not treat *.lnk as symbolic links under win32?  IMHO it
would be more an asset than an hindrance.

Cheers,
ChriS

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Philippe Fremy | 1 Feb 2005 11:54

Re: type inference for python


	Hi,

> I do. I did considerable work on this. The project
> was called Vyper. 

Woa, Vyper looks like a killer project.

But unlike vyper, my goal is not to provide an alternative python 
implementation with type inference and other goodies.

I aim at something like pychecker. That is, a tool that you can run to 
check the types consistency of a python. It is perfectly acceptable for 
it to be limited and to report false warning for twisted constructs.

The goal is just to make python programming more friendly. There are 
many small mistakes that could be caught by such a tool and creep in 
python programs. I keep thinking about the interview of a mailman 
developer, who said that a big problem of python is that eventhough you 
have a program running for a long time, there might be some hidden place 
where you did type mistake that will break your whole program with an 
exception.

Regarding this, python is no better than C program segfaulting.

> (3) Python specs weren't written by someone knowing about
> languages and standardisation. By far the worst problem
> was exceptions.

It is tricky for sure.
(Continue reading)

Marcin 'Qrczak' Kowalczyk | 1 Feb 2005 12:39
X-Face
Picon

Re: [WISH] Unix.fstat and symlinks for win32

Christophe TROESTLER <Christophe.Troestler <at> umh.ac.be> writes:

> Also, why not treat *.lnk as symbolic links under win32?

What do you mean? It's the OS which treats symlinks on Unix, and
Windows doesn't. For example you can't put a "link" to a directory
in the middle of a path. And you *can* edit its contents (which is
meaningless for a Unix symlink). It makes no sense to pretend that
they are the same when they are not.

--

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak <at> knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs


Gmane