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 >
