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