Thank you all for your answers, I think I got it right this time, but I
would still appreciate feedback:
https://gitlab.com/HiPhish/neovim.rkt/blob/master/nvim/api.rkt

I think what was confusing me was that I was thinking of Racket macros
like Common Lisp macros. Instead of trying to build a list that will be
the resulting S-expression I needed to build syntax objects.

> Neil Van Dyke wrote
> If you define a kind of domain-specific language (DSL) syntax
> extension in Racket for your Neovim API, your specification might then
> look like this (with the "..." filled in): 
Wouldn't making a DSL be overkill? Also, I don't have a choice in the
matter how the API data is stored, a hash table is what I receive. I do
not get the decide what the API is myself.

> BTW, consider making the `require` name be simply `neovim` or `nvim`,
> not `neovim/api` or `nvim/api`.  Or call the package `neovim-api`. 
The API is only a part of the library, there is also the "client"
(connecting to a Neovim instance) and the Racket "host" (allowing Neovim
plugins in Racket). I might later re-export the bindings from `nvim/api`
through `nvim`, I haven't decided on that yet.

> Also BTW, consider including the string "neovim" or "nvim" in the
> names of all provided identifiers of your API package, such as
> `neovim-command` instead of `command`.
Isn't this the sort of thing that should be handled by `prefix-in`? The
Common Lisp client prefixes `nvim:`
https://github.com/adolenc/cl-neovim/#neovims-api
https://github.com/adolenc/cl-neovim/blob/master/src/package.lisp#L26



> Philip McGrath wrote
> I guess my first question would be where does the hash table in
> nvim/api/specification.rkt come from, where else is it used, and is it
> necessary for the format to be what it currently is.
The hash table comes from Neovim. I can either send an RPC request (using
this library) or run `nvim --api-info` and read from Neovim's standard
output. The result is in the MessagePack format; MessagePack is similar
to JSON, except it's binary instead of text-based.
http://msgpack.org/

I wrote my own MessagePack library, and since the MessagePack standard
does not promise that keys of dictionaries need to be strings, only an
"object" I decided to unpack keys the way they are. I also use vectors
when unpacking MessagePack arrays because vectors are closer to what
arrays are than a linked list.



> Ryan Culpepper wrote
> IIUC, you are doing argument/result checking and conversion at run
> time.
No, I want to do everything at compile time. Your second code example is
what helped me to get it working, although I still don't quite
understand what `syntax-local-introduce` does and what the `#'here`
syntax object is supposed to be (I guess just some arbitrary syntax
object that's define right "here").

I'm not concerned with runtime type checks for now, I'll eventually port
the library to Typed Racket, then I'll just add the type annotations
above the function definition.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to