Re: Python discussion, anybody?

["Todd Rudick" <trudick@example.com>]

<< Lotta paths there. >>
  The code example you gave had only one execution path and type-casting 
(which, of course, tells you what the type of your variable is, and what you 
can do with it).

<< In practice, I think you are going to have the
same problem that optimizing C compilers have with aliasing through
pointers. >>
  Yes, which means--(drumroll please) No invisible aliasing through 
pointers! Seriously, this is a huge problem in C, thankfully not reproduced 
in the untyped oop languages I know of. That's not to say you can't have two 
variables pointing to the same object, but you can at least tell that they 
both COULD be pointing to the same object.

<< As Peter Gabriel said, "I'm a LISP engine, baby, and I want your
sexp!" It's a well-defined interface, no? >>
Huh?

<< In the theoretical extreme, you only have one type: the
union of all types ever used in your program (if the compiler proceeds
to generate the necessary interfaces) >>
  Only if your particular program has a path of program execution and 
assignment from every variable to every other variable. Maybe another 
example would help:

function trimLastChar(o) {
  return o.subString(0,o.lastIndex()-1);
}

  The information I'm trying to get to is that any object passed to 
trimLastChar must implement a method called subString and another called 
lastIndex. Somehow you have the idea that this generated interface for 
objects passed into this function would be the same as every other function. 
How so?
  The real complexity that I've glossed over (and why I said it's 
half-baked) is how to track the possible return type of something like this. 
Basicly, because the return type depends on the type returned by one of the 
methods it calls on an object coming in on the arg list, it won't 
necessarily have a single return type. So you might have to specialize this 
function for each call. Or you could just leave it be and not impose (i.e., 
propogate) any required interface on the return value of functions like 
this.
  Or, I'm thinking functions should have to specify their return type, 
always. That would make this:

String function trimLastChar(o) {
  return o.subString(0,o.lastIndex()-1);
}

  And then you would be able to pass this any object implementing a method 
compatible with the subString call and the lastIndex call therein, also 
including the fact that the subString method must return a String.

<< the interface is the string, which is parsed to a sexp. >>
  As I said, "eval" type expressions would be a problem, as they would be 
for many many quite ordinary compilation problems. I'd ignore them (which, 
for evaled definitions, might mean extra warnings. For evaled calls, you'd 
be in the normal 'see-what-happens-when-it-runs' mode that you expect from 
Python, Smalltalk, Perl, etc. for Lisp, I guess that means Lisp won't work)
  If you really mean that Lisp treats everything as a String, even code, 
well.. Don't whing if this won't work with your favorite ksh object-oriented 
package, tcl, basic, or the like.

-- Todd
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.