Mojo and Dynamism

[Mogball]

Mojo has the lofty goal of being a simple, powerful, and easy-to-use language like Python but with features that allow programmers to reach the performance of C. One of Mojo's approaches is to start from being a superset of Python and provide an incremental typing-for-performance story where the performance of Python code can be incrementally improved by adding type annotations, explicit variable declarations and error handling, switching def to fn, and so on. By making things like types explicit, dynamism is removed from the program and the compiler can generate faster code. The relationship between Mojo and dynamism has to be carefully managed to meet the goals of the language. The point of this post is to measure where that relationship stands now, what it will need going forward as Mojo grows more features, and develop a framework for managing that relationship.

Classes and Dynamism

One feature that Mojo lacks at the moment are classes, an inherently dynamic feature that provides inheritance and runtime polymorphism, the foundations of object-oriented programming.

Classes are implemented differently in many languages. In Python, for example, classes are much more flexible than in languages like C++ or Java -- they are more similar to classes in Javascript or Smalltalk. Methods can be defined and then deleted, and even conditionally defined! For example, this is valid Python code:

define = True

class C:
    print("hello") # prints 'hello'
    if define:
        def f(self): print(10)
    else:
        def f(self): print(20)


C().f() # prints '10'

In fact, the body of a Python class is just code that is executed, and the resulting local variables are bound to the attributes of a class object. When calling a class object, it returns a new object with a reference to the class object, in which it can perform attribute lookup. In addition, functions that would be member functions have their first argument bound to the new class instance through the Python descriptor mechanism.

Mojo as a superset of Python has to support the full "hash-table" dynamism in classes for compatibility with Python, but reference semantic classes are also important for systems programming and application programming, where this level of dynamism isn't needed and is actively harmful. We need to decide how to handle this.

One approach is to provide a decorator on class definitions (which can be opt-in or opt-out) to indicate whether the class is "fully dynamic" as in Python or whether it is "constrained dynamic" (e.g. has virtual methods that may be overridden but cannot have methods added or removed).

"Constrained dynamic" Mojo classes will use vtables for a more limited but more efficient constrained dynamism than full hash table lookups. In addition to raw lookups, constrained dynamic classes can use "class hierarchy analysis" to devirtualize and inline method calls, which are not valid for "fully dynamic" classes.

Swift has a similar issue, where the developers wanted to have constrained dynamism by default but needed full dynamism when working with Objective-C code: Objective-C is based on the Smalltalk object model and thus has the same issues as Python. Swift solved this by adding an opt-in @objc decorator, which provides full compatibility with Objective-C classes. Swift implicitly applies this decorator to subclasses of Objective-C or @objc classes for convenience.

If we chose to follow this design in Mojo, we could introduce a @dynamic decorator, in which the class is an instance of a hash table and the body is executed at runtime:

@dynamic
class C:
    def foo(): print("warming up")
    foo() # prints 'warming up'
    del foo
    def foo(): print("huzzah")
    foo() # prints 'huzzah'

We could of course make dynamic be the default, and have a decorator like @strict to opt-in to constrained dynamism as well. Regardless of the bias, we absolutely need to support full dynamism to maintain compatibility with Python.

An implementation question here would be "when does the body get executed?" when the class is defined at the top-level. In this case, the class C could be treated as a global variable with a static initializer that is executed when the program is loaded. This ties into a discussion about how to treat global variables and top-level code in general, which will come in a subsequent section. Naturally, if the class is never referenced, the body is never parsed and the static initializer is never emitted.

Syntactic Compatibility and @dynamic

A primary goal of Mojo is to minimize the syntactic differences with Python. We also have to balance that need with what the right default for Mojo is, and this affects the bias on whether this decorator is "opt-in" or "opt-out".

We find it appealing to follow the Swift approach by making "full dynamic" an opt-in choice for a Mojo class. This choice would add another syntactic divergence between Mojo and Python, but it is one that can be alleviated with an automatic mechanical tranformer from Python code to Mojo code (e.g. to deal with new keywords we take). In this case, all Python classes will be translated by sticking @dynamic on them, and they can be removed for incremental boosts to performance.

An alternate design is to require opt-in to "constraint dynamism" by adding a @strict (or use another keyword altogether) for vtable dynamism. We can evaluate tradeoffs as more of the model is implemented.

def and Dynamism

In Mojo, the goal of def is to provide a syntactic feature set that enables compatibility with Python. It allows, for example, omitting type annotations, implicit variable declarations, implicit raises, etc. But the Mojo def is not the same as a Python def. A commonly reported issue is that Mojo scoping rules differ from Python's. In Python, local variables are scoped at the function level, but Python also supports behaviour like:

