On Fri, Oct 5, 2018 at 2:10 PM Brandon Allbery <allber...@gmail.com> wrote:
> Haskell supports it via typeclass resolution, which is mostly a source of > confusion to newcomers who assume (read :: Read a => String -> a) must be > deciding what to produce based on the String because they're not expecting > return type polymorphism. It doesn't seem to be a problem otherwise. > (Multiparameter typeclasses have a bigger problem, return type polymorphism > being only one of several ways to expose it.) > D’oh, of course; I do that all the time. (My weirdness in Haskell being my first real language and Perl being my second shows in cases like this; I forget how to map things *back* from other languages into Haskell-isms.) But thinking about that, to me that’s so ingrained into how a type-inferring strict functional language works that it’s not the same thing as “polymorphism”; I only barely recognize that the thing that we do in Haskell more often than not, defining degenerate cases as separate function definitions, qualifies as “polymorphism”. (Elm doesn’t do it and it drives me batty.) > > On Fri, Oct 5, 2018 at 2:03 PM Trey Harris <t...@lopsa.org> wrote: > >> >> >> On Fri, Oct 5, 2018 at 1:13 PM Brandon Allbery <allber...@gmail.com> >> wrote: >> >>> My problem with it being in the signature is still that it doesn't say >>> which part of the contract it applies to; it appears to be claiming it's >>> part of dispatch, when it's not. >>> >> >> Explicit argument polymorphism has been shown to be useful and increasing >> in elegance more often than it causes debugging complexity, while return >> polymorphism has generally been a nightmare in languages that have tried >> it, no? True that no other polymorphic language (AFAIK, but haven’t looked >> lately) has true multimethods, but my guess is that return polymorphism >> would be even worse within multiple dispatch than in single-dispatch >> languages. >> >> Not that I thought you were arguing that --> *should* apply to dispatch, >> just trying to get everyone on the same page in case we’re not (and maybe >> I’m the one who needs my page flipped to the same place in the hymnal). >> >> But right now we have a situation where “everything within the signature >> *except >> for* the return constraint can participate in multi dispatch”, which >> does feel weird. But is that actually true? Something’s nagging at me that >> there’s something else in this category as well, but I can’t think what. >> (Recursive multi dispatch on signatures of multi Callable arguments, >> maybe? I would try but my machine’s offline upgrading….) If there are more >> rules about what participates in multi dispatch than “change anything in >> the signature to the left of the --> and you’re good”, then it’s >> probably acceptable for --> to not participate either—it’s already more >> complex than it looks. >> >> >> >> >>> >>> On Fri, Oct 5, 2018 at 12:01 PM Larry Wall <la...@wall.org> wrote: >>> >>>> On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote: >>>> : El jue., 4 oct. 2018 21:21, Brandon Allbery <allber...@gmail.com> >>>> escribió: >>>> : >>>> : > I don't think we've reached the point of such conventions yet. And >>>> there's >>>> : > some history here, in --> not having done anything in the early >>>> days except >>>> : > possibly slow things down, and between --> and 'returns' (which is >>>> now >>>> : > deprecated). >>>> : > >>>> : >>>> : Not yet. Maybe never... >>>> >>>> --> generalizes to pointy blocks and such. 'returns' doesn't. >>>> >>>> --> allows return of explicit literal Nil and True and 42. 'returns' >>>> doesn't. >>>> >>>> --> makes the return an official part of the routine's contract. >>>> 'returns' doesn't. >>>> >>>> For various purposes it would be nice to know we have the entire in/out >>>> contract >>>> before we start processing all the oh-by-the-way traits that can turn >>>> the contract >>>> into a time-traveling brain pretzel. For instance, what if one of the >>>> phaser traits >>>> needs to know will be returned, and the 'returns' comes after that? >>>> Putting in error >>>> messages that say "Too late for returns trait" is a design smell... >>>> >>>> So never say never. :) >>>> >>>> Larry >>>> >>> >>> >>> -- >>> brandon s allbery kf8nh >>> allber...@gmail.com >>> >> > > -- > brandon s allbery kf8nh > allber...@gmail.com >
