[PATCH] Implement SRFI-111 Boxes

[PATCH] Implement SRFI-111 Boxes

[Mark H Weaver]

[-- Attachment #1: Type: text/plain, Size: 92 bytes --]

Here's an implementation of SRFI-111 Boxes for stable-2.0.
What do you think?

      Mark



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: [PATCH] Implement SRFI-111 Boxes --]
[-- Type: text/x-patch, Size: 6921 bytes --]

From 625b1a68a7fcbe41abfd499937ecdf627a31530c Mon Sep 17 00:00:00 2001
From: Mark H Weaver <mhw@netris.org>
Date: Fri, 24 Jan 2014 00:21:17 -0500
Subject: [PATCH] Implement SRFI-111 Boxes.

* module/srfi/srfi-111.scm: New file.
* module/Makefile.am (SRFI_SOURCES): Add srfi/srfi-111.scm.
* test-suite/tests/srfi-111.test: New file.
* test-suite/Makefile.am (SCM_TESTS): Add tests/srfi-111.test.
* doc/ref/srfi-modules.texi (SRFI-111): New node.
---
 doc/ref/srfi-modules.texi      |   25 +++++++++++++++
 module/Makefile.am             |    3 +-
 module/srfi/srfi-111.scm       |   37 ++++++++++++++++++++++
 test-suite/Makefile.am         |    1 +
 test-suite/tests/srfi-111.test |   65 ++++++++++++++++++++++++++++++++++++++++
 5 files changed, 130 insertions(+), 1 deletions(-)
 create mode 100644 module/srfi/srfi-111.scm
 create mode 100644 test-suite/tests/srfi-111.test

diff --git a/doc/ref/srfi-modules.texi b/doc/ref/srfi-modules.texi
index 66d5bd1..8845c85 100644
--- a/doc/ref/srfi-modules.texi
+++ b/doc/ref/srfi-modules.texi
@@ -59,6 +59,7 @@ get the relevant SRFI documents from the SRFI home page
 * SRFI-88::                     Keyword objects.
 * SRFI-98::                     Accessing environment variables.
 * SRFI-105::                    Curly-infix expressions.
+* SRFI-111::                    Boxes.
 @end menu
 
 
