Minutes for 2025-11-21 meeting

[Wolfgang Corcoran-Mathe]

Dear WG2,

I've added minutes for last Friday's meeting:

https://codeberg.org/scheme/r7rs/wiki/Minutes+2025-11-21.-

This one was voluminous & a bit difficult to chronicle. I hope I
didn't travesty your opinions.

Respectfully submitted,

Wolfgang

--
Wolfgang Corcoran-Mathe <w...@sigwinch.xyz>

[John Cowan]

Here are my comments:

1. I wrestled a good deal with the issues of array lexical syntax back in the day and concluded that it's intractable. I could find no clean syntax that supported both nonzero lower bounds and storage classes other than the generic storage class, as I find the notations of SRFIs 58 and 63 intolerably ugly and un-Schemey.

Since it is possible to have custom storage classes (e.g. an equal?-based hash table for sparse arrays) and generalized arrays are inherently procedural, complete read-write invariance is impossible.  If lexical syntax for the CL-compatibIe subset with none of these features is nevertheless thought desirable, I would favor CL notation: #nA (where n is the number of dimensions) followed by nested list structure, or by the representation of any object in the case of #0A. 

2. PetaLisp arrays are implemented on top of CL arrays, which are a subset of SRFI 231 as noted above. Therefore, it is just as possible to implement PetaLisp arrays on top of SRFI 231, and some kind of underlying array system is dedirable.

3. I agree with Arthur that #*#t#f#t#f is hideous, but I think that #*tftf is tolerable (for reading only).

#32: I note that in SRFI 207 #"..." Is the string-style notation for bytevectors. 

#90: The logic behind the R6RS redefinition of real? came from the Racket team, and one of them did write it up in an email. The idea is that a complex number should be considered real only if its imaginary part is exactly zero, as an inexact zero may be the result of a floating-point rounding error. Tests of the Racket corpus showed that only a handful of programs depended on the R5RS behavior.

The reason WG1 did not accept this argument was not that we thought it was a bad idea, but that it was a silent breaking change from R5RS and all earlier reports that might undetectably break people's code. One of the WG1 formal comments suggested reintroducing the R6RS semantics under new names, but no one came up with satisfactory names that made the semantic distinction clear enough.

[Per Bothner]

On 12/1/25 00:11, John Cowan wrote:
> Here are my comments:
>
> 1. I wrestled a good deal with the issues of array lexical syntax back in the day and concluded that it's intractable. I could find no clean syntax that supported both nonzero lower bounds and storage classes other than the generic storage class, as I find the notations of SRFIs 58 and 63 intolerably ugly and un-Schemey.

The srfi-163 notation isn't quite as ugly (in my-not-so-humble opinion):

array-literal ::= array-literal-header datum
array-literal-header ::= "#" rank vectag array-bound*
array-bound ::= ["@"lower]":"length | "@"lower
vectag ::= "a" | type-tag

type-tag is typically a srfi-4 uniform vector TAG, such as "u32",
but other values could be allowed.

This has the advantage that it builds on actiual implementations (srfi-4 uniform vectors,
Common Lisp, Guile, Kawa).
--
--Per Bothner
p...@bothner.com http://per.bothner.com/

[John Cowan]

I agree that that is better. I think it would be even better if all array tags began with "a" so that there wouldn't be a partial collision with homogeneous vector tags. I'm also not a big fan of overloading "@" in this way: I'd rather use ":" or something else. But these are minor points.

[Wolfgang Corcoran-Mathe]

Hi John, it's great to hear from you.

On 2025-12-01 03:11 -0500, John Cowan wrote:
> #90: The logic behind the R6RS redefinition of real? came from the Racket
> team, and one of them did write it up in an email. The idea is that a
> complex number should be considered real only if its imaginary part is
> exactly zero, as an inexact zero may be the result of a floating-point
> rounding error. Tests of the Racket corpus showed that only a handful of
> programs depended on the R5RS behavior.

I don't know where to find that email, but I finally went through
the R6RS rationale[1] to see how they justified the new semantics:

> R5RS creates a more insidious problem by defining (real? z) to be
> true if and only if (zero? (imag-part z)) is true. This means, for
> example, that -2.5+0.0i is real. If -2.5+0.0i is represented as a
> compnum, then the compiler cannot rely on x being a flonum in the
> consequent of (if (real? x) <expression1> <expression2>). This
> problem could be fixed by writing all of the arithmetic operations
> so that any compnum with a zero imaginary part is converted to a
> flonum before it is returned, but that merely creates an analogous
> problem for compnum arithmetic, as explained below. R6RS adopted
> a proposal by Brad Lucier to fix the problem: (real? z) is now true
> if and only if (imag-part z) is an exact zero.

My first thoughts on reading this paragraph were (a) they call
their example a problem without telling us whether this really *is*
a significant analysis problem for actual compilers, and (b) they
are talking about using 'real?' to distinguish between flonums &
compnums, rather than between real numbers & complex numbers. Is
that actually the right way to think about 'real?'? Or did they
blithely turn a numerical predicate into a numerical *representation*
predicate?

(Clearly Brad Lucier is someone to talk to about this. I had no
idea he was the guy behind the change.)

Regards & best wishes,

Wolfgang

[1] https://www.r6rs.org/final/html/r6rs-rationale/r6rs-rationale-Z-H-2.html#node_toc_node_sec_11.6.6.2

--
Wolfgang Corcoran-Mathe <w...@sigwinch.xyz>