GNU bug report logs - #63330
[PATCH 0/4] Functional programming? In my C++?! It's more likely than you think!

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
Cc: 63330 <at> debbugs.gnu.org
Subject: [bug#63330] [PATCH 0/4] Functional programming?  In my C++?! It's more likely than you think!
Date: Sun, 07 May 2023 13:10:56 -0400

Hi,

Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:

> Am Sonntag, dem 07.05.2023 um 11:34 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler <liliana.prikler <at> gmail.com> writes:
>> 
>> > * gnu/packages/cpp.scm (lager): New variable.
>> > ---
>> >  gnu/packages/cpp.scm | 32 ++++++++++++++++++++++++++++++++
>> >  1 file changed, 32 insertions(+)
>> > 
>> > diff --git a/gnu/packages/cpp.scm b/gnu/packages/cpp.scm
>> > index 0ab7d0785b..fe6a0edd31 100644
>> > --- a/gnu/packages/cpp.scm
>> > +++ b/gnu/packages/cpp.scm
>> > @@ -101,6 +101,7 @@ (define-module (gnu packages cpp)
>> >    #:use-module (gnu packages web)
>> >    #:use-module (gnu packages xml)
>> >    #:use-module (gnu packages xorg)
>> > +  #:autoload   (gnu packages serialization) (cereal)
>> >    #:use-module (ice-9 match))
>> 
>> Does autoload buys us something here?  Otherwise I'd stick with the
>> conventional use-module, to avoid future instances of cargo-culting
>> :-).
> It only frees us from the import cycle that would exist otherwise.

OK, that's a good reason to have it.

>> In my opinion, that's a direction that should be pursued in Guile
>> (autoloading modules by default when declarative modules (no side
>> effects allowed) are used) rather than in every Guile applications
>> out there.
> Not sure I understand what you're saying, nor the impact of it.

I meant that it'd be nice if Guile gave us lazy loading by default
instead of relying on humans to use #:autoload where it makes sense.

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.