Email list hosting service & mailing list manager

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

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.