@@ -5181,6 +5182,30 @@ directive @code{#!curly-infix-and-bracket-lists}.  For example:
 
 For more information on reader options, @xref{Scheme Read}.
 
+@node SRFI-111
+@subsection SRFI-111 Boxes.
+@cindex SRFI-111
+
+@uref{http://srfi.schemers.org/srfi-111/srfi-111.html, SRFI-111}
+provides boxes: objects with a single mutable cell.
+
+@deffn {Scheme Procedure} box value
+Return a newly allocated box whose contents is initialized to
+@var{value}.
+@end deffn
+
+@deffn {Scheme Procedure} box? obj
+Return true if @var{obj} is a box, otherwise return false.
+@end deffn
+
+@deffn {Scheme Procedure} unbox box
+Return the current contents of @var{box}.
+@end deffn
+
+@deffn {Scheme Procedure} set-box! box value
+Set the contents of @var{box} to @var{value}.
+@end deffn
+
 @c srfi-modules.texi ends here
 
 @c Local Variables:
diff --git a/module/Makefile.am b/module/Makefile.am
index 8a7befd..47b9c2c 100644
--- a/module/Makefile.am
+++ b/module/Makefile.am
@@ -295,7 +295,8 @@ SRFI_SOURCES = \
   srfi/srfi-67.scm \
   srfi/srfi-69.scm \
   srfi/srfi-88.scm \
-  srfi/srfi-98.scm
+  srfi/srfi-98.scm \
+  srfi/srfi-111.scm
 
 RNRS_SOURCES =					\
   rnrs/base.scm					\
diff --git a/module/srfi/srfi-111.scm b/module/srfi/srfi-111.scm
new file mode 100644
index 0000000..3d3cd89
--- /dev/null
+++ b/module/srfi/srfi-111.scm
@@ -0,0 +1,37 @@
+;;; srfi-111.scm -- SRFI 111 Boxes
+
+;;      Copyright (C) 2014 Free Software Foundation, Inc.
+;;
+;; This library is free software; you can redistribute it and/or
+;; modify it under the terms of the GNU Lesser General Public
+;; License as published by the Free Software Foundation; either
+;; version 3 of the License, or (at your option) any later version.
+;;
+;; This library is distributed in the hope that it will be useful,
+;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;; Lesser General Public License for more details.
+;;
+;; You should have received a copy of the GNU Lesser General Public
+;; License along with this library; if not, write to the Free Software
+;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+(define-module (srfi srfi-111)
+  #:use-module (srfi srfi-9)
+  #:use-module (srfi srfi-9 gnu)
+  #:export (box box? unbox set-box!))
+
+(cond-expand-provide (current-module) '(srfi-111))
+
+(define-record-type <box>
+  (box value)
+  box?
+  (value unbox set-box!))
+
+(set-record-type-printer! <box>
+  (lambda (box port)
+    (display "#<box " port)
+    (display (number->string (object-address box) 16) port)
+    (display " value: ")
+    (write (unbox box) port)
+    (display ">" port)))
diff --git a/test-suite/Makefile.am b/test-suite/Makefile.am
index 01ffd1c..00f62fe 100644
--- a/test-suite/Makefile.am
+++ b/test-suite/Makefile.am
@@ -139,6 +139,7 @@ SCM_TESTS = tests/00-initial-env.test		\
 	    tests/srfi-69.test			\
 	    tests/srfi-88.test			\
 	    tests/srfi-105.test			\
+	    tests/srfi-111.test			\
 	    tests/srfi-4.test			\
 	    tests/srfi-9.test			\
 	    tests/statprof.test			\
diff --git a/test-suite/tests/srfi-111.test b/test-suite/tests/srfi-111.test
new file mode 100644
index 0000000..e2d76c6
--- /dev/null
+++ b/test-suite/tests/srfi-111.test
@@ -0,0 +1,65 @@
+;;;; srfi-111.test --- Test suite for SRFI-111 (Boxes). -*- scheme -*-
+;;;;
+;;;; Copyright (C) 2014 Free Software Foundation, Inc.
+;;;;
+;;;; This library is free software; you can redistribute it and/or
+;;;; modify it under the terms of the GNU Lesser General Public
+;;;; License as published by the Free Software Foundation; either
+;;;; version 3 of the License, or (at your option) any later version.
+;;;;
+;;;; This library is distributed in the hope that it will be useful,
+;;;; but WITHOUT ANY WARRANTY; without even the implied warranty of
+;;;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;;;; Lesser General Public License for more details.
+;;;;
+;;;; You should have received a copy of the GNU Lesser General Public
+;;;; License along with this library; if not, write to the Free Software
+;;;; Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+
+(define-module (test-srfi-111)
+  #:use-module (test-suite lib)
+  #:use-module (srfi srfi-1)
+  #:use-module (srfi srfi-111))
+
+(with-test-prefix "srfi-111"
+
+  (let ((test-vals '(#f #t #\space "string" -5 #e1e100 1e-30 #(a vector))))
+    (pass-if-equal "box and unbox"
+        test-vals
+      (map (lambda (x)
+             (unbox (box x)))
+           test-vals))
+
+    (pass-if "box?"
+      (and (box? (box 5))
+           (not (any box? test-vals))))
+
+    (pass-if-equal "set-box!"
+        "string"
+      (let ((b (box #f)))
+        (set-box! b "string")
+        (unbox b)))
+
+    (pass-if "eq? on boxes"
+      (let ((box1 (box #f))
+            (box2 (box #f)))
+        (and (eq? box1 box1)
+             (eq? box2 box2)
+             (not (eq? box1 box2)))))
+
+    (pass-if "eqv? on boxes"
+      (let ((box1 (box #f))
+            (box2 (box #f)))
+        (and (eqv? box1 box1)
+             (eqv? box2 box2)
+             (not (eqv? box1 box2)))))
+
+    (pass-if "equal? on boxes"
+      (let ((box1 (box "foo"))
+            (box2 (box "bar")))
+        (and (equal? box1 box1)
+             (equal? box2 box2)
+             (not (equal? box1 box2))
+             ;; Guile extension, not guaranteed by SRFI-111.
+             (begin (set-box! box2 (string #\f #\o #\o))
+                    (equal? box1 box2)))))))
-- 
1.7.5.4

Re: [PATCH] Implement SRFI-111 Boxes

[Taylan Ulrich Bayırlı/Kammer]

Mark H Weaver <mhw@netris.org> writes:

> Here's an implementation of SRFI-111 Boxes for stable-2.0.
> What do you think?
>
>       Mark

Has it been considered to coalesce the box type with Guile's "variable"
type?  I can see two concrete differences:

* External representation (*not* specified by SRFI-111)

* Variables can be "unbound" (empty), boxes can't

So we could get away with making the box API consist of aliases to a
subset of the variable API and still conform to SRFI-111.

This would eliminate type-disjointness between variables and boxes, make
boxes print with #<variable, make objects exist that are box? but error
when passed to unbox, and eliminate the extra record type.  And as a
more "volatile" point, it would make boxes perform possibly a bit faster
now (direct C implementation, whereas records all have some overhead as
of now AFAIK), but a bit slower in theory given a perfect record-type
implementation (needn't check for boundness during `unbox').

I suppose that's more cons than pros after all?  And very sorry if I'm
bikeshedding, I thought this was worth at least a mention and a quick
survey.

Taylan

Re: [PATCH] Implement SRFI-111 Boxes

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> From 625b1a68a7fcbe41abfd499937ecdf627a31530c Mon Sep 17 00:00:00 2001
> From: Mark H Weaver <mhw@netris.org>
> Date: Fri, 24 Jan 2014 00:21:17 -0500
> Subject: [PATCH] Implement SRFI-111 Boxes.
>
> * module/srfi/srfi-111.scm: New file.
> * module/Makefile.am (SRFI_SOURCES): Add srfi/srfi-111.scm.
> * test-suite/tests/srfi-111.test: New file.
> * test-suite/Makefile.am (SCM_TESTS): Add tests/srfi-111.test.
> * doc/ref/srfi-modules.texi (SRFI-111): New node.

Fine with me!

Ludo’.

Re: [PATCH] Implement SRFI-111 Boxes

[Ludovic Courtès]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:

> Has it been considered to coalesce the box type with Guile's "variable"
> type?  I can see two concrete differences:
>
> * External representation (*not* specified by SRFI-111)
>
> * Variables can be "unbound" (empty), boxes can't
>
> So we could get away with making the box API consist of aliases to a
> subset of the variable API and still conform to SRFI-111.

Even though both types are box-like, they represent conceptually
different things, so I think it’s better to keep them disjoint.

Ludo’.

Re: [PATCH] Implement SRFI-111 Boxes

[Andy Wingo]

A late reply, but at least the year is right :)

On Fri 24 Jan 2014 11:57, ludo@gnu.org (Ludovic Courtès) writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>
>> Has it been considered to coalesce the box type with Guile's "variable"
>> type?  I can see two concrete differences:
>>
>> * External representation (*not* specified by SRFI-111)
>>
>> * Variables can be "unbound" (empty), boxes can't
>>
>> So we could get away with making the box API consist of aliases to a
>> subset of the variable API and still conform to SRFI-111.
>
> Even though both types are box-like, they represent conceptually
> different things, so I think it’s better to keep them disjoint.

Why do you think so?  To me, Guile's variables are boxes, and the
ability to make a variable unbound is a Guile extension.

Andy
-- 
http://wingolog.org/

Re: [PATCH] Implement SRFI-111 Boxes

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> On Fri 24 Jan 2014 11:57, ludo@gnu.org (Ludovic Courtès) writes:
>
>> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
>>
>>> Has it been considered to coalesce the box type with Guile's "variable"
>>> type?  I can see two concrete differences:
>>>
>>> * External representation (*not* specified by SRFI-111)
>>>
>>> * Variables can be "unbound" (empty), boxes can't
>>>
>>> So we could get away with making the box API consist of aliases to a
>>> subset of the variable API and still conform to SRFI-111.
>>
>> Even though both types are box-like, they represent conceptually
>> different things, so I think it’s better to keep them disjoint.
>
> Why do you think so?  To me, Guile's variables are boxes, and the
> ability to make a variable unbound is a Guile extension.

Tu put it differently, I don’t think it would buy us anything to make
variable SRFI-111 boxes.  However, it could perhaps break code, and
would not allow for a separate type printer, which is useful.

Ludo’.

Re: [PATCH] Implement SRFI-111 Boxes

[Andy Wingo]

On Tue 25 Mar 2014 18:01, ludo@gnu.org (Ludovic Courtès) writes:

> Tu put it differently, I don’t think it would buy us anything to make
> variable SRFI-111 boxes.

Dunno; variables are slightly cheaper than records.  Their type checks
are easier and they take less memory.  

> However, it could perhaps break code

In what way?

> and would not allow for a separate type printer, which is useful.

Not sure what this point is, as the external representation was not
specified in SRFI-111.

Perhaps we are miscommunicating -- I would change what we currently call
"variables" to be "boxes".  WDYT?

Andy
-- 
http://wingolog.org/

Re: [PATCH] Implement SRFI-111 Boxes

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> On Tue 25 Mar 2014 18:01, ludo@gnu.org (Ludovic Courtès) writes:
>
>> Tu put it differently, I don’t think it would buy us anything to make
>> variable SRFI-111 boxes.
>
> Dunno; variables are slightly cheaper than records.  Their type checks
> are easier and they take less memory.  
>
>> However, it could perhaps break code
>
> In what way?

‘variable?’ would suddenly match any SRFI-111 box.

>> and would not allow for a separate type printer, which is useful.
>
> Not sure what this point is, as the external representation was not
> specified in SRFI-111.

I mean this:

  #<variable 15cb830 value: #<procedure + (#:optional _ _ . _)>>

vs.

  #<box 206f8c0 value: #<procedure + (#:optional _ _ . _)>>

I find it convenient that variables are distinguished.

> Perhaps we are miscommunicating -- I would change what we currently call
> "variables" to be "boxes".  WDYT?

You mean just the name, or making them SRFI-111 boxes?

Anyway, I don’t feel strongly about this particular point, but I think
we’ve been deprecating a lot lately.

Ludo’.

Re: [PATCH] Implement SRFI-111 Boxes

[Andy Wingo]

On Tue 25 Mar 2014 21:21, ludo@gnu.org (Ludovic Courtès) writes:

>>> However, it could perhaps break code
>>
>> In what way?
>
> ‘variable?’ would suddenly match any SRFI-111 box.

I would be OK with this FWIW -- eventually we could deprecate variable?
(though that would happen later in 2.2 I would think).

>> Perhaps we are miscommunicating -- I would change what we currently call
>> "variables" to be "boxes".  WDYT?
>
> You mean just the name, or making them SRFI-111 boxes?

I mean making SRFI-111 boxes the same as Guile variables, and renaming
Guile variables to be "boxes", and eventually deprecating the old
variable names.

> Anyway, I don’t feel strongly about this particular point, but I think
> we’ve been deprecating a lot lately.

Have you noticed it in your non-core code?  (Out of curiosity.)

Andy
-- 
http://wingolog.org/

Re: [PATCH] Implement SRFI-111 Boxes

[Ludovic Courtès]

Andy Wingo <wingo@pobox.com> skribis:

> On Tue 25 Mar 2014 21:21, ludo@gnu.org (Ludovic Courtès) writes:

[...]

>> Anyway, I don’t feel strongly about this particular point, but I think
>> we’ve been deprecating a lot lately.
>
> Have you noticed it in your non-core code?  (Out of curiosity.)

Yes, supporting 2.0.5 to 2.0.11 in Guix without deprecation warnings
requires a bit of care (esp. in the web code, which has changed a lot.)

Ludo’.