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 <toddandma...@zoho.com
<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 <toddandma...@zoho.com>

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

Reply via email to