From sales@lookelu.com Sun Jul 2 04:56:38 2000 From: sales@lookelu.com (The Western Web) Date: Sun, 2 Jul 2000 03:56:38 Subject: [Types-sig] The Western Web (Advertisement) Message-ID: <20000702105546.310F41CF44@dinsdale.python.org> The Western Web has just finished our new classified ad section. We have added new sections in the classifieds, hay/feed/shavings, livestock, camelids, cattle, deer and elk, poultry, rabbits, sheep, livestock equipment, swine, donkeys, dogs, mules and model horses. Ad Photos, Video and Audio for FREE! http://www.thewesternweb.com The new classified section is automated now and your ads will be posted immediatly. You can also add Multi-Media files (photos, sound and video) on line. This is a free service to you so use it at your will. http://www.westernwebclassified.com We have also finished the Western Web Search Engine, which is solely optimized for the western way of life. Please stop by the search engine add your site. http://www.searchthewesternweb.com Our message board is also now up and running so please use it . http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi Thank you, http://www.thewesternweb.com If you received this message in error please reply to this emal address with the word "remove " in the subject line. From danwang@CS.Princeton.EDU Tue Jul 11 03:46:36 2000 From: danwang@CS.Princeton.EDU (Daniel Wang) Date: 10 Jul 2000 22:46:36 -0400 Subject: [Types-sig] Core Python.... (less is more) Message-ID: I'm a bit new to the Python community, but being a graduate student stuck in academia. I was quite amazed to see a community of its own free will wanting to add static types into their favorite previous untyped language. (No days of lecturing and subversive homework assignments to brain wash you guys into thinking static types are useful....) I'm curious as to what if any interaction there has been between with the academic community. I've spent quiet a great deal of time studying and implementing relatively advanced type systems and am just dying to see one deployed for a "real language" that isn't Java. Those familiar with Generic Java will know that a lot of work was put in by some academics to get a design palatable enough for Sun to consider adopting. Even after all that got put into it, GJ is still "stuck in the labs". It would be nice to try to replicate a similar kind of interaction with the Python, with a slightly different outcome. (i.e. where the research gets set free and used by real people.) However, full Python seems to present some non-trivial challenges for existing type systems and is very difficult to discuss. I'm curious if it is possible to come up with a small subset of Python that has the following properties... 1. Is the core part of Python i.e. most if not all other constructs can be explained in terms of core features. 2. Small enough to admit a rigorous formal specification 3. Large enough to program interesting Python programs 4. Small enough to easily hack up toy type checkers and type tools 5. Large enough so as not to hide the underlying typing difficulties A nice small core language is quiet easy to a pointed headed type theorist and say "build me a type system for this". Points 2 and 3 are important for the type theorists so there's some chance of writing all these things up and publish it and maybe get tenure. :) (shoving them a Python manual or even the existing documents at an academic requires the academic spend a lot of time trying to figure out what's going on... Points 4.are 5. important of hacking prototyping and general discussion on the mailing list. So is anyone interested in formulating "core Python"? Once you have "core Python" one could take on a a slightly more ambitious project. One could extend core Python with enough features but still simple enough to admit a relatively simple static typing system which would be similar to ML or a safe C with polymorphism. Let's call this language "systems Python". The next step is to write a translator for "systems Python" into C, and finally perform the Squeak trick of writing a Python runtime system in a statically typed variant of Python itself. From this "systems Python", it then might be easier to slowly added more an more typing features until the majority if not a very large subset of Python is finally statically typeable, and efficiently compilable into C. Reading the existing proposals they all have the feeling of "we're not sure we've got it right here..." I think the solution to this problem is to start small and slowly test the design of the static type system. The task of bootstrapping Python would be a good way to test the design of the type system, and also more importantly investigate how the static type system aids compilation. Even if "systems Python" is a small of Python if it is efficiently compilable into C. People can at least consider writing extension in this subset rather than giving up and programming in C when Python gets a bit too slow. So anyone interested in helping figure out what "core Python" and "systems Python" actually look like... or has someone done this already? P.S. Turth in advertising disclaimer: This my subversive attempt to see some of all the research, I've been seeing and doing myself actually get used... and to push my own hidden agenda so I can convice the world that "types are cool". From paul@prescod.net Tue Jul 11 16:21:45 2000 From: paul@prescod.net (Paul Prescod) Date: Tue, 11 Jul 2000 10:21:45 -0500 Subject: [Types-sig] Core Python.... (less is more) References: Message-ID: <396B3B89.57F431DE@prescod.net> Daniel Wang wrote: > > I'm a bit new to the Python community, but being a graduate student stuck in > academia. I was quite amazed to see a community of its own free will wanting > to add static types into their favorite previous untyped language. (No days > of lecturing and subversive homework assignments to brain wash you guys into > thinking static types are useful....) Yes, but there is strong agreement in the Python community that static types need to be entirely optional. > I'm curious as to what if any interaction there has been between with the > academic community. I've spent quiet a great deal of time studying and > implementing relatively advanced type systems and am just dying to see one > deployed for a "real language" that isn't Java. The interest in static types comes in fits and starts (typically after conferences). We did get some academic interest just before the last wave died out. So no, we haven't really had much serious academic input yet. > Those familiar with Generic Java will know that a lot of work was put in by > some academics to get a design palatable enough for Sun to consider > adopting. Even after all that got put into it, GJ is still "stuck in the > labs". It would be nice to try to replicate a similar kind of interaction > with the Python, with a slightly different outcome. (i.e. where the research > gets set free and used by real people.) In my opinion, Generic Java was a lot easier than "static python". I think that you are familiar with the problems. > However, full Python seems to present some non-trivial challenges for > existing type systems and is very difficult to discuss. I'm curious if it > is possible to come up with a small subset of Python that has the following > properties... > > 1. Is the core part of Python i.e. most if not all other constructs can be > explained in terms of core features. > 2. Small enough to admit a rigorous formal specification > 3. Large enough to program interesting Python programs > 4. Small enough to easily hack up toy type checkers and type tools > 5. Large enough so as not to hide the underlying typing difficulties > > A nice small core language is quiet easy to a pointed headed type theorist > and say "build me a type system for this". Points 2 and 3 are important for > the type theorists so there's some chance of writing all these things up > and publish it and maybe get tenure. :) (shoving them a Python manual or > even the existing documents at an academic requires the academic spend a lot > of time trying to figure out what's going on... Your last point makes your approach unique. Traditionally we have talked about Python subsets specifically chosen to be *easier* to optimize. Later in your email you seem to be talking about the same thing. > Once you have "core Python" one could take on a a slightly more ambitious > project. One could extend core Python with enough features but still simple > enough to admit a relatively simple static typing system which would be > similar to ML or a safe C with polymorphism. Let's call this language > "systems Python". The next step is to write a translator for "systems Python" > into C, and finally perform the Squeak trick of writing a Python runtime > system in a statically typed variant of Python itself. Let's be careful here. Any language that is rougly like ML or "safe C" is not nearly as dynamic as Python. You have to decide whether you are interested in a very dynamic, but small Python subset or a static Python subset. > >From this "systems Python", it then might be easier to slowly added more an > more typing features until the majority if not a very large subset of Python > is finally statically typeable, and efficiently compilable into C. If that's possible, it sure isn't easy. > Reading the existing proposals they all have the feeling of "we're not sure > we've got it right here..." Okay, but consider the difference between the academic's view of "got it right" and the Python programmers. The acadmic's wants a clean mathematical abstraction. The Python programmer wants something that "feels like Python." And we all have different ideas of what feels like Python.... I think that that is the real problem. We don't all agree on what we want. There are three major subdivisions, those who want better error checking (ERR), those who want better performance (OPT) and those who want better documentation(DOC). Now we can divide those three into six by differentiating between those who want better ERR and DOC at module *boundaries* and those who want that pervasively. And for OPT, there are those who want most of their code sped up and those who wnat only "inner loops" sped up. You can already see a conflict. People who believe strongly in DOC are going to want the maximum number of type declarations and those who are interested in OPT just want to "prime" a type inferencer with the minimal amount of necessary information. > I think the solution to this problem is to start > small and slowly test the design of the static type system. The task of > bootstrapping Python would be a good way to test the design of the type > system, and also more importantly investigate how the static type system > aids compilation. I agree. But I don't think that those of us outside of academia have the extra bandwidth to take on this project. > Even if "systems Python" is a small of Python if it is efficiently > compilable into C. People can at least consider writing extension in this > subset rather than giving up and programming in C when Python gets a bit too > slow. Agreed. We have historically called this "systems Python" "swallow" but nobody has ever defined or implemented it. It sounds like a great project for a graduate student and a great contribution to the Python community. I can't get Dejanews to give me the first messages on swallow, but here are some later ones: http://www.deja.com/dnquery.xp?ST=MS&QRY=Python+swallow+type&svcclass=dnold&DBS=1 -- Paul Prescod - Not encumbered by corporate consensus "Computer Associates is expected to come in with better than expected earnings." Bob O'Brien, quoted in - http://www.fool.com/news/2000/foth000316.htm From neelk@cswcasa.com Tue Jul 11 17:42:39 2000 From: neelk@cswcasa.com (neelk@cswcasa.com) Date: Tue, 11 Jul 2000 12:42:39 -0400 Subject: [Types-sig] Core Python.... (less is more) Message-ID: Daniel Wang [mailto:danwang@CS.Princeton.EDU] wrote: > > I'm a bit new to the Python community, but being a graduate > student stuck in academia. I was quite amazed to see a community > of its own free will wanting to add static types into their favorite > previous untyped language. Didn't some Smalltalk people invent Strongtalk? And Common Lisp has had optional type declarations for ages, a feature which Dylan emphasized a lot more in its design. Nobody seems to have seized upon Hindley-Milner type inference, but I think that without something like Haskell's overloading or ML's functors, it's not possible to write sufficently reusable typed software -- and both of these are AFAIK very recent innovations. But I digress, and am probably retreading ground very familiar to you.... > However, full Python seems to present some non-trivial challenges for > existing type systems and is very difficult to discuss. I'm > curious if it is possible to come up with a small subset of Python > that has the following properties... > > 1. Is the core part of Python i.e. most if not all other > constructs can be explained in terms of core features. > 2. Small enough to admit a rigorous formal specification > 3. Large enough to program interesting Python programs > 4. Small enough to easily hack up toy type checkers and type tools > 5. Large enough so as not to hide the underlying typing difficulties What you want to look at is Oaklisp. It's basically Scheme with Python's OO system fully integrated into the language. (It actually predates Python, but my meaning should be clear.) I this that this will let you reuse much of Scheme's denotational semantics when defining your static Python subset. If you want, I'd be delighted to help, though everything I know about language theory is self-taught and likely weirdly incomplete. This also implies making some changes to core Python's semantics, such as adding lexical scoping and eliminating the type/class distinction, but both of these are widely (but not universally) regarded as good additions. > P.S. Turth in advertising disclaimer: This my subversive > attempt to see some of all the research, I've been seeing and > doing myself actually get used... and to push my own hidden agenda > so I can convice the world that "types are cool". Throw in ML's functors and I'm sold. They are so clearly the Right Thing it's not funny. :) -- Neel Krishnaswami neelk@cswcasa.com From danwang@CS.Princeton.EDU Tue Jul 11 20:04:28 2000 From: danwang@CS.Princeton.EDU (Daniel Wang) Date: 11 Jul 2000 15:04:28 -0400 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: Paul Prescod's message of "Tue, 11 Jul 2000 10:21:45 -0500" References: <396B3B89.57F431DE@prescod.net> Message-ID: Hmmm given the responses, I don't think I made myself all that clear... Baiscally it boils down to the fact that adding any sort of typing discipline for what ever reason to "full Python" is going to be a very hard thing to do. So, I'm basically asking what's a small and interesting chunk of the language to tackle first. From this small chunck one can very easily automatically define the appropiate runtime coercions so that when you cross over into the rest of Python there is an extra runtime check inserted at the right places. Then the big picture is to slowly grow this chunck of typeable Python into more and more of the full language. Ideally the subset of typeable Python is really a subset of full Python, with perhaps an extra interface description file to prime the type inference system and to provide module level interface documentation. For example, I can easily see doing the procedural subset of Python without classes in a relatively easy way. Also if you have a well defined static core it's easy to have this core interoperate with the existing very dynamic features of Python. The issue number 5. "Large enough not to hide any of the typing difficulties." Is really an issue about how to type the native dictionary Python types. Doing so will require some relatively novel typing techniques, but I think they can be handled. I'd like to let people use normal Python idioms and still have dictionaries "just work". It be nice to have a dictionary type that could state an invariant of the sort If you pass this dictionary a symbol with the value "x" it will return a value of the type int or string, pass it the value "y" and you will get the value 1. Which, would look something like { S("x") -> (int | string), S("y") -> S(1)} You should read S(v) as the singleton type which is a type that contains exactly one element whose value is "v". The question to ask is whether this sort of very fine grain type information will let you assign types to a very large subset of Python, and how much of this information can be inferred automatically. Oh well... these are just semi-random thoughts... but I think it be useful to pick out a subset... From neelk@cswcasa.com Wed Jul 12 17:40:18 2000 From: neelk@cswcasa.com (neelk@cswcasa.com) Date: Wed, 12 Jul 2000 12:40:18 -0400 Subject: [Types-sig] Core Python.... (less is more) Message-ID: Daniel Wang [mailto:danwang@CS.Princeton.EDU] wrote: > > Hmmm given the responses, I don't think I made myself all > that clear... > > Baiscally it boils down to the fact that adding any sort of typing > discipline for what ever reason to "full Python" is going to > be a very hard thing to do. So, I'm basically asking what's a > small and interesting chunk of the language to tackle first. From > this small chunck one can very easily automatically define the > appropiate runtime coercions so that when you cross over into > the rest of Python there is an extra runtime check inserted at the > right places. [...] > > For example, I can easily see doing the procedural subset of > Python without classes in a relatively easy way. I think that one of the issues the Types-Sig is supposed to be dealing with is the type/class unification, which I think could make dealing with a pure procedural subset hard. I don't know how familiar you are with the C Python implementation, so I'll explain. If you implement a new Python type in C, then the type of the new instances isn't an instance of the Class type. So you can't define classes that inherit from it, requires some special-casing if you write any reflective code, and in general is a rather odd wart on an otherwise high-level language. The JPython Java implementation has gone ahead and made the basic types like Integer part of the class hierarchy, as a matter of fact. But if these *do* become real classes, then it won't be possible to ignore the OO nature of Python in the core language.[*] I think you could get away with defining a subset that only permits single-inheritance, doesn't allow the use of special methods like __getattr__ and __setattr__, doesn't allow addition or removal of methods after class initialization, doesn't allow classes or instances to change their base classes, and only permits class declarations at toplevel. This is what an awful lot of Python code looks like already, so you wouldn't be restricting things too much in practice. You'd also have to define another module type, that doesn't allow the addition or removal of bindings after module initialization, doesn't allow the use of eval and its kin within the module, and do what's needful to allow you to figure out what bindings point to at compile time. Right now, it's not possible to optimize the for loop below so that it doesn't allocate a huge list of integers. [within a module foo] def somefunc(n): for i in range(n): print i because someone in another module can write import foo; foo.range = bar Again, very little code actually *does* this, but it's something you can't prove without whole-program analysis. So it seems reasonable to make this part of the subset language. This is a big message, so the question is probably a little bit late. :) Still: am I talking about the issues you are thinking of, or have I missed the point again? > It be nice to have a dictionary type that could state an > invariant of the sort > > If you pass this dictionary a symbol with the value "x" it > will return a value of the type int or string, pass it the > value "y" and you will get the value 1. > > Which, would look something like > > { S("x") -> (int | string), > S("y") -> S(1)} Dylan has a facility like this, and I must say it's extremely useful, especially because you can write methods that dispatch off of singleton types. For example, you could write factorial like this: define method fact(n :: singleton(0) ) => (answer :: ) 1 end method fact; define method fact(n :: ) => (answer :: ) n * fact(n - 1) end method fact; I'd love to see something like this show up in Python. [*] I'm not arguing that all types need to be classes, mind -- I really like the idea of singleton and union types -- but I do think all the instantiable types should be. -- Neel Krishnaswami neelk@cswcasa.com From skaller@maxtal.com.au Wed Jul 12 18:44:58 2000 From: skaller@maxtal.com.au (John Max Skaller) Date: Thu, 13 Jul 2000 03:44:58 +1000 Subject: [Types-sig] Core Python.... (less is more) References: <396B3B89.57F431DE@prescod.net> Message-ID: <396CAE9A.89B0D65@maxtal.com.au> Daniel Wang wrote: > > Hmmm given the responses, I don't think I made myself all that clear... > > Baiscally it boils down to the fact that adding any sort of typing > discipline for what ever reason to "full Python" is going to be a very hard > thing to do. So, I'm basically asking what's a small and interesting chunk > of the language to tackle first. Like I said, you have to throw out most of the __xxx__ class members. You might care to examine Vyper http://Vyper.sourceforge.net which is a high power version of python which aimed at providing static typing. It doesn't (yet). But to support reasonable interpretation, classes can't have __add__ methods (etc). They can have __getattr__ methods. I use algebraic typing, not dynamic typing (the interpreter is written in Ocaml, an ML dialect). > For example, I can easily see doing the procedural subset of Python without > classes in a relatively easy way. Actually, Vyper provides several major extensions to Python: they're not in the same league, really: it supports full lexical scoping including closures, garbage collection, and algebraic pattern matching. Static typing information is already present, you can add typing information to function arguments. However, this information is not currently used statically. As I have also said, the principal problem in statically typing python is NOT its dynamism per se, but the lack of any notion of an error. That is, the following code: x = 1/0 is perfectly correct python. There is no error here. The code is required to raise an exception. This kind of requirement completely defeats static typing. But then, the language 'specification' really just says what the CPython implementation does. -- John (Max) Skaller, mailto:skaller@maxtal.com.au 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net From paul@prescod.net Wed Jul 12 23:44:59 2000 From: paul@prescod.net (Paul Prescod) Date: Wed, 12 Jul 2000 17:44:59 -0500 Subject: [Types-sig] Core Python.... (less is more) References: Message-ID: <396CF4EB.2728D24E@prescod.net> neelk@cswcasa.com wrote: > > ... > > But if these *do* become real classes, then it won't be > possible to ignore the OO nature of Python in the core > language.[*] Let me play the devil's advocate fromt the point of view of tools I could use myself. Should Daniel really define "core Python" or "a small, optimizable Python subset." The former is probably more interesting to his thesis advisor as a really challenging problem, but the latter would allow us to write Python "extensions" that could be compiled to C and run really efficiently...which is a very interesting part of the problem for those of us interested in Python for its own sake. I think that requiring that the subset be rich enough that everything else can be defined (not just implemented, but defined) in terms of it sets a very high bar. Python wasn't designed from first principles so discovering them after the fact will be tricky. Let me suggest what I would use as my "benchmark" if I were going to take on a project like this in my university days. Make a Python subset/compiler which uses type declarations. Demonstrate that modules that previously could only be written in C can now be written in Python because the speed difference has narrowed. > I think you could get away with defining a subset that only permits > single-inheritance, doesn't allow the use of special methods like > __getattr__ and __setattr__, doesn't allow addition or removal of > methods after class initialization, doesn't allow classes or instances > to change their base classes, and only permits class declarations > at toplevel. He could make a subset that does not do inheritance at all without losing any functionality from C. If it makes his life easier, he could even pretend that classes don't exist in the same way that C extensions do. I wouldn't mind coding my inner loops in a non-OO subset. In fact, there would be rejoicing in the streets if we could avoid C's headaches for even 30% of what we currently do in C for speed reasons. Anyhow, if we went back to the "Py core" approach, I'm not clear how you would decide what to discard. You can't discard anything with first-class syntax because Python doesn't have an extensible syntax. The Lisp guys get away with it through macros and function calls. We don't have that option. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From danwang@CS.Princeton.EDU Thu Jul 13 00:06:51 2000 From: danwang@CS.Princeton.EDU (Daniel Wang) Date: 12 Jul 2000 19:06:51 -0400 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: Paul Prescod's message of "Wed, 12 Jul 2000 17:44:59 -0500" References: <396CF4EB.2728D24E@prescod.net> Message-ID: Paul Prescod writes: {stuff deleted} > Should Daniel really define "core Python" or "a small, optimizable > Python subset." The former is probably more interesting to his thesis > advisor as a really challenging problem, but the latter would allow us Just and FYI, I'm deep into the thesis pipeline, and this little crazy idea is something I plan to do after that nagging little thesis on garbage collection gets finished... I think the small optimizable Python subset is someting I could bite off without too much problem... In anycase I got the impression that the entire class system was built on top of dictionaries, or did I misunderstand how things actually work? From mwh21@cam.ac.uk Thu Jul 13 07:27:54 2000 From: mwh21@cam.ac.uk (Michael Hudson) Date: 13 Jul 2000 07:27:54 +0100 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: Daniel Wang's message of "12 Jul 2000 19:06:51 -0400" References: <396CF4EB.2728D24E@prescod.net> Message-ID: Daniel Wang writes: [schnipp] > In anycase I got the impression that the entire class system was built on top > of dictionaries, or did I misunderstand how things actually work? Well yes, but that's more-or-less an implementation detail (I's have said, anyway). Cheers, M. -- That's why the smartest companies use Common Lisp, but lie about it so all their competitors think Lisp is slow and C++ is fast. (This rumor has, however, gotten a little out of hand. :) -- Erik Naggum, comp.lang.lisp From paul@prescod.net Thu Jul 13 07:10:34 2000 From: paul@prescod.net (Paul Prescod) Date: Thu, 13 Jul 2000 01:10:34 -0500 Subject: [Types-sig] Core Python.... (less is more) References: <396CF4EB.2728D24E@prescod.net> Message-ID: <396D5D5A.9E1D8C69@prescod.net> Daniel Wang wrote: > > ... > > In anycase I got the impression that the entire class system was built on top > of dictionaries, or did I misunderstand how things actually work? Yes, but the language-level interface to dictionaries and classes are pretty different. -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/~perlis-alan/quotes.html From neelk@cswcasa.com Thu Jul 13 17:38:20 2000 From: neelk@cswcasa.com (neelk@cswcasa.com) Date: Thu, 13 Jul 2000 12:38:20 -0400 Subject: [Types-sig] Core Python.... (less is more) Message-ID: Paul Prescod [mailto:paul@prescod.net] wrote: > neelk@cswcasa.com wrote: > > > > ... > > > > But if these *do* become real classes, then it won't be > > possible to ignore the OO nature of Python in the core > > language.[*] > > Let me suggest what I would use as my "benchmark" if I were going to > take on a project like this in my university days. Make a Python > subset/compiler which uses type declarations. Demonstrate that modules > that previously could only be written in C can now be written > in Python because the speed difference has narrowed. If this is what you want, typing is only as a second-order effect; creating a more immutable module type and adding a method cache for method invocations is more effective and a lot easier. These two can probably combine to give a factor of 2-4 speedup in typical code, judging by how much faster Squeak is than Python. Let's start with an example: [within a module Foo] def bar(n): for i in range(n): side_effect() Now, a nice, big optimization would be to replace the 'range(n)' in the call to bar() with a for loop in C. As it stands, you need to a) create a list of Python integer objects of size n b) starting with zero, 1. create a Python integer object 2. Call the __getitem__ method on the sequence with the argument 3. Trap for an IndexError to find out if the iteration is complete. 4. Execute the loop body Both a), and b.1-3 all very expensive operations. But you can't optimize it away, because in another module, someone can do something like this: [in module Baz] import Foo Foo.range = some_crazy_function If you can disallow this, then you can start optimizing things a lot more aggressively. No need to create the list, no need to make the __getitem__ call, no need to allocate twice as many integer objects as you really need. *Big* speedup. And on top of this, you can now index module-level name lookups just like you can optimize name lookups inside function calls, which is yet another free 15% speedup. Now, the method cache. When you do a method invocation today, Python looks in the class object for the method, and if it finds a function, it wraps it in a method object. It then discards the method object when the call is done, and repeats whenever there's another method call. Caching the result will roughly halve the time it takes to do a method dispatch. -- Neel Krishnaswami neelk@cswcasa.com From paul@prescod.net Sun Jul 16 16:33:21 2000 From: paul@prescod.net (Paul Prescod) Date: Sun, 16 Jul 2000 10:33:21 -0500 Subject: [Types-sig] Core Python.... (less is more) References: Message-ID: <3971D5C1.529F788E@prescod.net> neelk@cswcasa.com wrote: > > ... > > If this is what you want, typing is only as a second-order effect; > creating a more immutable module type and adding a method cache for > method invocations is more effective and a lot easier. These two can > probably combine to give a factor of 2-4 speedup in typical code, > judging by how much faster Squeak is than Python. Okay, but you are talking about improving the interpreter. I'm talking about making a compiler or improving the existing compiler (Py2C). I would expect that a compiler using built-in types could achieve much more than 2-4 times speed improvement. -- Paul Prescod - Not encumbered by corporate consensus It's difficult to extract sense from strings, but they're the only communication coin we can count on. - http://www.cs.yale.edu/~perlis-alan/quotes.html From faassen@vet.uu.nl Thu Jul 20 19:31:32 2000 From: faassen@vet.uu.nl (Martijn Faassen) Date: Thu, 20 Jul 2000 20:31:32 +0200 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: References: <396B3B89.57F431DE@prescod.net> Message-ID: <20000720203132.A25827@vet.uu.nl> Hi all, Jumping in. Daniel Wang wrote: > > Hmmm given the responses, I don't think I made myself all that clear... > > Baiscally it boils down to the fact that adding any sort of typing > discipline for what ever reason to "full Python" is going to be a very hard > thing to do. So, I'm basically asking what's a small and interesting chunk > of the language to tackle first. Right -- that's basically the Swallow proposal (though it was originally mostly concerned with optimisation (OPT), not so much with ERR or DOC). I thought Paul Prescod did point this out to you. A fully type-annotated strict subset of Python. I should know about it, as I came up with the term 'Swallow'. :) > From this small chunck one can very easily > automatically define the appropiate runtime coercions so that when you cross > over into the rest of Python there is an extra runtime check inserted at the > right places. There were some issues with this raised by Guido among others in the previous wave of big discussion on this list. Some of the runtime checks might become very expensive (for instance if a list is passed into the Swallow part, and Swallow wants a list of strings, all the elements would need to be checked). > Then the big picture is to slowly grow this chunck of typeable Python into > more and more of the full language. Ideally the subset of typeable Python is > really a subset of full Python, with perhaps an extra interface description > file to prime the type inference system and to provide module level > interface documentation. Right, Swallow almost exactly. Um, sure, good idea! :) Regards, Martijn From danwang@CS.Princeton.EDU Thu Jul 20 19:40:55 2000 From: danwang@CS.Princeton.EDU (Daniel Wang) Date: 20 Jul 2000 14:40:55 -0400 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: Martijn Faassen's message of "Thu, 20 Jul 2000 20:31:32 +0200" References: <396B3B89.57F431DE@prescod.net> <20000720203132.A25827@vet.uu.nl> Message-ID: Martijn Faassen writes: > > There were some issues with this raised by Guido among others in the > previous wave of big discussion on this list. Some of the runtime checks > might become very expensive (for instance if a list is passed into the > Swallow part, and Swallow wants a list of strings, all the elements would > need to be checked). I there are schemes to avoid this particular problem. In this case you move the checks into the places when you deconstruct the list. i.e. you check that each element is a string when you access an element and just check that the thing you pass into the Swallow part is actually a list. This delays the error reporting which can be a good or bad thing.... Alternatively, one can add a flag to distinguish between homogeneous vs. heterogenous lists, or just make sure lists keep track of the set of types of all their elements. In anycase, there is some required cleverness for sure but I don't think this particular problem is a big one. This casting problem is very simlar to some boxing/unboxing issues found in the guts of several type based compilers I know about, and I think almost all the tricks used in that framework can be adapted. So where's the most recent info on Swallow... ? From sales@lookelu.com Thu Jul 20 23:34:11 2000 From: sales@lookelu.com (The Western Web) Date: Thu, 20 Jul 2000 22:34:11 Subject: [Types-sig] The Western Web Newsletter Message-ID: <20000721053233.A72CA1CDA3@dinsdale.python.org> THE WESTERN WEB WEEKLY NEWS LETTER Serving Over 75,000 Recipients The Western Web continues to grow and your patronage is greatly appreciated. The Western Web now has over 1500 new classified ads. You can now add pictures,video and audio for free with your free ad. It is easy to do and with our automated system these ads are posted immediately. To place an ad go to: http://www.westernwebclassified.com/cgi-bin/classifieds/classifieds.cgi Be sure to check out our search engine. We have over 1700 links to western lifestyles with categories for Art, Auto Racing, Dogs, Fishing, Gifts, Horses, Hunting,Livestock, Model Horses, Rodeo, Tractors, Trailers, Truck, Western Furniture,Western Lifestyles and Western Wear. All of the listed categories also have many subcategories to meet all your personal needs. You can go to the site and add a link to your site free. It is easy and your site will be posted in a timely manner. For all of you who have posted your Internet Sites go to our search engine to make sure your site has been posted and the links are correct. Take care when typing your web address. We test all sites before posting, if the link is not good, they are not posted. If your site has not been posted please resubmit. You can access the Search Engine from The Western Web home page or http://www.searchthewesternweb.com To add your link, select a category and necessary subcategories. Click on Add-a-listing and post you link. It is easy and free. Now, take a look at our upgraded message board: http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi Many new groupings have been added. You can check prices on Logo or Banner advertising at: http://www.thewesternweb.com/Advertising/Advertising.htm For you convenience, there are links to these sites and more, from The Western Web Home Page. Thank You, http://www.thewesternweb.com If you receive this message in error or want us to remove you from our newsletter of mailing list, please reply to this email address with the word "Remove" in the subject line. From faassen@vet.uu.nl Thu Jul 27 20:21:09 2000 From: faassen@vet.uu.nl (Martijn Faassen) Date: Thu, 27 Jul 2000 21:21:09 +0200 Subject: [Types-sig] Core Python.... (less is more) In-Reply-To: References: <396B3B89.57F431DE@prescod.net> <20000720203132.A25827@vet.uu.nl> Message-ID: <20000727212109.A4373@vet.uu.nl> Daniel Wang wrote: [snip some suggested solutions to problems I raised] > So where's the most recent info on Swallow... ? There isn't anything *concrete*, what'd you expect? :) You'll have to make up the recent info yourself. I'll make that stronger; this _is_ the recent info. ;) Regards, Martijn From sales@lookelu.com Mon Jul 31 19:24:04 2000 From: sales@lookelu.com (The Western Web) Date: Mon, 31 Jul 2000 18:24:04 Subject: [Types-sig] The Western Web Newsletter Message-ID: <20000801012201.BE12B1CEDE@dinsdale.python.org> THE WESTERN WEB WEEKLY NEWS LETTER Week of July 24, 2000 Serving Over 75000 Recipients With your assistance "The Western Web" continues to improve and your input is helpful.Our goal is to make "The Western Web" THE one place stop for all your Horse, Livestock and Western Life Style needs. If You have added your site to our search engine, please make sure everything is correct. If you haven't noticed we have upgraded the look and capabilities of The Western Web search engine. You can now type in your search word and find all related site links. Don't forget to add your Web Site to our search engine too. http://www.searchthewesternweb.com This week you might take a look at our "Events Calendar" in our Classified Ad section. You can post your upcoming events in subcategories such as: Events, Shows, Cuttings, Team Roping, Gymkhana, Clinics, Trail, Auctions, Rodeos, Reining, Barrel Racing, Team Penning and Performance & Halter. We also have a subcategory for "Other" to place any event not categorized. These ads are free and you can add pictures, video and audio. A note to our subscribers who have posted ads, with you User Name and Password you can update your events. http://www.westernwebclassified.com/cgi-bin/classifieds/classifieds.cgi At last, an online service available with the horse lover in mind, The Sale Barn.Com (www.thesalebarn.com). The Sale Barn offers an online auction specifically for horse-related items, whether you are buying or selling. The Sale Barn auctions off 100s of items daily with many items in the Hot Items Listing starting at $1.00! Usually there are from 150 to 200 items starting at only $1.00. From saddles, bridles, bits, spurs and unique gift items. Register now to qualify for our weekly drawing. The current prize is a 34 x 36 Wool Blend Show Blanket with wear leathers and silver conchos valued at $99.95! This item is featured on our Home Page at www.thesalebarn.com. Registration is free on our secure site with no credit card necessary. The Sale Barn is amongst the top 10 visited horse sites on the Internet with over 10,000 hits a day. A perfect opportunity to turn unneeded horse related items in to cash. The Sale Barn is the ebay of the horse world with categories directed to specific items such as saddles, headstalls, bits, spurs, ropes, gift items, horse trailers, etc. http://www.thesalebarn.com We appreciate you patronizing our sponsors. You to can have your web site on our front page along with Banks Power, Roo-hyde Saddlery, GMC, Bootbarn.com,Truckloads.net, Zig Zigler, Comforce, The Gaited Horse, Cowboy Tack, Painted Acres Ranch,The ShawnOshine,Tom Balding Bits & Spurs, Centenary of Federation and Stoxrus.com. You can find our reasonable rates at: http://www.thewesternweb.com/Advertising/Advertising.htm While at The Western Web site take a look at our message board: http://www.westernmessageboard.com/cgi-bin/Ultimate.cgi We can Design & Host your web site. Check out our low domain name registration prices at: http://www.thewesternweb.com/Web_Design/Domain_Name_Registration.htm For you convenience, there are links to these sites and more, from The Western Web Home Page. http://www.thewesternweb.com/ If you receive this message in error or want us to remove you from our newsletter e-mail list, please reply to this email address with the word "Remove" in the subject line. Thank You, http://www.thewesternweb.com