date:20050721


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 param(); # same with late binding
  say .param(); # late binding with method sigil
}

Interesting question is how the last two lines above behave depending
on whether param.does(Sub) or param.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ß)

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%20Infoselfund=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=sourcehl=en

and wrote

http://search.cpan.org/~timb/DBI/Roadmap.pod

which yielded:

https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det
ailsselfund=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 a coherent whole.

Have fun!

Tim.

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.

[perl #36615] [PATCH] dump_cfg call

# New Ticket Created by  Curtis Rawls 
# Please include the string:  [perl #36615]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36615 


This patch moves the dump_cfg() call from reg_alloc.c to cfg.c, making
it more in line with other CFG methods.

-Curtis


dump_cfg.patch
Description: Binary data

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: 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: Tail method calls, can(), and pre-currying

2005-07-21 Thread Adriano Ferreira

On 7/20/05, Brent 'Dax' Royal-Gordon [EMAIL PROTECTED] wrote:
 brentdax 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: 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: leo-ctx5 (r8656): test results

On 7/20/05, Leopold Toetsch [EMAIL PROTECTED] wrote:
 This is fixed now (r8657).
 
indeed, the results are much better:
Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
t\dynclass\foo.t 8  2048 98  88.89%  1-5 7-9
t\dynclass\gdbmhash.t   13  332813   13 100.00%  1-13
t\op\spawnw.t3   768 63  50.00%  4-6
4 tests and 88 subtests skipped.
Failed 3/157 test scripts, 98.09% okay. 24/2656 subtests failed, 99.10% okay.

 Thanks for testing,
 leo
 
thanks for fixing.
~jerry

Re: [PATCH] Pass all of spawnw.t on Win32/MSVC++

2005-07-21 Thread Jonathan Worthington


Jonathan Worthington [EMAIL PROTECTED] wrote:

jerry gay [EMAIL PROTECTED] wrote:

if i recall correctly, the options here are: 1) unix-like return value
from spawnw everywhere, 2) return platform-specific value, or 3)
return some object-like thingy.

i don't like option 1, as i believe spawnw should return something
platform-specific. an object-like thingy (option 3) might be nice, and
is definitely shiny, but it doesn't exist, and requires more
specification.

Sorry, I wasn't clear in what I wrote.  I was suggesting a 4th option - 
always return the exit code so the user can use it right away, as in we  
8 it on UNIX platforms, leave it as is on Win32, etc.  So if the exit code 
is 1, then Ix contains 1.  No matter which platform you're on.  User code 
has to do no shifts.


Just went and looked at what $? holds in Perl 5 and, well, it holds the 
POSIX value.  And the lower 8 bits actually can contain something useful 
(the signal that terminated the program and whether it core dumped).  So my 
idea would have thrown away potentially useful info.  That'd suck.


I still think consistent is important, not something platform specific.  So 
here's my patch again, with the comments cleared up to say why we left shift 
by 8.  I think it's the right thing to do.


All spawnw.t passes on Win32 with this patch.

Thanks,

Jonathan 


spawnwargs2.diff
Description: Binary data

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: 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: 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: 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: 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: [perl #36615] [PATCH] dump_cfg call

2005-07-21 Thread Curtis Rawls

Apologies, the submitted patch causes some tests to not terminate. 
This patch is the correct version.
-Curtis

On 7/21/05, via RT Curtis Rawls [EMAIL PROTECTED] wrote:
 # New Ticket Created by  Curtis Rawls
 # Please include the string:  [perl #36615]
 # in the subject line of all future correspondence about this issue.
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36615 
 
 
 This patch moves the dump_cfg() call from reg_alloc.c to cfg.c, making
 it more in line with other CFG methods.
 
 -Curtis
 
 



dump_cfg.patch
Description: Binary data

[PATCH] string_to_cstring memory leaks

2005-07-21 Thread Jonathan Worthington


Hi,


From docs/ROADMAP


* Memory leak - string_to_cstring returns a malloced string, which isn't 
freed everywhere


A quick grep through the src folder found a few cases like this.  I may have 
missed some, but this patch fixes those I spotted.  Compiles, passes all 
tests (apart from dynclasses, which are still to fix on Win32).


Note - yes, I know many of the strings are passed to internal_excpection, 
but IIRC many of those will be becoming real_exceptions in the future, so 
it's worth free'ing 'em.  :-)


Hope this helps,

Jonathan

P.S. I can give about a day a week of development time to Parrot at the 
moment, and hopefully might get to use Parrot in my dissertation project if 
folks at uni are happy with my ideas, which means I'd be using it more 
extensively for the next year or so.  I'm looking at the TODO list for 
things to pick off at the moment (easy ones first - I haven't really looked 
at Parrot for about six months and I never knew the code base amazingly well 
anyway); suggestions welcome.


cstringleaks.diff
Description: Binary data

Re: [PATCH] Pass all of spawnw.t on Win32/MSVC++

On 7/21/05, Jonathan Worthington [EMAIL PROTECTED] wrote:
 Jonathan Worthington [EMAIL PROTECTED] wrote:
  jerry gay [EMAIL PROTECTED] wrote:
  if i recall correctly, the options here are: 1) unix-like return value
  from spawnw everywhere, 2) return platform-specific value, or 3)
  return some object-like thingy.
 
  i don't like option 1, as i believe spawnw should return something
  platform-specific. an object-like thingy (option 3) might be nice, and
  is definitely shiny, but it doesn't exist, and requires more
  specification.
 
  Sorry, I wasn't clear in what I wrote.  I was suggesting a 4th option -
  always return the exit code so the user can use it right away, as in we 
  8 it on UNIX platforms, leave it as is on Win32, etc.  So if the exit code
  is 1, then Ix contains 1.  No matter which platform you're on.  User code
  has to do no shifts.
 
 Just went and looked at what $? holds in Perl 5 and, well, it holds the
 POSIX value.  And the lower 8 bits actually can contain something useful
 (the signal that terminated the program and whether it core dumped).  So my
 idea would have thrown away potentially useful info.  That'd suck.
 
 I still think consistent is important, not something platform specific.  So
 here's my patch again, with the comments cleared up to say why we left shift
 by 8.  I think it's the right thing to do.
 