def foo(k):
    for i in range(k):
        print(i)
    # Mojo complains that `i` is not defined, but this code should compile and
    # dynamically raise an `UnboundLocalError` depending on the value of `k`!
    print(i)

Python functions also have a notion of which names are supposed to be bound to local variables. In the following example, bar knows i refers to a captured local variable in foo, whereas baz tries to retrieve a value for i in its local variable map.

def foo():
    i = 2
    def bar():
        print(i)
    def baz():
        print(i)
        i = 10
    bar() # prints '2'
    baz() # throws an 'UnboundLocalError'

This gets at the heart of how Mojo should treat implicitly declared variables in defs. The short answer is: exactly how Python does. defs should carry a function-scoped hash table of local variables that is populated and queried at runtime. In other words, lookup of implicitly-declared variables woudl be deferred to runtime. On the other hand, the function does need to have a notion of what variable could be available in the function, in order to emit UnboundLocalErrors as required. Of course, the compiler can optimize the table away and do all the nice stuff compilers do if possible.

Difficulty arises when discussing defs themselves. Although defs should internally support full hashtable dynamism, what kind of objects are defs themselves? For instance:

def foo():
    bar()

def bar():
    print("hello")

foo() # prints 'hello'

def bar():
    print("goodbye")

foo() # should this print 'goodbye'?

In Mojo today, the first time the name lookup of bar is resolved, it is baked into a direct call to the first bar. Therefore, shadowing of bar does not propagate into the body of foo. On the other hand, if all defs were treated as entries in a hashtable, then it would.

One middle-ground approach would be to treat bar as a mutable global variable of type def() (one for each possible overload of bar). The dynamism can be escalated with a @dynamic decorator that removes static function overloading. However, both of these approaches risk creating confusing name lookup rules. For instance, would the following be allowed?

@dynamic
def bar(a): pass

def bar(a: Int): pass

This gets into the "levels of dynamism" Mojo intends to provide, and how that relates to defs. The reality is that defs in Mojo today only resemble Python defs on the surface. They share similar syntax, but Mojo defs are really extra syntax sugar on top of fn and are altogether a different beast than Python defs.

Four Levels of Dynamism

To summarize, in order to support incremental typing-for-performance, Mojo will have to support everything from strict, strongly-typed code to full Python hashtable dynamism but with syntax that provides a gradual transition from one end to the other.

Given all that has been discussed and what the language looks like today, Mojo's dynamism is moving into four boxes:

1. Compile-time static resolution.
2. Partial dynamism.
3. Full hashtable dynamism.
4. ABI interoperability with CPython.

The fourth category isn't explored here, but will important when/if we support subclassing imported-from-CPython classes in Mojo, because that will fix the runtime in-memory representation to what CPython uses.

The highest level of dynamism and the most faithful compatibility doesn't come from Mojo itself, it comes from Mojo's first class interoperability with CPython. This in effect will be Mojo's escape hatch for compatibility purposes and is what gives Mojo access to all of Python's vast ecosystem. Below that, Mojo will provide an emulation of Python's hash-table dynamism that is a faithful but not quite identical replication of Python behaviour (no GIL, for example!). Building this out will be a huge undertaking, and is something Mojo should do over time.

The most important thing to remember is that Mojo is not a "Python compiler". The benefit of sharing the same syntax as Python, however, means seemless interop is on the table:

@python
def python_func(a, b=[]):
    return a + [2] + b

fn mojo_func():
    try:
        print(python_func([3]))
    except e:
        print("error from Python:", e)

The goal of the "levels of dynamism" is to provide an offramp, starting by removing the @python decorator from python_func.

[ksandvik]

Just putting out the option that classes are in Mojo equivalent to Python and data grouping with functions is primarily done with traits/protocols and structs, similar to Rust.

[tekknolagi]

The Cinder project (which I used to work on) has some prior art for making method lookups faster and having compact instance storage in Static Python.

[15r10nk]

That's quite a difficult problem.

I can only share an idea that is going through my mind. I hope this might be helpful in some way.

Classes are just syntactic sugar for __dict__ and __class__.
The idea is to convert dictionaries to structs and not classes themselves.

This would require knowing which keys are accessed and whether this set of keys is finite.
But this could generalize the problem.
It is difficult to say whether this would make implementation easier or more difficult.
This is currently just an idea in my head and I don't know if it's possible to make it happen.

I also wanted to share with you two libraries I wrote to test some of my code that might also be useful to you.

• pysource-codegen generates random python code (currently 3.11 only)
• pysource-minimize can be used to minimize the Python code and produce a minimal reproduction for a bug.

