Am Do., 7. Dez. 2023 um 09:21 Uhr schrieb John Cowan <[email protected]>:
> Thanks for the examples. Note for the record that nobody questions the > need for lexical syntax for bytevectors/u8vectors, only for other kinds of > homogeneous records. However, your arguments apply equally to those cases. > Lexical syntax for bytevectors is already present in R6RS and R7RS-small, so the question of its necessity is less relevant. (For sure, Scheme could work well without it.) That said, there is another difference between bytevectors and other homogenous vectors; literal bytevectors allow us to embed general binary data in literals. As long as other homogeneous vectors are realized as views into bytevectors (as in the R6RS bytevector library), they can make use of the bytevector lexical format. This does not work in the other direction, making bytevectors special. > On Wed, Dec 6, 2023 at 11:20 PM Marc Feeley <[email protected]> > wrote: > >> >> > On Dec 6, 2023, at 8:13 AM, John Cowan <[email protected]> wrote: >> > >> > >> > >> > On Tue, Dec 5, 2023 at 11:07 PM Arthur A. Gleckler <[email protected]> >> wrote: >> > I don't understand. Isn't it to make it possible to put literals >> representing these values into one's program? Are you looking for a >> purpose beyond that? >> > >> > The alternative view is that we should not have such literals, but >> simply use macros of the form (s32 1 2 15 3453) that work at expand time >> rather than read time. See <https://codeberg.org/scheme/r7rs/issues/109> >> for the most recent discussion. >> > By the way, I just checked, and Marc Feeley, the author, is still >> subscribed to this mailing list. >> > >> > I'd be surprised if he weren't. >> >> I find it surprising that people are questioning the need for a lexical >> syntax for homogeneous vectors and I’m puzzled at some of the arguments >> given in issue 109. >> >> For a macro like (u8 1 2 3) to be a substitute for '#u8(1 2 3) it has to >> appear in an evaluated position. So it can work here: >> >> (define foo '#u8(1 2 3)) ;; equivalent to the proposed (define foo (u8 >> 1 2 3)) >> >> But it can’t be used in a nested literal such as >> >> (define foo '#(#u8(1 2 3) #u8(4 5 6) #u8(7 8 9))) ;; no equivalent with >> “u8” macro >> >> which is a perfectly fine representation for a literal 3x3 matrix of >> bytes. >> > While the simple "u8" macro from above wouldn't work, a more general macro producing a literal datum will work. This is actually what is proposed in #109. Such a macro would interpret a mini-DSL describing literals. (Personally, I would find a specialized macro "matrix-literal" better, but others would likely disagree.) > >> And what about literals that embed u8vectors like: >> >> (define smileys-utf8-alist >> '((#\😁 #u8(240 159 152 129)) >> (#\😳 #u8(240 159 152 179)) >> (#\😱 #u8(240 159 152 177)))) >> > See above. > Moreover, if there is no external representation for u8vectors, it would >> not be possible to pretty-print the following code after macro-expansion: >> >> (lambda () (u8 1 2 3)) >> >> That would be a real bummer for debugging and s-expression manipulation >> in general. >> > I don't understand this; many Scheme objects have no official written representation (e.g. records), yet implementations print something useful. > Finally, let’s not forget that SRFI-4 is now 25 years old! It is supported >> by most Scheme systems. This seems like the ideal situation for >> standardizing a feature! Lots of experience with the feature and broad >> support among Scheme systems. How much experience does anybody have with >> (u8 1 2 3)? >> > We are not really talking about (u8 ...) because we have #u8, do we? We are talking about, say (s16 ...) or a general macro to produce literals. The point is that the latter can be fully implemented as a Scheme library. Adding #s16, ... etc. means, on the other hand, that we add something to the big ball of mud that Scheme's lexical syntax already is. Whether 25 years old or not, it would be another feature piled on top, which would pervade all of Scheme (because lexical syntax is global and shared). Marc
