Re: routine declaration line question

On Fri, Oct 12, 2018 at 06:47:40AM -0400, Curt Tilmes wrote: : Adding it gives more information to the consumers of that routine, : the people reading it, the compiler optimizing use of the routine, : and the runtime execution which will validate the return and throw an : exception for you if it is

Re: routine declaration line question

On Fri, Oct 12, 2018 at 8:46 AM Simon Proctor wrote: > What if something could return an Int or a Rat? Or an single item or an > Array? Having Mu or Any as the listed return type isn't very useful. > > Maybe better to define a subset for it. Or just leave it empty and > document it. > For an Int

Re: routine declaration line question

What if something could return an Int or a Rat? Or an single item or an Array? Having Mu or Any as the listed return type isn't very useful. Maybe better to define a subset for it. Or just leave it empty and document it. On Fri, 12 Oct 2018, 13:35 Curt Tilmes, wrote: > > On Fri, Oct 12, 2018 at

Re: routine declaration line question

On Fri, Oct 12, 2018 at 7:46 AM Simon Proctor wrote: > Only if the routine has an easily defined return Type. Many do not. > Is there not always a common root, even if it is Mu? Why not explicitly mark those as Mu for documentation purposes at least? That would differentiate those from the one

Re: routine declaration line question

Only if the routine has an easily defined return Type. Many do not. On Fri, 12 Oct 2018 at 12:41, Curt Tilmes wrote: > > > On Fri, Oct 12, 2018 at 7:31 AM Todd Chester via perl6-users < > perl6-users@perl.org> wrote: > >> I was asking because sometimes the documentation for routines does >> not

Re: routine declaration line question

On Fri, Oct 12, 2018 at 7:31 AM Todd Chester via perl6-users < perl6-users@perl.org> wrote: > I was asking because sometimes the documentation for routines does > not give a --> and I find having to dig around to figure out what > the return is to be time consuming and confusing. > > Based on what

Re: routine declaration line question

On 10/12/18 3:47 AM, Curt Tilmes wrote: On Fri, Oct 12, 2018 at 6:08 AM Todd Chester via perl6-users mailto:perl6-users@perl.org>> wrote: > If nothing is being returned, it should really be indicated with --> Nil > since that can enable certain optimizations.  Similarly, if

Re: routine declaration line question

On Fri, Oct 12, 2018 at 6:08 AM Todd Chester via perl6-users < perl6-users@perl.org> wrote: > > If nothing is being returned, it should really be indicated with --> Nil > > since that can enable certain optimizations. Similarly, if a routine > always > > returns true upon success, that can be ind

Re: routine declaration line question

On 10/5/18 8:39 AM, Larry Wall wrote: On Thu, Oct 04, 2018 at 03:13:15PM -0400, Trey Harris 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 t

Re: routine declaration line question

On Fri, Oct 5, 2018 at 2:10 PM Brandon Allbery 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

Re: routine declaration line question

You're probably thinking of ;; in a signature. On 05/10/2018 20:02, Trey Harris wrote: > 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

Re: routine declaration line question

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. (Multip

Re: routine declaration line question

On Fri, Oct 5, 2018 at 1:13 PM Brandon Allbery 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 usefu

Re: routine declaration line question

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. On Fri, Oct 5, 2018 at 12:01 PM Larry Wall wrote: > On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote: > : El j

Re: routine declaration line question

Hi, El vie., 5 oct. 2018 a las 18:01, Larry Wall () escribió: > On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote: > : El jue., 4 oct. 2018 21:21, Brandon Allbery > escribió: > : > : > I don't think we've reached the point of such conventions yet. And > there's > : > some history here, i

Re: routine declaration line question

On Thu, Oct 04, 2018 at 09:35:08PM +0200, JJ Merelo wrote: : El jue., 4 oct. 2018 21:21, Brandon Allbery 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 thi

Re: routine declaration line question

On Thu, Oct 04, 2018 at 03:13:15PM -0400, Trey Harris 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 inc

Re: routine declaration line question

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 wrote: > > > El jue., 4 oct. 2018 21:21, Brandon Allbery > escribió: > >> I don't think we've reached the

Re: routine declaration line question

El jue., 4 oct. 2018 21:21, Brandon Allbery 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).

Re: routine declaration line question

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). On Thu, Oct 4, 2018 at 3:13 PM Trey Harris wrote: > Right; th

Re: routine declaration line question

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

Re: routine declaration line question

On 10/4/18 12:04 PM, Brandon Allbery 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 kn

Re: routine declaration line question

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 Tre

Re: routine declaration line question

El jue., 4 oct. 2018 a las 21:02, Trey Harris () escribió: > 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? > It's totally OK. The "incorrect" part might be because

Re: routine declaration line question

On 10/4/18 9:37 AM, Brandon Allbery wrote: Consider a function which returns the element at a given position in a list:     method AT-POS(\position) The only thing you can say about the result type is that it's whatever the type of the element at that position is. So it doesn't bother specif

Re: routine declaration line question

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 wrote: > I think they meant more like my AT-POS example: the point is the retu

Re: routine declaration line question