They are useful, but may still have some problems. You may find them useful to test mojo.

It's really cool what you are doing and I hope that you will be successful.

[Lorenzobattistela]

I believe this deserves a wide discussion about the priorities and main goals of mojo.
About classes: from my point of view, if mojo aims to be a superset of Python but reaching the performance of C code, I see the decorator as the best option. Constrainted dynamic classes should be something possible, but I do think that Python-like classes would be the default on that case. This means something like:

define = True

class C:
    print("hello") # prints 'hello'
    if define:
        def f(self): print(10)
    else:
        def f(self): print(20)


C().f() # prints '10'

@strict
class D:
    print("hello") # prints 'hello'
    if define:
        def f(self): print(10)
    else:
        def f(self): print(20)

D().f()  # should raise in class definition

This would keep old Python-like classes working and easier to write. This is my point of view, but I think that this should be aligned with the goals of the language (maybe we want to be strict by default).

I think the main point here for all the decisions commented is to align the design with the purpose of the language. Does mojo want to be Python-like in all this cases and specially mark what's designed for C-like performance? Do we aim to have C-like strict performance by default and make it clear when it's Python syntax and just reuse what Python does?

[NickW3101]

Agreed. Don't lose focus on being a superset. The further Mojo gets from that by default, the lower adoption will be.

[Mogball]

