Daphne Preston-Kendal <[email protected]> writes: > With talk of Guile 4.0 in the air, I’d like to propose that this > version should be taken as an opportunity to enable --r6rs and --r7rs > modes by default.
In general this sounds good to me, except for the backwards compatibility breakage. Is that breakage actually required? > Worse, due to the standard layout for many R7RS libraries (with a .sld > declaration which includes a .scm source file of the same base name), > Guile started in its default mode will try to load the wrong file when > importing such libraries, which doesn’t actually include any library > declaration – giving the illusion that Guile doesn’t support an R7RS > library, when in fact it would probably work fine with the --r7rs > flag. … > surprising results in the case of libraries which have a .scm version > targeting Guile besides a .sld version targetting standard R7RS. I > have created such a library myself (the SRFI 250 sample How many libraries of each kind are there? Would a smaller change of using the .scm first and .sld second by default and changing --r7rs to only change the order be sufficient? Then no currently working library would break on update and some r7rs libraries would be added as compatible, but not all. Specifying --r7rs would then only switch the preference around: prefer supporting r7rs over supporting guile specifics. > The second change will be harder to make. I suggest that if possible, > the next minor release of Guile should begin warning about the > deprecation of \xNN string escapes with no semicolon when the reader > encounters one; then Guile 4.0 can turn them off by default. What’s the advantage of removing support for those escapes? Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
