[Top][All Lists]

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

[bug#33215] [PATCH 05/11] guix: Add clojure-utils.

From: Ludovic Courtès
Subject: [bug#33215] [PATCH 05/11] guix: Add clojure-utils.
Date: Wed, 21 Nov 2018 23:12:12 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Hi Alex,

Alex Vong <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:


>>> +(define-syntax-rule (define-with-docs name docs val)
>>> +  "Create top-level variable named NAME with doc string DOCS and value 
>>> VAL."
>>> +  (begin (define name val)
>>> +         (set-object-property! name 'documentation docs)))
>> This is not necessarily a bad idea, but in general I’m very much in
>> favor of consistency: since we don’t use this anywhere else, I’d rather
>> not have it here either.  We could discuss it separately, but IMO it
>> shouldn’t be buried in a Clojure patch.
>> Thus I’d be in favor of using the same style in this file as in the rest
>> of Guix.
>> WDYT?
> No problem, I am happy to replace the doc string by a comment
> instead. IMO, providing doc string for variables in addition to
> procedures is more consistent [in a different way :)] since a procedure
> is just a special kind of variable. For example, 'defvar' in Emacs
> allows one to specify a doc string.

Yeah, that’s why I think it’s not necessarily a bad idea in itself, it’s
just something we don’t currently do in Guile Scheme.  :-)

> Besides, I thought it is okay to use custom syntactic form within a
> module (as long as it doesn't break other's code). However, I can see
> that the way I use it can be confusing since everyone are used to
> defining variable via 'define'. Is this what you have in mind when you
> wrote that you are in favor of consistency?

Yes, I think it makes it easier for people to find their way in the code
base and get started hacking it if it has somewhat consistent
conventions.  Of course coding style may vary a bit from module to
module and that’s fine, but overall I think we should try to use the
same “base language” so to speak.


Having said that, I realize I was probably too grumpy when I wrote this,
and I didn’t mention the main point, which is that this Clojure build
system looks really nice to me!  It’ll surely make it easier to add more
Clojure packages—now all we need is an importer to make that even
smoother.  :-)

Thank you,

reply via email to

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