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)
|
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.