[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Best practices for processing s-expressions representing configurati
Re: Best practices for processing s-expressions representing configurations/DSLs
Mon, 17 Dec 2018 16:35:39 -0500
Definitely you should view it as data. Think more than twice (indeed, more
than 200 times) before you evaluate s-expressions coming from outside.
"Eval is spelled E-V-I-L".
On Mon, Dec 17, 2018 at 4:03 PM Stephen Scheck <address@hidden>
> I'm very new to Guile/Scheme/Lisp programming (but love the concise,
> minimalist syntax!), so please bear with what may be some obvious answers.
> When representing application configurations or DSLs as s-expressions, what
> are common or best strategies for processing them? For example, here's an
> excerpt I found of the Guix package definition DSL to study as a prototype:
> (name "hello")
> (version "2.10")
> (build-system gnu-build-system)
> (arguments '(#:configure-flags '("--enable-silent-rules")))
> (inputs `(("gawk" ,gawk)))
> (synopsis "Hello, GNU world: An example GNU package")
> (description "Guess what GNU Hello prints!")
> (home-page "http://www.gnu.org/software/hello/")
> (license gpl3+))
> Would this just be executed directly within the equivalent of a regular
> Guile REPL (with the Guix extensions loaded, of course) ? Is each "key"
> (e.g. "name" or "build-system") just a function call? Or would it be better
> to slurp the whole s-expr in as a quoted, unevaluated structure, and
> iterate through its various sub-components, using conditionals to match the
> various keys and processing as necessary? I.e. would it be more typical to
> view the structure as just data, an arbitrarily nested list structure, with
> separate code to process it, or as code itself? Oh homoiconicity, it is a
> slippery notion!