Re: TODO list for Guile R7RS support

[Andy Wingo]

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 <address@hidden> 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/