On 10/4/18 1:49 AM, Peter Pentchev wrote: On Wed, Oct 03, 2018 at 10:50:14PM -0700, ToddAndMargo wrote: On Wed, Oct 3, 2018 at 7:21 PM ToddAndMargo mailto:toddandma...@zoho.com>> wrote: >> On 04/10/2018 03:07, ToddAndMargo wrote: >>> Hi All, >>> >>> In another thre

Re: routine declaration line question

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 wrote: > > > On Thu, Oct 4, 2018 at 02:13 JJ Merelo wrote: > >> >> >> El jue., 4 oct. 2018 a las 3:36, Trey Harris ()

Re: routine declaration line question

Hi El jue., 4 oct. 2018 a las 20:48, Trey Harris () escribió: > > > On Thu, Oct 4, 2018 at 02:13 JJ Merelo wrote: > >> >> >> El jue., 4 oct. 2018 a las 3:36, Trey Harris () escribió: >> >>> _All_ routines in Perl 6 return _something._ A lack of a "-->" simply >>> indicates stylistically that the

Re: routine declaration line question

On Thu, Oct 4, 2018 at 02:13 JJ Merelo wrote: > > > El jue., 4 oct. 2018 a las 3:36, Trey Harris () 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

Re: routine declaration line question

Consider a function which returns the element at a given position in a list: method AT-POS(\position) The only thing you can say about the result type is that it's whatever the type of the element at that position is. So it doesn't bother specifying a type at all, because the prototype can't

Re: routine declaration line question

On Wed, Oct 03, 2018 at 10:50:14PM -0700, ToddAndMargo wrote: > > > > > > > > On Wed, Oct 3, 2018 at 7:21 PM ToddAndMargo > > > > > wrote: > > > > > > > > > > >> On 04/10/2018 03:07, ToddAndMargo wrote: > > > > > >>> Hi All, > > > > > >>> > > > > >

Re: routine declaration line question

El jue., 4 oct. 2018 a las 4:53, Trey Harris () escribió: > > On Wed, Oct 3, 2018 at 22:21 ToddAndMargo wrote: > >> >> On 04/10/2018 03:07, ToddAndMargo wrote: >> >>> Hi All, >> >>> >> >>> In another thread, Timo wrote me: >> >>> >> >>> The "-->" part of the signature is optional. If ther

Re: routine declaration line question

El jue., 4 oct. 2018 a las 3:36, Trey Harris () 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

Re: routine declaration line question

On Wed, Oct 3, 2018 at 7:21 PM ToddAndMargo mailto:toddandma...@zoho.com>> wrote: >> On 04/10/2018 03:07, ToddAndMargo wrote: >>> Hi All, >>> >>> In another thread, Timo wrote me: >>> >>> The "-->" part of the signature is optional. If there isn't

Re: routine declaration line question

If a routine does not declare it's return type, absolutely anything can be returned. One reason may be that its return value isn't really useful. It could be that the writer didn't think to declare it. (or didn't want to) Another possibility is that the potential returned values are of many diff

Re: routine declaration line question

On Wed, Oct 3, 2018 at 7:21 PM ToddAndMargo > wrote: >> On 04/10/2018 03:07, ToddAndMargo wrote: >>> Hi All, >>> >>> In another thread, Timo wrote me: >>> >>> The "-->" part of the signature is optional. If there isn't >>>

Re: routine declaration line question

On 10/3/18 7:53 PM, Trey Harris wrote: On Wed, Oct 3, 2018 at 22:21 ToddAndMargo > wrote: >> On 04/10/2018 03:07, ToddAndMargo wrote: >>> Hi All, >>> >>> In another thread, Timo wrote me: >>> >>>         The "-->" part of the signatur

Re: routine declaration line question

> And not all subs return things, like "say" and "print". say and print return true if the print succeeded, just like in perl 5. > say say "hi"; hi True Useful if printing to a filehandle, and the file you're writing to is on a volume that fills up. Or a network drive that goes away. You do c

Re: routine declaration line question

On Wed, Oct 3, 2018 at 22:21 ToddAndMargo wrote: > >> On 04/10/2018 03:07, ToddAndMargo wrote: > >>> Hi All, > >>> > >>> In another thread, Timo wrote me: > >>> > >>> The "-->" part of the signature is optional. If there isn't > >>> one, it defaults to Mu, which is the type that e

Re: routine declaration line question

On 04/10/2018 03:07, ToddAndMargo wrote: Hi All, In another thread, Timo wrote me: The "-->" part of the signature is optional. If there isn't one, it defaults to Mu, which is the type that everything conforms to, i.e. the sub or method that either has "--> Mu" e

Re: routine declaration line question

I just spotted a grave mistake in my earlier mail: the --> constraints are validated at *run* time, not *compile* time; that's a very big difference, and an important one. Of course "every time a sub or method returns" doesn't make much sense if i had meant "compile time", but I felt i should real

Re: routine declaration line question

_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 anythi

Re: routine declaration line question

Perl 6 routines always return *something*; if you don't return anything explicitly, it will return the result of the last statement/expression, or Mu as a last resort. (Mu is the "least defined value" in Perl 6. Any is somewhat more common, but is slightly more defined since it can participate in j

routine declaration line question

Hi All, In another thread, Timo wrote me: The "-->" part of the signature is optional. If there isn't one, it defaults to Mu, which is the type that everything conforms to, i.e. the sub or method that either has "--> Mu" explicitly, or has it by leaving it out, may re