This Week in Mojo 2023-05-26
Mojo Playground Release
finally clauses are now supported on
try statements. In addition,
try statements no longer require
except clauses, allowing
finally clauses contain code that is always executed from control-flow leaves any of the other clauses of a
try statement by any means.
with statement emission changed to use the new
finally logic so that
with ContextMgr(): return
Will correctly execute
ContextMgr.__exit__ before returning.
New Mojo Dojo post: Mojo first impressions
sa- who is active on the Discord as
sa-codemade their own tensor struct for tensors with up to 2 dimensions as well as a linear regression struct, as they experiment with creating a nice API for a full library.
DayDun who has been actively raising bugs and answering questions on GitHub has been experimenting with ray tracing and attempting to improve performance via SIMD, here was the latest image and speed:
- yt7589 has been enthusiastically experimenting with their own matmul implementation of up to 4 dimensions similiar to
@operator for an
Python and Mojo creator exchange
Python creator and
Benevolent Dictator For most-of-Life Guido van Rossum had a small tongue-in-cheek exchange with Mojo creator and Modular CEO Chris Lattner:
How do you pronounce the flame emoji that’s part of the language name?
Good question, everyone I've heard say it out loud pronounced it as 🔥
Snark 😀 BTW we should talk some more about the evolution of Mojo's design in the context of Python.
It is super important to me that Mojo is a good member of the wider Python community. I'd love to reconnect of course!
Mojo Team Answers
Loosely held opinion, Mojo clearly needs to support:
Nested functions (currently wired up, but have a few issues given lifetimes are not here yet). I'd like @parameter to go away on the nested functions eventually too. Existing Python lambda syntax, which is sugar, we need to support type annotations here.
Lower priority, but I think we're likely to explore:
Possibly implement more flexible/general/ergonomic light-weight closures like Scala3 => syntax
User defined statement blocks, e.g.:
User defined statements are a nice way to shift more language syntax into the library, but are just syntactic sugar and will require a little more infra to get wired up. For example, I would like "return" in that context to return from the enclosing function (not from the lambda), and things like break to work for loop-like constructs. This is quite possible to wire up, but will require a bit of design work.
It still bugs me how "return" works the wrong way and break doesn't work in a "closure taking control flow" function in Swift. We can do better.
On question about Result type like Rust
It will be one of the things added when Abstract Data Types (ADT) and traits are in place
There are practical reasons why brackets will not work and why significant whitespace is crucial to the parser: lazy body parsing. Mojo's parser can trivially skip over the body of structs, functions, etc. because it can use the expected indentation to find the end of the indentation block.
Answer from Chris after more discussion
This suggestion cuts directly against or goals for Mojo, which is to be a member of the Python family. Thank you for your suggestions, but our goal isn't to design a new language from first principles (been there done that 😄), it is to lift an existing ecosystem. We are also not adding general syntactic sugar, we are focused on core systems programming features that Python lacks.
The issue with adding the type bultin to Mojo is that we don't have a runtime type representation yet. I.e. in Python, type returns a type instance that can be used like a class.
Infinite Recursion Error
We want the compiler to generate diagnostics on obvious bugs to help the programmer. If someone accidentally typos something or (like your initial example) does something that is obviously recursive, we should help the programmer out.
I don't think there is a good reason for people to want to exhaust the stack; generating an error seems fine, and if there is some important use case we can figure out if there are different ways to address the need.
I agree we should generate a good error rather than just crashing when an undetected-infinite recursion (or just DEEP recursion) happens, this isn't going to get fixed in the immediate future due to prioritization, but I agree we should do it at some point.
Watch out for LLVM which has tail call and other optimizations, which can turn things into closed form loops in some cases 😀