Email list hosting service & mailing list manager

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)

Re: Places in Scheme Marc Nieper-Wißkirchen 19 Aug 2022 17:58 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