From the outset, the goal of Mojo as a project was to build a new programming language that gives Python superpowers, not to build a Python compiler (as many have tried and have yet to succeed for various reasons -- projects like PyPy and Numba are fantastic but they're not 100% substitutes for Python itself). That doesn't mean that one day Mojo can't become one. Level 3 dynamism is something the language needs a lot of time to build out and bake, and it's something that as it becomes more sophisticated will become closer and closer to native CPython.

Starting from the goal of "Mojo will provide a bug-for-bug edgecase-for-edgecase reproduction of CPython but as a compiled language" is a nonstarter for Mojo as a project. But with first-class (i.e. share the same syntax) interop, Level 4 can be our escape hatch until in the fullness of time, Level 3 becomes nearly indistinguishable from native CPython.

[AriMKatz]

The highest level of dynamism and the most faithful compatibility doesn't come from Mojo itself, it comes from Mojo's first class interoperability with CPython. This in effect will be Mojo's escape hatch for compatibility purposes and is what gives Mojo access to all of Python's vast ecosystem

The most important thing to remember is that Mojo is not a "Python compiler".

Then neither will it be a superset, unless you consider Julia a superset because it can call into cpython.

[soraros]

unless you consider Julia a superset because it can call into cpython.

Julia's python interop isn't "first class", but that's rather irrelevant. The highest level of dynamism can go way beyond the said hashtable dynamism (think dynamically generating byte code, using eval everywhere, etc.), to a point where even things like PyPy can't reasonably support. There's no point arguing the language one uses on PyPy isn't python. Likewise, I wouldn't expect torch-dynamo to ever run on future version of mojo, but "ordinary" python package don't intercept and modify byte code.

[AriMKatz]

Julia's python interop isn't "first class"

With Julia's metaprogramming and multiple dispatch polymorphism, I'm not sure if there's a meaningful distinction. Can you point one out?

(think dynamically generating byte code, using eval everywhere, etc.

If that's all the gap is, then sure. But saying mojo isn't a python compiler implies otherwise, because I'm sure they'd agree pypy is a python compiler. Byte code generation and manipulation I'd take. Eval everywhere, borderline for me. Anything else? I'd probably disagree.

[soraros]

If that's all the gap is, then sure.

Do you have in mind some form of dynamism that's not covered by the above 4 levels you think is inherently python (and not cpython), and the lack of it warrants your position against mojo being a python superset? Maybe we suggest improvements to the mojo team so they can bridge the gap.

Offtopic

With Julia's metaprogramming and multiple dispatch polymorphism, I'm not sure if there's a meaningful distinction.

I don't see how is metaprogramming/polymorphism capability relevant when we are talking about FFI. Level (4.) is what I meant by native or first class interop, similar to how swift has native interop for ObjC but not yet for C++. of course, (4.) is not achieved, but it's simply a non-goal for Julia the language and for e.g. the pyjulia binding library. I don't think you argument against mojo being a superset based on capability that mojo has (aspired native interop) rather than something it doesn't have is all that compelling. But like I said, it's all rather irrelevant to this thread.

[AriMKatz]

It's relevant because it makes interop seamless and functionally first class. I don't see the difference between what can be achieved with macros and multimethods and what "first class" built in interop provides. You can have classes, override methods, context managers etc

Is there something I'm missing?

[florean]

It would seem natural to default to @strict (level 2) for .mojo and .🔥 files and @dynamic (level 3) for .py files. I would also think about module or package flags. If I include __mojo_strict__ = True in my package's __init__.py, then the default for the package should be the same as the @strict decorator. I think I will try to avoid mixing levels of dynamism inside modules and will reserve the decorators for very exceptional cases.

[Mogball]

One think to think about with global modifiers to strictness would be code readability. If I open a random .mojo file from a package, how do I know if it's running in strict or dynamic mode? The file extension ideas proposed seems like an easy way to alleviate this.

[drunkwcodes]

I vote for @Mogball's way of decorators.

I'm so frustrated about the dynamism of python class. I had to add those needless hasattr() calls in the legacy code.
I'm tempted to make more memes.
IMO the dynamism is not encouraged in the majority of code.
I didn't investigate AI field, though.

The syntax is good to serve the performance first, then the compatibility second.

[drunkwcodes]

Hey! I ranted to supermeme.ai then it gave me a decent meme!

[Moosems]

I've used hastattr() to reduce boilerplate before 🤷‍♂️

[gryznar]

After these changes will dynamic/strict classes coexist with struct?

[Mogball]

Yes. structs are here to stay.

[gryznar]

If .py files will be supported (as a superset they should), there is a clear way for me:

• .py files dynamic as in Python for compatibility
• .mojo static only for profits from strictnes

In such case Python whole codebase could be just copied to Mojo project and it will work with some performance boost.

If someone would like to squeeze performance, these .py files could be just transfered to .mojo files. This approach could be also much simpler to implement and maintain than "duality" in .mojo

[maxme1]

I really like this idea. Also, this way the user gets a kind of "context switch" for free: I don't need to think about the dynamism of the function/class I'm looking at, I know that I'm reading a .mojo file so I know for a fact it's static.

[lattner]

If .py files will be supported (as a superset they should), there is a clear way for me:
.py files dynamic as in Python for compatibility
.mojo static only for profits from strictnes

Super interesting idea. We can definitely explore having the compiler treat .py files differently than .mojo files.

[ivellapillil]

The intention is that Python code could be ported as is or with minimal changes to Mojo proper. It is not just interoperability using Python interpreter. It is intended to be a successor language to Python, with warts and all, similar to what C++ is to C.

[czheo]

similar to what C++ is to C

Exactly what I have question of. C++ is notorious for its complexity. If Mojo is going to be Python++, it will likely walk a similar path.
By the end of the day, I feel it will be a call the Mojo team has to make, in terms of the trade-offs between keeping the core language simple vs including more features in the cost of complexities. I'm under the impression that Mojo is going to embrace the later approach. I'm not judging that one is better than the other. After all, there are successful languages having walked the same path, such as C++ or Scala. I also appreciate the aesthetic simplicities of languages like Lisp, Haskell or (arguably) Python, which is from the other end of the spectrum. I'd like to invoke some rethinking here whether introducing class is a good decision at least at this stage.

[ivellapillil]

If we want a clean small language, nowadays we have so many languages to choose from to satisfy everyone's needs. Mojo's USP is specifically that it is Python++. That is going to be its strength (and also its weakness). The huge ecosystem of Python will bootstrap Mojo only if all of Python's features are supported as first class. What cannot be supported needs to be easily translatable. Otherwise Mojo will end up in the graveyard of cool, but unpractical languages.

[czheo]

@svihar I generally agree. I can see values of introducing class if Python++ is what Mojo aims to be. When migrating Python class to Mojo, someone can

1. import the .py file if they don't care much about performance
2. copy the class definition to .mojo file, and add @dynamic / @strict annotation based on how dynamically the class is defined
3. re-implement the class using struct/trait

I feel this covers the spectrum of use cases pretty well. Also having both class and struct in the language is already pretty naturally to C++ programmers, but Mojo can potentially make the difference between them more meaningful.

[PriNova]

I'm a big fan a functional programming in the core/business logic. This approach loves the most compiler too in regards of the optimization pass. Think of pure functions, algebraic data types (which can be realized with structs) and static code resolving, pattern matching on ADT etc.
For the outer layers (the shell) like I/O, Network, DB and GUI parts, there fits the object oriented approach best in my experience.
I hope Mojo will not fall into the trap of OOP too much.
Dynamism on the python part is OK for portability, but on the Mojo part, FP, ADT, pattern matching and as few as possible polymorphism or multi dispatching and more focus on data oriented programming I propose. The most performance you get is with data-oriented design to have the least few memory cache hits and can fill the LCaches perfectly, also in the GPU, TPU, ASICS domain.