monadless VS py2many

The `{..}` is from `RecordWildCards`.

I do like the omission of `let` and `where` in favor of just variable definitions. For monadic notation, instead of `get` and `return` I'd prefer something like https://github.com/monadless/monadless

The main problem with `do`-inspired monadic notation is that it forces monadic code to always be in A-normal form, which is pretty annoying. It'd be far nicer to allow for monadic code to look the same as normal code, just with say an extra brace (such as "IO { }") to indicate that you're inside a monad.

Well `RecordWildcards` has been around for 14 years... but even without it instead of `{..}` you'd just have `_`s. The main thing that is different is that your Kind example had nested case statements while your Haskell example tried to match everything on one shot, which makes for a non-equivalent comparison.

> Not sure how that could work, though. Idris had an interesting syntax, but IIRC it wasn't general.

I assume you're talking about idiom brackets for applicatives? The general syntax is given in something like https://github.com/monadless/monadless. The idea is to basically take async-await syntax and generalize it to any monad.

So e.g. your `Maybe` example (using `!` for the equivalent of `await` for concision) would look like

  Maybe {

> If anything, async-await feels like an extremely non-functional thing to begin with

It, like many other things, forms a monad. In fact async-await is a specialization of various monad syntactic sugars that try to eliminate long callback chains.

Hence things like Haskell's do-notation are direct precursors to async-await (some libraries such as Scala's monadless https://github.com/monadless/monadless make it even more explicit, there lift and unlift are exactly generalized versions of async and await).

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Reimplement a large enough, commonly used subset of python stdlib using this dialect and we may be in the business of writing cross platform apps (perhaps start with android and Ubuntu/Gnome)

For py2many, there is an informal specification here:

https://github.com/py2many/py2many/blob/main/doc/langspec.md

Would be great if all the authors of "python-like" languages get together and come up with a couple of specs.

I say a couple, because there are ones that support the python runtime (such as cython) and the ones which don't (like py2many).

It'd not fully solve your issue, but have you ever seen https://github.com/py2many/py2many ?

Cython doesn't consume python3 type hints and needs special type hints of its own. But it's certainly more mature than other players in the field.

What we need is a rpython suitable for app programming and a stdlib written in that dialect.

https://github.com/py2many/py2many/blob/main/doc/langspec.md

No intermediate AST. To understand the various stages of transpilation and separation of language specific and independent rewriters, this file is a good starting point:

https://github.com/adsharma/py2many/blob/main/py2many/cli.py...

This is awesome! The direction of using a subset of python, while leveraging the user base and static typing to accomplish some other everyday task in a different language is very legit IMO.

I took a cursory look at:

https://github.com/zanellia/prometeo/blob/master/prometeo/cg...

It seems quite similar in spirit to

https://github.com/adsharma/py2many/blob/main/pyrs/transpile...

I'm not spending much time on py2many last few months (started a new job). Let me know if any of it sounds useful - especially the ability to transpile to 7-8 languages including Julia, C++ and Rust.

Link to the test that's relevant for this discussion:

https://github.com/adsharma/py2many/blob/main/tests/cases/in...

This is an explicit deviation from python's bigint, which doesn't map very well to systemsey languages. The next logical step is to build on this to have dependent and refinement types.

Work in progress here:

https://github.com/adsharma/Typpete