You're probably missing the fact that it's much harder to understand how the Haskell program works without (_|_). I've seen lots of questions like "why doesn't my recursion work" that could be answered simply as "because your function is strict, so (_|_) is it's minimal fixpoint".
Отправлено с iPhone Nov 16, 2011, в 15:31, Jesse Schalken <jesseschal...@gmail.com> написал(а): > I like the idea of a mascot. I like the idea of a lamb called Da, as most of > Haskell's strength comes from it's closeness to pure lambda calculus. > > A few things I'd like to see in a mascot: > - Simple. You should be able to draw it in a few seconds. > - Look good in black and white. > - Have obvious features so it is identifiable from a distance. > - Be a little bit cute. > > I don't see why ⊥ has to be featured. ⊥ means a computation can terminate > without returning a value. That is a flaw, not a strength. If a computation > may fail, return a Maybe or Either String. If a computation might not > terminate, let it not terminate and I can find out why with my debugger. That > covers all the use cases of ⊥. It also undermines the type system as > beginners often write functions which return ⊥ where they should either be > returning a Maybe or Either String, or expressing the violated precondition > in the type system so it can be tested at compile time. What am I missing? > > On Wed, Nov 16, 2011 at 9:47 PM, Bas van Dijk <v.dijk....@gmail.com> wrote: > On 16 November 2011 11:05, MigMit <miguelim...@yandex.ru> wrote: > > Maybe it's just me, but I've thought that being non-strict just means that > > it's possible for a function to produce some value even if it's argument > > doesn't; in other words, that it's possible to have "f (_|_) ≠ (_|_)". If > > there was no such thing as (_|_), what would non-strictness mean? > > Thanks, non-strictness is indeed defined using ⊥ like you mentioned. > > I think I was confusing non-strict evaluation with coinduction. They > have the same advantages but the latter is less powerful but safer > than the former. > > Bas > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
