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

Re: The mathematical name behind "unfold-right" in srfi-1 Marc Nieper-Wißkirchen 06 Jun 2020 19:52 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.