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 (af64cbe9969a6369b0ec4d4b8cca6f13896358cc). If you can still get it to produce with = 3, that's a bug. You should see 𝐰ith = 3 instead.

[Kodiologist]

Admittedly, https://github.com/python/cpython/issues/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 https://github.com/python/cpython/issues/90678#issuecomment-1114210071

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.