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 Marc Nieper-Wißkirchen 18 Apr 2023 05:57 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