Re: Generate function defintions at compile time

[email protected] wrote on 08/23/2017 06:56 PM:

> Wouldn't making a DSL be overkill?

No.  In Racket, a DSL (aka minilanguage, syntax extensions, or macros) 
can be a very small implementation effort that does exactly what one 
wants, in a very maintainable way.

> Also, I don't have a choice in the matter how the API data is stored, a hash table is what I receive.

You're already running contrived Racket code to generate the hash syntax 
that you paste into the source file.  So you can alternatively paste 
slightly different contrived syntax, if that gives you an advantage.  
(Initially, because you happened to paste a Racket hash syntax into that 
file, you were making your life a lot harder than it needed to be.)

> 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.

This is getting into reuse ecology questions.  For now, you might just 
ask yourself whether this all needs to be in one package.  And, if 
multiple packages, just use the respective package name as the reusable 
`require` name.

> Isn't this the sort of thing that should be handled by `prefix-in`?

`prefix-in` is an old kludge for an old idea that, AFAIK, is no longer 
considered as good an idea as it used to be.  I recommend trying to make 
usually-unique identifiers like I said, and save the generic terms for 
custom `#lang`.

> 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.

I'm sure you have your reasons for wanting to compile-in what Neovim 
seems to want to be dynamic info.  Such as startup performance, or the 
ability to later add annotations for semantics missing in the API 
encoding that Neovim emits.

Eventually, perhaps you'll want your Racket API interface to check at 
runtime against the Neovim process what API it supports, and perhaps 
enable/disable/change bits of your Racket API interface. You might end 
up adding annotations to your DSL, or paste multiple versions of the 
Neovim APIs into that one file, and tweak your DSL's syntax transformers 
to generate more sophisticated code.

-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/[email protected]
For more options, visit https://groups.google.com/d/optout.