Re: routine declaration line question

2018-10-12 Thread Larry Wall
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

Re: routine declaration line question

2018-10-12 Thread Curt Tilmes
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

Re: routine declaration line question

2018-10-12 Thread Simon Proctor
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

Re: routine declaration line question

2018-10-12 Thread Curt Tilmes
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

Re: routine declaration line question

2018-10-12 Thread Simon Proctor
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

2018-10-12 Thread Curt Tilmes
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

Re: routine declaration line question

2018-10-12 Thread Todd Chester via perl6-users
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

2018-10-12 Thread Curt Tilmes
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

Re: routine declaration line question

2018-10-12 Thread Todd Chester via perl6-users
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

Re: routine declaration line question

2018-10-05 Thread Trey Harris
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

2018-10-05 Thread Timo Paulssen
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? >

Re: routine declaration line question

2018-10-05 Thread Brandon Allbery
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.

Re: routine declaration line question

2018-10-05 Thread Trey Harris
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

Re: routine declaration line question

2018-10-05 Thread Brandon Allbery
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

Re: routine declaration line question

2018-10-05 Thread JJ Merelo
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,

Re: routine declaration line question

2018-10-05 Thread Larry Wall
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

Re: routine declaration line question

2018-10-05 Thread Larry Wall
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

Re: routine declaration line question

2018-10-04 Thread Brandon Allbery
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

2018-10-04 Thread JJ Merelo
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

2018-10-04 Thread Brandon Allbery
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;

Re: routine declaration line question

2018-10-04 Thread Trey Harris
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

2018-10-04 Thread ToddAndMargo
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

Re: routine declaration line question

2018-10-04 Thread Brandon Allbery
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

Re: routine declaration line question

2018-10-04 Thread JJ Merelo
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

2018-10-04 Thread ToddAndMargo
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

Re: routine declaration line question

2018-10-04 Thread Trey Harris
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

Re: routine declaration line question

2018-10-04 Thread ToddAndMargo
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

Re: routine declaration line question

2018-10-04 Thread Brandon Allbery
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

2018-10-04 Thread JJ Merelo
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

Re: routine declaration line question

2018-10-04 Thread Trey Harris
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

2018-10-04 Thread Brandon Allbery
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

2018-10-04 Thread Peter Pentchev
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

2018-10-04 Thread JJ Merelo
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

Re: routine declaration line question

2018-10-04 Thread JJ Merelo
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 >

Re: routine declaration line question

2018-10-03 Thread ToddAndMargo
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

2018-10-03 Thread Brad Gilbert
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

Re: routine declaration line question

2018-10-03 Thread ToddAndMargo
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

2018-10-03 Thread ToddAndMargo
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

Re: routine declaration line question

2018-10-03 Thread yary
> 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

Re: routine declaration line question

2018-10-03 Thread Trey Harris
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

Re: routine declaration line question

2018-10-03 Thread ToddAndMargo
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"

Re: routine declaration line question

2018-10-03 Thread Timo Paulssen
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

Re: routine declaration line question

2018-10-03 Thread Trey Harris
_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

Re: routine declaration line question

2018-10-03 Thread Brandon Allbery
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

routine declaration line question

2018-10-03 Thread ToddAndMargo
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