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)
|
Email threading styles
Lassi Kortela
(06 Jun 2020 20:20 UTC)
|
Re: Email threading styles
Arthur A. Gleckler
(06 Jun 2020 20:26 UTC)
|
Re: Email threading styles
Lassi Kortela
(06 Jun 2020 20:33 UTC)
|
Re: Email threading styles
Marc Nieper-Wißkirchen
(06 Jun 2020 20:42 UTC)
|
Re: Email threading styles
Arthur A. Gleckler
(06 Jun 2020 20:45 UTC)
|
Rescuing SRFI GitHub issues and PRs
Lassi Kortela
(06 Jun 2020 20:50 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
John Cowan
(06 Jun 2020 20:55 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Arthur A. Gleckler
(06 Jun 2020 21:14 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
John Cowan
(06 Jun 2020 21:17 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Arthur A. Gleckler
(06 Jun 2020 21:39 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Arthur A. Gleckler
(06 Jun 2020 21:02 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Lassi Kortela
(06 Jun 2020 21:06 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Göran Weinholt
(07 Jun 2020 10:25 UTC)
|
Re: Rescuing SRFI GitHub issues and PRs
Arthur A. Gleckler
(07 Jun 2020 15:33 UTC)
|
Re: Email threading styles
Lassi Kortela
(06 Jun 2020 21:17 UTC)
|
Re: Email threading styles
Arthur A. Gleckler
(06 Jun 2020 21:37 UTC)
|
Re: Email threading styles
Marc Nieper-Wißkirchen
(06 Jun 2020 20:28 UTC)
|
Re: Email threading styles
Lassi Kortela
(06 Jun 2020 20:38 UTC)
|
Re: Email threading styles
Marc Nieper-Wißkirchen
(06 Jun 2020 20:48 UTC)
|
Re: Email threading styles
Lassi Kortela
(06 Jun 2020 20:56 UTC)
|
Re: Email threading styles
Arthur A. Gleckler
(06 Jun 2020 20:58 UTC)
|
Re: The mathematical name behind "unfold-right" in srfi-1
Marc Nieper-Wißkirchen
(06 Jun 2020 20:18 UTC)
|
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.