I figure they'll evolve with wider use, but we certainly aren't there yet. On the other hand, discussions like this will help shape that evolution.
On Thu, Oct 4, 2018 at 3:35 PM JJ Merelo <jjmer...@gmail.com> 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... > >> >> On Thu, Oct 4, 2018 at 3:13 PM Trey Harris <t...@lopsa.org> wrote: >> >>> Right; that's what I meant by "stylistically" — a `--> Mu` can highlight >>> that something is being returned (and that side-effects are not the primary >>> purpose), while nothing indicates that the return value, though it exists, >>> is incidental and probably from "falling off the end" or using `return` as >>> a control-flow jump. >>> On Thu, Oct 4, 2018 at 15:04 Brandon Allbery <allber...@gmail.com> >>> wrote: >>> >>>> Arguably it should be --> Any, since Mu vs. Any has meaning with >>>> respect to Junctions. But in this case it's just not stating a redundancy. >>>> >>>> The way you'd phrased it makes it sound like it's an explicit >>>> no-meaningful-result, as opposed to 'we don't know or care'. >>>> >>>> On Thu, Oct 4, 2018 at 3:02 PM Trey Harris <t...@lopsa.org> wrote: >>>> >>>>> Ah (replying to both Brandon and JJ since their replies crossed): >>>>> >>>>> So `--> Mu` is not a sufficient and/or correct return constraint for >>>>> things like AT-POS because why, then? >>>>> On Thu, Oct 4, 2018 at 14:56 Brandon Allbery <allber...@gmail.com> >>>>> wrote: >>>>> >>>>>> I think they meant more like my AT-POS example: the point is the >>>>>> return value, but you can't say ahead of time what type it will have. >>>>>> >>>>>> On Thu, Oct 4, 2018 at 2:48 PM Trey Harris <t...@lopsa.org> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Oct 4, 2018 at 02:13 JJ Merelo <jjmer...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> El jue., 4 oct. 2018 a las 3:36, Trey Harris (<t...@lopsa.org>) >>>>>>>> escribió: >>>>>>>> >>>>>>>>> _All_ routines in Perl 6 return _something._ A lack of a "-->" >>>>>>>>> simply indicates stylistically that the return is not useful because >>>>>>>>> it's >>>>>>>>> whatever "falls off the end". (There's a bit of variance here as I'm >>>>>>>>> not >>>>>>>>> sure it's a convention everyone has followed.) It's equivalent to >>>>>>>>> "--> Mu" >>>>>>>>> because anything that could "fall of the end" is Mu. >>>>>>>>> >>>>>>>> >>>>>>>> No, it means that it's not constrained to a type. It can still >>>>>>>> return something, but it can be anything. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I get all that, except for the "No" at the front. ;-) >>>>>>> >>>>>>> Or were you talking about the "not useful" bit? Yes, of course in >>>>>>> any given codebase, the lack of a return value has no more or less >>>>>>> meaning >>>>>>> than a lack of any constraint. The programmer may not like using >>>>>>> constraints at all and treats Perl 6 like Perl 5 in the respect of >>>>>>> wanting >>>>>>> arbitrarily mungible values. >>>>>>> >>>>>>> But the word "stylistically" was important, as I was responding to >>>>>>> Todd's question about the docs—I think a lack of a return value in the >>>>>>> docs >>>>>>> (at least, the ones I could come up with in a grep pattern on my >>>>>>> checkout >>>>>>> of docs) does tend to indicate that the return is not useful, that the >>>>>>> routine is a "procedure" run for its side effects rather than for >>>>>>> evaluation. >>>>>>> >>>>>>> Is that what you meant? >>>>>>> >>>>>>> If you were saying in "it can still return something, but can be >>>>>>> anything", that "anything ⊃ (is a strict superset of) `Mu`", then I >>>>>>> don't understand, because I thought all values conformed to Mu. >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> brandon s allbery kf8nh >>>>>> allber...@gmail.com >>>>>> >>>>> >>>> >>>> -- >>>> brandon s allbery kf8nh >>>> allber...@gmail.com >>>> >>> >> >> -- >> brandon s allbery kf8nh >> allber...@gmail.com >> > -- brandon s allbery kf8nh allber...@gmail.com
