Re: nested 'our' subs - senseless?
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?
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?
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
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
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?
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?
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?
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
