Hacker News new | past | comments | ask | show | jobs | submit login
A dialect of Lisp that's embedded in Python (hylang.org)
2 points by raytopia on April 10, 2024 | hide | past | favorite | 5 comments



"embedded" is such a strange word to use.

1) install hy via pip

2) run the hy command, which exposes python3 calls, functions, "libc" and has a LISP syntax.

btw you won't believe it, but it's "embedded" all the way down:

run Hy Embedded in Python which is Embedded in C. which is Embedded in Assembler which is Embedded in an ALU microcode stack which is Embedded in gates Which are embedded in quantum effects.

"Implemented" feels better. Implemented in Python3 and exposing the Python3 import libraries and native systemcall methods.

Is the REPL coded in Hy or in Python? Can I e.g. break from Hy inside the exec('Hy') and be at the Python3 REPL? If thats the case I can probably come at "embedded"


It's something like: A is embedded in B if A is implemented in B or using B, and the features of A are different from the corresponding entities in B, and B uses A.

E.g. A and B are both languages with, say, functions and variables. A is implemented using B. B programs use A programs. But A variables are not B variables, and A functions are not B functions. B cannot directly call an A a function as if it were another B function, or directly access an A variable as if it were a B variable.

Python is embedded in C if it used as an extension language called by C programs. It is written in C, and Python functions and variables do not correspond to C functions and variables. If it's used standalone, then it doesn't appear embedded in C, only implemented in it.

C is not embedded in assembler or vice versa, even if we have C implemented in assembler. Reason being that assembler and C functions and variables are (or can easily be) the same. C can call an assembly language function as if it were a C function, and vice versa. This is is because even if implemented in assembler, the C is compiled. So there is no embedding. A C interpreter in assembly language would be embedded if it is used for extending assembly language applications. We would have the conditions met: implemented in, entities are incompatible, used by.

Some assembly languages (or the instruction sets they represent) are implemented in terms of microcode. The embedding would have to be: instruction set embedded in microcode. Some our conditions are satisfied: the instruction set's instructions are different from microinstructions. Some are not: microcode doesn't call programs in the instruction set that is being microcoded. It strictly implements the instruction set.

Likewise, logic gates do not invoke microcode, only implement it. Thus microcode is not embedded in logic gates.

A language A implemented in B is not necessarily embeddable. Supporting embedding requires special work; like providing an API by which B programs can use A programs. For instance, GNU Bash and GNU Awk are languages implemented in C. They are not embedded in C, and not embeddable in their current state. We cannot link a "libbash.so" (doesn't exist) which would process a Bash script for us, and provide an API to access functions and variables defined in that script. If we had a "libbash.so", then that library would be what is embeddable; /bin/bash would not be considered embedded in C.

Based on all this, using my definitions, would you say Hy is embedded, or just implemented?


> Based on all this, using my definitions, would you say Hy is embedded, or just implemented?

Can I see the Python REPL inside Hy? or is Hy a microcosm, inside the python runtime?

I tend to implemented. I like your model that its interpreted languages which are somewhat inherently embeddable, and compiled languages exist in the machine they are compiled for (at whatever level it is in the stack from physics upwards)

If however, you can mutate the state of Python such that new features expose into Hy, by invoking some outer call from Hy into Python to install and provide a function, then I think embedded might be the way to go.


I'm not sure I agree with your reverse manipulation criterion. It implies that we can't have an embedding if the guest language is sandboxed. E.g. JS isn't embedded in the browser. Or POSIX regcomp and regexec doesn't achieve embedding the regex language in C programs.


Yea, I'm looking pretty wrong. I guess the word fits. I think the existence of a JIT and a pseudo-machine you can "code" to, inside a system which provides execution primitives and a memory model and some kind of IO, means to a world view outside that pseudo machine you're embedded inside it. So from the outside shell your run Hy by executing Hy inside Python. it's embedded.

Colour me wrong.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: