unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: ludo@gnu.org (Ludovic Courtès)
To: Alex Vong <alexvong1995@gmail.com>
Cc: 33215@debbugs.gnu.org
Subject: [bug#33215] [PATCH 05/11] guix: Add clojure-utils.
Date: Wed, 21 Nov 2018 23:12:12 +0100	[thread overview]
Message-ID: <878t1mqdvn.fsf@gnu.org> (raw)
In-Reply-To: <875zwq8pmd.fsf@gmail.com> (Alex Vong's message of "Wed, 21 Nov 2018 22:35:54 +0800")

Hi Alex,

Alex Vong <alexvong1995@gmail.com> skribis:

> ludo@gnu.org (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.

WDYT?

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,
Ludo’.

  reply	other threads:[~2018-11-21 22:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-31  6:02 [bug#33215] [PATCH 00/11] build-system: Add 'clojure-build-system' Alex Vong
2018-10-31  6:05 ` [bug#33215] [PATCH 01/11] gnu: clojure: Move from java to lisp Alex Vong
2018-10-31  6:06 ` [bug#33215] [PATCH 02/11] gnu: clojure: Remove 'remove-archives' snippet Alex Vong
2018-10-31  6:07 ` [bug#33215] [PATCH 03/11] gnu: clojure: Refactor to ensure there's a single list of libraries Alex Vong
2018-10-31  6:08 ` [bug#33215] [PATCH 04/11] gnu: clojure: Use (guix build java-utils) to simplify build phases Alex Vong
2018-10-31  6:09 ` [bug#33215] [PATCH 05/11] guix: Add clojure-utils Alex Vong
2018-11-20 21:55   ` Ludovic Courtès
2018-11-21 14:35     ` Alex Vong
2018-11-21 22:12       ` Ludovic Courtès [this message]
2018-10-31  6:10 ` [bug#33215] [PATCH 06/11] build-system: Add 'clojure-build-system' Alex Vong
2018-11-20 22:03   ` Ludovic Courtès
2018-10-31  6:11 ` [bug#33215] [PATCH 07/11] gnu: Add clojure-instaparse Alex Vong
2018-10-31  6:11 ` [bug#33215] [PATCH 08/11] gnu: Add clojure-core-match Alex Vong
2018-10-31  6:12 ` [bug#33215] [PATCH 09/11] gnu: Add clojure-algo-generic Alex Vong
2018-10-31  6:13 ` [bug#33215] [PATCH 10/11] gnu: Add clojure-tools-macro Alex Vong
2018-10-31  6:14 ` [bug#33215] [PATCH 11/11] gnu: Add clojure-algo-monads Alex Vong
2018-11-19 12:53 ` bug#33215: [PATCH 00/11] build-system: Add 'clojure-build-system' Danny Milosavljevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878t1mqdvn.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=33215@debbugs.gnu.org \
    --cc=alexvong1995@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).