quasilyte

Does anyone know what data structure is that? I never seen anything like it, so I'm interested in learning how to call it. :)

Congrats with v1.0! I remember the times when it was called MangoDB. :D

You might be interested in https://github.com/mvdan/gogrep/issues/32#issuecomment-56866...

When gogrep becomes more usable as a library, it would be easier to write such Go programs easier.

As for the alternative formats, I experimented with JSON, TOML and some custom format that is even terser. It wasn't an easy choice, but I'm pretty comfortable with the result. That being said, there could be a several input formats in the future.

Mostly because plugins support in Go is not ideal and it still requires compilation (in plugin mode).

I believe Daniel Martí plans to make gogrep usable as a library, so it will be possible to write such Go programs in the future.

Features:

* Custom linting rules without re-compilation.

* Diagnostics are written in a declarative way.

* Quickfix action support.

* Powerful match filtering features, like expression type pattern matching.

Uses gogrep for AST pattern matching.

Planning to use this secret weapon on the next Go contributors workshop in Russia. :)

I've contributed https://go-review.googlesource.com/c/go/+/117615 thanks to appendCombine check. :3

With minor Emacs Lisp compiler patch (addition of %return, %goto and %label intrinsics), it is now possible to output Lisp that is optimal.

Possible implementation (about 20 lines of code): https://github.com/Quasilyte/goism/issues/57

Not sure if "defadvice" around "byte-compile-form" is acceptable for all users.

I see three main approaches for the tasks projects like ecaml and goism try to solve:

1. Use a plugin system (ecaml)

2. Transcompile to a target language (gosim and emscripten-like platforms)

3. Embed another VM inside Emacs and call its eval

There are many differences between these approaches and I am not sure one of them is objectively better as a general solution.

For the end users, all of these approaches can deliver good level of integration (they require different sets of tricks to achieve that).

It is technically possible, but optimal solution will require more than catch and throw (cl-lib uses them) Simple demonstration: https://pastebin.com/vXp0qPw3

Some S-expressions with `cl-return' can be rewritten to avoid the need of it (by the optimizer); not sure it covers 100% of the cases though.

I love Emacs Lisp.

Emacs has really good support for it which continues to improve over time.

But.. I love more than one language (and more than one Lisp for sure). Will you try to persuade me that I am wrong in that regard?

You can call map/reduce/filter from Go code: `xs := lisp.Mapcar(f, ys)`.

Mapconcat is already used inside runtime implementation: https://github.com/Quasilyte/goism/blob/master/src/emacs/rt/... (Print and Println functions).

Currently, no. Hope I get your question right..

Name mangling scheme preserves fully qualified package path. All goism sources live inside GOPATH (1), so nothing stops us from implementing a jump to Go definition.

For given `goism-foo/bar.baz` Emacs symbol, Go definition can be found in `GOPATH/src/foo/bar/` package. Exact location can be found by using existing Go tools (simple grep-like solution can work, too).

(1) It can change in future; see https://news.ycombinator.com/item?id=13368846 and even more relevant: https://github.com/golang/go/issues/17271

The potential damage can be reduced.

There can be a backend that generates Emacs Lisp code. Not necessary optimized or idiomatic, but it could be a good starting point for rewriting.

But in general, I agree with you.

Some optimizations are easier in Go than in Emacs Lisp, hence the potential quality of produced bytecode can be higher. For big packages that can be implemented in Go naturally (nearly without pain), this can be an advantage.

I found some optimizations that are not implemented inside Emacs lapcode optimizer. If I will port them to byte-opt everyone win, right (if they pass Emacs team review, of course)?

It is possible to emit Emacs Lisp instead of bytecode/lapcode. This was the first code generator target actually.

Easier to debug, simpler to trust (for the end user) and not that hard to generate.

The problem is that it is harder to implement some features of Go in terms of Emacs Lisp without going down to the virtual machine level. Best examples are arbitrary return statements (can be emulated by throw/catch) and goto.

I used Emacs Lisp for scripting tasks like code and data generation. It is great to have an ability to evaluate form right inside the spot you want results to be inserted. This kind of code does not require AST manipulations or macro.

Also, some of my projects that become bigger than 1000 LoC could benefit from static typing and (subjectively) better tooling.

By the way, I think extending Emacs in Racket would be great; just do not have an idea on how to implement that integration smoothly.