Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall wrote: : Do the following exist then: :has @x; # private, lexically scoped [...] :has %y; # private, lexically scoped [...] Yes, the sigil is fairly orthogonal to all this, hopefully. Yes, for isn't the sigil just a compact form of saying "does Hash" or "does Array" ? (as well as being part of the unique name, of course) Sam.
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On 7/21/05 8:14 PM, Larry Wall wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
>> The only thing I immediately don't like is the use of the normal identifier
>> character "_" to indicate the "specialness" of a particular variable (or
>> attribute or whatever we're calling them these days). IMO, a "_" should
>> just be a "_" no matter where it occurs. Making a leading "_" mean
>> something special (triggering a slew of new semantics) in a particular
>> context seems a bit hacky to me.
>>
>> Damian may not like the colon, but I couldn't help thinking that the "_"
>> could be replaced with ":" and things would be cleaner.
>
> Well, but the _ really is part of the name, insofar as it's trying to
> isolate the namespace. Even with : we had to say that it would probably
> be stored in the symbol table with the leading colon.
Eh, an implementation detail (or, arguably, syntactic sugar for symbol table
lookups, depending on how it was "really" implemented in Parrot).
> Plus history is on the side of leading _ meaning "private implementation
> detail"
Sure, by *convention*, not as imperative magic :)
> and the : is awfully confusing in the neighborhood of adverb pairs. If it
> were just sigiled variables, the : would probably be fine, but
>
> method :foo() {...}
>
> just has a strangeness to it that won't go away. Arguably that's a feature,
> but I'm mostly worried with visual confusion with all the other colons
> in Perl 6.
I'm not married to the colon. Speaking of traits and adverbs, why not use
one of those in the "has" declaration instead? That'd certainly be a lot
more explicit than the magic leading underscore (although I'm at a loss as
to what the trait would be named...)
-John
Re: Tail method calls, can(), and pre-currying
On Thu, Jul 21, 2005 at 11:58:41AM -0300, Adriano Ferreira wrote:
: Larry said:
: > So I guess I agree that .tailcall is probably just a bad synonym for
"return".
:
: But is there any other case where we need an explicit tail call with "goto"?
I suppose that depends on whether the tail-call optimization is
general enough to work indirectly at run time.
: And about a way to curry a method with its receiver to a sub, is there
: a shorthand?
$sub = &ThatClass::meth.assuming($obj);
is the shortest thing that specifies the other class.
$sub = &meth.assuming($obj);
should work if the method would be selected by MMD. I'd think a lot of
these cases are actually covered by currying the class to have an
implicit invocant, turning it into a module. Other than that, there's
always something like:
$sub = -> [EMAIL PROTECTED] { $obj.meth(@args) };
which presumably can optimize the tailcall away. Possibly
$sub = { $obj.meth(@_) };
could be forced to recognize that @_ is the slurpy arg to the closure.
Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thu, Jul 21, 2005 at 10:17:13PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Larry Wall wrote:
: >has $x; # private rw, no accessors, not virtual, name lexically
: >scoped
: >
: >has $_x; # private rw, rw _x accessor, not virtual, name class scoped
:
: Even if I come across as intellectually handicapped but could
: someone help me over this mental bridge: What is the difference
: between these two scopes?
:
: class Foo
: {
: #class scope starts here
:
: has $x; # where does this go if not Foo::x
The name goes into the lexical scope, but it generically represents
a slot in the instance.
: has $_y; # this goes into Foo::_y
:
: # both $x and $_y can be used in code from here on
: # and refer to the same two things respectively, right?
$x is visible only in the rest of the lexical scope. In contrast,
$_y would presumably still be visible if the class were reopened.
: # or does class scope mean shared by all instances
: # and lexically scopes per instance?
Class scope is basically package scope. For instance attributes and
methods the package contains proxies representing the slots in the
actual instance.
: #class scope ends here
: }
:
:
:
: >Other thinkings:
: >
: >* Any self method can be called via $.x(@args) syntax, short for
: > $?SELF.x(@args).
:
: Isn't & the code sigil?
Sure, if you want to declare an attribute containing a code reference.
But & doesn't have much to do with the call syntax in any event,
whether you're calling subs or methods. You can declare an attribute
as &.foo and call it as $.foo without a problem, since it's just
$?SELF.foo() either way, and the accessor methods are not associated
with sigils. I think $.foo and &.foo are synonymous as attributes,
except insofar as we can probably deduce that &.foo is dealing with
a sub ref and not just any old scalar value.
: >* All roles can write completely private $x attributes that are not
: > visible outside their lexical scope but are nevertheless
: > per-instance.
:
: I understand that correctly, that $x in
:
:role Foo { has $x = 7; method foo { $x++ } }
:
: denotes a reference to an Item from the data environment of the object
: that foo is invoked on.
I don't know what you mean by "data environment". The second
occurrence of $x denotes the generic proxy declared by the "has"
that represents an eventual slot in the actual instance. This slot
presumably has no other obvious name to any other role or to the
class that composes this role, though presumably there's an internal
way to get back from a particular slot to the slot's metadata, which
presumably knows which role supplied the definition.
: The type of the $?SELF that Foo is composed into
: obviously is a subtype of Foo. What happens with this hidden payload if
: the object changes its type such that it is no Foo anymore? E.g. by
: undefining the slot &.Foo::foo?
Um, people who undefine functions that are going to be called later get
what they deserve. As for what happens to $x's slot in the absence
of the lexical reference from &Foo::foo, I expect the metadata would
still have pointers to it so it wouldn't necessarily be reclaimed
unless you told the object that is "undoes" Foo. Or to look at it
another way, all the objects that "do" Foo have a closure over that
$x proxy, so it's not going to go away until everyone forgets about
the Foo role itself.
Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
: On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
: > Have at it...
:
: The only thing I immediately don't like is the use of the normal identifier
: character "_" to indicate the "specialness" of a particular variable (or
: attribute or whatever we're calling them these days). IMO, a "_" should
: just be a "_" no matter where it occurs. Making a leading "_" mean
: something special (triggering a slew of new semantics) in a particular
: context seems a bit hacky to me.
:
: Damian may not like the colon, but I couldn't help thinking that the "_"
: could be replaced with ":" and things would be cleaner. Example:
Well, but the _ really is part of the name, insofar as it's trying to
isolate the namespace. Even with : we had to say that it would probably
be stored in the symbol table with the leading colon. Plus history is
on the side of leading _ meaning "private implementation detail", and
the : is awfully confusing in the neighborhood of adverb pairs. If it
were just sigiled variables, the : would probably be fine, but
method :foo() {...}
just has a strangeness to it that won't go away. Arguably that's a feature,
but I'm mostly worried with visual confusion with all the other colons
in Perl 6.
Plus, the leading underscore would only be magical on attributes and
methods, I suspect.
Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thu, Jul 21, 2005 at 05:15:34PM -0400, Stevan Little wrote:
: Larry,
:
: This means that Roles are now first-class-ish things. Meaning they
: cannot just simply be composed into classes since now we have to keep a
: table of elements which are private to a Role.
Well, we've kinda been squinting at that issue from both ends for a
while now, and there's something in both views.
: I personally don't like this, I think it brings us back to Mix-ins and
: (possibly) looses some of the benefits of Roles. But that is just my
: initial gut reaction. I am going to have to let is sink in a little
: more to know for sure. In the meantime I have some questions:
:
: On Jul 21, 2005, at 2:48 PM, Larry Wall wrote:
: >* All roles can write their shared attributes as $.x and not worry
: > about whether the class declares them or not.
:
: I assume they need not worry because we can rely on conflict resolution
: to deal with most issues? Or are you thinking something different?
No, that's correct. We've just basically said that $.x is now a method
call, and as long as you stick to that invocation syntax it just has
to be declared as a method somewhere in the parentage/role-age of
this object. But collisions in $.x declaration will be treated as
collisions in method declaration.
: >* All roles can write completely private $x attributes that are not
: > visible outside their lexical scope but are nevertheless
: > per-instance.
:
: So the Role's scope is preserved here, as opposed to pushing $x into
: the classes scope. Correct?
My notion is that $x (the name proxy) is stored in the lexical scope
of the closure that just happens to be the closure for the role,
rather than keeping a name proxy in the package. In either case,
$x or $.x is not a real variable, but a placeholder for a particular
slot in the object. The actual proxy could be stored in the role's
package if that makes it easier to keep track of, but I'd like the
scoping of the name to be lexical like an "our" in that case. But if
we can figure out how to store it more like a "my" variable but still
figure out which slot it maps to when instantiated, that might be cool.
Unfortunately, it could map to different slots in different objects,
so the class in question would have to keep track of where MyRole::('$x')
actually maps to.
It's certainly possible that this notion doesn't really map terribly
well onto roles. I was just hoping for a way to encourage people
to write private attributes, and shortening $.x to $x for that seemed
like good huffmanization in the class, as long as $x actually scopes
to being very private and doesn't interfere in any way with the
class's public interface. So basically if the role can carry the
same idea through and allow "local" attributes that have guaranteed
zero influence on the interface, that'd be cool too.
: >* All roles can write explicitly shared $_x attributes that are
: >private
: > to the class but visible to other roles and trusted classes.
:
: What other roles? the other roles that the class does()?
That's what I meant. $_x variables are the old $:x, basically, and
while they have some kind of proxy in the class's package space, the
leading character is examined to enforce namespace distinction and
some amount of privacy. Like the old $:x they also imply private
accessors that are really little more than subs you can call with
method syntax.
: This would
: make it difficult to compose role methods into the method table without
: bringing along a lot of meta-info about from whence they came. It is
: doable I think, but adds some complexity for which I am not sure the
: cost outweighs the benefits.
It's possible that roles should only do the class-based $_x and $.x,
and leave the lexically named $x to the class, unless we can figure
out how the class can keep track of the role's lexical scope and/or
package.
But I like the $x/$.x distinction for classes, since it encourages
people to write completely private attributes to begin with, and
then maybe take the step of adding a dot when the want to provide
an accessor.
One other implementation downside I didn't mention is that it makes
it a little harder to decide that
submethod BUILD ($x) {...}
wants to set the private $x attribute. Though in theory we can see the $x
declaration from the BUILD declaration. However, we still get
submethod BUILD ($_x) {...}
pretty much for free.
Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry, This means that Roles are now first-class-ish things. Meaning they cannot just simply be composed into classes since now we have to keep a table of elements which are private to a Role. I personally don't like this, I think it brings us back to Mix-ins and (possibly) looses some of the benefits of Roles. But that is just my initial gut reaction. I am going to have to let is sink in a little more to know for sure. In the meantime I have some questions: On Jul 21, 2005, at 2:48 PM, Larry Wall wrote: * All roles can write their shared attributes as $.x and not worry about whether the class declares them or not. I assume they need not worry because we can rely on conflict resolution to deal with most issues? Or are you thinking something different? * All roles can write completely private $x attributes that are not visible outside their lexical scope but are nevertheless per-instance. So the Role's scope is preserved here, as opposed to pushing $x into the classes scope. Correct? * All roles can write explicitly shared $_x attributes that are private to the class but visible to other roles and trusted classes. What other roles? the other roles that the class does()? This would make it difficult to compose role methods into the method table without bringing along a lot of meta-info about from whence they came. It is doable I think, but adds some complexity for which I am not sure the cost outweighs the benefits. Have at it... Stevan
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thu, Jul 21, 2005 at 02:29:33PM -0600, Paul Seamons wrote: : On Thursday 21 July 2005 12:48 pm, Larry Wall wrote: : > * Don't need to topicalize self any more. : > : > * .foo can (again) always be the topic without warnings. : : Thank you. : : Do the following exist then: : :has @x; # private, lexically scoped : :has @_x; # private, class scoped, rw _x accessor : :has @.x; # read only, implies @_x for storage, is virtual ($obj.x) : :has @.x is rw; # implies @_x for storage, is virtual : :has %y; # private, lexically scoped : :has %_y; # private, class scoped, rw _y accessor : :has %.y; # read only, implies %_y for storage, is virtual ($obj.y) : :has %.y is rw; # implies %_y for storage, is virtual Yes, the sigil is fairly orthogonal to all this, hopefully. Larry
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thursday 21 July 2005 12:48 pm, Larry Wall wrote: > * Don't need to topicalize self any more. > > * .foo can (again) always be the topic without warnings. Thank you. Do the following exist then: has @x; # private, lexically scoped has @_x; # private, class scoped, rw _x accessor has @.x; # read only, implies @_x for storage, is virtual ($obj.x) has @.x is rw; # implies @_x for storage, is virtual has %y; # private, lexically scoped has %_y; # private, class scoped, rw _y accessor has %.y; # read only, implies %_y for storage, is virtual ($obj.y) has %.y is rw; # implies %_y for storage, is virtual Paul
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
Larry Wall wrote:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x;# private rw, rw _x accessor, not virtual, name class scoped
Even if I come across as intellectually handicapped but could
someone help me over this mental bridge: What is the difference
between these two scopes?
class Foo
{
#class scope starts here
has $x; # where does this go if not Foo::x
has $_y; # this goes into Foo::_y
# both $x and $_y can be used in code from here on
# and refer to the same two things respectively, right?
# or does class scope mean shared by all instances
# and lexically scopes per instance?
#class scope ends here
}
Other thinkings:
* Any self method can be called via $.x(@args) syntax, short for
$?SELF.x(@args).
Isn't & the code sigil?
* All roles can write completely private $x attributes that are not
visible outside their lexical scope but are nevertheless per-instance.
I understand that correctly, that $x in
role Foo { has $x = 7; method foo { $x++ } }
denotes a reference to an Item from the data environment of the object
that foo is invoked on. The type of the $?SELF that Foo is composed into
obviously is a subtype of Foo. What happens with this hidden payload if
the object changes its type such that it is no Foo anymore? E.g. by
undefining the slot &.Foo::foo?
Regards,
--
TSa (Thomas Sandlaß)
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote: > Have at it... The only thing I immediately don't like is the use of the normal identifier character "_" to indicate the "specialness" of a particular variable (or attribute or whatever we're calling them these days). IMO, a "_" should just be a "_" no matter where it occurs. Making a leading "_" mean something special (triggering a slew of new semantics) in a particular context seems a bit hacky to me. Damian may not like the colon, but I couldn't help thinking that the "_" could be replaced with ":" and things would be cleaner. Example: has $x; # private rw, no accessors, not virtual, name lexically scoped has $:x;# private rw, rw _x accessor, not virtual, name class scoped has $.x;# has read-only method # $.x always virtual # implies existence of "real" $:x internal variable # $.x is itself read-only even in this class # $:x may be set in methods or submethods # both names are class scoped ...and so on. Other than that, I like where it's going. I would like to see some example scenarios to convince myself that it really does address the concerns indicated at the start of the explanation, however. Maybe Luke and Sam can whip some up? :) -John
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
HaloO Sam,
you wrote:
This in turn implies that the $.foo syntax is, in general, bad
practice!
Yup.
I claim the opposit. But I might have a very different meaning in mind
when I say that. So it's opposit in an orthogonal direction :)
Not very huffmanised, is it?
The syntax is just right for the statefull, imperative programming style.
If that is not your thing, so be it.
Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute
$.SUPER::foo
Hmm? Isn't a $ sigil expression a single scalar typed, referential
expression anymore? The secondary . sigil is in my eyes just perfect
to express self reference! If I use %.arm to scratch %.leg
it is pretty much clear which particular parts of my body are involved.
And if I give a rw reference to $.guts to a surgeon method it is just one
possible result that some parts have become undefined or look funny ;)
And yes, this means a *dynamic* change of self type! E.g. a changing
$.belly_circumference could change a man from .does(LeightWeight) to
.does(HeavyWeight).
What I do *not* understand is what or where $.SUPER::brain should
refer to. If Perl6 avoids the problem of 'schizophrenic self reference'
where some methods make false assumptions about the object layout
or have access to hidden parts then all methods which shall be applicable
to the object's referential environment must be type sound. This means for
example that the type system prevents dispatches to base class methods
even though the invocant is instanciated from a derived class. This is a
typical example where Rotweiler instances are *not* a subtype of Dog
instances---at least not as far as playing is concerned.
The example with the $.collar in the Rotweiler class could be
solved by forcing the slot into outside constness which has
the side-effects that the Pet::loose_collar method is not applicable
and thus the $?SELF.lose_collar() call in Dog::play has to dispatch
elsewhere or fail! In other words: Rotweiler.does(Dog::play) is false!
A strong type system can find that out, a weaker one let's the code
die in Pet::loose_collar on const assignment.
Then we could even sneak in making $.foo(bar) a not-so-offensive
./foo(bar),
with ($.foo)(bar) meaning what $.foo(bar) currently means. But that really
is a seperate issue, and speculation of it meaningless if we retain the
current specified behaviour.
I'm seeking a solution along the ideas of homogenious self reference
as outlined above. This would e.g. allow the &.foo code ref to mean
a ref to the most specific method applicable to the self type unless
the programmer has arranged that something else is stored there.
As long as the method requires arguments there is just the one char
inconvenience of typing &.foo(1,2) instead of .foo(1,2) or whatever
syntax implicitly derefs and calls &.foo with $?SELF as the invocant.
Then there is also room for some dwimmery for dispatching .foo through
$?SELF when the type of $_ would fail the dispatch. So from a certain
point of view I like $Larry's ruling that the compiler has to statically
insure that the self type puts the invocant into a fair position for the
dispatch at hand. Perl6 is (type)strong in the source ;)
Another thing I do not understand from a typing point of view is how
perlkind expects a simple .foo expression in the lexical scope of a
class which defines a method foo to be usefull on a random $_ with a
type that is incompatible with the $?SELF type of the invocant of the
method that this .foo call happens to be written. An example:
class FooDefiner
{
has $.text = 'FooDefiner hit';
method foo { say $.text }
method foocaller
{
for 1..3 { .foo } # 1
for 1..3 { foo } # 2
}
}
I think compile time name lookup in both lines resolves to
&FooDefiner::foo which requires a self type of ::FooDefiner
and I think that Int.does(FooDefiner::foo) is false. So an
invocation of &FooDefiner::foocaller would simply produce
a type error or six warnings and no printout if the foo calls
are dispatched over $_, right?
Regards,
--
TSa (Thomas Sandlaß)
Re: Do I need "has $.foo;" for accessor-only virtual attributes?
On Thu, Jul 21, 2005 at 05:16:39PM +1200, Sam Vilain wrote:
: Making $.foo =:= $?SELF.foo, and getting to the "raw" attribute $.SUPER::foo
: seems like the better solution to me. But of course, it would, because
: that's
: how *I* program, and $?SELF != all(@coders).
:
: Then we could even sneak in making $.foo(bar) a not-so-offensive ./foo(bar),
: with ($.foo)(bar) meaning what $.foo(bar) currently means. But that really
: is a seperate issue, and speculation of it meaningless if we retain the
: current specified behaviour.
That's kind of the direction I've been thinking while I was driving,
but there are many ramifications. Of course, the nice thing about
ramifications is that it presents an opportunity to possibly clean
up some other infelicities, such as getting rid of the privacy colon,
which doesn't play well with the rest of the language, and which Damian
has been wanting to get rid of. It also lets us do some unification
of the private variables with the internal representation of public
variables, something Luke has been asking about for ages. It solves
the virtual redefinition problem posed by Sam, and it unifies the
concept of attribute and method "slots" under a single syntax. Oh,
it also is a solution to the self-call problem.
At the moment I'm thinking of something along these lines:
has $x; # private rw, no accessors, not virtual, name lexically scoped
has $_x;# private rw, rw _x accessor, not virtual, name class scoped
has $.x;# has read-only method
# $.x always virtual
# implies existence of "real" $_x internal variable
# $.x is itself read-only even in this class
# $_x may be set in methods or submethods
# both names are class scoped
has $.x is rw;
# has rw virtual method
# $.x is also always virtual
# implies existence of "real" $_x internal variable
# $.x is virtually rw in this class
# $_x is non-virtually rw in this class
# setting $_x limited to submethods
# warning if you set $_x in ordinary method
method x () {...}
# as before
method _x () {...}
# an explicitly private method
and possibly
has method x () {...}
# implicitly private method, not callable by trustees
# lexically scoped name like "has $x"
# could be "my method" instead
Other thinkings:
* Any self method can be called via $.x(@args) syntax, short for
$?SELF.x(@args).
* Any private method can be called via $_x(@args) syntax, short for
$?SELF._x(@args), assuming the private call is allowed at all.
* Trusted classes can use the $other._x(@args) syntax to call your private
accessors, but only on $_x attributes and _x methods, not on completely
private $x attributes.
* @.x(@args) is short for $?SELF.x(@args)[]
* %.x(@args) is short for $?SELF.x(@args){}
* &.x(@args) is short for $?SELF.x(@args).
* Extra parens are required when using this syntax to return a function
pointer that you then want to call, either $.x()() or ($.x)(). (Or
maybe we make &.x(@args) imply one set of parens.)
* All roles can write their shared attributes as $.x and not worry
about whether the class declares them or not.
* All roles can write completely private $x attributes that are not
visible outside their lexical scope but are nevertheless per-instance.
* All roles can write explicitly shared $_x attributes that are private
to the class but visible to other roles and trusted classes.
* You may not declare both $_x and $.x because a declaring of $.x is
actually declaring $_x underneath.
* You *may* declare both $x and $.x because they are invisible to each
other.
* "has $x" has no effect on method dispatch, either public or private.
* "has $_x" has no effect on public method dispatch.
* Don't need to topicalize self any more.
* .foo can (again) always be the topic without warnings.
Have at it...
Larry
Re: Hash creation with duplicate keys
On Thu, Jul 21, 2005 at 11:21:05AM -0600, Luke Palmer wrote:
: On 7/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
: > Hi,
: >
: > # Perl 5
: > my %hash = (a => 1, b => 2, a => 3);
: > warn $hash{a}; # 3
: >
: > But I vaguely remember having seen...:
: >
: > # Perl 6
: > my %hash = (a => 1, b => 2, a => 3);
: > say %hash;# 1
: >
: > Can somebody confirm this?
:
: Yes. This is for the case:
:
: foo(a => 1, *%defaults);
:
: So that foo's $a gets one even if it exists in %defaults.
It's likely that the leftmost-wins rule applies only to binding,
not assignment.
Larry
Re: Referring to package variables in the default namespace in p6
"TSa (Thomas Sandlaß)" wrote:
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.
When something knows that it is being evaluated in lvalue context, it
should probably return something like "undef but autovifify:{...}". The
assignment operator could then check for the "autovivify" property when
its LHS is undefined.
Re: Hash creation with duplicate keys
On 7/20/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Hi,
>
> # Perl 5
> my %hash = (a => 1, b => 2, a => 3);
> warn $hash{a}; # 3
>
> But I vaguely remember having seen...:
>
> # Perl 6
> my %hash = (a => 1, b => 2, a => 3);
> say %hash;# 1
>
> Can somebody confirm this?
Yes. This is for the case:
foo(a => 1, *%defaults);
So that foo's $a gets one even if it exists in %defaults.
Luke
Re: Referring to package variables in the default namespace in p6
HaloO Matthew,
you wrote:
I wasn't getting hung up on whether $::($varname) should somehow be
cached to avoid a dynamic lookup based on the current value of $varname
every time. And I assume that if $*Main::foo hadn't been created,
assigning to $::($varname) would create it as expected (again, without
any caching of $varname).
Here your expectations might be disappointed, sorry.
The non-symbolic form $*Main::foo = 'bar' creates code that
makes sure that the lhs results in a proper scalar container.
The symbolic form might not be so nice and return undef!
Then undef = 'bar' of course let's your program die.
Unfortunately I'm unsure how the runtime interface to
making dynamic namespace entries looks like. Note that
the operator ::= acts at compile time, too.
My guess is that the compiler collects all potential data
items and arranges for auto-vivification and/or autoloading
and even on-the-fly instance composition and such like things.
But for symbolics this is your task.
My confusion initially stemmed from chat on #perl6 about $::Foo and
$::('Foo') being Very Different Things - and the fact that there was
ever any confusion over whether $::foo was your 'closest' $foo variable
or something else.
So to conclude, for reading they amount to the same result but through
different paths. But since the symbolic lookup might result in undef
the behaviour for writing is indeed a Very Different Thing.
@Larry, please correct if I gave wrong advice.
--
TSa (Thomas Sandlaß)
Re: Tail method calls, can(), and pre-currying
Larry said: > So I guess I agree that .tailcall is probably just a bad synonym for "return". But is there any other case where we need an explicit tail call with "goto"? And about a way to curry a method with its receiver to a sub, is there a shorthand? Thanks, Adriano.
Re: Tail method calls, can(), and pre-currying
On Thu, Jul 21, 2005 at 09:59:57AM -0300, Adriano Ferreira wrote:
: I can understand the convenience of turning a method into a subroutine
: by currying the object. Syntactical support for this seems cool too.
: But, can someone remind me why there is the need for an explicit tail
: call syntax? It has to do with some oddity of Perl in some situations
: that prevents the code generator to infer that should be a a tail
: call? I am thinking about how tail calls are handled in languages like
: Scheme or Lua. In these,
:
:sub f ( $a ) {
: return g($a);
:}
:
: urges for (and compiles to) a tail call with no need for explicit
: marks by the programmer. Obviously, in Perl, there are some issues
: with the calling context that should be propagated to the callee.
Though, arguably, g is probably more interested in the context of f in
this case, so automatic tailcall optimization is not necessarily throwing
away any information that the return would not have to pass down to
g() anyway. So I guess I agree that .tailcall is probably just a bad
synonym for "return".
: Also getting tail method calls right is an immediate win for the issue
: of implementing delegation. Am I right?
Yes, presuming the delegator doesn't want to capture control again after
the delegation. But delegation is just syntactic sugar anyway, so
if you want control back you should just write it that way explicitly
and the tailcall disappears.
Larry
Re: MML dispatch
chromatic wrote:
Why would a class not also define a type?
It does. A class is an instance generator. So all instances
share the same property of 'beeing instanciated from SomeClass'.
This can be used to type them. Question is where this type is
placed in the type lattice and how it compares to the type of
structurally/semantically identical objects beeing instanciated
from another class.
My proposal is to hang the type off the top, most unspecific
type Any or actually a bit further down, under Object
which excludes Package, Module, Class, Grammar and Role.
The name of the class is inserted in the appropriate place into
the namespace and is available as type parameter for the Ref[::T]
role.
It is actually quite interesting that there is no special form
for compile time object instantiation with the keyword object.
class Point
{
has Num $.x;
has Num $.y;
}
object center of Point # without of we get classless objects
{
.x = 23;
.y = 42;
}
object pi of Num = 3.14;
our Int object answer = 42;
say answer; # prints 42
say center.x # prints 23
# and even more
our Array object some_values = (1,2,3,4,5);
for some_values { say }
Hmm, looks somewhat unperlish :))
--
TSa (Thomas Sandlaß)
Re: Referring to package variables in the default namespace in p6
On Thu, 21 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variable.
Let me restate that in my own words. You mean that a symbolic runtime
lookup $::($Foo) with the value of $Foo at that time shall be cached
in the immediatly surrounding namespace and that cached ref is then
accessable through the syntax $::Foo?
Hm, I seem to be making a bit of a pigs ear of explaining myself here, but
thank you for bearing with me. What I was trying to confirm was that
if you create a variable in your immediately surrounding namespace:
$*Main::foo = 'bar'; # (assuming you are in the default namespace)
and a variable containing the string 'foo':
my $varname = 'foo';
then the principle of least surprise suggests to me that the result of
evaluating $::($varname) should be identical to that of evaluating $::foo.
I wasn't getting hung up on whether $::($varname) should somehow be cached
to avoid a dynamic lookup based on the current value of $varname every
time. And I assume that if $*Main::foo hadn't been created, assigning to
$::($varname) would create it as expected (again, without any caching of
$varname).
My confusion initially stemmed from chat on #perl6 about $::Foo and
$::('Foo') being Very Different Things - and the fact that there was ever
any confusion over whether $::foo was your 'closest' $foo variable or
something else.
BTW, I wonder if $::() means $::($_) :)
hehe; that would almost be nice... :)
Otherwise the two $::... forms would be horribly confusingly different
Sorry, they are the same thing: namespace lookup. But without ::() the
compiler does it at compile time for bareword resolving. Without a sigil
in front the result can be used where a type is expected:
for ("blahh", "fasel", "blubber") -> $name
{
($name).new;
}
We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
I dought that assigning two different meanings just because their
are two syntactical forms is a good idea.
Fantastic - all my fears are allayed, then. $::foo is $::('foo') is $foo
(assuming it hasn't been our'd or my'd), and all is well in the world.
[lest] I (and other future legions of newbies) would despair. :)
You consider yourself a 'legion of newbies' ;)
Well, earlier I may have been legion, but I think i've regained my karmic
balance a bit now... ;)
cheers;
M.
Re: More on Roles, .does(), and .isa() (was Re: Quick OO .isa question)
chromatic wrote:
On Tue, 2005-07-19 at 18:47 +0200, "TSa (Thomas Sandlaß)" wrote:
I strongly agree. They should share the same namespace. Since
code objects constitute types they also share this namespace.
This means that any two lines of
class Foo {...}
roleFoo {...}
sub Foo {...}
method Foo {...}
subtype Foo of Any where {...}
in the same scope should be a simple redefinition/redeclaration error.
I don't understand this. What does a scope have to do with a namespace?
I meant a scope of source code, basically everything delimited by braces.
And that nesting of braces *is* the namespace, or not? Well, at least the
compile time view of it.
The Perl6 namespace is available at runtime as well. But it is beyond me
how much these differ. But for the specification of the language only the
source code aspect is relevant.
Why does a code object constitute a type?
Is this more a 'how do function types work' question or
are you doughting the usefullness of this concept for Perl6?
The sort function e.g. takes a parameter of type Comparator
which is a code type describing instances that accept two parameters
of the type that is to be sorted and return a value of a type
that describes the relative order implemented by the comparator.
Actually the Comparator is usually a parametric type, that is
instanciated with concrete types and thus forming a non-parametric
code type. The invokation of such a type are the instances of the
type. During a sort run many of these instances are created.
I can understand there being separate types, perhaps, for Method,
Submethod, MultiSub, MultiMethod, and so on,
... and subtypes thereof.
but I don't understand the
purpose of sharing a namespace between types and function names,
What should 'mysubtype' in the following signature
sub blah ( mysubtype &sref )
{
my Int $x = sref( "Str", 23, Foo.new );
}
mean if not a constraint of the type of &sref?
Above it is used as a function that accepts (Str, Int, Object)
and returns Int. Depending on the definition of ::mysubtype
this usage is erroneous or not. I ask myself---or @Larry---how
the same effect could be achieved without the indirection through
a name. Perhaps:
sub blah( Code[Str, Int, Object --> Int] &sref ) {...}
The same question arises when ::subtype shall be declared:
subtype mysubtype of Code[Str, Int, Object --> Int];
subtype mysubtype of Code:(Str, Int, Object) returns Int;
nor of
having funcitons declare/define/denote/de-whatever types.
Here's an attempt of code joke around foo (ignore at will)
class foo
{
submethod postfix:{'( )'} ( $x ) { say $x }
}
sub foo( &foo ) { say foo }
sub bar ( foo $foo, foo &foo )
{
$_ = foo.new;
my foo $f = \foo;
my foo &f = \foo;
my foo @f = foo;
say foo(23);
say .(42);
}
--
TSa (Thomas Sandlaß)
Re: Tail method calls, can(), and pre-currying
On 7/20/05, Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Is there a Perl 6 tail call syntax,
> One suggestion was a tweak of `can`'s definition: instead of returning
> a reference to the method, it returns one with the invocant already
> curried into it. Thus, the above becomes this:
> Am I missing something? How do you think a tail method call should be
> performed?
I can understand the convenience of turning a method into a subroutine
by currying the object. Syntactical support for this seems cool too.
But, can someone remind me why there is the need for an explicit tail
call syntax? It has to do with some oddity of Perl in some situations
that prevents the code generator to infer that should be a a tail
call? I am thinking about how tail calls are handled in languages like
Scheme or Lua. In these,
sub f ( $a ) {
return g($a);
}
urges for (and compiles to) a tail call with no need for explicit
marks by the programmer. Obviously, in Perl, there are some issues
with the calling context that should be propagated to the callee.
Also getting tail method calls right is an immediate win for the issue
of implementing delegation. Am I right?
Regards,
Adriano.
Re: Referring to package variables in the default namespace in p6
Matthew Hodgson wrote:
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variable.
Let me restate that in my own words. You mean that a symbolic runtime
lookup $::($Foo) with the value of $Foo at that time shall be cached
in the immediatly surrounding namespace and that cached ref is then
accessable through the syntax $::Foo?
My understanding is that the expression $::($Foo) is *always* triggering
dynamic lookup with the then current value of $Foo. If this is not what
you want then say so with one of these:
my$FooCache := $::($Foo); # everytime when dynamic scope is entered
state $FooCache := $::($Foo); # once and for all
Otherwise
for ("blahh", "fasel", "blubber") -> $name
{
$::($name) = 42;
}
wouldn't be really usefull. BTW, I wonder if $::() means $::($_) :)
Otherwise the two $::... forms would be horribly confusingly different
Sorry, they are the same thing: namespace lookup. But without ::() the
compiler does it at compile time for bareword resolving. Without a sigil
in front the result can be used where a type is expected:
for ("blahh", "fasel", "blubber") -> $name
{
::($name).new;
}
We can consider the equivalence of $foo and $::foo as TIMTOWTWI.
I dought that assigning two different meanings just because their
are two syntactical forms is a good idea.
in their behaviour, and I (and other future legions of newbies) would
despair. :)
You consider yourself a 'legion of newbies' ;)
--
TSa (Thomas Sandlaß)
Re: Referring to package variables in the default namespace in p6
On Thu, 21 Jul 2005, "TSa (Thomas Sandlaß)" wrote:
Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for $::Foo.
Is that the leaf name variable Foo in your current (innermost) namespace?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost names to
their body:
sub foo ( $param )
{
say $::param; # prints argument bound to $param
say $param; # same
say $OUTER::param; # prints value of result of a lookup
# that starts outside of sub foo
# but
my ::param $x = ::param.new; # look for param type info
Okay; if this is how $::foo works, then it makes a whole lot of sense :)
Or is it an attempt to dereference the disambiguated type Foo?
What is the use of reference to a type?
I have no idea - I was going on the basis of Larry's comment concerning
$::Foo looking a bit like an attempt to dereference ::Foo.
In other words you just can't use a sigiled expression where a type
is expected: my $::Foo $x; is just a syntax error. This is why I regard
the sigils as type mark-up. That means writing $Foo or $::Foo just
tells the compiler that you want to handle the item Foo.
Is there any reason why $::Foo could not do both, and not start by
searching your current namespace for a variable called $Foo... and then
start searching your current namespace hierarchy for a type called Foo
and try to dereference it (whatever that does)?
This is my position if I read the double negation correctly.
Oops - the double negative was a typo there; apologies... even then, I
think I understand that you agree that $::foo simply means an outwards
search of your current namespace scope for a variable called $foo.
Sorry if that wasn't clear initially. But I hope the above rants
clarify what I mean.
I hope that i'm on the right page now - thank you for taking the time to
clarify :)
Presumably it should behave in precisely the same way that $::('Foo')
does for sanity - does that search the current namespace for just types
or variables or both?
Not for sanity. $::Foo is just syntactic sugar for $::('Foo') because
'Foo' is a compile time constant. But $::( some_calculated_name ) might
not in general be evaluateable at compile time and thus forces the
compiler to generate symbolic lookup code which
1) calls some_calculated_value
2) starts lookup with the stringified return value
Note that because of the $ sigil it looks for something that does the
Scalar/Item role! We can consider the sigils as lookup filters.
I guess $::('Foo') was a bad example - $Foo="Foo"; $::($Foo) would have
been better at illustrating my point - which was that if $::($Foo)
searches outwards through namespace for a variable whose name is held in
$Foo, then $::Foo should end up referring to the same variable. Otherwise
the two $::... forms would be horribly confusingly different in their
behaviour, and I (and other future legions of newbies) would despair. :)
thanks again;
M.
Re: DBI v2 - The Plan and How You Can Help
On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote: > Once upon a time I said: I'm back now and, after digesting a small mountain of non-DBI related emails, I'll start digesting all your replies and getting up to speed with Perl 6. Many thanks to all who replied on and off-list. Tim.
Re: DBI v2 - The Plan and How You Can Help
On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote: > > When I go to the donation page and attempt to make a donation, the > drop-down box does not give DBI as a valid recipient. Is it possible > several people may not have donated as they noticed the same results, or > maybe they did and it all went into the Perl Development Fund instead? The Perl Foundation default donation page doesn't list the DBI Development Fund (for various reasons). To get that option you can use http://dbi.perl.org/donate/ which will redirect you[1] Thank you. Tim. [1] https://donate.perlfoundation.org/index.pl?node=Contribution%20Info&selfund=102 > > > > -Original Message- > > From: Tim Bunce [mailto:[EMAIL PROTECTED] > > Sent: Friday, July 01, 2005 7:06 PM > > To: perl6-language@perl.org; dbi-users@perl.org > > Subject: DBI v2 - The Plan and How You Can Help > > > > > > Once upon a time I said: > > > > > > http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=source&hl=en > > > > and wrote > > > > http://search.cpan.org/~timb/DBI/Roadmap.pod > > > > which yielded: > > > > > > https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det > > ails&selfund=102 > > > > (A little over $500 of that I effectively put in myself.) > > > > My *sincere* thanks to all those who donated to the fund, especially > > individuals. I had hoped for more corporate response with less from > > individuals and I'm touched by the personal generosity shown. > > > > I've not drawn any money from it yet and doubt that I will myself. > > (I'm considering suggesting that the Perl Foundation make payments > > from the fund to people making specific contributions to the DBI. > > I'm thinking especially of work on a comprehensive test harness. > > But I'll see how the developments below pan out before making > > specific arrangements.) > > > > > > So, that lead to: > > > > > > http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/th > > read/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0 > > > > Which sums up fairly well where I'm at: DBI v1 will rumble on > > for Perl 5 > > and DBI v2 will be implemented for Perl 6. > > > > > > --- digression --- > > > > At this point I'd like to make a slight digression to highlight the > > amazing work going on in the Perl 6 community at the moment. > > Especially Autrijus' Pugs project which has brought Perl 6 to life. > > Literally. Take a look at: > > > > http://pugscode.org/talks/yapc/slide1.html > > http://use.perl.org/~autrijus/journal > > > > and especially: > > > > http://use.perl.org/~autrijus/journal/24898 > > > > Yes, that really is Perl 6 code using the DBI being executed by Pugs. > > > > That's great, and I was truly delighted to see it because it takes the > > pressure off the need to get a DBI working for Perl 6 - because it > > already is working for Perl 6. At least for Pugs. (The Ponie project > > is also likely to provide access to Perl 5 DBI from Perl 6 by enabling > > future versions of Perl 5 to run on Parrot.) > > > > --- digression --- > > > > > > I have recently come to an arrangement that will enable me to put some > > worthwhile development time into DBI (still very much part-time, but > > enough to give it focus and move forward). > > > > My initial goals are: > > > > 1. to work on a more detailed specification for the DBI v2 API that > > takes advantage of appropriate features of Perl 6. > > > > 2. to work on a more detailed specification for the DBDI API > > > > http://groups-beta.google.com/group/perl.perl6.internals/msg/c > > fcbd9ca7ee6ab4 > > > > 3. to work on tools to automate building Parrot NCI interfaces to > > libraries (such as database client libraries, obviously :) > > > > > > But I'm hoping you'll join in and help out. > > > > I've kept an eye on Perl 6 and Parrot developments but I'm no > > expert in > > either. What I'd like *you* to do is make proposals (ideally fairly > > detailed proposals, but vague ideas are okay) for what a Perl > > 6 DBI API > > should look like. > > > > Keep in mind that the role of the DBI is to provide a consistent > > interface to databases at a fairly low level. To provide a > > *foundation* > > upon which higher level interfaces (such as Class::DBI, > > Tangram, Alzabo > > etc. in Perl 5) can be built. > > > > So, if you have an interest in the DBI and Perl 6, put your thinking > > cap on, kick back and dream a little dream of how the DBI could be. > > How to make best use of the new features in Perl 6 to make > > life easier. > > > > Then jot down the details and email them to me (or to > > dbi-users@perl.org > > if you want to kick them around in public for a while first). > > > > I'm about to fly off for two weeks vacation (in a few hours), > > blissfully > > absent of any hi-tech gear beyond a mobile phone. When I get back I'll > > gather up your emails and try to distill them into
Re: Referring to package variables in the default namespace in p6
Matthew Hodgson wrote:
These rules are all fair enough - but they are then ambiguous for
$::Foo. Is that the leaf name variable Foo in your current (innermost)
namespace?
It is not ambiguous if the sigil rules that expression. I assume
that the parameters of a sub are definining innermost names to
their body:
sub foo ( $param )
{
say $::param; # prints argument bound to $param
say $param; # same
say $OUTER::param; # prints value of result of a lookup
# that starts outside of sub foo
# but
my ::param $x = ::param.new; # look for param type info
# The above compiles preliminarily but eventually needs
# a type param. If the only name that is in scope is the
# formal param then I presume a late compile error occurs.
# Well, or the runtime *value* of $param is taken as the
# type which essentially renders $x a constant.
# and
my param $y = param.new; # works only if param pre-declared.
# Also
say param(); # requires a code type to be in scope
say ¶m(); # same with late binding
say .param(); # late binding with method sigil
}
Interesting question is how the last two lines above behave depending
on whether ¶m.does(Sub) or ¶m.does(Method) and what light
that sheds on the $?SELF.method problem :)
Or is it an attempt to dereference the disambiguated type Foo?
What is the use of reference to a type? The compiler, dispatcher
and class and object composer need type information to do their
job, of course. And they might handle this information through
refererences. But when this happens the source is already digested.
In other words you just can't use a sigiled expression where a type
is expected: my $::Foo $x; is just a syntax error. This is why I regard
the sigils as type mark-up. That means writing $Foo or $::Foo just
tells the compiler that you want to handle the item Foo.
Or is it like perl5, shorthand for $*Main::Foo?
This is clearly specified as not beeing the case.
Is there any reason why $::Foo could not do both, and not start by
searching your current namespace for a variable called $Foo... and then
start searching your current namespace hierarchy for a type called Foo
and try to dereference it (whatever that does)?
This is my position if I read the double negation correctly.
Sorry if that wasn't clear initially. But I hope the above rants
clarify what I mean.
Presumably it should behave in precisely the same way that $::('Foo')
does for sanity - does that search the current namespace for just types
or variables or both?
Not for sanity. $::Foo is just syntactic sugar for $::('Foo') because
'Foo' is a compile time constant. But $::( some_calculated_name ) might
not in general be evaluateable at compile time and thus forces the
compiler to generate symbolic lookup code which
1) calls some_calculated_value
2) starts lookup with the stringified return value
Note that because of the $ sigil it looks for something that does the
Scalar/Item role! We can consider the sigils as lookup filters.
Regards,
--
TSa (Thomas Sandlaß)