after further discussion (on #parrot) with chip and others, chip
decided that the proper option for spawnw is to return an object-like
thingy. and after this discussion, i fully agree, and take back my
previous statements about platform-specific values being the way to
go. that said...

 All spawnw.t passes on Win32 with this patch.
 
i'll apply this patch today. additionally, i'll add some text to
ops/sys.ops specifying that spawnw should return something
object-like. i've created a TODO ticket in RT for the spawnw
object-like return.

~jerry

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 %hasha;# 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 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

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 %hasha;# 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: [PATCH] Pass all of spawnw.t on Win32/MSVC++

On 7/21/05, jerry gay [EMAIL PROTECTED] wrote:
 i'll apply this patch today. additionally, i'll add some text to
 ops/sys.ops specifying that spawnw should return something
 object-like. i've created a TODO ticket in RT for the spawnw
 object-like return.
 
applied, r8660. also opened [perl #36619].

[perl #36619] [TODO] spawnw return value

# New Ticket Created by  jerry gay 
# Please include the string:  [perl #36619]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36619 


the return value from spawnw is highly system dependent as currently
implemented. instead, spawnw should return something object-like, that
wraps the platform-specific semantics.

[perl #36620] Bug in editor/ops2vim.pl

# New Ticket Created by  Amir Karger 
# Please include the string:  [perl #36620]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36620 


editor/ops2vim.pl says:

while (@ARGV) {
 
AFAIK, that should be 

while (ARGV) {

I'm running perl 5.8.6. Using ops2vim.pl that came with parrot-0.2.2, I got
just one (broken) line out of the script. Removing the @ makes it work fine.

-Amir Karger

Re: [perl #36620] Bug in editor/ops2vim.pl

actually, it should be 
while() {

applied, thanks.

On 7/21/05, via RT Amir Karger [EMAIL PROTECTED] wrote:
 # New Ticket Created by  Amir Karger
 # Please include the string:  [perl #36620]
 # in the subject line of all future correspondence about this issue.
 # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36620 
 
 
 editor/ops2vim.pl says:
 
while (@ARGV) {
 
 AFAIK, that should be
 
while (ARGV) {
 
 I'm running perl 5.8.6. Using ops2vim.pl that came with parrot-0.2.2, I got
 just one (broken) line out of the script. Removing the @ makes it work fine.
 
 -Amir Karger

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: OSCON testing tutorial?

2005-07-21 Thread Randal L. Schwartz

 Michael == Michael G Schwern [EMAIL PROTECTED] writes:

Michael Nearest Krispy Kreme is in Beaverton on RT 26 or Clackmas
Michael just off 205.  Hmmm, chromatic lives in Beaverton...

So do I, but I'm not allowed *near* that place.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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 %.armleft to scratch %.legright
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ß)

[perl #36623] Deleting Globals/Lexicals

# New Ticket Created by  Matt Diephouse 
# Please include the string:  [perl #36623]
# in the subject line of all future correspondence about this issue. 
# URL: https://rt.perl.org/rt3/Ticket/Display.html?id=36623 


There's currently no way to delete a global or a lexical.

 chip mdiep: you should be able to delete a global and (in the  
current system) a lexical, though a different way
 chip mdiep: so that'd be a bug

--
matt diephouse
http://matt.diephouse.com

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?


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 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?

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 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?

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?

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 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: Tail method calls, can(), and pre-currying