[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best practices for processing s-expressions representing configurati

From: John Cowan
Subject: Re: Best practices for processing s-expressions representing configurations/DSLs
Date: 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>

> Hello,
> 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:
>     (package
>       (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 "";)
>       (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!

reply via email to

[Prev in Thread] Current Thread [Next in Thread]