GNU bug report logs - #30237
Generalizing ‘and=>’

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guile; Reported by: Mathieu Lirzin <mthl@HIDDEN>; dated Wed, 24 Jan 2018 12:11:01 UTC; Maintainer for guile is bug-guile@HIDDEN.

Message received at 30237 <at> debbugs.gnu.org:


Received: (at 30237) by debbugs.gnu.org; 31 Jan 2018 14:23:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 31 09:23:56 2018
Received: from localhost ([127.0.0.1]:50433 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1egtIp-0003js-TQ
	for submit <at> debbugs.gnu.org; Wed, 31 Jan 2018 09:23:56 -0500
Received: from eggs.gnu.org ([208.118.235.92]:53897)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mthl@HIDDEN>) id 1egtIn-0003jY-Bi
 for 30237 <at> debbugs.gnu.org; Wed, 31 Jan 2018 09:23:54 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mthl@HIDDEN>) id 1egtIg-0003cc-U6
 for 30237 <at> debbugs.gnu.org; Wed, 31 Jan 2018 09:23:48 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53017)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <mthl@HIDDEN>)
 id 1egtIg-0003cW-QP; Wed, 31 Jan 2018 09:23:46 -0500
Received: from [2a01:e35:2ec2:e580:7d5f:f616:fc6f:3970] (port=39932 helo=godel)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <mthl@HIDDEN>)
 id 1egtIg-0006Uz-3Z; Wed, 31 Jan 2018 09:23:46 -0500
From: Mathieu Lirzin <mthl@HIDDEN>
To: Mark H Weaver <mhw@HIDDEN>
Subject: Re: bug#30237: Generalizing =?utf-8?B?4oCYYW5kPT7igJk=?=
References: <877es731ar.fsf@HIDDEN> <877es7ti5j.fsf@HIDDEN>
 <87y3kn10li.fsf@HIDDEN> <87shamvebr.fsf@HIDDEN>
