[Python-Dev] Parrot -- should life imitate satire?

[Samuele Pedroni]

[Dan Sugalski]
> >A question: when you say variable you mean variable (perl sense of that)
> >or object. It has already been pointed out but it's really confusing
> >from the point of view of python terminology. Will perl6 have only
> >variables which contain objects, truly references to objects like Python
> >or ...?
> 
> Well, it sort of looks like:
> 
>    name--->variable--->value
> 
Ok, I got your explanation. I see that perl6 will still have a rather 
convoluted model and quiet different from Python...

> I think the variable here would correspond to a Python object
Possible but not in a natural way.


> I think it's the potential existence of references (or pointers, or 
> whatever you want to call them) that necessitate the three-level split.
Makes perfectly sense.


> sounds like the things I'm calling 'name' and 'variable' are much more 
> tightly bound in Python.
No,

a name/variable is just slot in a namespace/ symbol table,

that contains a pointer to a value/object which contains data and also 
points to the type-specific vtable.

Quiet different.

Do your values come with a vtable that then is "copied" in the variable?
Your vtable are for things like scalar, vs array vs. hash.
Do they possibly change when the value change (e.g. string to integer
 for a scalar var)?


> the way Python would do things, in which case Python variable vtables might 
> just have an "overwrite myself with the incoming info" function, rather 
> than allow it to be overridden)
No, unless you have a generic Python PMC which mirrors/ or uses a vtable
that goes together with the value (in the sense of your scheme).

Otherwise I think python assigment would be more some flavor
of reference (perl sense) assignment.

If you map Python built-in data object to PMC then assignment
is a just a matter of namespace manipulation.

For the momement I don't really see a natural way of mapping python
semantics over your three-level scheme, maybe is just the lack of details.
Especially I see a lot of problem if you want a mapping that can also
allow interoperability beetween Python and Perl code.

> Yup. I am profoundly tempted, and I think it will go in, to have a "stable 
> code" switch that can be given to the optimizer which guarantees that, once 
> the compilation phase is done and we finally get to run for real, code will 
> not change. And then apply all the advanced optimization techniques at that 
> point.
> 
I don't really get this. In python the kind of dynamic changes you can
do are reloading code, changing the base classes of a class, adding/substituting
methods in a class or instance. When an application really need one of this
techniques with your philosophy it will be treated as 2nd-class citizen.
What I was referring were de-optimization techniques (yes they are a mess
to deal with for the compiler writer).
Reading about native compilation of dynamic languages I have been conviced
that in general performance is a matter of implemention and it better
to keep it transparent to the user, having constructs that should
be avoided not for design reasons but because the compiler uses
some tricks and not others is a bad thing, for a dynamic language IMHO.
And in any case you still have the problem with polymorphic calls
and to deal with them - in case you want to speed them up - you still
have to make asssumptions at runtime and possibly take them back.

> 
> >For the rest is just speed vs. memory, customization is a clear example
> >for that.
> 
> Sure. The one nice thing that both perl and python have going for them is 
> the ultimate presence of all the source (or a high-enough level 
> representation of it to feed to the optimizer) at run time. We can tell 
> with more surety what side-effects various methods and functions in 
> external code libraries will have, and we can get more aggressive (maybe) 
> because of it.
That is probably not directly true for polimorphic call sites. But of
course you can type-profile the program at runtime.

> Unlike, say, C, where passing a pointer to a routine outside 
> what the compiler can see will hobble the optimizer a whole lot in many 
> cases...
> 

regards, Samuele Pedroni.