Re: nested 'our' subs - senseless?

2008-05-05 Thread David Green

On 2008-May-3, at 5:04 pm, John M. Dlugosz wrote:

What does this mean?

our sub outer ()
 {
  ...
  our sub inner () { ... }
 }


inner;  # defined?

I think this should be illegal.  Nested named subs makes sense for  
'my', with the rules of visibility matching the ability to clone the  
closure.  But putting the nested sub into package scope is  
nonsense.  It's really a different clone every time outer is called,  
and doesn't make sense to call unless outer is already pending.


I don't know why it would be any more illegal than "sub foo { our  
$var... }".  The inner sub would be in the package's scope, but the  
name "inner()" would be available only in outer's scope.  So that use  
of "inner" in the last line would be an error.


If inner doesn't actually need anything from outer's block scope,  
then there is no reason to declare it nested.  If you have something  
specific in mind, like creating specific clones on the fly, then the  
code in outer can explicitly post the version it creates to the  
package scope and make it clear exactly when it's being created.


E.g.

our sub outer (::T $x)
 {
  # explicitly create a new multi with every specialization
  state %didit;
  unless ++ %didit{ $x.HOW } {
 my multi sub inner (T $x)  {  ... }
 Package::<&inner> = &inner;
}
 }



Well, for one thing, "Package::inner" in this example is set at run- 
time, while "our sub inner" in your first example is declared at  
compile-time, right?



-David



Re: nested 'our' subs - senseless?

2008-05-05 Thread John M. Dlugosz

Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:

On Mon, May 5, 2008 at 6:01 AM, John M. Dlugosz
<[EMAIL PROTECTED]> wrote:
  

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:



No, because {...} is just a declaration. You can give a
definition later in the surrounding module/package/class.
Within that scope there can be only one definition, of course.

  

 I did not mean to use { ... } to mean declaration only, but to show that I
omitted the good stuff.  In Perl 6, it is not "declaration only" but a body
that doesn't complain when it is redefined, so that should not matter.



Given that Perl 6 assigns a specific meaning to '{ ... }', it's
recommended that examples that omit code instead be written as '{ doit
}' or the like.

  
Larry said it should be clear from context, either way something is 
omitted. 

And an actual { ... } body does not change the meaning here.  It just 
allows that the sub can be redefined without error, but does not change 
how it is entered into the symbol tables now.


--John


Re: nested 'our' subs - senseless?

2008-05-05 Thread Jon Lang
On Mon, May 5, 2008 at 6:01 AM, John M. Dlugosz
<[EMAIL PROTECTED]> wrote:
> TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
>
> >
> > No, because {...} is just a declaration. You can give a
> > definition later in the surrounding module/package/class.
> > Within that scope there can be only one definition, of course.
> >
>
>  I did not mean to use { ... } to mean declaration only, but to show that I
> omitted the good stuff.  In Perl 6, it is not "declaration only" but a body
> that doesn't complain when it is redefined, so that should not matter.

Given that Perl 6 assigns a specific meaning to '{ ... }', it's
recommended that examples that omit code instead be written as '{ doit
}' or the like.

-- 
Jonathan "Dataweaver" Lang


Re: New specdoc available

2008-05-05 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


In "24.28.1 abs" you define

  our ::?CLASS multi method abs ( $x: )

I would rather nail down the return type to 'Num where {$_ >= 0}'.
The latter might also get a nice name, e.g. Abs. This in turn would
make the abs multi method/sub kind of redundant.

I guess that the standard set of functions/methods mustn't contain
a norm as extension to the above.




I think I listed a single method of this class because it was mentioned 
in the synopses somewhere.  That is, just gathering what is already 
stated, not fleshing it out yet.


Shouldn't abs return the same kind of class it was run on?  That is, Int 
in this case, not Num.  Should it be generic and simply work for all 
types that have the +/- concept?  Count on member dot syntax deferring 
to sub calls to still allow $x.abs instead of abs($x) to work.


my Int $y = $x.abs;# should be Int without complaint, not
 # coersion of Num back to Int.


For factoring out such things, we need to better define the "interfaces" 
that will be used for generic code.  For example, we can have 
ispositive/isnegative tests without full ordering, and perhaps generic 
code that called .isnegative would be more efficient than comparing < 0 
especially when you need to remember to turn 0 into the correct type.


