Re: The mathematical name behind "unfold-right" in srfi-1
chansey97
(06 Jun 2020 09:12 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(06 Jun 2020 11:39 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1
John Cowan
(06 Jun 2020 19:07 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(06 Jun 2020 19:23 UTC)
|
||
Total functional programming
Lassi Kortela
(06 Jun 2020 19:37 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(06 Jun 2020 19:37 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1 Marc Nieper-Wißkirchen (06 Jun 2020 19:53 UTC)
|
||
Re: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(06 Jun 2020 20:18 UTC)
|
||
(missing)
|
||
(missing)
|
||
(missing)
|
||
Fwd: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(07 Jun 2020 10:17 UTC)
|
Thanks for chiming in Lassi. I am deliberately replying in this thread because I often do not find it helpful if the list structure of a thread is suddenly turned into that of a tree because people start new threads on subtopics. Maybe it's just who thinks so. Marc Am Sa., 6. Juni 2020 um 21:37 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de>: > > Am Sa., 6. Juni 2020 um 21:23 Uhr schrieb Marc Nieper-Wißkirchen > <xxxxxx@nieper-wisskirchen.de>: > > > > If I had the time, I'd love to put together a Lisp that uses the principles of Turner's elementary total functional programming <https://homepages.dcc.ufmg.br/~mariza/CELP/sblp2004/papers/turner.pdf>, which obliterates the difference between lazy and strict by allowing codata to be constructed but not accessed, thus making it truly the dual of data. The language is not Turing-complete, but an amazing number of algorithms are available nonetheless. The paper is very accessible (as proved by the fact that I understand it) and well worth reading. > > > > Thanks for the reference. I will take a look at it. > > I just stumbled about the question of whether f⊥=⊥or not. The paper > says (correctly, of course) that the eager languages say yes while > lazy languages say no. This may look like some asymmetry between > eagerness and laziness but, in fact, everything is completely > symmetric: Instead of applying a (potential) calculation "f" to a > *value*, which is ⊥in this case, we can also turn the whole program > inside out and co-apply a *continuation* to a calculation "f". In the > case of the continuation⊥, we are therefore led to the question of > whether ⊥f =⊥or not. Well, an eager language says no while a lazy > language says yes.