Alternative topological sorting implementation Maxime Devos (13 Apr 2023 15:12 UTC)
Re: Alternative topological sorting implementation Marc Nieper-Wißkirchen (13 Apr 2023 15:29 UTC)
Re: Alternative topological sorting implementation Maxime Devos (13 Apr 2023 16:00 UTC)
Re: Alternative topological sorting implementation Marc Nieper-Wißkirchen (13 Apr 2023 20:18 UTC)
Re: Alternative topological sorting implementation Marc Nieper-Wißkirchen (13 Apr 2023 20:35 UTC)
Re: Alternative topological sorting implementation Maxime Devos (17 Apr 2023 21:33 UTC)
Re: Alternative topological sorting implementation Marc Nieper-Wißkirchen (18 Apr 2023 05:58 UTC)
Re: Alternative topological sorting implementation Maxime Devos (18 Apr 2023 07:53 UTC)
Re: Alternative topological sorting implementation Maxime Devos (17 Apr 2023 21:13 UTC)

Re: Alternative topological sorting implementation Maxime Devos 17 Apr 2023 21:32 UTC

Op 13-04-2023 om 22:34 schreef Marc Nieper-Wißkirchen:
> PPS Maybe I should have better pointed to what I called liquids here:
> https://github.com/mnieper/scheme-libraries#liquids.  Although one can
> change them with set!, there is no mutation of a location in the store
> happening, > but just some delimited continuation wizardy.  The thing I
> like about liquids is that they abstract away from the rather
> low-level continuation primitives.
 >
> So you can just set! visiting and set! visited and are still doing
> pure programming. :)  Liquids can be easily implemented in Guile.  Do
> you think they would make a good addition?

AFAICT, these are just parameter objects, except for 'change them with
liquid-set!, but purely!'.  I haven't ever seen a use of doing a
mutation of a parameter that couldn't be improved by doing a
'parameterize' (cf. let-liquid') (or not using parameters at all) instead.

As such, I would answer your question with 'no'.  (Of course, perhaps
there is some application where mutating a parameter would be a really
good fit instead.)

Even then, I disagree with "and are still doing pure programming." -- if
you implement a pure implementation (e.g. in Scheme without set! stuff)
of an impure language (e.g. Scheme with set! stuff), and then use your
pure implementation to the impure language, then you're doing impure
programming -- it's the language that matters, not the implementation of
the language (*).

(*) There might be some exceptions like if e.g. you use the purity of
the host language to implement, say, time travel, for the implemented
impure language, but usually I find the "but the mutation is implemented
purely!!!" a pointless distinction (except for neatness points).

Greetings,
Maxime.