thoughts for Mojo🔥 lang? static performance oriented py-superset

[goyalyashpal]

Titles:

• thoughts for Mojo🔥 lang? static performance oriented py-superset
• any thoughts for Mojo🔥 ? python's optional static performance oriented superset

Why Mojo🔥

my extracted summary (click me)

A backstory and rationale for why we created the Mojo language.
https://docs.modular.com/mojo/why-mojo.html

This meant a programming language with

• powerful compile-time metaprogramming,
• integration of adaptive compilation techniques,
• caching throughout the compilation flow,

A language for next-gen compiler technology

Mojo is the first major language designed expressly for MLIR, which makes Mojo uniquely powerful when writing systems-level code for AI workloads.

A member of the Python family

The Mojo language has lofty goals: we want full compatibility with the Python ecosystem,

• we want predictable low-level performance and low-level control, and
• we need the ability to deploy subsets of code to accelerators. Additionally,
• we don’t want to create a fragmented software ecosystem

Further, we decided that the right long-term goal for Mojo is to provide a superset of Python (that is, to make Mojo compatible with existing Python programs) and to embrace the CPython implementation for long-tail ecosystem support.

we designed Mojo to allow you, the programmer, to decide when to use static or dynamic.

---

Mojo🔥

my summary of why it felt important to me

• choice of static type checking or dynamic typing
• explicit choice of immutability and mutability; aka memory ownership; via borrowed and inout
• compile time metaprogramming

Syntactic additions

my extracted list which i think would need any changes in hy translator, so, E&OE

• fn strict function definitions
• let (rt constant) and var (rt value) declarations inside a def; alias (compile-time value)
• static struct
• additional and simple types Int , Bool, String, and Tuple
• @value decorator

[Kodiologist]

As best I can tell, you're asking for Hy to support Mojo. Insofar as Mojo is a different language from Python, this is out of scope. Insofar as it's merely another implementation of Python, this should be covered under #934.

[goyalyashpal]

Insofar as Mojo is a different language from Python, this is out of scope. Insofar as it's merely another implementation

well, it's a different language in development which aims to be fully compatible with existing python source files.

It is a superset of python - just like typescript is to javascript.

like i said, the potions options it provides are very resonating with performance related tasks.

[goyalyashpal]

my thought was that - as hy converts sources to python - it will technically be possible to be able to make some additions to hy & being able to generate the corresponding mojo code

so, it will provide the expressiveness & consistency of hy while being more performant on demand.

[scauligi]

as hy converts sources to python

As a(n important) nitpick, the Hy compiler compiles Hy sources to Python AST, which is a level or two below source code.
The hy2py tool uses Python's own stdlib to convert that back to Python source, but it's not guaranteed to be 100% accurate (indeed there are ASTs one can create with Hy that cannot be represented by Python source).

Mojo is not yet open source, so I have no clue whether they're parsing Mojo source to (an extension of) Python AST or something else.

[goyalyashpal]

hi @ scauligi ! thanks for ur input and clarification.

so, do u know of any way to get any static typing or pure functional nature with python/hylang?

[scauligi]

Unfortunately all the Python type checkers I'm aware of seem to be syntax-based, and so wouldn't work with Hy.

For "pure-functional" coding, depending on your needs, I think defining "frozen" dataclasses using attrs will work quite well.

[Kodiologist]

The hy2py tool uses Python's own stdlib to convert that back to Python source, but it's not guaranteed to be 100% accurate (indeed there are ASTs one can create with Hy that cannot be represented by Python source).

It's supposed to be 100% accurate. Do you have any examples of "ASTs one can create with Hy that cannot be represented by Python source"? 'Cause that's a bug.

[scauligi]

I meant it in terms of weirdness like with being a valid AST symbol but invalid Python syntax, so we have:

>>> weird = Module(body=[Assign(targets=[Name(id='with', ctx=Store())], value=Constant(value=3))], type_ignores=[])
>>> ast.unparse(weird)
'with = 3'
>>> with = 3
╭─────────────────────────────────────────────────╮
│ with = 3                                        │
│      ▲                                          │
╰─────────────────────────────────────────────────╯
SyntaxError: invalid syntax

[Kodiologist]

I went to some lengths to make sure Hy only emits Python-legal names, though (af64cbe). If you can still get it to produce with = 3, that's a bug. You should see 𝐰ith = 3 instead.

[Kodiologist]

Admittedly, python/cpython#90678 is itself a bug (which it seems will never be fixed, since my PR has sat unreviewed), but that's why we have the workaround.

[goyalyashpal]

Unicode-mangling
- @ Kodiologist at python/cpython#90678 (comment)

ohw, wow. i don't think that is good approach at all. but more power to you

i would have prefferred having involving using some namespace like concept i.e. say mandatorily requiring some macro: to handle that mangling and put restriction on syntax,
, and disallowing it otherwise with no restriction onsyntax.