Hi Mark! Hope all is well. I'm behind as usual. Just an additional perspective here.
On Thu 09 Feb 2012 06:09, Mark H Weaver <m...@netris.org> writes: > R7RS TODO I think you probably agree, but we should be clear about it in any case: the current drafts are not final. I look forward to R7RS being a report that Guile can happily support. However I think there is room for some discussion on various points, before the final version comes out :) Most things are well-thought-out and I won't comment on them. > * let-values and let*-values (without loading SRFI-11) This and other "what bindings are visible" questions can be solved without affecting Guile's default environment, as Guile supports `library' without having R6RS libs in its default environment. That said, it might make sense to expose more bindings to the default environment. The mounting number of bindings makes me cringe, but hey, maybe it's the right thing? Dunno. > * |...| symbol notation, and \xXX within symbols I'm looking forward to |...|. \xXX are r6rs hex escapes, which are off by default it seems. Should we turn it on by default? > * support \xXXXX in string literals Again, supported, but off by default currently; to flip in 2.2? > * allow whitespace between \ and newline in string literals A bug in the spec, I think: http://thread.gmane.org/gmane.lisp.guile.bugs/4859/focus=4873 > * #true and #false Yes! > * datum labels for circular and shared substructures Yes! > * nan? and finite? now accept complex numbers > (should probably change inf? and infinite? as well) Do you need to file a bug with the spec? Have you? > * R7RS exceptions Are they like R6RS exceptions? The semantics of the interaction of guard with dynamic wind is still batshit crazy, and I hope guard doesn't make it into the spec as is. > * define-library A big one, and something to check in the newer specs.. > * vector->string and string->vector Real wtf procedures, if you ask me... > * write bytevectors with #u8 (and elements in hex) by default? Is this incompatible wrt srfi-4? > * {map,for-each} stops when shortest list runs out WDYT about this? > * string-{map,for-each} accepts multiple strings > * vector-{map,for-each} Bleh... > * make sure {map,vector-map,string-map} are multi-return safe This is an interesting one. It would be nice to have expandable stacks so we can do the straightforward implementation. Dunno. Just some off the cuff thoughts. Happy hacking! Andy -- http://wingolog.org/
