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)
|
Am Mo., 17. Apr. 2023 um 23:32 Uhr schrieb Maxime Devos <xxxxxx@telenet.be>: > > > > 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. Replacing the mutation of a parameter (which has indefinite extent) with parameterize (which has dynamic extent) is generally not possible without a non-local program transformation (which may not be possible). As an example, consider you have a for-each (higher-order) procedure modeling some sequence and want to return a fold procedure for it. You would have to use the liquids' set! for it. > 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 (*). I get your point, but liquids don't reimplement Scheme's `set!`. Scheme's `set!' modifies locations in the store (of the formal semantics of Scheme), and this modification can be observed. This is not true for the liquid-version of `set!'. Of course, one has to agree upon what one means by purity (where there is no absolute definition). The definition I use here is exactly about whether previously allocated locations in the store are modified (and so that this mutation is observable). > (*) 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). You can employ a much stricter definition of purity (let us call it "strict-purity") for now. Neither the liquid version of `set!', nor the use of parameters (even without mutating them), nor the use (delimited) continuation, nor the procedure `cons' are strictly pure. In particular, your solution of the topological sort is also not strictly pure. For many reasonings, this strict pureness is not helpful, though. See my for-each/fold example from above, where you need pureness in the first sense but where questions of strict pureness are not helpful. Marc