Most active commenters
  • klibertp(3)

←back to thread

160 points leontrolski | 16 comments | | HN request time: 0.285s | source | bottom
1. Y_Y ◴[] No.41887424[source]
If only there was a language that let you modify the interpreter on the fly so you could do this as part of normal execution...
replies(4): >>41887458 #>>41887499 #>>41887640 #>>41888996 #
2. BiteCode_dev ◴[] No.41887458[source]
Python can actually do this using "# coding:", albeit less elegantly than lisp.

I would say it's a good thing, I don't want to see a hundred of half baked, badly tested and vaguely document DSL with no decent tooling support.

replies(2): >>41887507 #>>41887939 #
3. knighthack ◴[] No.41887499[source]
Try Nim's macros.
4. develatio ◴[] No.41887507[source]
Can you provide some more info / links regarding the “# coding:” feature? I wasn’t able to find anything.
replies(4): >>41887621 #>>41887770 #>>41887778 #>>41887841 #
5. ◴[] No.41887621{3}[source]
6. klibertp ◴[] No.41887640[source]
You're Lisp-baiting, aren't you? ;) I'd add Elixir next to Nim (already mentioned); also Rust. Recently, also Scala.

The reason we don't have such metaprogramming available everywhere is mostly because you have to subscribe to a particular ideology to allow it. If you think programmers are generally intelligent and responsible, you put macros and metaclasses in your language. If, on the other hand, you think most programmers are dumb code monkeys (with a few exceptions, maybe) your language becomes like early Java or early Go.

replies(2): >>41887659 #>>41887668 #
7. keybored ◴[] No.41887659[source]
That dichotomy is interesting considering Guy Steele’s Growing a Language talk and his Scheme background. But maybe just mentioning Scheme is misleading here...
replies(1): >>41891495 #
8. Y_Y ◴[] No.41887668[source]
(Isn't lisp-baiting the raison d'être of hn?)

Since you mention it, Python does have a fairly elaborate metaclass system, but it seems like it's only really used for implementing the language and rarely if ever wielded by "users". I guess that's a reflection of the language ideology you're talking about.

Also for what it's worth, I know myself to be a dumb code monkey, but being in the CRUD gutter doesn't preclude me from looking at the metasyntactic stars.

9. klibertp ◴[] No.41887770{3}[source]
If you place `# coding: utf-8` on the first line of a Python script, it'll try to interpret the raw bytes contained later in the file by passing them through a relevant codec[1]. Since the codec receives the raw source and transforms it before any interpretation happens, you can (here's the point I'm starting to guess) supply a codec that parses the code, transforms the AST, and dumps it back to the source for execution. It would be similar to how "parse transforms" work in Erlang, though there you're handed AST and not bytes.

[1] https://docs.python.org/3/library/codecs.html

replies(1): >>41888833 #
10. JackC ◴[] No.41887778{3}[source]
The idea is you can register a custom file encoding, analogous to built-in file encodings like utf-8, and use it to transform the source file before python loads it. An example is pyxl, kind of like jsx, where you put `# coding: pyxl` at the top and then it will transform bare `<html>` in the python file into calls to a template builder: https://github.com/gvanrossum/pyxl3

Incidentally this turns out to be super hard to search for without asking an LLM, since "python coding" is so overloaded, and using the feature this way is intentionally undocumented because it's not really what it's for, and not something I think most python users really want to encourage. So, forbidden python knowledge!

replies(1): >>41887802 #
11. kevindamm ◴[] No.41887802{4}[source]
It's specified in PEP 263 [0] which pulls up easier on search if you quote it and include the typical "special comment symbol" -*- around it.

[0]: https://peps.python.org/pep-0263/

12. BiteCode_dev ◴[] No.41887841{3}[source]
Codecs (https://docs.python.org/3/library/codecs.html) can change the content of the file on the fly. You can abuse that to create new syntax, although it is evidently not the original intent.

Let's say you hate significative spaces, here is a (very fragile) PoC for your pain:

https://0bin.net/paste/42AQCTIC#dLEscW0rWQbE70cdnVCCiY72VuJw...

Import that into a *.pth file in your venv, and you can then do:

    # coding: braces_indent
 
    def main() {
        print("Hello, World!")
        if True {
            print("This is indented using braces.")
        }
    }
You also can use import hooks (python ideas does that), bytecode manipulations (pytest does that) or use the ctypes module (forbiddenfruit does that).

Still, I'm very happy it stays limited to super specific niches. Big power, big responsibilities, and all that.

13. pas ◴[] No.41887939[source]
That's probably an argument for a language with good DSL support.

When this comes up I usually link to the work of Alan Kay and others (the very mystical sounding STEPS project at VPRI)

""" The big breakthrough is making it easy to create new DSLs for any situation. Every area of the OS has its own language (and you can just add more if you feel the need) so that the whole OS including networking and GUI is very compact, understandable, and hackable. This particular project focused on compactness, just to prove that it is quantitatively more expressive. """

comment by sp332 https://news.ycombinator.com/item?id=11687952

final report from 2016 https://news.ycombinator.com/item?id=11686325

14. zahlman ◴[] No.41888833{4}[source]
>how "parse transforms" work in Erlang, though there you're handed AST and not bytes.

Oh, I didn't know about this. Was thinking about doing something similar in my own language, so I'll have to check that out.

15. radarsat1 ◴[] No.41888996[source]
Why would I want to extend the language syntax as part of normal execution?
16. klibertp ◴[] No.41891495{3}[source]
Thanks for bringing it up. I had a good read. I agree entirely with Steele! It's ironic, however, that it's written in the context of Java - he mentions just three features that would make Java growable: generics, operator overloading, and value types. We all know how it went: generics were added sometime later, but there's still no operator overloading, and value types came to the language 20 years after the talk :)