guix-devel
[Top][All Lists]
Advanced

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

Re: Some macros to make package definitions prettier


From: Ludovic Courtès
Subject: Re: Some macros to make package definitions prettier
Date: Tue, 03 Mar 2015 21:44:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)

address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> I’ve applied it locally and will push shortly.
>
> It might be too late, but I have a nitpick on my macro: the implicit
> quoting of phase names 1. makes it impossible to provide them
> dynamically (e.g. procedure argument), 2. might give an illusion that
> they're sort of compile-time constants (like the 'delete', 'add-before',
> etc. tokens are).
>
> I guess it's fine since they are literal symbols in pretty much all
> cases (or really all cases) so far, but it bothered me so I wanted to
> share; it might be best to avoid such implicit-quoting in the future.

I actually agree.  Well, next round?

> Another nitpick would be that standards-compliant syntax-rules won't
> match the 'delete', 'replace', etc. literal tokens if they have a
> different binding during use than during definition of the macro.  (The
> identifier is matched by symbol name (i.e. "unhygienically") only if
> it's unbound during both definition and use.)  But I think this is
> really a problem in the Scheme standard, because this kind of macro is
> probably ubiquitous in Scheme code "in the wild."  (And psyntax usually
> does it the way we expect.)

In think Guile 2.1 is standards-compliant in that respect though.  A
related problem will be the ‘_’ procedure of (guix ui) that will need to
be renamed (which is annoying at worst, but OK.)  ‘delete’ might be more
of a problem.

> Regarding the automatic conversion, I'll look into your recommendation,
> and also ponder on a hand-baked solution in Guile or Elisp, but I wonder
> if it will be possible to cover all edge-cases, especially comments.  On
> the upside, we can auto-verify the results (sans comments and code
> formatting) by comparing package objects for equality before and after
> the transformation, since a use of 'modify-phases' should have the exact
> same result as the direct alist mangling...

Yes, but the package object contains quoted code, so we can’t directly
compare them for equality in this case.

That said, any problems would be easily spotted I guess.

Thanks,
Ludo’.



reply via email to

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