hebigo VS py2many

The Lissp transpiler incrementally compiles and executes each top-level form to Python. It needs to do this in case there's a macro definition that might affect the compilation of a subsequent form. If it's only executing definitions, this is harmless, but if you want to precompile the main module, it needs the guard, or the side effects will happen too.

If you want Python to be as customizable as Lissp, check out Hissp (and Hebigo).

Python's lambdas can have as many lines as you want. Just wrap parens around it. Hissp uses this form as a compilation target. Its REPL shows the Python compilation. Play around with it til you get it: https://github.com/gilch/hissp

The original Lisp's S-expression syntax was just supposed to be an intermediate language used by the compiler when processing the real language based on M-expressions, which kind of never took off. Numerous alternatives to S-expressions have been proposed, and some retain homoiconicity, another feature diagnostic of a Lisp (and one that ECMAScript lacks). For example, see Hebigo's readme, which shows a direct correspondence between its Python-like syntax and that of Hissp's default reader (Lissp), which uses the S-expressions. Julia can also be written in S-expressions, but this usually only used in macro definitions.

I think LoL is too CL-specific. If you know both languages first, you can pretty much translate, but since they'd be trying to learn Lisp in the first place, this is a bad idea.

On the other hand, [Hissp][1] has a pretty good tutorial for anyone coming from a Python background.

[1]: https://github.com/gilch/hissp

Hebigo: a whitespaceLisp isomorphic to Hissp that looks like Python.

> Another problem is that there are hundreds of built-in library functions that need to be compiled from Python from C

An approach I've advocated as one of the main authors of py2many is that all of the python builtin functions be written in a subset of python[1] and then compiled into native code. This has the benefit of avoiding GIL, problems with C-API among other things.

Do checkout the examples here[2] which work out of the box for many of the 8-9 supported backends.

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

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...

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