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. For example, the first thing that jumped out at me is that you're using strings for all the hash keys rather than symbols, which prevents you from using a (faster) hasheq. Also, it is strange to me that functions is a vector and not a list. But it would probably make even more sense to use structs for many of these things, unless it needs to be `read`-able or convertible to json or something.
-Philip On Tue, Aug 22, 2017 at 5:06 PM, Neil Van Dyke <n...@neilvandyke.org> wrote: > hiph...@openmailbox.org wrote on 08/22/2017 05:29 PM: > >> So far it looks good, but I am stuck on macros. There is a hash table >> which serves as a specification for which functions to generate, it is >> stored in the file 'nvim/api/specification.rkt'. This table has the key" >> functions" which contains a vector of more hash tables. >> > > You *can* go from hashes at syntax expansion time to syntax, but, in this > case, I think there are ways that are more idiomatic and (once you're > comfortable with syntax extension) easier... > > 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): > > (define-and-provide-neovim-api > (version ...) > (error-types ...) > (types ...) > (functions ...) > (ui-events ...)) > > Or: > > (define-and-provide-neovim-api > #:version ... > #:error-types ... > #:types ...) > #:functions ... > #:ui-events ...) > > Then you implement your `define-and-provide-neovim-api` syntax > transformer using `syntax-case` or `syntax-parse`. (When you're > implementing this, it sometimes (not always) helps to type an example use > of your syntax, then type an example of what syntax you would like that to > expand to, and then rework those two examples into your `syntax-case` or > `syntax-parse` form.) > > Or, a somewhat different way is to have separate definition forms in > Racket for each element of the API, such as: > > (define neovim-foo (neovim-api-lambda ...)) > (provide neovim-foo) > > Or: > > (define-and-provide-neovim-procedure neovim-foo ...) > > BTW, consider making the `require` name be simply `neovim` or `nvim`, not > `neovim/api` or `nvim/api`. Or call the package `neovim-api`. > > 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`. (For example, I included "roomba" in every name in " > http://www.neilvandyke.org/racket/roomba/";.) This is not a rule, just > something to consider. Personally, I would probably make it > `neovim-command` in the API library that can be used from `#lang racket`, > and then, someday, I have the option of making a `#lang neovim` that (among > doing other things) provides that procedure simply as `command` rather than > `neovim-command`. > > > -- > 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. > -- 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.
