Hy versus Racket as base for pollen #107

First of all: Very cool project! I hope Pollen will gain much more traction, because I can see many usecases for a language like it.

In the backstory of Pollen it says that in the beginning a simple markup-notation implemented in Python was tried as base for Pollen, but was later replaced, as we know, by a Racket-based language.

I assume the Python approach failed because the Python syntax is rather heterogeneous when compared to Lisps.
In Python the operator can be in front of (print("hello world")), between (x = 100) or mixed with (for i in range(100)) the operands, and this makes the fencing of the code within a text more difficult. The fencing problem is made even worse by the fact that vanilla Python uses indentation to define blocks.
So the problem with Python here is its syntax.

Due to the homogenous syntax of Lisps these problems don't exist when using a Lisp dialect, and Pollen's genius design of marking commands with the little used lozenge ◊ symbol enables Pollen to be a preprocessor language for basically all text-based file types instead of being yet another obscure and limited template language.

Hy is a Lisp dialect that maps 1:1 to Python. Hy can use all existing Python code and many of the tools (like the packet manager).

What are the pros & cons of Hy versus Racket as the base of Pollen? Two advantages of Hy over Racket I can think of:
- There is an extremely large number of (often high-quality) libraries and algorithms available for Python
- From my perspective, Python is a very human-friendly language to write in, which makes it easy relatively easy to write code that can actually be maintained and debugging Python code is also quite easy in my experience. So if you wanted to use a very complex function in Pollen, you could write it in Python and import it in Pollen.
And would it be possible, with reasonable effort, to switch the base which Pollen is build upon from Racket to another Lisp, such as Hy? To what extend is Hy is written in itself (as the original Lisp reportedly was)[http://www.paulgraham.com/rootsoflisp.html]?

First of all: Very cool project! I hope Pollen will gain much more traction, because I can see many usecases for a language like it. In the [backstory of Pollen](https://docs.racket-lang.org/pollen/Backstory.html) it says that in the beginning a simple markup-notation implemented in Python was tried as base for Pollen, but was later replaced, as we know, by a Racket-based language. I assume the Python approach failed because the Python syntax is rather heterogeneous when compared to Lisps. In Python the operator can be in front of (`print("hello world")`), between (`x = 100`) or mixed with (`for i in range(100)`) the operands, and this makes the fencing of the code within a text more difficult. The fencing problem is made even worse by the fact that vanilla Python uses indentation to define blocks. So the problem with Python here is its syntax. Due to the homogenous syntax of Lisps these problems don't exist when using a Lisp dialect, and Pollen's genius design of marking commands with the little used lozenge ◊ symbol enables Pollen to be a preprocessor language for basically all text-based file types instead of being yet another obscure and limited template language. [Hy](https://en.wikipedia.org/wiki/Hy) is a Lisp dialect that maps 1:1 to Python. Hy can use all existing Python code and many of the tools (like the packet manager). - What are the pros & cons of Hy versus Racket as the base of Pollen? Two advantages of Hy over Racket I can think of: - There is an extremely large number of (often high-quality) libraries and algorithms available for Python - From my perspective, Python is a very human-friendly language to write in, which makes it easy relatively easy to write code that can actually be maintained and debugging Python code is also quite easy in my experience. So if you wanted to use a very complex function in Pollen, you could write it in Python and import it in Pollen. - And would it be possible, with reasonable effort, to switch the base which Pollen is build upon from Racket to another Lisp, such as Hy? To what extend is Hy is written in itself (as the original Lisp reportedly was)[http://www.paulgraham.com/rootsoflisp.html]?

Thank you for the kind words. I don’t know much about Hy. In principle, what you say could work. Pollen however depends on the Scribble subsystem for a lot of the heavy lifting, including parsing the text-based notation. So porting Pollen to Hy (or any other Lisp) would require porting some part of Scribble.

Could it be done? Sure.
Would I do it? No.
Why not? What would I get out of it? I don’t need two Pollens.
Could someone else port it? Sure. I’m surprised the Scribble stuff hasn’t been ported more widely (though IMO a teeny bit of it appears in JavaScript ES5, in the string-interpolation notation).

Thank you for the kind words. I don’t know much about Hy. In principle, what you say could work. Pollen however depends on the [Scribble subsystem](https://docs.racket-lang.org/scribble/) for a lot of the heavy lifting, including parsing the text-based notation. So porting Pollen to Hy (or any other Lisp) would require porting some part of Scribble. Could it be done? Sure. Would I do it? No. Why not? What would I get out of it? I don’t need two Pollens. Could someone else port it? Sure. I’m surprised the Scribble stuff hasn’t been ported more widely (though IMO a teeny bit of it appears in JavaScript ES5, in the string-interpolation notation).

PS. On reflection, I think I’m underestimating the difficulty. Almost everything in Racket relies on its macro system to compile, which AFAIK doesn’t exist in Hy either. So you probably wouldn’t be able to do a direct port — you’d have to recreate the Scribble reader in Python.

Alternatively, rather than thinking in terms of porting Pollen to Hy, maybe it would be better to look around for text-based surface notation systems for Python, and work backwards from there.

PS. On reflection, I think I’m underestimating the difficulty. Almost everything in Racket relies on its macro system to compile, which AFAIK doesn’t exist in Hy either. So you probably wouldn’t be able to do a direct port — you’d have to recreate the Scribble reader in Python. Alternatively, rather than thinking in terms of porting Pollen to Hy, maybe it would be better to look around for text-based surface notation systems for Python, and work backwards from there.

Thanks for the answer! So it makes sense that Racket was selected as base for Pollen, because Racket is the only one that features something like Scribble.

Almost everything in Racket relies on its macro system to compile, which AFAIK doesn’t exist in Hy either.

I'm not an expert in Hy, but it seems that it does support macros: https://docs.hylang.org/en/stable/tutorial.html#macros

Lets see what the future will bring. Definitely interesting developments.

Thanks for the answer! So it makes sense that Racket was selected as base for Pollen, because Racket is the only one that features something like Scribble. > Almost everything in Racket relies on its macro system to compile, which AFAIK doesn’t exist in Hy either. I'm not an expert in Hy, but it seems that it does support macros: https://docs.hylang.org/en/stable/tutorial.html#macros Lets see what the future will bring. Definitely interesting developments.

Labels Milestones

Hy versus Racket as base for pollen #107