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 is wrong.  (There is a tiny, tiny bit of runtime
: overtime to do that check.  Optimization could easily offset or overwhelm
: that overhead.)

Note that in the specific case of returning Nil or some other literal
value, there is no runtime check at all, and the last statement of
the routine is evaluated in sink context because its value is known to
be unwanted.  In fact, if you *try* to return something in addition to
what --> already returns, it'll question your sanity:

> p6 'sub troo ( --> True ) { return False }'
===SORRY!=== Error while compiling -e
No return arguments allowed when return value Bool::True is already 
specified in the signature

Larry


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 Int or a Rat, you could just document with --> Numeric.  It isn't as
constrained as a subset Int|Rat could be, but it is accurate -- everything
that gets returned will be Numeric.  Better documented than omitting at
least, IMHO.  In appropriate cases, a subset may be warranted for
documentation, even if not in the implementation.

Can we agree at least the simple cases should get documented with a -->?
(I think most already are, and most changes have been adding them.)

Curt


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 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 ones just not documented that pick up Mu by default.
>
> Curt
>
>


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 ones just not documented that pick up Mu by default.

Curt


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 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 Larry stated, I do believe that the documentation
>> should always have a --> in the definition line.  This was
>> my question, not whether or not I should write a definition
>> line for my own subs.
>>
>
> I agree.  The documentation should always describe the routine with a -->
>
> Curt
>
>


-- 
Simon Proctor
Cognoscite aliquid novum cotidie

http://www.khanate.co.uk/


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 what Larry stated, I do believe that the documentation
> should always have a --> in the definition line.  This was
> my question, not whether or not I should write a definition
> line for my own subs.
>

I agree.  The documentation should always describe the routine with a -->

Curt


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 a
routine always
 > returns true upon success, that can be indicated with --> True.

Am I interpreting Larry correctly?  Should every definition line
always have a --> at the end?


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 wrong.  (There is a tiny, 
tiny bit of runtime overtime
to do that check.  Optimization could easily offset or overwhelm that 
overhead.)


Like many things in Perl, you are free to add the extra stuff if you 
want to take advantage of that,
but also free to leave it out if you don't feel like it.  The language 
supports many different levels
of formality you get to choose from.  For "quick and dirty" programming, 
go ahead and leave

them out if  you want.

Curt



Hi Curt,

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 Larry stated, I do believe that the documentation
should always have a --> in the definition line.  This was
my question, not whether or not I should write a definition
line for my own subs.

-T

'"quick and dirty" programming', huh.  I live and die by Top Down.
You can't maintain "stream of conscience" programming.  If you
do a little up front planning, you save yourself 10 times the
time down the road trying to maintain it.


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 the return value, though it exists,
: is incidental and probably from "falling off the end" or using `return` as
: a control-flow jump.

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 indicated with --> True.

Larry



Am I interpreting Larry correctly?  Should every definition line
always have a --> at the end?


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

D’oh, of course; I do that all the time. (My weirdness in Haskell being my
first real language and Perl being my second shows in cases like this; I
forget how to map things *back* from other languages into Haskell-isms.)

But thinking about that, to me that’s so ingrained into how a
type-inferring strict functional language works that it’s not the same
thing as “polymorphism”; I only barely recognize that the thing that we do
in Haskell more often than not, defining degenerate cases as separate
function definitions, qualifies as “polymorphism”. (Elm doesn’t do it and
it drives me batty.)
​


>
> On Fri, Oct 5, 2018 at 2:03 PM Trey Harris  wrote:
>
>>
>>
>> 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 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  wrote:
>>>
 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 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
>


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?
> 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.
> ​


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.
(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  wrote:

>
>
> 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 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  wrote:
>>
>>> 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 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


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 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  wrote:
>
>> 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 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
>


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


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

We can implement a TOOLATE phaser to take care of that :-)

>
> So never say never.  :)
>

I said _maybe_ never. :-)
Which, of course, "maybe never" ~~ /never/, but not "maybe never" ~~
/^^never$$/
-- 
JJ


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


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 incidental and probably from "falling off the end" or using `return` as
: a control-flow jump.

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 indicated with --> True.