--John


Re: New specdoc available

2008-05-05 Thread TSa

HaloO,

John M. Dlugosz wrote:
I posted my current work at 
http://www.dlugosz.com/files/specdoc.pdf

Please look.


In "24.28.1 abs" you define

  our ::?CLASS multi method abs ( $x: )

I would rather nail down the return type to 'Num where {$_ >= 0}'.
The latter might also get a nice name, e.g. Abs. This in turn would
make the abs multi method/sub kind of redundant.

I guess that the standard set of functions/methods mustn't contain
a norm as extension to the above.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan


Re: nested 'our' subs - senseless?

2008-05-05 Thread John M. Dlugosz

TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:


No, because {...} is just a declaration. You can give a
definition later in the surrounding module/package/class.
Within that scope there can be only one definition, of course.


I did not mean to use { ... } to mean declaration only, but to show that 
I omitted the good stuff.  In Perl 6, it is not "declaration only" but a 
body that doesn't complain when it is redefined, so that should not matter.


Re: What does 'eqv' do exactly?

2008-05-05 Thread TSa

HaloO,

John M. Dlugosz wrote:

Yes.  How is a snapshot different from the object?


My interpretation is that === is an equivalence relation
on a WHICH set and eqv is an equivalence relation on a
WHAT set. A "mutable value" is an element of a (n>1):1 mapping
of a subset of WHAT to a single WHICH. A 1:1 mapping is an
"immutable value". A 1:(m>1) mapping has no funny name. Neither
has a n:m mapping. IOW, a value is a subset of the cartesian
product of the WHAT and WHICH sets. A snapshot of a value is
picking one element of that set. For == the WHAT is Num and for
eq it is Str. Both map 1:1 to their respective WHICH sets. The
=:= checks binding of names so it is an equivalence relation
on a set of names. But I'm unsure if such a set is denoted with
WHO or VAR. But I tend to think it's the latter.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan


Re: nested 'our' subs - senseless?

2008-05-05 Thread TSa

HaloO,

John M. Dlugosz wrote:

What does this mean?

our sub outer ()
  {
   ...
   our sub inner () { ... }
  }


inner;  # defined?


No, because {...} is just a declaration. You can give a
definition later in the surrounding module/package/class.
Within that scope there can be only one definition, of course.

The above just is the same as

   sub outer () {...}
   sub inner () {...}

unless of course a sub special form also creates an 'our' scope.
Well, or I don't understand what 'our' means.


I think this should be illegal.  Nested named subs makes sense for 'my', 
with the rules of visibility matching the ability to clone the closure.  
But putting the nested sub into package scope is nonsense.  It's really 
a different clone every time outer is called, and doesn't make sense to 
call unless outer is already pending.


Sorry, I have the impression you mix up the definition of the
inner sub and the creation of invocations of it. Why should an
invocation of outer also invoke inner? Or why should that cause
a re-definition at runtime or some such.


If inner doesn't actually need anything from outer's block scope, then 
there is no reason to declare it nested.  If you have something specific 
in mind, like creating specific clones on the fly, then the code in 
outer can explicitly post the version it creates to the package scope 
and make it clear exactly when it's being created.


If I understand that correctly, then it's orthogonal to the issue
of scoping. Yet in other words, writing the definition of inner into
outer is a matter of taste, like e.g. indentation style.



our sub outer (::T $x)
  {
   # explicitly create a new multi with every specialization
   state %didit;
   unless ++ %didit{ $x.HOW } {
  my multi sub inner (T $x)  {  ... }
  Package::<&inner> = &inner;
 }
  }


Why should a programmer do a compiler's task? Note that the last line
simply overwrites the previous binding of the symbol unless multis
have special assignment semantics. So I think it should read

&OUR::inner:(T) = &inner;

I always thought that a generic sub is about sharing a single
body between several types. The above seems to require different
bodies for different bindings of ::T. That is the task of a multi
sub. Now if you can write a type function that computes the
implementations from the input types then you can eagerly call
that at compile time or lazily at runtime. In the latter case you
can cache the implementations if you like. But you can also forget
them as needed because they can be re-computed. Thus dispatch is
just an implementation strategy to fit the abstract concept onto
a concrete, finite machine.


Regards, TSa.
--

"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12  -- Srinivasa Ramanujan