3 ms·

So your point is that a Lisp that ships a JIT will help you implement a "copy-and-patch JIT" because "macros" and "code is data"? Let me point out that Go neit

So your point is that a Lisp that ships a JIT will help you implement a "copy-and-patch JIT" because "macros" and "code is data"? Let me point out that Go neither ships a JIT, nor has macros, so I really don't see how that's relevant insight for the Go ecosystem.

pjmlp 2y ago
Go has poor man's macros via //go:generate, and having a JIT available that is an implementation detail, e.g. Yaegi could support a JIT if they feel like it.
- ncruces 2y ago
  I know. But you're not running //go:generate at runtime, and for Yaegi to gain a JIT... well, they'd have to implement much of what's in the blog. That's the point. Mind you, I wouldn't mind having a something that translates Wasm to Go at compile time, and ship Go instead, for the cases where the Wasm doesn't change. But people also load Wasm at runtime, and for that to work, you need the (Wasm) compiler available at runtime, and there just aren't that many such compilers for the Go ecosystem.
- jerf 2y ago
  go:generate is not macro support. It is just the ability to specify a command to run in the source code when you run "go generate". Having been around this loop multiple times now with people, here is the source code for go:generate: https://github.com/golang/go/blob/master/src/cmd/go/internal/generate/generate.go#L497 https://github.com/golang/go/blob/master/src/cmd/go/internal... I've highlighted the line where it executes the given command. This is not aimed at you specifically, pjmlp, but anyone in general who would like to vigorously assert go generate really is a macro facility is invited to point me at even a single line that involves such a thing in the source code. The only slightly useful thing it does is on line 366, where it will set some conceivably useful environment variables for the command it runs. But otherwise, this is "go generate": You add: //go:generate echo hello! and when you type "go generate" in the shell, go runs "echo hello!" for you. That's it. While you could conceivably use it to generate macros, you will be bringing 100% of the macro execution code to go generate; it provides no help. The closest thing Go has to built-in macro support is that it does ship with full AST parsing, some code built on top of that, and it can re-emit code based on your changes. (I don't target this at you pjmlp because I'm pretty sure from previous interactions you are not a Go programmer, and a disturbingly large portion of the Go community itself vigorously and emotionally believes that go generate is a macro generation facility, so how were you to know? People seem to have a very, very hard idea with a feature being labelled "generate" that in fact generates nothing.)
  - pjmlp 2y ago
    No issues, that is also why I stated "poor man's", so it is even poorer than I imagined, :)
    - mseepgood 2y ago
      It's not "poor man's", it's simply a completely different thing and as such not comparable and irrelevant to this topic. It's not run at runtime, it's not run at build time, it's run at development time before commit. It's like saying a house is a poor man's apple.
      - pjmlp 2y ago
        [flagged]
        jerf 2y ago
        I do not have a second account. I don't know what "it" is in that comment; I fear "it" is still some sort of macro capability, which doesn't exist, at dev time, compile time, run time, or otherwise. Like I said, the idea that "go generate" is some sort of macro language other than a thin wrapper around a command to run is very common. I suppose it would be interesting to try to get people to describe this macro language that supposedly exists. What's the macro look like to transparently wrap a string in a print statement for debugging?
        pjmlp 2y ago
        No worries, I knew that, it was more a jab to those kind of remarks that don't help anyone. Sorry if you got annoyed with your reference.
        ncruces 2y ago
        I guess the meta programming that most often gets used with //go:generate ends up being text/template. The Go sort algorithm (pdqsort) is implemented in this way so the same algorithm can be used to implement the various existing sort APIs. https://github.com/golang/go/blob/master/src/sort/gen_sort_variants.go https://github.com/golang/go/blob/master/src/sort/gen_sort_v...
