Email list hosting service & mailing list manager

Re: Wrapping up SRFI 177: Portable keyword arguments John Cowan (02 Mar 2020 23:53 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Feeley (03 Mar 2020 04:46 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:29 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 06:43 UTC)
Re: Wrapping up SRFI 177: Portable keyword arguments Marc Nieper-Wißkirchen (03 Mar 2020 07:51 UTC)
Identifier syntax, and using macros with call/kw Lassi Kortela (03 Mar 2020 08:57 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:00 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:06 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 09:19 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:48 UTC)
Re: Identifier syntax, and using macros with call/kw Shiro Kawai (03 Mar 2020 10:03 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 10:12 UTC)
Re: Identifier syntax, and using macros with call/kw John Cowan (06 Oct 2020 20:20 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (07 Oct 2020 07:29 UTC)
Syntax for identifier syntax Lassi Kortela (03 Mar 2020 09:55 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 10:16 UTC)
Re: Syntax for identifier syntax John Cowan (03 Mar 2020 13:37 UTC)
Re: Syntax for identifier syntax Lassi Kortela (03 Mar 2020 13:42 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (03 Mar 2020 14:59 UTC)
Re: Syntax for identifier syntax Jim Rees (04 Mar 2020 18:12 UTC)
Re: Syntax for identifier syntax Marc Nieper-Wißkirchen (04 Mar 2020 18:18 UTC)
Re: Syntax for identifier syntax John Cowan (04 Mar 2020 23:48 UTC)
Re: Identifier syntax, and using macros with call/kw Marc Nieper-Wißkirchen (03 Mar 2020 09:13 UTC)
R7RS-large backward compatibility Lassi Kortela (03 Mar 2020 10:31 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (03 Mar 2020 11:31 UTC)
Specifying a meeting point for different keyword systems Lassi Kortela (03 Mar 2020 11:56 UTC)
Re: Specifying a meeting point for different keyword systems Marc Nieper-Wißkirchen (03 Mar 2020 15:03 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 19:36 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 19:51 UTC)
Re: R7RS-large backward compatibility John Cowan (05 Mar 2020 20:03 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (05 Mar 2020 20:17 UTC)
Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (08 Mar 2020 09:00 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 09:06 UTC)
Re: R7RS-large backward compatibility John Cowan (08 Mar 2020 21:58 UTC)
Re: R7RS-large backward compatibility Lassi Kortela (08 Mar 2020 22:40 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 07:42 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 11:46 UTC)
Re: [scheme-reports-wg2] R7RS-large backward compatibility Lassi Kortela (09 Mar 2020 12:07 UTC)
Re: R7RS-large backward compatibility Per Bothner (09 Mar 2020 16:30 UTC)
Re: [scheme-reports-wg2] Re: R7RS-large backward compatibility Marc Nieper-Wißkirchen (09 Mar 2020 16:48 UTC)

Re: R7RS-large backward compatibility Per Bothner 09 Mar 2020 16:30 UTC

On 3/8/20 2:58 PM, John Cowan wrote:

> By the same token (and this is why I have also copied xxxxxx@ on this email), incorporating SRFI-140 into R7RS-large violates the charter requirements, in my judgment.

Charter requirements are less of a concern to me that what is better for the Scheme language
and community in the long run.

>  The value of (string-set! (string-upcase (string #\a \#b \#c) 1 #\!) is defined by R7RS-small as "A!C".  But in a SRFI-140 world, string-upcase returns an immutable string and so the string-set! call fails.

I guess it is *possible* to write a correct and meaningful program that that calls string-set!
on the result of string-upcase but I find that very hard to conceive of.
So I think the concern with breaking program is valid, but string-upcase is ulikely
to be an issue.

While breaking old programs is unfortunate, srfi-140 is the best kind of incompatibility:
Programs break cleanly (compile-time or run-time type-checking rather than wrong result or
hard-to-detect performance degradation); the fix is local and trivial (usually add a call
to string-copy); and the fixed programs work fine on older implementations.

In my limited experience after making strings by default immutable, there were very few
places I had to fix my code.

It would be helpful if someone had larger programs that use strings, and tried running
then with srfi-140 - perhaps using Kawa.  I'd like to know if you had to change much,
and if it was difficult to do so.

On 3/9/20 12:42 AM, Marc Nieper-Wißkirchen wrote:
> I agree with the problem the SRFI 140 string procedures have.  The base language (R7RS-small) would have to be evolved first.  The approach to call immutable strings something else (like `text's) seems the best way out.

That would be an absolute disaster.  It would break *every* existing string-using program,
not in the sense of no longer working, but in the sense of using a deprecated/obsolete API,
as well as performance issues for programs that are not updated.

How do you visualize the state of Scheme if the new standard recommends text-upcase etc
in place of string-upcase etc?  How will tutorials and other documents be changed?  Who
will change their existing programs to use the new text-xxx APIs?  My guess is almost nobody.

Either leave strings R7RS-large unchanged from R7RS-small (perhaps with a deprecation
warning), or some variant of srfi-152 (also perhaps with a deprecation warning), or
go with srfi-140 (possibly with some tweaking).  srfi-135 would be a disaster, IMO.

--
	--Per Bothner
xxxxxx@bothner.com   http://per.bothner.com/