Date: Wed, 31 Jan 2018 15:23:43 +0100
In-Reply-To: <87shamvebr.fsf@HIDDEN> (Mark H. Weaver's message of "Tue, 30
 Jan 2018 23:31:52 -0500")
Message-ID: <87shamm7io.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30237
Cc: 30237 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Mark H Weaver <mhw@HIDDEN> writes:

> This generalization will inevitably slow it down, and it's not clear
> that this is useful in practice.  It's also not particularly natural,
> because these return value(s) somehow need to be interpreted as a
> boolean.  There are multiple ways to do that, and it's not clear which
> is the best way.
>
> I think we should resist the temptation to make simple things more
> complicated without good reason.  Making things more complicated always
> has a cost.  I'm a big believer in keeping things simple, especially the
> widely used primitive operations.

Generalizing the arity of things tends to make them more =E2=80=9Csimple=E2=
=80=9D for
example thinking of =E2=80=98+=E2=80=99 as an arbitrary arity function inst=
ead of a
binary operator is simpler.

I am realizing that In this case, the semantics are indeed unclear for
multiple values.  For example if multiple values were to be handled then
=E2=80=98(and=3D> (values 1 2) list)=E2=80=99 should work in the first plac=
e.  Moreover as
you pointed what should be done regarding the truthiness of multiple
values is not clear either.  As a consequence I withdraw my proposition
to generalize =E2=80=98and=3D>=E2=80=99 to multiple values.

Having said that I think the implementation you previously proposed
(without the arity 0 case) keep things simple:

  (define and=3D>
    (case-lambda
      ((val proc) (and val (proc val)))
      ((val . procs)
       (let loop ((val val) (procs procs))
         (if (null? procs)
             val
             (and val (loop ((car procs) val)
                            (cdr procs))))))))

> Finally, there still some question in my mind whether this
> generalization would be useful in practice.  Have you found a
> real-world use case where this generalized 'and=3D>' makes life easier?

I took some time to think about a pseudo-realistic use case.  Consider
some configuration variables that are set from the process environment.
We want to check and transform what the user provides with some slight
variations for each variable:

  ;;; Higher-order utilities.

  (define (ensure pred)
    (lambda (val)
      (and (pred val) val)))

  (define (check pred msg)
    (lambda (val)
      (unless (pred val)
        (display msg))
      val))

  ;;; Process and check variables (unrealistic but give an idea).

  (define (split-path str)
    (string-split str #\:))

  (define (no-empty-strings? lst)
    (not (any (lambda (str) (string=3D? "" str)) lst)))

  (define (keep-existing-files lst)
    (filter file-exists? lst))

  (define (warn-deprecated-path lst)
    (when (any (lambda (string-suffix? "/old-bar")))
       (display "Please don't refer to \"old-bar\" for XYZ reason")))

  ;;; Global variables.

  (define %foo
    ;; Apply procedures in a pipeline fashion...
    (and=3D> (and=3D> (and=3D> (and=3D> (getenv "FOO") split-path)
                         (ensure no-empty-strings?))
                  keep-existing-files)
           (ensure pair?)))

  (define %bar
    ;; ...or with more idiomatic procedure calls.
    (let ((lst (split-path (or (getenv "BAR")
                               "/etc/bar:/usr/share/bar"))))
      (when (no-empty-strings? lst)
        (warn-deprecated-path lst)
        lst)))

Handling arbitrary arities would allow rewriting those variables in a
more elegant way:

  (define %foo
    (and=3D> (getenv "FOO")
           split-path
           (ensure no-empty-strings?)
           keep-existing-files
           (ensure pair?)))

  (define (no-deprecated-dirs? lst)
    (not (any (lambda (str) (string-suffix? "/old-bar" str)) lst)))

  (define %bar
    (and=3D> (or (getenv "BAR") "/etc/bar:/usr/share/bar")
           split-path
           (ensure no-empty-strings?)
           (check no-deprecated-dirs?
                  "Please don't refer to \"old-bar\" for XYZ reason")))

=E2=80=98and-let*=E2=80=99 would be a reasonable alternative but the benefi=
t of this
form is that it favours the use of higher-order procedures in place of
special syntax.

WDYT?

--=20
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-guile@HIDDEN:
bug#30237; Package guile. Full text available.

Message received at 30237 <at> debbugs.gnu.org:


Received: (at 30237) by debbugs.gnu.org; 31 Jan 2018 04:32:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 30 23:32:37 2018
Received: from localhost ([127.0.0.1]:50176 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1egk4b-0006tk-2r
	for submit <at> debbugs.gnu.org; Tue, 30 Jan 2018 23:32:37 -0500
Received: from world.peace.net ([50.252.239.5]:51314)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1egk4Z-0006tS-H0
 for 30237 <at> debbugs.gnu.org; Tue, 30 Jan 2018 23:32:35 -0500
Received: from pool-72-93-27-251.bstnma.east.verizon.net ([72.93.27.251]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1egk4T-0001us-E1; Tue, 30 Jan 2018 23:32:29 -0500
From: Mark H Weaver <mhw@HIDDEN>
To: Mathieu Lirzin <mthl@HIDDEN>
Subject: Re: bug#30237: Generalizing =?utf-8?B?4oCYYW5kPT7igJk=?=
References: <877es731ar.fsf@HIDDEN> <877es7ti5j.fsf@HIDDEN>
 <87y3kn10li.fsf@HIDDEN>
Date: Tue, 30 Jan 2018 23:31:52 -0500
In-Reply-To: <87y3kn10li.fsf@HIDDEN> (Mathieu Lirzin's message of "Wed, 24
 Jan 2018 21:08:25 +0100")
Message-ID: <87shamvebr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 30237
Cc: 30237 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Mathieu Lirzin <mthl@HIDDEN> writes:

> IMO It would be nice if multiple values
> were handled too.  here is one solution inspired by =E2=80=98compose=E2=
=80=99.
>
> (define and=3D>
>   (case-lambda
>     ((val proc) (and val (proc val)))
>     ((val proc . procs)
>      (let loop ((p proc) (ps procs))
>        (if (null? ps)
> 	   (p val)
> 	   (loop (lambda args
> 		   (call-with-values (lambda () (apply p args))
> 		     (lambda (arg0 . args*)
> 		       (and arg0 (apply (car ps) arg0 args*)))))
> 		 (cdr ps)))))))

This generalization will inevitably slow it down, and it's not clear
that this is useful in practice.  It's also not particularly natural,
because these return value(s) somehow need to be interpreted as a
boolean.  There are multiple ways to do that, and it's not clear which
is the best way.

I think we should resist the temptation to make simple things more
complicated without good reason.  Making things more complicated always
has a cost.  I'm a big believer in keeping things simple, especially the
widely used primitive operations.

Thoughts?

      Mark




Information forwarded to bug-guile@HIDDEN:
bug#30237; Package guile. Full text available.

Message received at 30237 <at> debbugs.gnu.org:


Received: (at 30237) by debbugs.gnu.org; 24 Jan 2018 20:08:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 24 15:08:39 2018
Received: from localhost ([127.0.0.1]:41338 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eeRLa-00018e-VS
	for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 15:08:39 -0500
Received: from eggs.gnu.org ([208.118.235.92]:44012)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mthl@HIDDEN>) id 1eeRLY-00018R-RY
 for 30237 <at> debbugs.gnu.org; Wed, 24 Jan 2018 15:08:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mthl@HIDDEN>) id 1eeRLS-0000X5-36
 for 30237 <at> debbugs.gnu.org; Wed, 24 Jan 2018 15:08:31 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54479)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <mthl@HIDDEN>)
 id 1eeRLR-0000X0-Uq; Wed, 24 Jan 2018 15:08:30 -0500
Received: from [2a01:e35:2ec2:e580:7d5f:f616:fc6f:3970] (port=47266 helo=godel)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <mthl@HIDDEN>)
 id 1eeRLR-0001MB-9l; Wed, 24 Jan 2018 15:08:29 -0500
From: Mathieu Lirzin <mthl@HIDDEN>
To: Mark H Weaver <mhw@HIDDEN>
Subject: Re: bug#30237: Generalizing =?utf-8?B?4oCYYW5kPT7igJk=?=
References: <877es731ar.fsf@HIDDEN> <877es7ti5j.fsf@HIDDEN>
Date: Wed, 24 Jan 2018 21:08:25 +0100
In-Reply-To: <877es7ti5j.fsf@HIDDEN> (Mark H. Weaver's message of "Wed, 24
 Jan 2018 10:01:44 -0500")
Message-ID: <87y3kn10li.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: 30237
Cc: 30237 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Hello Mark,

Mark H Weaver <mhw@HIDDEN> writes:

> Mathieu Lirzin <mthl@HIDDEN> writes:
>
>> Here is a proposal for generalizing =E2=80=98and=3D>=E2=80=99 to a pipel=
ine of procedures.
>> It acts like a =E2=80=9Cbind=E2=80=9D operator in an ad-hoc =E2=80=9CMay=
be=E2=80=9D monad which uses #f
>> to represent the absence of value.  Not sure if it is useful in
>> practice, but it feels like a natural generalization.
>>
>> The current definition is the following:
>>
>>   (define (and=3D> value procedure)
>>     (and value (procedure value)))
>>
>> Here is my proposition:
>>
>>   (define-syntax and=3D>
>>     (syntax-rules ()
>>       ((_) #t)
>>       ((_ val) val)
>>       ((_ val proc)
>>        (and val (proc val)))
>>       ((_ val proc proc* ...)
>>        (and=3D> (and val (proc val)) proc* ...))))
>
> Be careful, macros are different than procedures!  Instead of binding
> values to variables, they bind _unevaluated_ forms to pattern variables.
> So 'val' is a misleading name for the first operand of the macro above.
> In fact, what's being bound there is an _expression_, and you are then
> expanding this into something that contains two copies of that
> expression.  So, for example:
>
>   (and=3D> (compile-webkitgtk)
>          test
>          install)
>
> expands into:
>
>   (and=3D> (and (compile-webkitgtk)
>               (test (compile-webkitgtk)))
>          install)
>
> which expands into:
>
>   (and (and (compile-webkitgtk)
>             (test (compile-webkitgtk)))
>        (install (and (compile-webkitgtk)
>                      (test (compile-webkitgtk)))))
>
> So you end up compiling webkitgtk 4 times, and testing it twice, before
> finally installing it.  More generally, if you pass N+1 operands, the
> first operand will be evaluated 2^N times.

Indeed I overlooked that.

> The other problem is that 'and=3D>' is currently a procedure, and you're
> replacing it with a macro.  There are a couple of issues with this.  One
> is that procedures are first-class objects in Scheme, but macros aren't.
> Procedures can be passed as arguments to procedures, stored in data
> structures, etc, but macros cannot.
>
> For example, if 'and=3D>' is a procedure, you can write:
>
>   (map and=3D> vals procs)
>
> but you can't do this if 'and=3D>' is a macro.
>
> The other problem with changing 'and=3D>' to a macro is that this
> effectively changes the ABI of Guile, which we can't do within a stable
> release series (2.2.x).  Existing .go files that use 'and=3D>' were
> compiled to generate a normal procedure call for 'and=3D>', and if that
> procedure no longer exists then the code will break.  This change
> requires all users of 'and=3D>' to be recompiled.

I initially implemented it as a procedure but move to the macro side of
thing in an attempt to generate more efficient code while handling
procedures that return multiple values.  But this can't work given the
issue you described above.

>> Let me know if such change is welcome or not, so I can provide a
>> complete patch including documentation.
>
> I think it's worth considering something along these lines for the
> 'master' branch which will eventually become Guile 3, although in order
> to support existing callers that expect 'and=3D>' to be a first-class
> procedure, we might want to arrange for a bare 'and=3D>' to expand into a
> reference to a first-class procedure that does the same job, similar to
> what we do with 'define-inlinable'.

I don't think making it a macro worths the breaking change.

> The other option would be to implement your enhanced 'and=3D>' as a normal
> procedure using case-lambda, maybe something like this:
>
>   (define and=3D>
>     (case-lambda
>       ((val proc) (and val (proc val)))
>       ((val . procs)
>        (let loop ((val val) (procs procs))
>          (if (null? procs)
>              val
>              (and val (loop ((car procs) val)
>                             (cdr procs))))))
>       (() #t)))
>
> The first case is not strictly needed, but is included as an
> optimization to avoid heap-allocating a list for the 'procs' rest
> argument in the common case of two arguments.
>
> The second case is implemented as a loop instead of a recursive call to
> 'and=3D>', to prevent repeatedly heap-allocating the rest list on each
> iteration, which would lead to O(N^2) allocations for N arguments.  It
> would be nicer to use 'match' here, but since 'and=3D>' is defined early
> in boot-9.scm, we must restrict ourselves to core functionality in its
> implementation.

That's a clear explanation.  IMO It would be nice if multiple values
were handled too.  here is one solution inspired by =E2=80=98compose=E2=80=
=99.

(define and=3D>
  (case-lambda
    ((val proc) (and val (proc val)))
    ((val proc . procs)
     (let loop ((p proc) (ps procs))
       (if (null? ps)
	   (p val)
	   (loop (lambda args
		   (call-with-values (lambda () (apply p args))
		     (lambda (arg0 . args*)
		       (and arg0 (apply (car ps) arg0 args*)))))
		 (cdr ps)))))))

I am not sure if there is a way to avoid constructing the composition of
functions.

> I'm not sure if it makes sense to include the final (nullary) case.
> Unlike 'and', 'or', '+', '*' and similar operations where every argument
> is treated uniformally, in this case the first argument is qualitatively
> different than the others.  Therefore, it seems to me that this
> procedure naturally generalizes down to 1 argument, but no further.

I don't think so, I defined it only because I took inspiration from
=E2=80=98and=E2=80=99.

> Finally, there still some question in my mind whether this
> generalization would be useful in practice.  Have you found a real-world
> use case where this generalized 'and=3D>' makes life easier?

Not really.  :-)

> Do you know about SRFI-2 (and-let*)?  How would that work for your use
> case?

Yes I know about =E2=80=98and-let*=E2=80=99 which is a proper way to do pip=
elining while
checking for #f.  My motivation for extending =E2=80=98and=3D>=E2=80=99 was=
 to have
something similar but without the special syntax.

Thanks for the in-depth review.

--=20
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Information forwarded to bug-guile@HIDDEN:
bug#30237; Package guile. Full text available.

Message received at 30237 <at> debbugs.gnu.org:


Received: (at 30237) by debbugs.gnu.org; 24 Jan 2018 15:02:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 24 10:02:23 2018
Received: from localhost ([127.0.0.1]:41198 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eeMZD-0000gZ-Ch
	for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 10:02:23 -0500
Received: from world.peace.net ([50.252.239.5]:60798)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mhw@HIDDEN>) id 1eeMZB-0000gL-9u
 for 30237 <at> debbugs.gnu.org; Wed, 24 Jan 2018 10:02:21 -0500
Received: from pool-72-93-27-251.bstnma.east.verizon.net ([72.93.27.251]
 helo=jojen)
 by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.89) (envelope-from <mhw@HIDDEN>)
 id 1eeMZ5-0004T5-3b; Wed, 24 Jan 2018 10:02:15 -0500
From: Mark H Weaver <mhw@HIDDEN>
To: Mathieu Lirzin <mthl@HIDDEN>
Subject: Re: bug#30237: Generalizing =?utf-8?B?4oCYYW5kPT7igJk=?=
References: <877es731ar.fsf@HIDDEN>
Date: Wed, 24 Jan 2018 10:01:44 -0500
In-Reply-To: <877es731ar.fsf@HIDDEN> (Mathieu Lirzin's message of "Wed, 24
 Jan 2018 13:10:20 +0100")
Message-ID: <877es7ti5j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 30237
Cc: 30237 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

Hi Mathieu,

Mathieu Lirzin <mthl@HIDDEN> writes:

> Here is a proposal for generalizing =E2=80=98and=3D>=E2=80=99 to a pipeli=
ne of procedures.
> It acts like a =E2=80=9Cbind=E2=80=9D operator in an ad-hoc =E2=80=9CMayb=
e=E2=80=9D monad which uses #f
> to represent the absence of value.  Not sure if it is useful in
> practice, but it feels like a natural generalization.
>
> The current definition is the following:
>
>   (define (and=3D> value procedure)
>     (and value (procedure value)))
>
> Here is my proposition:
>
>   (define-syntax and=3D>
>     (syntax-rules ()
>       ((_) #t)
>       ((_ val) val)
>       ((_ val proc)
>        (and val (proc val)))
>       ((_ val proc proc* ...)
>        (and=3D> (and val (proc val)) proc* ...))))

Be careful, macros are different than procedures!  Instead of binding
values to variables, they bind _unevaluated_ forms to pattern variables.
So 'val' is a misleading name for the first operand of the macro above.
In fact, what's being bound there is an _expression_, and you are then
expanding this into something that contains two copies of that
expression.  So, for example:

  (and=3D> (compile-webkitgtk)
         test
         install)

expands into:

  (and=3D> (and (compile-webkitgtk)
              (test (compile-webkitgtk)))
         install)

which expands into:

  (and (and (compile-webkitgtk)
            (test (compile-webkitgtk)))
       (install (and (compile-webkitgtk)
                     (test (compile-webkitgtk)))))

So you end up compiling webkitgtk 4 times, and testing it twice, before
finally installing it.  More generally, if you pass N+1 operands, the
first operand will be evaluated 2^N times.

The other problem is that 'and=3D>' is currently a procedure, and you're
replacing it with a macro.  There are a couple of issues with this.  One
is that procedures are first-class objects in Scheme, but macros aren't.
Procedures can be passed as arguments to procedures, stored in data
structures, etc, but macros cannot.

For example, if 'and=3D>' is a procedure, you can write:

  (map and=3D> vals procs)

but you can't do this if 'and=3D>' is a macro.

The other problem with changing 'and=3D>' to a macro is that this
effectively changes the ABI of Guile, which we can't do within a stable
release series (2.2.x).  Existing .go files that use 'and=3D>' were
compiled to generate a normal procedure call for 'and=3D>', and if that
procedure no longer exists then the code will break.  This change
requires all users of 'and=3D>' to be recompiled.

> Let me know if such change is welcome or not, so I can provide a
> complete patch including documentation.

I think it's worth considering something along these lines for the
'master' branch which will eventually become Guile 3, although in order
to support existing callers that expect 'and=3D>' to be a first-class
procedure, we might want to arrange for a bare 'and=3D>' to expand into a
reference to a first-class procedure that does the same job, similar to
what we do with 'define-inlinable'.

The other option would be to implement your enhanced 'and=3D>' as a normal
procedure using case-lambda, maybe something like this:

  (define and=3D>
    (case-lambda
      ((val proc) (and val (proc val)))
      ((val . procs)
       (let loop ((val val) (procs procs))
         (if (null? procs)
             val
             (and val (loop ((car procs) val)
                            (cdr procs))))))
      (() #t)))

The first case is not strictly needed, but is included as an
optimization to avoid heap-allocating a list for the 'procs' rest
argument in the common case of two arguments.

The second case is implemented as a loop instead of a recursive call to
'and=3D>', to prevent repeatedly heap-allocating the rest list on each
iteration, which would lead to O(N^2) allocations for N arguments.  It
would be nicer to use 'match' here, but since 'and=3D>' is defined early
in boot-9.scm, we must restrict ourselves to core functionality in its
implementation.

I'm not sure if it makes sense to include the final (nullary) case.
Unlike 'and', 'or', '+', '*' and similar operations where every argument
is treated uniformally, in this case the first argument is qualitatively
different than the others.  Therefore, it seems to me that this
procedure naturally generalizes down to 1 argument, but no further.

Finally, there still some question in my mind whether this
generalization would be useful in practice.  Have you found a real-world
use case where this generalized 'and=3D>' makes life easier?

Do you know about SRFI-2 (and-let*)?  How would that work for your use
case?

     Regards,
       Mark




Information forwarded to bug-guile@HIDDEN:
bug#30237; Package guile. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 24 Jan 2018 12:10:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 24 07:10:36 2018
Received: from localhost ([127.0.0.1]:40420 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1eeJsy-0000W7-CA
	for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 07:10:36 -0500
Received: from eggs.gnu.org ([208.118.235.92]:41934)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <mthl@HIDDEN>) id 1eeJsw-0000Vs-3v
 for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 07:10:34 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mthl@HIDDEN>) id 1eeJso-0003Fz-Er
 for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 07:10:28 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:39589)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <mthl@HIDDEN>) id 1eeJso-0003FW-Bq
 for submit <at> debbugs.gnu.org; Wed, 24 Jan 2018 07:10:26 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:32852)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <mthl@HIDDEN>) id 1eeJsn-00032F-9E
 for bug-guile@HIDDEN; Wed, 24 Jan 2018 07:10:26 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <mthl@HIDDEN>) id 1eeJsm-0003CT-Ef
 for bug-guile@HIDDEN; Wed, 24 Jan 2018 07:10:25 -0500
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46460)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <mthl@HIDDEN>)
 id 1eeJsm-0003CC-4T
 for bug-guile@HIDDEN; Wed, 24 Jan 2018 07:10:24 -0500
Received: from [2a01:e35:2ec2:e580:7d5f:f616:fc6f:3970] (port=47184 helo=godel)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <mthl@HIDDEN>) id 1eeJsk-0001n4-QP
 for bug-guile@HIDDEN; Wed, 24 Jan 2018 07:10:23 -0500
From: Mathieu Lirzin <mthl@HIDDEN>
To: bug-guile@HIDDEN
Subject: Generalizing =?utf-8?B?4oCYYW5kPT7igJk=?=
Date: Wed, 24 Jan 2018 13:10:20 +0100
Message-ID: <877es731ar.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -5.0 (-----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

Hello,

Here is a proposal for generalizing =E2=80=98and=3D>=E2=80=99 to a pipeline=
 of procedures.
It acts like a =E2=80=9Cbind=E2=80=9D operator in an ad-hoc =E2=80=9CMaybe=
=E2=80=9D monad which uses #f
to represent the absence of value.  Not sure if it is useful in
practice, but it feels like a natural generalization.

The current definition is the following:

  (define (and=3D> value procedure)
    (and value (procedure value)))

Here is my proposition:

  (define-syntax and=3D>
    (syntax-rules ()
      ((_) #t)
      ((_ val) val)
      ((_ val proc)
       (and val (proc val)))
      ((_ val proc proc* ...)
       (and=3D> (and val (proc val)) proc* ...))))

Let me know if such change is welcome or not, so I can provide a
complete patch including documentation.  Even if it's a small change, I
would like to assign copyright for future changes.

Thanks.

--=20
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37




Acknowledgement sent to Mathieu Lirzin <mthl@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guile@HIDDEN. Full text available.
Report forwarded to bug-guile@HIDDEN:
bug#30237; Package guile. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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