Re: Re: Re[2]: Re: class proposal

On Thu, 24 Jun 2004 16:20:42 -0700 Mark Hahn <[email protected]> wrote:

> Lenard Lindstrom wrote:
> 
> > Prothon prototypes do  not give one a simpler alternative
> > to metaclasses as
> > claimed. It simply does not allow it, period.
> 
> Why haven't you told me this before?  :-(
> 
> Can you show me a metaclass example that Prothon cannot handle?  I would
> like to understand this situation better.
>
Metaclassing let me make Python's class statement create prototype
object instances. In Python the class statement is simply a specialized
function call. The inheritance section and class body are evaluated to
provide the arguments. By default object 'type' is called to return a
new object. Metaclassing is simply a way to change the function called.
This permits new kinds of class systems to be added to Python without
changes to the language. But in Prothon one only has prototypes. And the
object statement can only return new prototype instances. In Python if
you do not like existing object behaviour you are free to implement
your own object types and have language support for them.

> > I fear that Prothon is simply becoming an extended Stackless Python
> > without the latters flexible C-Python api. I am still wondering what
> > advantage Prothon's distinctive interpreter design has over Stackless
> > Python.
> 
> The more I learn about Python's interpreter the more I learn there isn't
> much difference.  You seem to think there is a big difference in this "type"
> business but I'm not convinced.  I suspect it is just a vestige left over
> from the old Python design.
>
They let Python C extension modules customize an object in attribute lookup
and memory management. One could add new object types to Python by writing
a module.

> > Prothon has no reference counting to simplify life for C
> > module designers. But tools like SWIG and Pyrex effective hide
> > C-Python reference counting. And as a language Prothon
> > lies somewhere between Pyrex and Ruby in compatiblity with Python. At
> > the C api level there is little simularity. So in effect all modules
> > added to Prothon will be written from scratch - no automatic
> > translation from Python.
> 
> This is a function of having no backwards compatibility.  Saying that we
> would have automatic translation would have been a form of backwards
> compatibility and limited our design choices.  Believe me, being forced to
> have C object compatibility would have ruined our object design.  Prothon's
> objects are the key to it's power.
>
One of the things that cropped up on the Python list was how much advantage
Prothon would have if it could bypass years of development time by using
Python's libraries. Many Python users will be disappointed to find that
Prothon will not be able to run even a simple Python program without
modification.
 
> > Given that Prothon is becoming more
> > convensional with time is the extra effort worth it?
> 
> What made you expect an unconventional language?  There is nothing in the
> Prothon prime directive about conventionality.  There are only things about
> it being a great language.
>
Prototypes are supposed to be revolutionary. Adding classes to keep large
companies happy is being conventional. If classes are truly necessary then
they should be in the language. But if present they will be used. And Prothon
will be precieved as another object-oriented language, even if this is not true.
Given the number of well established OO languages already in existance will
a newcomer be given serious consideration?

> > If one starts
> > with Stackless Python and throws out the backwards compatibility
> > requirement what kind of language would result? Would Prothon still
> > have its advantages?
> 
> Once you throw out backwards compatibility you end up with Prothon by
> definition.  You end up with a language that can be whatever it wants to be
> based on what the designers feel is important.  Given the same set of
> designers (us) you will end up with the same language.
> 
A language that diverges from Python will remain compatibible in those areas
where change is not required. Prothon was advertised as Python with prototypes.
It has delivered on the prototypes; it is not Python. Even simple Python programs
require modification to run under Prothon. And it will be difficult and time
consuming to make any Prothon feature consistent with Python. I keep stumbling
onto new differences every time I try Prothon. Many error reports will have
to be submitted to clear them all up.

My question is just who is Prothon targetted towards? I think many Python users,
expecting Prothon to be just an enhanced Python, will be put off by its
incompatiblity. Prothon is different enough from Python to discourage the porting
of existing Python applications. Only in those areas where Prothon has a definite
advantage will it make sense. I am not convinced that prototypes give any clear
advantage in most cases.

I see Prothon's strengths being native thread support and builtin i18n. So
Prothon should be designed for those applications where these features are
important. Maybe compatiblity with Python should not be a consideration at
all?

Lenard Lindstrom
<[email protected]>