Introspection Wolfgang Corcoran-Mathe (10 May 2020 23:41 UTC)
Re: Introspection Marc Nieper-Wißkirchen (11 May 2020 07:11 UTC)
Multiple-values SRFI Lassi Kortela (11 May 2020 09:09 UTC)
Re: Multiple-values SRFI Marc Nieper-Wißkirchen (11 May 2020 09:41 UTC)
Re: Multiple-values SRFI Lassi Kortela (11 May 2020 10:52 UTC)
Re: Multiple-values SRFI Lassi Kortela (11 May 2020 11:04 UTC)
Re: Introspection John Cowan (11 May 2020 18:02 UTC)
Re: Introspection Marc Nieper-Wißkirchen (11 May 2020 18:26 UTC)
Re: Introspection Marc Feeley (11 May 2020 18:34 UTC)
Re: Introspection Marc Nieper-Wißkirchen (11 May 2020 19:29 UTC)
Re: Introspection Marc Feeley (12 May 2020 04:15 UTC)
Re: Introspection John Cowan (12 May 2020 15:36 UTC)
Re: Introspection Lassi Kortela (12 May 2020 16:07 UTC)
Re: Introspection John Cowan (12 May 2020 18:19 UTC)
Re: Introspection Lassi Kortela (12 May 2020 18:46 UTC)
Re: Introspection Marc Nieper-Wißkirchen (04 Jun 2020 16:39 UTC)
Re: Introspection Marc Nieper-Wißkirchen (09 Jun 2020 08:38 UTC)
Re: Introspection John Cowan (09 Jun 2020 17:53 UTC)
Re: Introspection Marc Nieper-Wißkirchen (09 Jun 2020 19:39 UTC)
Re: Introspection John Cowan (10 Jun 2020 21:46 UTC)
Re: Introspection Marc Nieper-Wißkirchen (11 Jun 2020 11:55 UTC)
Re: Introspection Marc Nieper-Wißkirchen (04 Jun 2020 16:36 UTC)

Re: Introspection Marc Feeley 12 May 2020 04:15 UTC

> On May 11, 2020, at 3:29 PM, Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
> Am Mo., 11. Mai 2020 um 20:34 Uhr schrieb Marc Feeley <xxxxxx@iro.umontreal.ca>:
>>
>>> On May 11, 2020, at 2:02 PM, John Cowan <xxxxxx@ccil.org> wrote:
>>>
>>> I agree that the proposed SRFI is an excellent idea, especially with the additional macros to go from lists/vectors to multiple values.  Indeed, given such a SRFI, I question whether SRFI 195 actually adds anything.   It seems simpler just to continue to restrict boxes to hold a single object which can be converted to and from multiple values.
>
> Restricting something usually makes things more complicated, says the
> mathematician.

I don’t view the “single value” nature of boxes as a restriction.  Similarly, the “two value” nature of pairs is not a restriction.  These structures correspond to specific common usage patterns:

1) box = mutable cell
2) pair = joining two values together

Vectors are another common usage pattern where multiple elements are joined together and indexable.  Boxes and pairs are theoretically redundant because the same effect could be obtained with vectors of length 1 or 2.  When a program uses the box type it conveys to the programmer the concept that there is a single contained value.  Similarly, using the pair type conveys the concept of a group of 2 values.  This helps the programmer reason about the program better than if the vector type was used everywhere instead of boxes and pairs.

However I like the idea of special forms to convert between multiple values and lists and vectors.  This is possible but rather verbosely with the call-with-values procedure:

  (call-with-values (lambda () (values 1 2 3)) list)    => (1 2 3)
  (call-with-values (lambda () (values 1 2 3)) vector)  => #(1 2 3)

With a special form these conversions could be more direct.  Here is an idea:

  (values=>vector (values 1 2 3))  ;; #(1 2 3)

  (vector->values (vector 1 2 3))  ;; same as (values 1 2 3)

Note that values=>vector is a special form and vector->values is a procedure.  There could also be list variants.

The use of cond's => syntax reminds the reader that values=>vector is a special form and not a procedures (which typically use the -> kind of arrow like vector->values).

An even more concise approach would limit the conversion to vectors:

  (=>vector (values 1 2 3))  ;; #(1 2 3)

  (->values (vector 1 2 3))  ;; same as (values 1 2 3)

Marc