Larry


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 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  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 
>>> 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  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 
> 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  wrote:
>>
>>>
>>>
>>> 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 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


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

Not yet. Maybe never...

>
> On Thu, Oct 4, 2018 at 3:13 PM 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 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  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  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 
 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  wrote:
>
>>
>>
>> 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 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
>


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; 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  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  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 
>>> 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  wrote:

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


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
a control-flow jump.
On Thu, Oct 4, 2018 at 15:04 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 know or care'.
>
> On Thu, Oct 4, 2018 at 3:02 PM Trey Harris  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  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  wrote:
>>>


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


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 know or care'.


On Thu, Oct 4, 2018 at 3:02 PM Trey Harris > 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 mailto: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 mailto:t...@lopsa.org>> wrote:



On Thu, Oct 4, 2018 at 02:13 JJ Merelo mailto:jjmer...@gmail.com>> wrote:



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



I think the misunderstanding is that when I say "what" others
are hearing "what type".  What I mean by "what" is "what
information".

My fault for not making myself more clear.


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 Trey Harris  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  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  wrote:
>>
>>>
>>>
>>> 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 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


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 it's the default
constraint, so you don't really have to write it explicitly.

JJ


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 
specifying a type at all, because the prototype can't know ahead of time 
what lists you might use it on contain. If you need to know, you can 
smartmatch the type of the returned value afterward or use the .^can MOP 
method to see if it supports a named method, etc.


