Re: Do I need "has $.foo;" for accessor-only virtual attributes?

2005-07-21 Thread Sam Vilain

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?

2005-07-21 Thread John Siracusa
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

2005-07-21 Thread Larry Wall
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?

2005-07-21 Thread Larry Wall
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?

2005-07-21 Thread Larry Wall
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?

2005-07-21 Thread Larry Wall
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?

2005-07-21 Thread Stevan Little

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?

2005-07-21 Thread Larry Wall
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?

2005-07-21 Thread Paul Seamons
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?

2005-07-21 Thread TSa (Thomas Sandlaß)

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?

2005-07-21 Thread John Siracusa
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?

2005-07-21 Thread TSa (Thomas Sandlaß)

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?

2005-07-21 Thread Larry Wall
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

2005-07-21 Thread Larry Wall
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

2005-07-21 Thread Dave Whipp

"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

2005-07-21 Thread Luke Palmer
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

2005-07-21 Thread TSa (Thomas Sandlaß)

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

2005-07-21 Thread Adriano Ferreira
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

2005-07-21 Thread Larry Wall
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

2005-07-21 Thread TSa (Thomas Sandlaß)

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

2005-07-21 Thread Matthew Hodgson

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)

2005-07-21 Thread TSa (Thomas Sandlaß)

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

2005-07-21 Thread Adriano Ferreira
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

2005-07-21 Thread TSa (Thomas Sandlaß)

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

2005-07-21 Thread Matthew Hodgson

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

2005-07-21 Thread Tim Bunce
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

2005-07-21 Thread Tim Bunce
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

2005-07-21 Thread TSa (Thomas Sandlaß)

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