A reference type
Marc Nieper-Wißkirchen
(18 Aug 2022 21:45 UTC)
|
Re: A reference type
John Cowan
(19 Aug 2022 01:36 UTC)
|
Re: A reference type
Lassi Kortela
(19 Aug 2022 10:03 UTC)
|
Re: A reference type
Marc Nieper-Wißkirchen
(19 Aug 2022 10:11 UTC)
|
Re: A reference type
Lassi Kortela
(19 Aug 2022 10:25 UTC)
|
Places in Scheme
Marc Nieper-Wißkirchen
(19 Aug 2022 10:42 UTC)
|
Re: Places in Scheme
Marc Nieper-Wißkirchen
(19 Aug 2022 11:36 UTC)
|
Re: Places in Scheme
Per Bothner
(19 Aug 2022 16:33 UTC)
|
Re: Places in Scheme Marc Nieper-Wißkirchen (19 Aug 2022 17:58 UTC)
|
Re: Places in Scheme
Panicz Maciej Godek
(25 Aug 2022 15:20 UTC)
|
Re: Places in Scheme
Ray Dillinger
(26 Aug 2022 02:29 UTC)
|
Re: A reference type
Marc Nieper-Wißkirchen
(19 Aug 2022 10:54 UTC)
|
Re: A reference type
Marc Nieper-Wißkirchen
(19 Aug 2022 11:44 UTC)
|
Re: A reference type
Peter Bex
(19 Aug 2022 12:02 UTC)
|
Re: A reference type
Marc Nieper-Wißkirchen
(19 Aug 2022 12:26 UTC)
|
Big words
Lassi Kortela
(19 Aug 2022 16:29 UTC)
|
Re: Big words
Marc Nieper-Wißkirchen
(19 Aug 2022 18:07 UTC)
|
Re: Big words
Lassi Kortela
(19 Aug 2022 20:06 UTC)
|
Re: Big words
Marc Nieper-Wißkirchen
(19 Aug 2022 20:31 UTC)
|
Re: Big words
blake@xxxxxx
(19 Aug 2022 22:06 UTC)
|
Re: Big words
blake@xxxxxx
(19 Aug 2022 22:08 UTC)
|
Re: Big words
Arthur A. Gleckler
(19 Aug 2022 18:09 UTC)
|
Re: Big words
John Cowan
(19 Aug 2022 18:39 UTC)
|
Am Fr., 19. Aug. 2022 um 18:33 Uhr schrieb Per Bothner <xxxxxx@bothner.com>: > > On 8/19/22 04:36, Marc Nieper-Wißkirchen wrote: > > PS Admittedly, the issue is very subtle, which is why the fundamental > > criticism is not against a special form as introduced by SRFI 17, but > > against naming it `set!'. > > Well, in other languages people do use the same assignment operator '=' or ':=' > for both modifying variables (local and global) as well as modifying properties > (fields) and array elements. Sure, most software written in C++, Java, and whatever mainstream language mostly works and there are programmers in these languages so the designs of these languages cannot be too bad. But when you ask the typical, say, C++ programmer about the difference between mutating a binding and mutating a value, the difference between lexical scoping and dynamic scoping, the notion of continuation, the essence of proper tail calls, lexical and dynamic environments, etc., you won't get many satisfying answers. And if you want to explain these things to the average C++ programmer, C++ is by far not the most convenient language to clarify these concepts. On the other hand, Scheme is exceptionally clear in these regards, and it is comparably easy to teach, demonstrate and explain all these topics. Ad-hoc overloading `set!' with an operation of quite different semantics won't make working Scheme programs not work anymore. Nor would it make it harder to write Scheme programs. But it would make it harder to teach some particular concepts as it would remove some of Scheme's clarity. > So people seem to comfortable with that approach. It does not mean to be a major > source of confusion or errors. Anecdotal stories of students being confused > may be biased by the teacher not liking the idea. Matthias Felleisen reported the same on the list. And I can also tell that students struggle to understand the difference between creating a binding, mutating a binding, and mutating a value, especially when they come from a mostly imperative language (like C++ and Java). But without understanding this difference, code like (let ((x 10)) (define (f) x) (let ((x 20)) (f))) ; => 10 is hard to understand. Anyway, SRFI 19 was finalized long ago and says: "This is a controversial issue. This srfi does not wish to imply that all Scheme implementations should support this feature; it only requests that implementations that do implement generalized set! should be compatible with this srfi." Opinions about what Scheme and Scheme code ought to look like differ, and given that cite from SRFI 19, there is not much to argue about. Marc