a-french-anon 2y ago
CL compilers aren't really JIT, they're AOT with user access to the compiler; yes, I know the distinction is blurry in this specific case (https://news.ycombinator.com/item?id=24387664 https://news.ycombinator.com/item?id=24387664). Macros and homoiconicity have absolutely nothing to do with my example. The fact is that go provides a compiler, so it should allow one to embed it in the final binary to use it at runtime.

pjmlp 2y ago

Go has poor man's macros via //go:generate, and having a JIT available that is an implementation detail, e.g. Yaegi could support a JIT if they feel like it.

ncruces 2y ago
I know. But you're not running //go:generate at runtime, and for Yaegi to gain a JIT... well, they'd have to implement much of what's in the blog. That's the point. Mind you, I wouldn't mind having a something that translates Wasm to Go at compile time, and ship Go instead, for the cases where the Wasm doesn't change. But people also load Wasm at runtime, and for that to work, you need the (Wasm) compiler available at runtime, and there just aren't that many such compilers for the Go ecosystem.
jerf 2y ago
go:generate is not macro support. It is just the ability to specify a command to run in the source code when you run "go generate". Having been around this loop multiple times now with people, here is the source code for go:generate: https://github.com/golang/go/blob/master/src/cmd/go/internal/generate/generate.go#L497 https://github.com/golang/go/blob/master/src/cmd/go/internal... I've highlighted the line where it executes the given command. This is not aimed at you specifically, pjmlp, but anyone in general who would like to vigorously assert go generate really is a macro facility is invited to point me at even a single line that involves such a thing in the source code. The only slightly useful thing it does is on line 366, where it will set some conceivably useful environment variables for the command it runs. But otherwise, this is "go generate": You add: //go:generate echo hello! and when you type "go generate" in the shell, go runs "echo hello!" for you. That's it. While you could conceivably use it to generate macros, you will be bringing 100% of the macro execution code to go generate; it provides no help. The closest thing Go has to built-in macro support is that it does ship with full AST parsing, some code built on top of that, and it can re-emit code based on your changes. (I don't target this at you pjmlp because I'm pretty sure from previous interactions you are not a Go programmer, and a disturbingly large portion of the Go community itself vigorously and emotionally believes that go generate is a macro generation facility, so how were you to know? People seem to have a very, very hard idea with a feature being labelled "generate" that in fact generates nothing.)
- pjmlp 2y ago
  No issues, that is also why I stated "poor man's", so it is even poorer than I imagined, :)
  - mseepgood 2y ago
    It's not "poor man's", it's simply a completely different thing and as such not comparable and irrelevant to this topic. It's not run at runtime, it's not run at build time, it's run at development time before commit. It's like saying a house is a poor man's apple.
    - pjmlp 2y ago
      [flagged]
      - jerf 2y ago
        I do not have a second account. I don't know what "it" is in that comment; I fear "it" is still some sort of macro capability, which doesn't exist, at dev time, compile time, run time, or otherwise. Like I said, the idea that "go generate" is some sort of macro language other than a thin wrapper around a command to run is very common. I suppose it would be interesting to try to get people to describe this macro language that supposedly exists. What's the macro look like to transparently wrap a string in a print statement for debugging?
        pjmlp 2y ago
        No worries, I knew that, it was more a jab to those kind of remarks that don't help anyone. Sorry if you got annoyed with your reference.
        ncruces 2y ago
        I guess the meta programming that most often gets used with //go:generate ends up being text/template. The Go sort algorithm (pdqsort) is implemented in this way so the same algorithm can be used to implement the various existing sort APIs. https://github.com/golang/go/blob/master/src/sort/gen_sort_variants.go https://github.com/golang/go/blob/master/src/sort/gen_sort_v...

a-french-anon 2y ago

CL compilers aren't really JIT, they're AOT with user access to the compiler; yes, I know the distinction is blurry in this specific case (https://news.ycombinator.com/item?id=24387664 https://news.ycombinator.com/item?id=24387664). Macros and homoiconicity have absolutely nothing to do with my example. The fact is that go provides a compiler, so it should allow one to embed it in the final binary to use it at runtime.