Parameterized Types 
Author Message
 Parameterized Types

Hello,

<asbestos-cape="if you respond, be nice">

I came across http://www.*-*-*.com/ ~guido/static-typing/  the other day.
Some things that struck me as odd:

-  parameterized types:

   class foo<TYPE>:  pass
   def func<TYPE>: pass

   Why is this necessary?  I think the point of parameterized types is
   to tell the python compiler that we are only going to use TYPE and
   TYPE.  Is this correct?

Which begs the question:   is it possible to write an analyzing
tracer which traces the types of objects and generates efficient code?
for example -- the gcd() function:

   def gcd(a,b):
      if a>b: return a
      return b

Now, if in my program all I pass to gcd() are int's, the tracer would
recognize this. So I don't need any decl statement; the compiler "knows"
that I will only pass in int's.  Presumably, no optimizations would be
made if my script passes in a lone string or makes a decision between
passing a string or passing an int, etc.

-  Syntax for static typing

   The suggestion

      decl f(x: int) -> int

   or

      decl f(x: int) -> [int]

   looks to me like a mathematical mapping.  Is there any cleaner way to
   specify this?  instead of ->, can't we overload an existing keyword
   ('return')?  Similarly, [int] looks like 'list of integers of size
   1'.  The slides expressed inlining and explicit forms of declarations;
   is it possible to come to a concensus before TMTOWTDI?
   For that matter, is -> or return even needed?

     def f(x: int) int:
       pass

   I use Python for scripting and larger programs (RPGs, etc.).
   What I need in static typing is this:

     + Clean and unambiguous
     + No new keywords ('->' vs. 'return')

     + There's only *one* (right) way to do it.

   I pondered whether it is important to be able to write class/func
   prototypes separately from implementations -- but then that we get
   the following:

     decl func( x: int ) -> int
     def func(x)
       pass

   or

     decl func( x: int ) -> int
     def func(x: int ) -> int:
       pass

   I like the second approach better because it is more consistent
   (imho) between declaration & implementation.  Then again..
   with the first approach, if you take out the decl statement, then
   func becomes fully generic.  In the second implementation, func
   stays statically typed even when we remove the decl statement.

An additional concern is that Python will become
like Pascal in the sense that it is very readable, but it just
takes too long to write out (relative to C/perl/etc.)

</asbestos-cape>

Roey Katz
president,
Federation of Ignorant Scripters.



Fri, 04 Jul 2003 23:40:49 GMT  
 Parameterized Types

Quote:

> I came across http://www.python.org/~guido/static-typing/  the other day.
> Some things that struck me as odd:

> -  parameterized types:

>    class foo<TYPE>:  pass
>    def func<TYPE>: pass

>    Why is this necessary?  I think the point of parameterized types is
>    to tell the Python compiler that we are only going to use TYPE and
>    TYPE.  Is this correct?

Yes.

However, you may want to use foo or func with a number of different
types. Each usage effectively gives you a different definition of foo
or func; for each specific usage, you can still tell what type TYPE
refers to.

Quote:
> Which begs the question:   is it possible to write an analyzing
> tracer which traces the types of objects and generates efficient code?
> for example -- the gcd() function:

>    def gcd(a,b):
>       if a>b: return a
>       return b

> Now, if in my program all I pass to gcd() are int's, the tracer would
> recognize this.

One strategy is to automatically specialize gcd for ints, and use this
specialization every time gcd is called with ints; it would use a
different specialization if somebody passes different arguments.

Quote:
>    The slides expressed inlining and explicit forms of declarations;
>    is it possible to come to a concensus before TMTOWTDI?

Static typing is not appearing tomorrow; there's plenty of time to
settle a syntax (although probably not by means of consensus ...).

Regards,
Martin



Sat, 05 Jul 2003 07:29:36 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Oberon[-2] and Parameterized Types

2. Parameterized types in Java (Was: Will Java kill Lisp?)

3. Szyperski & parameterized types in Oberon?

4. parameterized class types as parameters

5. Parameterized data type example.

6. parameterized derived types

7. Fortran 88 Parameterized Data Types

8. Database Connection, Parameterized Statement

9. Composition Editor Q/parameterized help file name Q

10. Using Blocks for Parameterized Adapters

11. Eiffel compilers and generics (parameterized classes)

12. parameterized partial evaluation

 

 
Powered by phpBB® Forum Software