Re: Some macros to make package definitions prettier

["Thompson, David" <dthompson2@worcester.edu>]

On Wed, Feb 25, 2015 at 1:12 PM, Andreas Enge <andreas@enge.fr> wrote:
>
> On Wed, Feb 25, 2015 at 05:42:23PM +0100, Taylan Ulrich Bayırlı/Kammer wrote:
>>   (delete foo)
>>   (replace bar 'x)
>>   (add-before baz pre-baz 'y)) ;=> ((bar . x) (pre-baz . y) (baz . 2))
>> This has the following advantages:
>> - The order in which the phases are modified is top-down, where in our
>>   current style it's bottom-up which both distracts (IMO), and one may
>>   forget, as the chain grows and one forgets that it's indeed just a
>>   chain of function calls like (foo (bar (baz x))).
>> - Indentation doesn't keep growing as one adds more modifications.
>
> Actually, I do not like the imperative, non-functional style of these
> syntax rules. For me, they rather obscure what is happening.

It's still functional.  Should we not use 'cond' because it obscures
the series of nested 'if' expressions that it truly is?

> The indentation is just a question of style; in my first recipes, I did not
> indent consecutive modifications of phases, which was just as readable,
> I think (but this only works if you indent manually, and people disliked
> the unorthodox (non-)indentation).

Yeah, I'm not too into manual indenting to make a nested form look linear.

> The general drawback of such syntax rules is that newcomers do not see all
> the inner cogwheels of the system. So on one hand, one gains that contributing
> packages becomes easier; on the other hand, understanding what is actually
> happening becomes harder, and also learning scheme through guix becomes more
> difficult as we move to our own domain specific language.

It's a balancing act.  We can certainly go overboard with macros.
However, I think it's important to build up our packaging language to
be more expressive and declarative.  So, a macro to hide the nested
alist consing that we do constantly is appealing to me.

My 2 cents,

- Dave