(The \ in there means it's a raw value, for speed; AT-POS, as suggested 
by being all uppercase, is used internally for a bunch of things and 
wants to be as fast as possible, so it's using some internal tricks.)


Hi Brandon,

Thank you for the nice description.

As I told Peter, I think I am demanding too much from the routine
line.  I do believe that there should be a required written
description of "what" the routine does to give me the "what"
is returned.

I think the misunderstanding is that when I say "what" others are 
hearing "what type".  What I mean by "what" is "what information".


My fault for not making myself more clear.

-T


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


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 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 return
   >>> absolutely whatever it wants.
   >>>
   >>> After all, the "-->" part is a constraint, and it gets
   >>> validated at compile time every time a sub or method
   >>> returns.
   >>>
   >>> I got to thinking, some routines do not return anything.  Without
   >>> the "-->" constraint, how am I to determine if something is
   >>> being returned?
   >>>
   >>> Yours in confusion,
   >>> -T

  On 10/3/18 6:44 PM, Timo Paulssen wrote:
   > 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 really point it out before
  causing
   > too much confusion.
   >

  Hi Timo,

  Thank you for the help over on the chat line with IN!

  My confusion is not that it returns something (Mu).

  My confusion is "what" it returns.  And not all subs
  return things, like "say" and "print".

  I am presuming I am to pick the "what" from context
  from the examples?

  -T


On 10/3/18 7:53 PM, yary wrote:

   > 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 check
for those, right?


-y


Hi Yary,

Ya,  my misunderstanding.  Trey just taught me that.  Home
brew ones too.

$ p6 'sub x($Str) {say $Str};say x("y");'
y
True


I think where I got mixed up was not realizing that the
things subs return can be ignored.  And it is not like I
don't do that all the time either.  I think I just
spaced as in Modula2, you get the finger shaken at you.

Now All I have to figure out is how tot tell "what" is being
returned.  Am I suppose to pick that up from context?

-T



On 10/3/18 10:02 PM, Brad Gilbert wrote:

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
different types.

---

Note that any returned value that gets ignored will get sunk.
(That means the `.sink()` method will get called)

  class Baz {
  method sink () { say 'the result of foo() was sunk' }
  }
  sub foo () {
  Baz.new
  }

  foo(); # the result of foo() was sunk

So I suppose it is similar to Modula2, except it is up to the writer
of the class if they shake their finger at you.
On Wed, Oct 3, 2018 at 10:26 PM ToddAndMargo 


Thank you.  The default return is Mu.  That I get.

How do I figure out what data is being returned? Trial and error?


You just quoted Brad Gilbert's message.  Please reread the part that
starts with "If a routine does not declare a return type..." and
goes on until "...of many different types."  If the routine's
documentation does not describe its return value, it probably falls
under the "not useful" umbrella.  If the documentation does describe
it, there you have it.

Before continuing on this abstract "how do I tell in general" part,
let us know which routines exactly are you wondering right now about.

G'luck,
Peter



Hi Peter,

I think I am demanding too much from the routine line.  I
do believe that there should also be a required written description
of "what" the routine does to give me the "what" is returned.

I think the misunderstanding is that when I say "what" others are 
hearing "what type".  What I mean by "what" is "what information".


My fault for not making myself more clear.

-T


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


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

I think it referred to the part "the return is not useful". It might or
might not be useful, only it will not be constrained. But took me a while,
so I get that you didn't get that...

JJ


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


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 know ahead of time what lists you
might use it on contain. If you need to know, you can smartmatch the type
of the returned value afterward or use the .^can MOP method to see if it
supports a named method, etc.

(The \ in there means it's a raw value, for speed; AT-POS, as suggested by
being all uppercase, is used internally for a bunch of things and wants to
be as fast as possible, so it's using some internal tricks.)

On Thu, Oct 4, 2018 at 1:51 AM ToddAndMargo  wrote:

> >>
>  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
>    >>> 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 return
>    >>> absolutely whatever it wants.
>    >>>
>    >>> After all, the "-->" part is a constraint, and it
> gets
>    >>> validated at compile time every time a sub or method
>    >>> returns.
>    >>>
>    >>> I got to thinking, some routines do not return anything.
> Without
>    >>> the "-->" constraint, how am I to determine if something is
>    >>> being returned?
>    >>>
>    >>> Yours in confusion,
>    >>> -T
> 
>   On 10/3/18 6:44 PM, Timo Paulssen wrote:
>    > 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 really point it out before
>   causing
>    > too much confusion.
>    >
> 
>   Hi Timo,
> 
>   Thank you for the help over on the chat line with IN!
> 
>   My confusion is not that it returns something (Mu).
> 
>   My confusion is "what" it returns.  And not all subs
>   return things, like "say" and "print".
> 
>   I am presuming I am to pick the "what" from context
>   from the examples?
> 
>   -T
> >>
> >> On 10/3/18 7:53 PM, yary wrote:
> >>>   > 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 check
> >>> for those, right?
> >>>
> >>>
> >>> -y
> >>
> >> Hi Yary,
> >>
> >> Ya,  my misunderstanding.  Trey just taught me that.  Home
> >> brew ones too.
> >>
> >> $ p6 'sub x($Str) {say $Str};say x("y");'
> >> y
> >> True
> >>
> >>
> >> I think where I got mixed up was not realizing that the
> >> things subs return can be ignored.  And it is not like I
> >> don't do that all the time either.  I think I just
> >> spaced as in Modula2, you get the finger shaken at you.
> >>
> >> Now All I have to figure out is how tot tell "what" is being
> >> returned.  Am I suppose to pick that up from context?
> >>
> >> -T
>
>
> On 10/3/18 10:02 PM, Brad Gilbert wrote:
>  > 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
>  > different types.
>  >
>  > ---
>  >
>  > Note that any returned value that gets ignored will get sunk.
>  > (That means the `.sink()` method will get called)
>  >
>  >  class Baz {
>  >  method sink () { say 'the result of foo() was sunk' }
>  >  }
>  >  sub foo () {
>  >  Baz.new
>  >  }
>  >
>  >  foo(); # the result of foo() was sunk
>  >
>  > So I suppose it is similar to Modula2, except it is up to the writer
>  > of the class if they shake their finger at you.
>  > On Wed, Oct 3, 2018 at 10:26 PM ToddAndMargo 
>
> Thank you.  The default return is Mu.  That I get.
>
> How do I figure out what data is being 

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,
> > > > >   >>>
> > > > >   >>> 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 return
> > > > >   >>> absolutely whatever it wants.
> > > > >   >>>
> > > > >   >>> After all, the "-->" part is a constraint, and it 
> > > > > gets
> > > > >   >>> validated at compile time every time a sub or method
> > > > >   >>> returns.
> > > > >   >>>
> > > > >   >>> I got to thinking, some routines do not return anything.  
> > > > > Without
> > > > >   >>> the "-->" constraint, how am I to determine if something is
> > > > >   >>> being returned?
> > > > >   >>>
> > > > >   >>> Yours in confusion,
> > > > >   >>> -T
> > > > > 
> > > > >  On 10/3/18 6:44 PM, Timo Paulssen wrote:
> > > > >   > 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 really point it out before
> > > > >  causing
> > > > >   > too much confusion.
> > > > >   >
> > > > > 
> > > > >  Hi Timo,
> > > > > 
> > > > >  Thank you for the help over on the chat line with IN!
> > > > > 
> > > > >  My confusion is not that it returns something (Mu).
> > > > > 
> > > > >  My confusion is "what" it returns.  And not all subs
> > > > >  return things, like "say" and "print".
> > > > > 
> > > > >  I am presuming I am to pick the "what" from context
> > > > >  from the examples?
> > > > > 
> > > > >  -T
> > > 
> > > On 10/3/18 7:53 PM, yary wrote:
> > > >   > 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 check
> > > > for those, right?
> > > > 
> > > > 
> > > > -y
> > > 
> > > Hi Yary,
> > > 
> > > Ya,  my misunderstanding.  Trey just taught me that.  Home
> > > brew ones too.
> > > 
> > > $ p6 'sub x($Str) {say $Str};say x("y");'
> > > y
> > > True
> > > 
> > > 
> > > I think where I got mixed up was not realizing that the
> > > things subs return can be ignored.  And it is not like I
> > > don't do that all the time either.  I think I just
> > > spaced as in Modula2, you get the finger shaken at you.
> > > 
> > > Now All I have to figure out is how tot tell "what" is being
> > > returned.  Am I suppose to pick that up from context?
> > > 
> > > -T
> 
> 
> On 10/3/18 10:02 PM, Brad Gilbert wrote:
> > 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
> > different types.
> >
> > ---
> >
> > Note that any returned value that gets ignored will get sunk.
> > (That means the `.sink()` method will get called)
> >
> >  class Baz {
> >  method sink () { say 'the result of foo() was sunk' }
> >  }
> >  sub foo () {
> >  Baz.new
> >  }
> >
> >  foo(); # the result of foo() was sunk
> >
> > So I suppose it is similar to Modula2, except it is up to the writer
> > of the class if they shake their finger at you.
> > On Wed, Oct 3, 2018 at 10:26 PM ToddAndMargo 
> 
> Thank you.  The default return is Mu.  That I get.
> 
> How do I figure out what data is being returned? Trial and error?

You just quoted Brad Gilbert's message.  Please reread the part that
starts with "If a routine does not declare a return type..." and
goes on until "...of many different types."  If the routine's
documentation does not describe its return value, it probably falls
under the "not useful" umbrella.  If the documentation does describe
it, there you have it.

Before continuing on this abstract "how do I tell in general" 

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 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 return
>> >>> absolutely whatever it wants.
>> >>>
>> >>> After all, the "-->" part is a constraint, and it gets
>> >>> validated at compile time every time a sub or method
>> >>> returns.
>> >>>
>> >>> I got to thinking, some routines do not return anything.  Without
>> >>> the "-->" constraint, how am I to determine if something is
>> >>> being returned?
>> >>>
>> >>> Yours in confusion,
>> >>> -T
>>
>> On 10/3/18 6:44 PM, Timo Paulssen wrote:
>> > 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 really point it out before causing
>> > too much confusion.
>> >
>>
>> Hi Timo,
>>
>> Thank you for the help over on the chat line with IN!
>>
>> My confusion is not that it returns something (Mu).
>>
>> My confusion is "what" it returns.
>
>
> I'm not clear on what you mean. When "--> XXX" is given, then an XXX is
> returned. When no "-->" is given, it technically returns Mu but you can
> pretend it is like a Pascal/Module "procedure" that does not return
> anything.
>

Or anything that is a subclass of Mu. That is, anything.

JJ


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

JJ


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
  >>> 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 return
  >>> absolutely whatever it wants.
  >>>
  >>> After all, the "-->" part is a constraint, and it gets
  >>> validated at compile time every time a sub or method
  >>> returns.
  >>>
  >>> I got to thinking, some routines do not return anything.  Without
  >>> the "-->" constraint, how am I to determine if something is
  >>> being returned?
  >>>
  >>> Yours in confusion,
  >>> -T

 On 10/3/18 6:44 PM, Timo Paulssen wrote:
  > 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 really point it out before
 causing
  > too much confusion.
  >

 Hi Timo,

 Thank you for the help over on the chat line with IN!

 My confusion is not that it returns something (Mu).

 My confusion is "what" it returns.  And not all subs
 return things, like "say" and "print".

 I am presuming I am to pick the "what" from context
 from the examples?

 -T


On 10/3/18 7:53 PM, yary wrote:

  > 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 check
for those, right?


-y


Hi Yary,

Ya,  my misunderstanding.  Trey just taught me that.  Home
brew ones too.

$ p6 'sub x($Str) {say $Str};say x("y");'
y
True


I think where I got mixed up was not realizing that the
things subs return can be ignored.  And it is not like I
don't do that all the time either.  I think I just
spaced as in Modula2, you get the finger shaken at you.

Now All I have to figure out is how tot tell "what" is being
returned.  Am I suppose to pick that up from context?

-T



On 10/3/18 10:02 PM, Brad Gilbert wrote:
> 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
> different types.
>
> ---
>
> Note that any returned value that gets ignored will get sunk.
> (That means the `.sink()` method will get called)
>
>  class Baz {
>  method sink () { say 'the result of foo() was sunk' }
>  }
>  sub foo () {
>  Baz.new
>  }
>
>  foo(); # the result of foo() was sunk
>
> So I suppose it is similar to Modula2, except it is up to the writer
> of the class if they shake their finger at you.
> On Wed, Oct 3, 2018 at 10:26 PM ToddAndMargo 

Thank you.  The default return is Mu.  That I get.

How do I figure out what data is being returned? Trial and error?


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
different types.

---

Note that any returned value that gets ignored will get sunk.
(That means the `.sink()` method will get called)

class Baz {
method sink () { say 'the result of foo() was sunk' }
}
sub foo () {
Baz.new
}

foo(); # the result of foo() was sunk

So I suppose it is similar to Modula2, except it is up to the writer
of the class if they shake their finger at you.
On Wed, Oct 3, 2018 at 10:26 PM ToddAndMargo  wrote:
>
> >> 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
> >>  >>> 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 return
> >>  >>> absolutely whatever it wants.
> >>  >>>
> >>  >>> After all, the "-->" part is a constraint, and it gets
> >>  >>> validated at compile time every time a sub or method
> >>  >>> returns.
> >>  >>>
> >>  >>> I got to thinking, some routines do not return anything.  Without
> >>  >>> the "-->" constraint, how am I to determine if something is
> >>  >>> being returned?
> >>  >>>
> >>  >>> Yours in confusion,
> >>  >>> -T
> >>
> >> On 10/3/18 6:44 PM, Timo Paulssen wrote:
> >>  > 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 really point it out before
> >> causing
> >>  > too much confusion.
> >>  >
> >>
> >> Hi Timo,
> >>
> >> Thank you for the help over on the chat line with IN!
> >>
> >> My confusion is not that it returns something (Mu).
> >>
> >> My confusion is "what" it returns.  And not all subs
> >> return things, like "say" and "print".
> >>
> >> I am presuming I am to pick the "what" from context
> >> from the examples?
> >>
> >> -T
>
> On 10/3/18 7:53 PM, yary wrote:
> >  > 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 check
> > for those, right?
> >
> >
> > -y
>
> Hi Yary,
>
> Ya,  my misunderstanding.  Trey just taught me that.  Home
> brew ones too.
>
> $ p6 'sub x($Str) {say $Str};say x("y");'
> y
> True
>
>
> I think where I got mixed up was not realizing that the
> things subs return can be ignored.  And it is not like I
> don't do that all the time either.  I think I just
> spaced as in Modula2, you get the finger shaken at you.
>
> Now All I have to figure out is how tot tell "what" is being
> returned.  Am I suppose to pick that up from context?
>
> -T


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
 >>> 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 return
 >>> absolutely whatever it wants.
 >>>
 >>> After all, the "-->" part is a constraint, and it gets
 >>> validated at compile time every time a sub or method
 >>> returns.
 >>>
 >>> I got to thinking, some routines do not return anything.  Without
 >>> the "-->" constraint, how am I to determine if something is
 >>> being returned?
 >>>
 >>> Yours in confusion,
 >>> -T

On 10/3/18 6:44 PM, Timo Paulssen wrote:
 > 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 really point it out before
causing
 > too much confusion.
 >

Hi Timo,

Thank you for the help over on the chat line with IN!

My confusion is not that it returns something (Mu).

My confusion is "what" it returns.  And not all subs
return things, like "say" and "print".

I am presuming I am to pick the "what" from context
from the examples?

-T


On 10/3/18 7:53 PM, yary wrote:

 > 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 check 
for those, right?



-y


Hi Yary,

Ya,  my misunderstanding.  Trey just taught me that.  Home
brew ones too.

$ p6 'sub x($Str) {say $Str};say x("y");'
y
True


I think where I got mixed up was not realizing that the
things subs return can be ignored.  And it is not like I
don't do that all the time either.  I think I just
spaced as in Modula2, you get the finger shaken at you.

Now All I have to figure out is how tot tell "what" is being
returned.  Am I suppose to pick that up from context?

-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 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 return
 >>>         absolutely whatever it wants.
 >>>
 >>>         After all, the "-->" part is a constraint, and it gets
 >>>         validated at compile time every time a sub or method
 >>>         returns.
 >>>
 >>> I got to thinking, some routines do not return anything.  Without
 >>> the "-->" constraint, how am I to determine if something is
 >>> being returned?
 >>>
 >>> Yours in confusion,
 >>> -T

On 10/3/18 6:44 PM, Timo Paulssen wrote:
 > 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 really point it out before
causing
 > too much confusion.
 >

Hi Timo,

Thank you for the help over on the chat line with IN!

My confusion is not that it returns something (Mu).

My confusion is "what" it returns. 



I'm not clear on what you mean. When "--> XXX" is given, then an XXX is 
returned. When no "-->" is given, it technically returns Mu but you can 
pretend it is like a Pascal/Module "procedure" that does not return 
anything.


And not all subs
return things, like "say" and "print".


That's not the case. "say" and "print" return something that conforms to 
-->Bool:D (in most cases, True).




I am presuming I am to pick the "what" from context
from the examples?


What context or examples are you referring to? Both docs rather clearly 
state that True is typically returned, and in the case of
https://docs.perl6.org/routine/say the very second code example states 
this in English and then shows it with an example.


My misunderstanding!  Even the home spun ones "--> Bool".
Thank you!


$ p6 'sub x($Str) {say $Str};say x("y");'
y
True


Now all I have to figure out is what exactly is being
returned in Mu


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 check for
those, right?


-y





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
> >>> 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 return
> >>> absolutely whatever it wants.
> >>>
> >>> After all, the "-->" part is a constraint, and it gets
> >>> validated at compile time every time a sub or method
> >>> returns.
> >>>
> >>> I got to thinking, some routines do not return anything.  Without
> >>> the "-->" constraint, how am I to determine if something is
> >>> being returned?
> >>>
> >>> Yours in confusion,
> >>> -T
>
> On 10/3/18 6:44 PM, Timo Paulssen wrote:
> > 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 really point it out before causing
> > too much confusion.
> >
>
> Hi Timo,
>
> Thank you for the help over on the chat line with IN!
>
> My confusion is not that it returns something (Mu).
>
> My confusion is "what" it returns.  And not all subs
> return things, like "say" and "print".
>
> I am presuming I am to pick the "what" from context
> from the examples?
>
> -T
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
>


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 everything
> >>> conforms to, i.e. the sub or method that either has "--> Mu"
> >>> explicitly, or has it by leaving it out, may return
> >>> absolutely whatever it wants.
> >>>
> >>> After all, the "-->" part is a constraint, and it gets
> >>> validated at compile time every time a sub or method
> >>> returns.
> >>>
> >>> I got to thinking, some routines do not return anything.  Without
> >>> the "-->" constraint, how am I to determine if something is
> >>> being returned?
> >>>
> >>> Yours in confusion,
> >>> -T
>
> On 10/3/18 6:44 PM, Timo Paulssen wrote:
> > 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 really point it out before causing
> > too much confusion.
> >
>
> Hi Timo,
>
> Thank you for the help over on the chat line with IN!
>
> My confusion is not that it returns something (Mu).
>
> My confusion is "what" it returns.


I'm not clear on what you mean. When "--> XXX" is given, then an XXX is
returned. When no "-->" is given, it technically returns Mu but you can
pretend it is like a Pascal/Module "procedure" that does not return
anything.

And not all subs
> return things, like "say" and "print".


That's not the case. "say" and "print" return something that conforms to -->
 Bool:D (in most cases, True).


>
> I am presuming I am to pick the "what" from context
> from the examples?


What context or examples are you referring to? Both docs rather clearly
state that True is typically returned, and in the case of
https://docs.perl6.org/routine/say the very second code example states this
in English and then shows it with an example.


>
> -T
>
>
> --
> ~~
> Computers are like air conditioners.
> They malfunction when you open windows
> ~~
>


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"
explicitly, or has it by leaving it out, may return
absolutely whatever it wants.

After all, the "-->" part is a constraint, and it gets
validated at compile time every time a sub or method
returns.

I got to thinking, some routines do not return anything.  Without
the "-->" constraint, how am I to determine if something is
being returned?

Yours in confusion,
-T


On 10/3/18 6:44 PM, Timo Paulssen wrote:

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 really point it out before causing
too much confusion.



Hi Timo,

Thank you for the help over on the chat line with IN!

My confusion is not that it returns something (Mu).

My confusion is "what" it returns.  And not all subs
return things, like "say" and "print".

I am presuming I am to pick the "what" from context
from the examples?

-T


--
~~
Computers are like air conditioners.
They malfunction when you open windows
~~


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 really point it out before causing
too much confusion.

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"
>    explicitly, or has it by leaving it out, may return
>    absolutely whatever it wants.
>
>    After all, the "-->" part is a constraint, and it gets
>    validated at compile time every time a sub or method
>    returns.
>
> I got to thinking, some routines do not return anything.  Without
> the "-->" constraint, how am I to determine if something is
> being returned?
>
> Yours in confusion,
> -T


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
anything that could "fall of the end" is Mu.

On Wed, Oct 3, 2018 at 21: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"
> explicitly, or has it by leaving it out, may return
> absolutely whatever it wants.
>
> After all, the "-->" part is a constraint, and it gets
> validated at compile time every time a sub or method
> returns.
>
> I got to thinking, some routines do not return anything.  Without
> the "-->" constraint, how am I to determine if something is
> being returned?
>
> Yours in confusion,
> -T
>


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 junction autothreading.) It's analogous to Perl 5 returning undef if you
don't give it something else to return.

On Wed, Oct 3, 2018 at 9:07 PM 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"
> explicitly, or has it by leaving it out, may return
> absolutely whatever it wants.
>
> After all, the "-->" part is a constraint, and it gets
> validated at compile time every time a sub or method
> returns.
>
> I got to thinking, some routines do not return anything.  Without
> the "-->" constraint, how am I to determine if something is
> being returned?
>
> Yours in confusion,
> -T
>


-- 
brandon s allbery kf8nh
allber...@gmail.com


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 return
   absolutely whatever it wants.

   After all, the "-->" part is a constraint, and it gets
   validated at compile time every time a sub or method
   returns.

I got to thinking, some routines do not return anything.  Without
the "-->" constraint, how am I to determine if something is
being returned?

Yours in confusion,
-T