Real progress

[Christian Iversen]

Hello world!

It's the dear leader here. I feel like I've made some real progress,
which I would like to share with you:

>>> FAILED (failures=10)

This is with a whole host of new brütal unit tests, which the old
compiler fails on. All in all, I think we have the same number of
failing unit tests for the new and old compiler now.

The new compiler support several new pieces of basic syntax (compound
boolean operators, for-else, while-else, try-else, nested list
comprehension, and more), while still lacking a little bit in class
support. Thus, the "same number of failing tests" doesn't mean that the
same _things_ are failing.

A few things still are not supported in Pyjaco v2.0:

- Class decorators
- Function decorators in class methods
- Multiple inheritance
- Metaclasses
- Nested classes
- Generator expressions
- Yield
- The __getattribute__ "real" magic that happens
- Modules

The 10 failures in the current test suite are all because of missing
support for certain features in classes (almost all of them are because
of missing @staticmethod).

The old class system is essentially a hack, and I'm looking at whether
it would be best to re-implement the old hacks, or try and innovate a
little bit.

I can definitely see 4 out of the 6 mentioned problems go away if we
implement a bit of new compiler code for geneerating classes.

It would also enourmeously streamline the internals, since what I'm
considering is implementing type(). Here's what that means:



In python, when you do:

class foo(bar):
def func(self):
return 42

you are telling python to create a new class object, which should
inherit from "bar" and contain a function "func". It is equivalent to
the following line:

def func(self):
return 42
foo = type("foo", (bar,), {"func": func})

Now, in the current compiler, this same class would be constructed
approximately like so:

var foo = __inherit(bar, "foo", <true or false>);

foo.PY$func = function() { return int(42); }
...


Now, the similarity between __inherit() and type() should be pretty
clear. Not only would removing __inherit cause a lot of other problems
to go away, it would also make type() work, which would mean that
dynamic class creation, metaclasses, class decorators and the like would
either automagically work, or be very simple to support. Additionally,
since the current road block for MRO (Method Resolution Order, for
Multiple Inheritance) is that we don't have a flattened class
inheritance list, multiple inheritance would also be relatively easy to
support.

So that's what I'm working on at the moment. Any comments about the new
class system, or anything else pyjaco-related?

/Dear leader out

--
Med venlig hilsen
Christian Iversen

[Samuel Ytterbrink]

So type would in it self be implemented with type? Since it is a object with a callable interface?

--
--
You are subscribed to the Google Group pyj...@googlegroups.com
To unsubscribe from this group, send email to
pyjaco+un...@googlegroups.com

--- You received this message because you are subscribed to the Google Groups "pyjaco - The Python to Javascript compiler" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pyjaco+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
//Samuel Ytterbrink

[Christian Iversen]

On 2013-07-26 19:14, Samuel Ytterbrink wrote:
> So type would in it self be implemented with type? Since it is a object
> with a callable interface?

Indeed!

This is what python does, and how the object hierarchy is bootstrapped:

>>> type(type) == type
True

Now, many people believe the python root class is "object", but really
it's "type". Look:

>>> type(object) == type
True

So I'm thinking we might as well try to do the same for pyjaco, so we
would have a more similar semantic, and an easier time emulating OO in
general.