RE: This week's summary

[Garrett Goebel]

> Rejigging NCI to use the ffcall library
>  Nick Glencross wondered about rejigging NCI, the parrot Native Call
>  Interface to use the ffcall library. In fact he went so far as to offer
>  up a proof of concept implementation. Apparently the ffcall approach
>  makes it much easier to write callbacks in PIR/PASM. Leo thought it
>  sounded like a useful thing to do, but licensing issues (ffcall is under
>  the GPL) meant that Parrot might have to stick with the current NCI
>  interface.
>
>   

As was stated in the thread, the author of ffcall has agreed in the past
that he would be willing to release ffcall under LGPL for use with Perl6.

RE: .method == $self.method or $_.method?

[Garrett Goebel]

Autrijus Tang wrote:
> > Luke Palmer wrote:
> > 
> > And it would be a shame to disallow the use of $_ in map.
> 
> Err, wait, I don't think we are discussing whether $_ is to
> be outlawed in map {}.

Perhaps we should consider making $_ readonly in map and grep?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  garrett at scriptpro dot com

RE: simple grammar example

[Garrett Goebel]

Aldo Calpini wrote:
> 
> I'm preparing a talk about Perl6 for the Italian Perl Workshop, and I 
> would like to have a slide comparing a BNF (yacc/bison) grammar to a 
> Perl6 one, to show how powerful in parsing/lexing
> Perl6 regexen are.
> 
> so I ask your assistance in helping me putting up a simple, yet 
> impressive enough, sample.

Since you're doing slides, I don't know how useful this will be, but I
noticed the other day that Damian has released Perl6::Rules. 
 
http://search.cpan.org/~dconway/Perl6-Rules-0.03/Rules.pm

It's the long promised implementation of Perl 6 regex syntax in Perl 5. It
implements most, but not all of Perl 6 regex syntax due to limitations of
Perl 5.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

Synopsis 3 not on dev.perl.org?

[Garrett Goebel]

I found Luke Palmer's Synopsis 3 on perl.com at
http://www.perl.com/pub/a/2004/03/18/synopsis3.html but didn't see it out at
http://dev.perl.org/perl6/synopsis/.

--
Garrett Goebel
IS Development Specialist 

ScriptPro   Direct: 913.403.5261 
5828 Reeds Road   Main: 913.384.1008 
Mission, KS 66202  Fax: 913.384.2180 
www.scriptpro.com  garrett at scriptpro dot com 
 

RE: Object spec [x-adr][x-bayes]

[Garrett Goebel]

Sam Vilain wrote:
> 
> On Thu, 06 Mar 2003 05:10, Garrett Goebel wrote:
> > Several people have mentioned a desire to see Perl6
> > and Parrot facilitate object persistence. Should
> > such issues be tackled in Parrot?
> 
> Not necessarily.  Just be friendly to object persistence 
> frameworks by exporting object relationships in a 
> sensible and consistent manner.  It is those relation-
> ships that drive the object persistence frameworks, and 
> implementations of the object structure in various
> languages.

"exporting object relationships in a sensible and consistent manner"

Sounds like something worthy of more than a passing reference. In the
context of parrot, what falls within the scope of a sensible and consistent
manner? 

 
> The exact semantics and mechanisms of object persistence
> are still quite a research topic, so it is not appropriate
> yet to select one method as the best.  However, I believe
> that the concepts of Object, Attribute, Association,
> Methods are stable.
>
> > What does parrot need to facilitate object persistence
> > and cross-language OO? Obviously the OMG's UML and
> > family of specifications deal with these issues. What
> > other practical approaches exist?
> 
> UML does not deal with persistence.  It deals with
> specifying and modelling objects.

When I said "UML and family" I was lumping in Meta-Object Facility (MOF),
Common Warehouse Metamodel (CWM), Common Object Request Broker (CORBA),
Object Constraint Language (OCL), etc. 10,000+ pages of spine tingling
object modeling, persistence, and interchange specifications... Important in
itself not just as the provider of a common vocabulary and semantics for
programming, but also a helpful sleep aid.

MOF nails down Packages, Classes, Associations, Attributes, and Operations.
Objects being instances of classes... And while the OMG specs are overkill,
there's probably some gems of relevant insight in them. Especially if it is
a goal for parrot to allow python code to invoke methods on objects coded in
perl.

Over on perl6-internals you've been talking about the need for Associations.
Is the addition of associations all that's missing from Parrot to support
"exporting object relationships in a sensible and consistent manner"?

What are the traps and pitfalls that'll need to be avoided in Parrot's
design to make object persistence not just possible but realistically
feasible? For example: serializing objects without capturing their
associations. Will the absence of associations force us to rely on
attributes and convention to serialize an object's associations? I.e., as I
thought you were implying, a messy hack that'll come back to haunt us?

--
Garrett Goebel
IS Development Specialist

ScriptPro  Direct: 913.403.5261
5828 Reeds RoadMain:   913.384.1008
Mission, KS 66202  Fax:913.384.2180
www.scriptpro.com  garrett at scriptpro dot com

RE: Object spec

[Garrett Goebel]

Several people have mentioned a desire to see Perl6 and Parrot facilitate
object persistence. Should such issues be tackled in Parrot? Will there ever
be a Parrot Object Database that we can serialize our Perl, Python and Ruby
objects into, to be used at some later date in code written in Jako?

If an appropriate parrot topic, I'd be especially interested to hear the
thoughts of people like Sam Vilain, Dave Rolsky, Piers Cawley, and others
who've already spent a great deal of tuits tackling these issues.

What does parrot need to facilitate object persistence and cross-language
OO? Obviously the OMG's UML and family of specifications deal with these
issues. What other practical approaches exist?

--
Garrett Goebel
IS Development Specialist

ScriptPro  Direct: 913.403.5261
5828 Reeds RoadMain:   913.384.1008
Mission, KS 66202  Fax:913.384.2180
www.scriptpro.com  garrett at scriptpro dot com
 

RE: Arrays vs. Lists [x-adr]

[Garrett Goebel]

From: Michael Lazzaro [mailto:[EMAIL PROTECTED]]
> 
> Just to clarify... in P6, is this an array reference, or a list 
> reference?
> 
>   [1,2,3]

Exactly. It's still up in the air...

Apoc 2, RFC 175:
> So it works out that the explicit list composer:
> 
>[1,2,3]
> 
> is syntactic sugar for something like:
> 
>scalar(list(1,2,3));
> 
> Depending on whether we continue to make a big
> deal of the list/array distinction, that might
> actually be spelled:
>
>scalar(array(1,2,3));


 
> What about this?
> 
>   \@array

hmm. As perl Apoc2, Lists, RFC 175... arrays and hashes return a reference
to themselves in scalar context... I'm not sure what context '\' puts them
in.

I'd guess \@array is a reference to an array reference.
 

> I'd say both of them are array references, but there's no variable 
> associated with the first one -- it's just an anonymous 
> container.  So 
>
> I'd rewrite the definition to:
> 
>- Lists are an ordered collection of scalar values
>- Arrays are containers that store lists
> 
> (Coupled with Uri's explanations, of course... it's the 'container' 
> part that allows read/write, as opposed to simply read.)  Yes/no?

I'd just stick with Uri's explanation. Arrays are allocated. Lists are on
the stack...

It doesn't need improving... The only question is whether it is still
accurate in the _context_ of Perl6 ;)

 
> But is it OK for a list to be silently promoted to an array when used 
> as an array?  So that all of the following would work, and 
> not just 50% of them?
> 
> (1..10).map {...}
> [1..10].map {...}
> 
> (@a,@b,@c).pop
> [@a,@b,@c].pop

There's only one person who can answer that... and he's not reading ;)



--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

 

RE: Arrays vs. Lists [x-adr]

[Garrett Goebel]

Uri Guttman wrote:
> 
> arrays are allocated and lists are on the stack. so arrays
> can have references to them but lists can't. 

Apoc 2, RFC 175:
>
>  scalar(list(1,2,3));
[...]
>  scalar(array(1,2,3));

Which would imply one could take a reference to either. 


> can anyone see any changes in perl6 to invalidate that
> separation of lists and arrays?

Immediately thereafter, Larry left room to imply list may actually be
spelled a-r-r-a-y...


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  garrett at scriptpro dot com

out-of-place-rant (was: summarizing the obvious)

[Garrett Goebel]

Michael Lazzaro wrote:
> On Friday, January 31, 2003, at 09:40  AM, Garrett Goebel wrote:
> >
> > 
> > I'm disappointed that The Perl Foundation (TPF) has been so 
> > quiet and unresponsive on support for our core language
> > designers and architects. I dropped a note to all the TPF
> > contacts over a week ago, and have yet to receive a reply.
> > It is a sad state of affairs when a language as prevalent
> > as Perl and with such a strong sense of community can be so 
> > disorganized and lacking when it comes to financial
> > sustenance.
> > 
> 
> It's worse than that, IMO.  Think of all the businesses that benefit 
> from Perl... it's bloody *everywhere*.  It's the, what, fourth most 
> popular language, after C/C++/Java, according to that 
> monster-job-search-based-statistic on slashdot.  And yet the entire 
> population of the Perl-using planet can't support 4 or 5 full time 
> designers/developers?  Have we just not been effective in getting the 
> word out, or are businesses truly that cheap?  Does Perl need to be 
> made into a commercially supported product, w/ venture capital, a'la 
> other recent open source pkgs, in order to get funded?

Don't forget giving credit where credit is due. YetAnother has accomplished
a good deal. I don't understand the current relative silence, but they did
setup and administer The Perl Foundation (TPF). Quite a number of companies
and individual did fund TPF's 2002 grants
(http://donate.perl-foundation.org/index.pl?node=Fund+Drive+Details&selfund=
2). O'Reilly and ActiveState have for a long time employeed a substantial
number of people who spend a significant amount of time improving Perl. And
don't forget the folks and hardware donations behind CPAN. There are
doubtlessly many other organizations which support people like ValueClick
has Ask.

I just don't follow the lack of active and organized financial support for
Perl6...

I may not have the time, knowledge, and ability to contribute much to Perl6
language design or Parrot. But, point me where I can send a check that'll
support Larry, Damian, and Dan. That for the moment, I can still manage... 

I'll shut up now. No need to mention that this belongs on advocacy.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

summarizing the obvious (was: arrays, hashes unified ...)

[Garrett Goebel]

From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > $idx_of_foo = $queue['foo']; # named lookup
> > $nth_foo= $queue[600];   # ordered lookup
> >
> > One is SvPOK the other SvIOK...
> >
> > Can't we handle both and still have the ordered lookup be fast?
[...]
> YOU CAN'T USE THE TYPE OF THE 'INDEX' OBJECT TO DETERMINE
> WHETHER YOU'RE DOING A HASHLIKE OR AN ARRAYLIKE LOOKUP. As
> Dan pointed out ages ago.

Got it. 

Conflating indexed and named lookups (creating a syntactic homonym), isn't
desirable or reasonably feasible. If we went down that route, it'd wind up
being more confusing, self-limiting, breed complexity in a response to
resolve the over-simplification, and drag down performance. Or probably
better left at "not desirable".

Or for the extremely thick:
  GOOD: Separate syntax for indexed vs. named lookups
  BAD:  Same syntax with >= 2 contextual meanings

Apologies for revisiting the graveyard of bad ideas and contributing
negatively to the signal to noise ratio. I too have great difficulty in
keeping up with the list. For the most part, I tend to read the replies of
the more enlightened to others' questions, comments, and proposals. How
Damian, our most prolific, found the time to sift through so much I don't
know.


I'm disappointed that The Perl Foundation (TPF) has been so quiet and
unresponsive on support for our core language designers and architects. I
dropped a note to all the TPF contacts over a week ago, and have yet to
receive a reply. It is a sad state of affairs when a language as prevalent
as Perl and with such a strong sense of community can be so disorganized and
lacking when it comes to financial sustenance.

RE: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]

[Garrett Goebel]

From: Piers Cawley [mailto:[EMAIL PROTECTED]]
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > And what's to prevent that collection object from handling: 
> >
> > my $queue = SomeQueue.new;
> >  
> > $queue.push('foo');
> > $queue.push('bar');
> > $queue.push('baz');
> >  
> > my $index_of_foo = $queue['foo']; # undef if no foo in queue.
> 
> Because I also want to be able to access 
> 
>$nth_foo = $queue[$n]
> 
> Which I thought was so blindingly obvious as not to need stating.

Never underestimate blindingly obvious when I'm involved ;)

$idx_of_foo = $queue['foo']; # named lookup
$nth_foo    = $queue[600];   # ordered lookup

One is SvPOK the other SvIOK...

Can't we handle both and still have the ordered lookup be fast?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: arrays, hashes unified indexing syntax impact on futurevariat ion s on other collection types [x-bayes]

[Garrett Goebel]

Piers Cawley wrote:
> Garrett Goebel <[EMAIL PROTECTED]> writes:
> >
> > What was the reason again which Larry rejected unifying the 
> > syntax for array and hash indexing? As Piers said, we know
> > whether $a is an array or hash reference when we do:
> >
> > print $a->{foo};
> 
> But as someone else pointed out, there may be classes that have both
> hashlike and arraylike interfaces. For instance:
> 
>my $queue = SomeQueue.new;
> 
>$queue.push('foo');
>$queue.push('bar');
>$queue.push('baz');
> 
>my $index_of_foo = $queue{'foo'}; # undef if no foo in queue.

And what's to prevent that collection object from handling: 

my $queue = SomeQueue.new;
 
$queue.push('foo');
$queue.push('bar');
$queue.push('baz');
 
my $index_of_foo = $queue['foo']; # undef if no foo in queue.


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]> 

RE: arrays, hashes unified indexing syntax impact on future varia tion s on other collection types

[Garrett Goebel]

Apologies in advance for beating this dead horse...

Damian Conway wrote:
> Garrett Goebel wrote:
>
> > What was the reason again which Larry rejected unifying the 
> > syntax for array
> > and hash indexing?
> 
> Because some things have both, and do different things with each.

Ok $0 is special. But isn't it _the_ special case? And strictly speaking,
its an ordered associative array right? It doesn't really need the full
range of expression offered by $0{...} and $0[...]. All it needs is $0[1]
for ordered lookups and $0["1"] for named lookups.

Or going back to the statement that "some things have both". Silly question
I'm sure, but can you imagine a collection object that really needs $0[1]
and $0{1}? And wouldn't it be a fair argument that such a collection object
is too fancy for its own good?

Hmm... $0[$!]

However isn't that something the collection object should have to deal with?
It seems like such nice thing to unify collection syntax. Then in Perl6 we'd
have scalars and containers. We'd still give sigils to arrays and hashes as
befits their perl heritage. Other collection objects could either be derived
from arrays and hashes, use some other generic sigil or define their own.


> And because some built-in redundancy is useful for error checking,
> especially on complex nested data structures.

I'm no one to argue with that...

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

arrays, hashes unified indexing syntax impact on future variation s on other collection types

[Garrett Goebel]

Joseph F. Ryan wrote:
> Stéphane Payrard wrote:
> >
> >I think that arrays and associative tables are very 
> >different entities for two reasons:
> >  -type of keys. array keys are integers
> >  -cost of insertion and deletion operations: O(n) and
> >   lower for associative table ( O(1) if you don't care
> >   for key ordering, O(log(n)) if you care for ordering). 
> >
> >This is enough to warrant different syntaxes for arrays and hash.
> 
> I'm sure I'll get shot for saying this, but no it doesn't.
> PHP arrays are simply associative arrays with a integer as
> the key value.

What was the reason again which Larry rejected unifying the syntax for array
and hash indexing? As Piers said, we know whether $a is an array or hash
reference when we do:

print $a->{foo};


Someone correct me when I go astray...

Currently in Perl6 you can assign an anonymous array or hash to a scalar as
follows:

$a = [1,2,3];
$b = {a => 1, b => 2};
  or
$a = array(1,2,3);
$b = hash(a => 1, b => 2);


If arrays and hashes both settled on []:

$a = [1,2,3];
$b = [a => 1, b => 2];
  or
$a = array(1,2,3);
$b = hash(a => 1, b => 2);


It'd mess up the explicit list and hash composer syntax [] and {}. After all
if unified, what's:

$b = [a => 1, b => 2];

An anonymous array of ordered key/value pairs or an anonymous hash?

If this could be resolved in a way which would allow us to translate our
expectations of Perl5 arrays and hashes into Perl6... Wouldn't it give us a
standard syntax for working with collections? So we could punt on Bags,
Sets, Dictionaries, OrderedCollections, etc. and all the variations on
arrays and hashes that people are suggesting. I.e., Deliver a version of
standard Perl arrays and hashes... and make provisions for, but leave the
rest out of the core.

$bag = bag(1,2,1);
print "ok"  if 2 == scalar $bag->[1];

@a = (1,2,3);
%h = (a => 1);
%oh is ordered = (a => 1);
©c is bag = (1,2,1); # (C) symbol or some other sigil

RE: Multimethod/multisub thought...

[Garrett Goebel]

From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Brent Dax wrote:
> # >
> # > This is also a problem with using want().
> # > 
> # > If we don't provide wants_scalar/wants_list, someone will
> # > build it with want(), so we might as well try to address
> # > it.  I suggest that want() return a special value when
> # > the calling context is ambiguous, and any wants_scalar/
> # > wants_list property be designed to accommodate this
> # > (probably by specifying which one should be the default).
> # 
> # Where "special value" is a junction: 'scalar' | 'list'?
> 
> Actually, I was thinking C, though a junction of all 
> the possible contexts might be good too.  Remember, want()
> is more than just scalar/array now.

sure, sure... 

I was ambiguously referring back to Dan's example, were xyzzy(scalar) and
xyzzy(list) were the only valid options.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Multimethod/multisub thought... [x-adr]

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> 
> Okay, I think I remembered the problem. Assume the following:
> 
> list bar(int);   # bar takes an int, returns a list
> scalar bar(int); # bar takes an int, returns a scalar
> 
> and also assume the following:
> 
> xyzzy(scalar); # xyzzy takes a scalar
> xyzzy(list);   # xyzzy takes a list
> 
> and then we make the call:
> 
> xyzzy(bar(1));
> 
> Which bar do we call? And which xyzzy?

So the question is: if the calling context is ambiguous, do we dispatch to
the implementation matching:

1)  first valid signature w/ warning
2)  most valid signature w/ warning
3)  default calling context w/ warning
4)  exception when ambiguous

I'd take what's behind door number 1...


Brent Dax wrote:
>
> This is also a problem with using want().
> 
> If we don't provide wants_scalar/wants_list, someone will 
> build it with want(), so we might as well try to address
> it.  I suggest that want() return a special value when
> the calling context is ambiguous, and any wants_scalar/
> wants_list property be designed to accommodate this
> (probably by specifying which one should be the default).

Where "special value" is a junction: 'scalar' | 'list'?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: L2R/R2L syntax [x-adr][x-bayes]

[Garrett Goebel]

From: Damian Conway [mailto:[EMAIL PROTECTED]]
> 
> We should bear in mind that Larry has had some health issues.
> And that he's currently unemployed with four children to support.
> Other matters are taking precedence at the moment.

Hmm... If the Larry and the Perl Foundation would be agreeable. I'd just as
soon see a grant set up for Larry again this year. And if so, I'd like to
see the Perl Foundation grant(s) publicized before tax-deductable donations
to non-profit organizations can no longer be applied to 2002.

If so, I'm pretty sure I'll be able to match last years' contribution.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Comparing Object Identity

[Garrett Goebel]

Michael Lazzaro wrote:
> 
> I'm more worried about storing them than creating them.
> The good thing about using memaddresses is that they're
> free;

An UUID could be free up until the point where you request it.


> I think the odds of you wanting a truly unique ID for any 
> given class are so low that we'd probably be better off
> leaving it as a DIY project.

I thought we wanted to be able to guarantee a unique identifier across the
life of the object? -Objects may outlive processes... I'd rather trust the
implementation than DIY'ers.


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Comparing Object Identity [x-adr][x-bayes]

[Garrett Goebel]

John Siracusa wrote:
> 
> I'm saying that there are many kinds of objects that
> naturally want to have an "id" method or attribute
> that has nothing whatsoever to do with "this is the
> same object" comparisons.
[...]
> Using the method/attribute named "id" for "this is
> the same object" comparisons is just plain bad
> Huffman coding.  The "this is the same object"
> method/attribute should have a name that reflects
> the relative rarity of its use.

Other common names for the proposed .id are:

UUID: Universal Unique Identifier (DCE)
  http://www.opengroup.org/onlinepubs/9629399/apdxa.htm

GUID: Globally Unique Identfier (EFI)
  http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf
  (page 319)

Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
are identical in implementation. And won't rollover until 3400AD ;)

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]

[Garrett Goebel]

John Siracusa wrote:
> On 12/12/02 12:55 PM, Larry Wall wrote:
> > As for namespace pollution and classes that use .id in Perl 5, I
> > don't think it's going to be a big problem.  Built-in identifiers
> > do not have a required prefix, but they have an optional prefix,
> > which is C<*>.  I think we can probably parse
> > 
> >   $a.*id == $b.*id
> > 
> > if you really need to get to Object.id().
> 
> That'll only work out if everyone always writes it as "*id".  
> If not, my Perl 6 objects that override "id()" won't work correctly
> with any other classes or functions that simply call "id" and
> expect it to really be "*id"

yes...

So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;

I'm not sure I understand what Larry means by "most-global"... Do you mean
outer-most scope, root-of-method-inheritence, or both?

And what of the case we someone does want to explicitly override a "builtin"
method like UNIVERSAL::can? What is the Perl6 equivalent to:

  *UNIVERSAL::can = sub { print qq{hello\n} };
  sub foo {};
  print main->can('foo')";

And what will:

  main.*can('foo')

result in?


Larry Wall wrote:
> 
> I'd almost be tempted to argue that if push comes to shove, it's
> the list splat star that gets shoved.

Don't you suspect the list splat will be more common than most-global?

RE: Status Summary; next steps [x-bayes][x-adr]

[Garrett Goebel]

On Mon, 2002-11-25 at 14:25, Michael Lazzaro wrote:
> (2) The behavior of an explicit bool type, _if_ one exists, 
> that stores "truth", not "value".  Such that C = (0 but true)> stores true, not 0, and does so in "the
> most efficient way".

There is no explicit bool type.

Larry Wall wrote:
> 
> Please don't think of C as a boolean type.  There is
> no boolean type in Perl, only a boolean context.  Or looking
> at it from the other direction, *every* type is a boolean
> type.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.44.021031
1952540.18773-10%40london.wall.org


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Status Summary; next steps [x-bayes][x-adr]

[Garrett Goebel]

From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
> 
> If you don't already know whether it exists, or how it will 
> roughly work (lexically), you shouldn't be discussing it on
> p6d.  Kicked back to p6l.
[...]
> and again... what's the scope of p6d

p6d exists to document the language. A task which consists of going over the
A&E's and Larry's posts to p6l, etc. and flushing them out into
deliverables:

o  Perl6/Parrot regression tests
o  Language Specification derived from tests
o  Core Perl Documentation / User Manual

Flushing them out consists of:
o  disambiguation
o  isolating potential problems
o  writing tests and documentation

I have difficulty separating the pd6 disambiguation discussions from
language design... as I expect do others. Language design discussion belongs
on p6l. And I for one, would like to see a big red flag delimiting
speculation, when it occurs on p6d. Though there's the p6d argument that a
limited amount of speculation is called for, in that we should use the p6d
cabal to work our language design issues into a coherent refined proposal
before dumping them into the fray that is p6l. 


> , and how does it differ from p6l?

p6d differs from p6l, in that p6d has a specific goal: "document the
language". Whereas p6l is a rather more ambiguous forum for people to
influence Larry's design and explain it one another.

That said, it is also hoped that p6d will also have a beneficial effect on
p6l. Where p6l undergoes an iterative wave of questions and proposals
re-examining issues covered in previous A&E's following each new release,
p6d hopes to annotate its documentation to include the various trade-offs
involving alternative syntax, semantics, implementation impacts, ideological
ax grinding, etc. so that p6l can refer people to the old arguments instead
of wasting ever more time on them.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: String concatentation operator

[Garrett Goebel]

From: Dan Sugalski [mailto:dan@;sidhe.org]
> At 5:57 PM -0500 11/14/02, Ken Fox wrote:
> >
> >Wasn't one of the main problems with Jarkko's juxtaposition
> >proposal that it would kill indirect objects? Have we chased
> >our tail on this subject after the colon became required for
> >indirect objects?
> 
> I dunno. Makes the direct object syntax interesting  as well. 
> What does:
> 
> 
>   $foo = any(Bar::new, Baz::new, Xyzzy::new);
>   $foo.run;
> 
> do?

If you're wonder what Joe "I can hardly keep up" Blogg thinks...

Assuming junctions have neither a property nor a method named 'run', I'd
assume that $foo in a want method context would delegate the run method
invokation to one of the object-eigenstates.

But what would:

$foo = all(Bar::new, Baz::new, Xyzzy::new);
$foo.run;

do?

Invoke the run method against all of the object-eigenstates? And if not in a
void context, return a junction containing their results?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Primitive Vs Object types

[Garrett Goebel]

Dan Sugalski wrote:
> At 8:29 PM +0100 11/7/02, Leopold Toetsch wrote:
> >Michael Lazzaro wrote:
> >>On Thursday, November 7, 2002, at 06:36  AM, Austin Hastings wrote:
> >>
> >>>For 'bit', the key value is (eenie, meenie, ...) '1'.
> >
> >>  From A2 we have:
> >>
> >>"Run-time properties really are associated with the object in 
> >>question, which implies some amount of overhead. For that reason, 
> >>intrinsic data types like C and C may or may not allow 
> >>run-time properties.
> >
> >From E2: a C will never have attributes or promote to an object.
> 
> Attributes aren't properties.

I thought:

  'attributes' :Perl5 == 'properites' isa Perl6

Can someone point me to Perl6 definitions for both terms?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED] 

RE: perl6-lang Project Management

[Garrett Goebel]

Angel Faus wrote:
> 
> So, while we all wait for Larry to wait the design, is there any 
> reason not to start working in the documentation?

Any chance of getting a wiki setup at:
  http://dev.perl.org/perl6/cathecism/

Say using a wiki which uses pod for markup like:
 
http://search.cpan.org/author/MSERGEANT/AxKit-XSP-Wiki-0.04/lib/AxKit/XSP/Wi
ki.pm

So people can start working on the Perl6 Core documentation, etc.?

RE: UTF-8 and Unicode FAQ, demos

[Garrett Goebel]

Ken Fox wrote:
> Damian Conway wrote:
> > Larry Wall wrote:
> >> That suggests to me that the circumlocution could be >>*<<. 
> > 
> > A five character multiple symbol??? I guess that's the 
> > penalty for not upgrading to something that can handle
> > unicode.
> 
> Unless this is subtle humor, the Huffman encoding idea is
> getting seriously out of hand. That 5 char ASCII sequence
> is *identically* encoded when read by the human eye. Humans
> can probably type the 5 char sequence faster too. How does
> Unicode win here?
> 
> I know I'm just another sample point in a sea of samples

Can't we have our cake and eat it too? Give ASCII digraph or trigraph
alternatives for the incoming tide of Perl6 Unicode?

Allow both >>*<< and »*«?

Or something similar '>>*'<<, [>*<], etc...

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: [RFC] Perl Operator List, TAKE 6

[Garrett Goebel]

David Wheeler wrote:
> On Friday, November 1, 2002, at 12:21  PM, Michael Lazzaro wrote:
> 
> >   ^[op] - [maybe] synonym for «op»
> > - [maybe] synonym for »op«
> 
> I think that would be:
> 
>`<> - synonym for «op»
>`>>op<< - synonym for »op«
> 
> Unless I misunderstood Larry's post, in which case it might be:
> 
>`<>` - synonym for «op»
>`>>op<<` - synonym for »op«

I think that was:

   `<> - synonym for «op»
   `>>op`<< - synonym for »op«

Larry wrote:
> I could see using backtick as the "escape" code for things
> like `<< or `>> which would turn into what some benighted
> soul called "girly" angles.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: [RFC] Perl6 Operator List, Take 5

[Garrett Goebel]

From: Larry Wall [mailto:larry@;wall.org]
> I was misconfigured here.  My pine was marking it as UTF-8 even though
> the window was Latin-1.  So you ought to be able to see this: 
> @a «*» @b.
> 
> I'm definitely going to look into mutt though...gotta have 
> Unicode email.


In the quest for keys anyone can reach on any keyboard...

instead of «*» why not: (>*<), <)*(>, >)*(<, [>*<], or [)*(]

Which stands out best?
  @a «*» @b
  @a (>*<) @b
  @a <)*(> @b
  @a >)*(< @b
  @a [>*<] @b
  @a [)*(] @b

IMHO [>*<]


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Wh<[ie]>ther Infix Superposition ops

[Garrett Goebel]

From: Simon Cozens [mailto:simon@;ermine.ox.ac.uk]
> [EMAIL PROTECTED] (Larry Wall) writes:
> > So I would look favorably on finding a replacement for 
> > "superposition".
> 
> Predicate calculus? :) Seriously, I see no problem with
> calling them "set operators".

Great minds think alike. Or in this case even me ;)  I was just describing
superpositions as set operations to one of our developers... 

I'm left wondering what the relationship between Perl6 and relational
databases will be. Where one will leave off and the other will begin.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Draft Proposal: Declaring Classwide Attributes

[Garrett Goebel]

On Mon, 14 Oct 2002, Larry Wall wrote:
: We haven't solved the problem of instance methods that want to
: reject class invocants at compile time.  Though I suppose explicitly
: declaring the type of the invocant would have that effect.  I'm sure
: there are some who would argue (and I might be one of them) that an
: implicit invocant should default to only accepting an instance, and
: you have to declare an untyped invocant to get class-or-instance.
: (Or declare it with a class superposition like (Class|Dog), which
: presumably lets you pass either a Class instance or a Dog instance).

In your superposition example (Class|Dog), am I'm assuming correctly that
you could invoke that method with an instance of any object that IS-A Dog?



--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Private contracts?

[Garrett Goebel]

Michael G Schwern:
> Garrett Goebel wrote:
> > Michael G Schwern:
> > > shouldn't we have private invariants and conditions?
> > 
> > no. 
> 
> Ummm, why?
 
Maybe I'm just grinding an ax...

If you allow an interface's post conditions and invariants to be overlooked,
then you've got a broken interface. If you derive an interface then you've
got to garrauntee to satisfy the same output and invariant constraints. You
can't pick and chose, or your not deriving an interface. You're coming up
with a new one.

I think my ax could rest more peacefully if I could see more clearly how the
syntax would allow us to clearly disambiguate between the interface and the
implementation; constraints on a method's inputs and outputs as separate
from how its implemented. 


> I hope we're not going to explicitly seperate interfaces from
> implementation.  ie. That you can define an interface at the 
> same time as you implement it.  This is something I really
> like about Perl as opposed to other OO systems, class
> definition and implementation are not kept seperate.

I hope we do when we explicitly flag a class as an interface. After all, a
class which isn't explicitly qualified as an interface still has one. And
you can still attach pre, post, and invariant conditionals to its methods
and attributes. I'd be a whole lot more happy with your syntax if you
weren't explicitly hanging the 'is Interface' attribute off them.

How can you garrauntee the interface when you conflate it with the
implementation? It becomes difficult to separate the two. But I suppose that
is what your private idea is all about. In the context of a class private
means "just don't inherit this". In the context of an interface private
means "this is not part of the interface". It still looks like it'll be
messy when deep inheritence is involved.

I guess I'm kosher with private conditions and invariants in the sense that
any conditions on a private method or attribute would implicitly not be
inherited. So long as private method is not considered part of an interface.
However, I would still disagree with allowing private conditions on
non-private methods. At least not when you're tagging the class with a label
declaring it to be an interface, since non-private methods are implicitly
part of the interface.


> Of course, if "interfaces" in the Java sense are just classes with no
> implementation details, there's no reason why you can't do it 
> seperately.

TIMTOWTDI. But if you're going to explicitly label something as an
interface, the bondage and discipline ought to be consistent with DBC
principles.


> "Interface" is not quite simply the union of "method signature",
> "conditions" and "invariants".  Interfaces are a combination 
> of the three, true, but it's only a subset of their use. 
> They're all useful beyond simply enforcing how subclasses are
> designed and implemented.

Understood. But again, if you're hanging an "Interface" tag on a class, you
ought to be constricted to using them according to what they mean in the
context of an interface.

In short, go ahead and write it in a single class. You know where the
interface leaves off and the implementation begins. Just don't hang the
'Interface' attribute off it. 

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Delegation syntax? (was: Re: Private contracts)

[Garrett Goebel]

John Williams:
> Reaction #2:  Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve 
> the problem?

What about when you want to be able to dynamically swap the objects to which
you're delegating?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Private contracts?

[Garrett Goebel]

Michael G Schwern:
> Garrett Goebel wrote:
> > A derived interface can loosen input constraints... so
> > it must be able to either satisfy all inherited pre-
> > conditions _or_ its own pre-conditions.
> 
> Looking around, this seems to be regarded as something of a
> compromise because truly determining what a real logical
> weaking is is hard.  Are there other ways to do it, just to
> mull them over?

I thought about this for a while while reading your post. There are
certainly pre-conditions which you will want to be enforced all the way down
the line. And running counter to this is the need to be able to weaken
pre-condition constraints to handle a wider range of inputs.  Which requires
that the derived class not need to satisfy all inherited pre-conditions.

So the following wouldn't necessarily DWIM (if you know what I mean):

Class Foo {
  method count($from, $to) {
PRE { $to < 10  }
PRE { $from >= .lower_bound }
  } 
}
Class Bar is Foo { method count { PRE { .to < 100 } } }
Class Baz is Bar { method count { ... implementation ... } }

if you call Bar->count(-1, 99) you're no longer effectively constraining
$from >= .lower_bound. 

if you call Baz->count(-1, 99) you'll fail the Foo precondition. But since
you haven't defined any pre-conditions for Baz does this mean you have to
satisfy all inherited preconditions or that there are none? I.e. where's the
boolean OR logic when inherited pre-conditions are defined, but the derived
class' pre-conditions are undefined?

So currently, you'll need to rewrite all applicable pre-conditions for each
derived class, because you don't know if one of the existing or future
refactorings of a super-classes will weaken the input constraints. So you
can't assume you'll ever successfully pass all inherited pre-conditions.
I.e. you can only trust the class' own pre-conditions.


This is where I get pretty fuzzy. How to address the issue? -Assuming I've
understood it correctly and that it really is an issue. Can anyone back me
up with a yea or neh as to whether or not this is real problem... or just my
misunderstanding?


I wonder if it might be useful to somehow tag a pre-condition to be
invariably enforced ('AND') like post and invariant conditions... or
alternatively marked as overridable ('OR' --the default) to allow loosing
input constraints. 

Perhaps replacing the Class Foo example above with:

Class Foo {
  method count($from, $to) {
PRE { $to < 10  } # 'is OR' is default
PRE is AND { $from >= .lower_bound }
  } 
}
Class Bar is Foo { method count { PRE { .to < 100 } } }
Class Baz is Bar { method count { ... implementation ... } }

With two more semantic changes:
o  modifying the 'OR'ing of a class' inherited pre-conditions
   to be only one inheritence level deep
o  a class which has no pre-conditions would be required to 
   satisfy the inherited pre-conditions (no OR if undef)

So calling Bar->count(-1, 99) where the current class (Bar) has no
pre-conditions would DWIM. I.e., it would have to satisfy the 'OR'
pre-conditions from Bar and the 'AND' pre-condition from Foo.


Have I walked off into la-la land on a foundation of misunderstandings?

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Private contracts?

[Garrett Goebel]

Michael G Schwern:
> Michael G Schwern wrote:
> > I see us already smashing too many things into the
> > method signature as it is.  It will rapidly get
> > messy if you have a method with a complex signature
> > and a handful of attributes and preconditions.
> 
> I think I have my own counter example.
> 
> Consider defining an abstract class with an interface
> and I want to put some conditions onto an abstract
> method.
> 
>  class Abstract::Human is interface {
>  attr head, shoulders, knees, toes;
>invar { .head == 1 }
>invar { .shoulders == .knees == .toes == 2 }
>
>method eat ($food) is pre  { !$food.isa('Poison') }
>   is post { .return eq 'Burp' }
>  }
> 
> since I have no method body for eat() I have no choice but to 
> hang it off the signature as an attribute.

That wasn't the way I remembered it from Apoc 4... The following example is
not in A4, but its what I inferred from it...

Class Foo {
  method eat($food) is abstract {
PRE { ... }
POST { ... }
  }
}

Class Bar is Foo {
  method eat {
PRE { ... }
... implementation ...
POST { ... }
  }
}


'eat' may be an abstract method inherited by Bar from Foo... but the PRE and
POST conditions are still inherited. Though I can see the issue that
abstract precludes an implementation. But does that also require use to
preclude the code block?

Also if you rely on attributes to hang conditions... you're ruling out the
ability to reference things in the lexical context of the code block.

--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Private contracts?

[Garrett Goebel]

Michael G Schwern:
> On Thu, Oct 03, 2002 at 05:30:49PM -0400, Trey Harris wrote:
> > In a message dated Thu, 3 Oct 2002, Michael G Schwern writes:
> > 
> > > On Thu, Oct 03, 2002 at 03:59:08PM -0400, Mike Lambert wrote:
> > > > With pre/post conditions, a subclass is allowed to weaken the
> > > > preconditions or strengthen the postconditions.
> > >
> > > How exactly does one "weaken" a precondition?
> > 
> > You weaken a precondition by adding ORs; you strengthen a 
> postcondition by adding ANDs.
> 
> As expressions in Perl run a tad beyond simple boolean logic, 
> could you give a concrete example?

all inherited pre-conditions pass
  or
class' own pre-conditions pass


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: Private contracts?

[Garrett Goebel]

Garrett Goebel:
> Michael G Schwern:
> > But I don't want my subclasses to be constrained by that.  
> > It's just an implementation detail that I only wish to
> > enforce upon ATV and not it's children.

implementation details don't belong in interfaces

RE: Private contracts?

[Garrett Goebel]

Michael G Schwern:
> 
> I've been mucking about a bit more with this whole interface thing.
> 
> So if we make method signatures only enforced on subclasses 
> if the parent class or method has the interface property...
> 
> except private methods, obviously.
> 
> And if we make pre/post conditions and class invariants 
> always enforced...

no. 

post-conditions and invariants are always enforced, but pre-conditions are
different. A derived interface can loosen input constraints... so it must be
able to either satisfy all inherited pre-conditions _or_ its own
pre-conditions.

 
> shouldn't we have private invariants and conditions?

no. 

I should inject that I disagree with the use of term private as meaning
non-inheritable. I think of private as an methods and attributes accessible
only within the namespace of that class or its descendants. Perhaps a better
term would be something like:

  method foo is disinherited { ... }


I also need to separate out the DBC topic from the interface one. For
instance I have a hard time thinking about attributes in the context of
interfaces. For me, interfaces should be limited to a bunch of abstract
methods with conditions. Any other declarations within an interface IMO
should be errors. I.e., all other declarations belong in the implementation
class...

If you want to have a public and private "inheritable" interfaces that's
fine. But what's the point of a non-inheritable interface? Myself, I call
non-inheritable methods "functions".

 
> class ATV is Car, interface {
>   attr _tilt is private;
>   invar { ._tilt <= 20 } is private;
>   
>   method turn($direction, $how_sharp) {
>pre  { $how_sharp <= 20 } is private;
>...implementation...
>   }
> }

An interface shouldn't have attributes. And per above, private
pre-conditions are pointless.  I would rewrite the above as:

class ATV is Car, interface {
  invar { .tilt <= 20 };
  method tilt() is private; # in the "to class heirachy" sense
  method turn($direction, $how_sharp) {
pre  { $how_sharp <= 20 };
  }
}

 
> I've implemented an ATV where I've put in a saftey
> protection against rolling over in a turn as both an
> invariant and a pre-condition.  It will not allow you
> to turn the car too sharply, else it simply blows up.
> Wait second... ;)
> 
> But I don't want my subclasses to be constrained by that.  
> It's just an implementation detail that I only wish to
> enforce upon ATV and not it's children.  So they're
> private.
> 
> Makes sense, no?

No. Per DBC, pre-conditions are satisfied if either the inherited
pre-conditions _or_ its own pre-conditions are satisfied. Thus allowing the
loosening of input constraints which I believe is what you're after.


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

RE: auto deserialization

[Garrett Goebel]

From: Damian Conway
> But I must say I now like Adam's
> 
>   my Date $date .= new('June 25, 2002');
> 
> much more than my own proposal.

This thread appears to have wound down, but I'm still a little confused. I
understand the above syntax could be used to pass initialization data to the
constructor, but why wouldn't the original suggestion work for an object
doesn't require it initialization data and supports lvalue assignment?

Don't the following statements have identical meaning?

my Date $date;
my Date $date = Date->new();


And admittedly, I don't have a firm grasp on how lvalue assignment would be
mapped to object methods... but wouldn't the following statements also be
identical?

$date = 'June 25, 2002';
$date->STORE('June 25, 2002');


So what again is wrong with:

my Date $date = 'June 25, 2002';


--
Garrett Goebel
IS Development Specialist

ScriptPro   Direct: 913.403.5261
5828 Reeds Road   Main: 913.384.1008
Mission, KS 66202  Fax: 913.384.2180
www.scriptpro.com  [EMAIL PROTECTED]

Topicalizers as user-defined extensions

[Garrett Goebel]

Allison Randal wrote:
> Garrett Goebel wrote:
> >
> > I guess the next question in the context of the following is:
> > 
> > Larry Wall wrote in Apocalypse 4:
> > >
> > > It should be possible to make user-extensible syntax look
> > > just like built-in syntax. 
> > 
> > How would I create a user-extensible construct that works 
> > like given/when? I'm guessing the answer is: you don't.
> 
> I sure hope you can. I intend to use it.

Hmm... Out of curiosity what kind of user-extensible topicalizer aware
constructs would you make? And thinking of this in the context of user
defined functions, am I correct in assuming that we would need to be able to
specify per-parameter topicalizer awareness? So this would impact whatever
replaces function prototypes?

If topicalizers aren't going to be limited to given/when, but may slowly
creep in wholesale, then I have a few more questions...

Larry Wall in Apocalypse 4 writes:
> A when is the only defaulting construct that pays attention
> to the current topicalizer regardless of which variable it
> is associated with.

Which is fine when there's only one topicalizer. But is the C EXPR's
current topicalizer awareness limited to the current C scope? Or the
scope of any topicalizer which might be later introduced? I.e., will we be
able to specify which topicalizers a topicalizee pays attention to? Or will
all topicalizees be aware of all topicalizers?

RE: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

[Garrett Goebel]

From: Allison Randal [mailto:[EMAIL PROTECTED]]
> On Wed, Feb 27, 2002 at 04:24:48PM -0600, Garrett Goebel wrote:
> > From: Allison Randal
> > 
> > Not just some value external to the switch, but the value in $_.
> > 
> > I now see the DWIM aspect. Thanks BTW.
> > 
> > But how often will people have non- C statements 
> > within a C scope that'll need the special case
> > handling so they can see a different $_ than C?
> 
> That's exactly what the non- C statements will see currently.

Yes, I understand why that would be DWIMish. But is it going to be used
enough to justify the seeming inconsistency with the "$_ is _the_ default
variable" concept that Perl5 uses and Perl6 uses consistently outside
given/when. Topicalizers add a layer of complexity to the things that won't
be staring you in the face when you look at the code.

I'm neither a language guru nor designer, so I defer to the greater wisdom.
I do worry that as Perl grows richer, so does the need for underlying
consistency and simplicity. I guess it is all about seeking the correct
balance. And that is something Larry and the Perl community have a pretty
good track record with so far.


> Are you asking the question in the context of Apocalypse 4 or in the
> context of the hypothetical "C aliases to $_" discussion? I'll
> answer as if the former, because it seems to fit the best, but if you
> meant the latter the answer would be slightly different.

Scanning the "C aliases to $_" discussion provoked me to go back and
reread Apocalypse 4. So I'd have to say Apoc4

 
> I think we're bogged down in the "$_ is default" idea. We really have
> two entirely separate defaults, $_ and topic. Sometimes they're the
> same and sometimes they're not.

And until now I was safe assuming the one fixed variable $_ as the default.
Now there is the one special case C where I need to know the
difference. And nothing visible in the code to remind me that its there.
Difficult to teach, yet another thing to remember, and a potential nuisance
to debug. Though I guess I'm getting an inkling of how a year from now it'll
be yet another tool who's usefulness I'll take for granted.


> Hm... pretend for a moment that there's a
> variable $topic (there isn't, but pretend). It's very
> similar to $_, but not quite. When you do a
> 
>   given $x {
>   ...
>   }
> 
> then both $_ and $topic hold the value of $x. But, when you do a
> 
>   given $x -> $y {
>   ...
>   }
> 
> $topic holds the value of $y (i.e. the value of $x), but $_ 
> doesn't (it hasn't been affected at all). 
> 
> C always defaults to $topic, it doesn't care about $_ 
> (except that when $topic has no value at all, it will
> "steal" a value from $_).

Really? I missed that. But yes, there it is:

Larry Wall in Apocalypse 4 writes:
> Outside the scope of any topicalizer, a when will assume that
> its given was stored in $_ and will test implicitly against
> that variable. 

I wonder if this:

for 'foo' {
  given 'food' -> $x {
print when /$_/
  }
}

would print "food"?

And makes me wonder if:

for 'foo' {
  given 'food' -> {
print when /$_/
  }
}

Wouldn't be a useful syntax for specifying that the switch value can only be
seen by the case value? I.e. No don't inject 'food' as a lexical, and don't
associate it with the fixed default variable $_ either...


> I think your more general question boils down to: "Is this 
> whole notion of topic really worth the effort"? And the
> confusion about C actually supports your argument.
> Perl gurus and newbies alike are going to have to do a
> little mental stretching for this one (just a tiny bit).
>
> But I do think it's worth it. Despite the details of consistency and
> clarity that still need to be worked out, it's a very dwim change that
> is a big part of the elegance of the switch statement.

Exactly. And thanks to multiple readings of Apocalypse 4, and your
explanations... I'm pretty sure I'm getting it. I might even be a little
more comfortable with it. 

I certainly hope the idea of the topic, topicalizers, and topicalizees as
separate from the fixed $_ default variable gets pounded out quite throughly
in the "What's New?" section of the Perl6 documentation. 

RE: Topicalizers: Why does when's EXPR pay attention to topicaliz er r egardless of associated variable?

[Garrett Goebel]

Dang... why isn't you see so many more obvious errors, the moment after you
click send?

From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> 
> or without the special case:
> 
> $hi = 'hello';
> $x  = 'burt';
> for $hi -> $y {
>   given {
> when /burt/ { print "Go Away" };
  default { print $y };
  ^^
>   }
> }

RE: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

[Garrett Goebel]

From: Allison Randal
> Garrett Goebel wrote:
> > 
> > Why does C's EXPR pay attention to the topicalizer 
> > regardless of associated variable?
> > 
> > Why introduce the special case?

>
> Why? Because it's oh-so dwim. Think about it, if you've just typed a
> 
>   given $x { ...
> or
>   given $x -> $y { ...
> 
> you know for a fact that you're going to want every C to
> compare against the $_ or $y. Why force people to type:
> 
>   when $y =~ /a/ {...}
>   when $y =~ /b/ {...}
>   ...
> 
> when you already know what they mean? And yes, it's the 
> common case. How many times do you think you'll have a
> switch statement and want the case to compare against
> some value external to the switch?

Not just some value external to the switch, but the value in $_.

I now see the DWIM aspect. Thanks BTW.

But how often will people have non- C statements within a C
scope that'll need the special case handling so they can see a different $_
than C?

To adapt your example:

$hi = 'hello';
$x  = 'burt';
for $hi {
  given $x -> $y {
when /burt/ { print "Go Away" };
default { print };
  }
}

or without the special case:

$hi = 'hello';
$x  = 'burt';
for $hi -> $y {
  given {
when /burt/ { print "Go Away" };
default { print };
  }
}

The second is obviously more explict, but does but requires a few more keys
be typed. I wonder if the C/C special case is really going to
be used regularly enough to justify the loss of clarity, consistency, and
the additional obfuscation potential.

$_ = 'foo';
given 'bar' -> $z {   
  if /foo/ { ... }# true,  $_ = foo
  when 'bar' {# true,  $_ = bar
if /foo/ { ... }; # true,  $_ = foo
  }
  $_ = 'baz'; #$_ = baz
  when 'bud' {# false, $_ = bar
if /baz/ { ... }; # true,  $_ = baz
  }
}


I guess the next question in the context of the following is:

Larry Wall wrote in Apocalypse 4:
> It should be possible to make user-extensible syntax look
> just like built-in syntax. 

How would I create a user-extensible construct that works like given/when?
I'm guessing the answer is: you don't.

RE: Semicolons: where they're needed

[Garrett Goebel]

From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Garrett Goebel:
> # Larry Wall in Apocalypse 4 writes:
> # > this special rule only applies to constructs that take a
> # > block (that is, a closure) as their last (or only) argument.
> # > Operators like sort and map are unaffected. However, certain
> # > constructs that used to be in the statement class may become
> # > expression constructs in Perl 6.
> #
> # Does that mean there may still be constructs which take a
> # block, as their last argument, but which don't require a
> # semicolon if they can be written as one-liners?
> #
> # How terribly unpopular would it be if the "when do I need
> # to use a semicolon" question was simply answered:
> #
> # is block-ending construct's final curly on a line by itself ? 0 : 1
> 
> Oooh, there's a problem with that concept:
> 
>   if(foo) {
>   bar
>   } #There's a semicolon here...
>   else {#which leaves this else dangling!
>   baz
>   }

Really?

Isn't the C's block the one with the final curly in the if/elsif/else
statement?

And throwing caution to the wind... I'm one of the fools that prefers:

if foo {
  1
} elsif bar {
  2 
} else {
  3
}

I don't like lining up your C's and C's with C's because
visually it makes it look like a separate statement (to me). I don't mean to
disgress into matters of taste... but it would certainly be nice if all
constructs with dangling blocks could be expected to follow the same rules.

RE: Topicalizers: Why does when's EXPR pay attention to topicalizer r egardless of associated variable?

[Garrett Goebel]

From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> Speaking of which, you forgot your trailing semicolon for the
> C expression's final closure/block.

s/expression/statement/

Semicolons: where they're needed

[Garrett Goebel]

Larry Wall in Apocalypse 4 writes:
> this special rule only applies to constructs that take a
> block (that is, a closure) as their last (or only) argument.
> Operators like sort and map are unaffected. However, certain
> constructs that used to be in the statement class may become
> expression constructs in Perl 6.

Does that mean there may still be constructs which take a block, as their
last argument, but which don't require a semicolon if they can be written as
one-liners?

How terribly unpopular would it be if the "when do I need to use a
semicolon" question was simply answered:

is block-ending construct's final curly on a line by itself ? 0 : 1


And can we assume that "on a line by itself" ignores non-$/ whitespace?

Ambiguity with regards to switch statements special handling of Class::Name

[Garrett Goebel]

Larry Wall wrote:
> I think the switch statement will have to recognize any
> Class::Name known at compile time, and force it to call
> $!.isa(Class::Name).

Don't you mean the case/when statement? Wouldn't you want the following to
work:

for @obj {
  when Dog { ... }
  when Cat { ... }
}

Topicalizers: Why does when's EXPR pay attention to topicalizer regardless of associated variable?

[Garrett Goebel]

From: Austin Hastings [mailto:[EMAIL PROTECTED]]
> 
> for @A {
>   for @B -> $x {
> when /a/ $_ -> $a { s/a/b/; ... $a ...; }
>   }
> }
> 
> Once we get inside the curlies, $_ is aliased to the localized var for
> the C (in this case, $x).

I went back and read the Apocolypse 4: RFC 022. I may even understand it
this time through. At least, I no longer have a brain fart when reading the
code above. -Speaking of which, you forgot your trailing semicolon for the
C expression's final closure/block.

Why does C's EXPR pay attention to the topicalizer regardless of
associated variable?

Why introduce the special case? Especially when consistency and
simplification seem to be a strong undercurrent in Perl6? I'm curious what
the reasoning behind the special case is. I don't see what it gives us...
beside one more thing to remember. What would be a use case that illustrates
the need for the special case? And is the special case the common one?

$_ = 'foo';
given 'bar' -> $f {
  if   /foo/ {print};   # true, prints 'foo'
  when /bar/ {print};   # true, prints 'foo'
  when /bar/ -> $g {print}; # true, prints what? 'foo'
}

RE: Perl6 -- what is in a name?

[Garrett Goebel]

From: Melvin Smith [mailto:[EMAIL PROTECTED]]
> At 01:52 PM 1/28/2002 -0600, Garrett Goebel wrote:
> >From: Brent Dax [mailto:[EMAIL PROTECTED]]
> > > Aaron Sherman:
> > > #
> > > # I think the first guy that gets hired to maintain Perl6 code,
> > > # and think "hey, I know Perl, no sweat" will disagree with
> > > # you.
> > >
> > > I disagree.  He'll see stuff he doesn't understand and try to
> > > consult perldoc on it, at which point he'll realize that he's
> > > working with Perl 6.  Then he'll run out, get Camel IV, read
> > > it, and go back to work. Programmer is working with a better
> > > version of language, program is fixed, and ORA made fifty
> > > bucks.  Everybody's happy.  :^)
> >
> >Perhaps. Or perhaps he'll be like our company's lead C++ 
> >developers. They liked Perl4 well enough for a certain problem
> >domain, saw some Perl5 code... and have tried to stay away from
> >it ever since.
> >
> >Perl6 isn't going to make everyone happy.
> 
> I have a hard time believing those C++ guys are really Perl lovers;
> I'ver never spoken to a Perl fan that didn't have dreams of a making
> the language even better than it already is; better OO in Perl, etc.
> Maybe they just have a huge unwieldy Perl4 app they don't 
> wish to port.

They were C++ lovers not Perl lovers. Perl was just a tool in their chest.
In their minds Perl4 was a simple elegant swiss army knife for data munging.
Perl5 was a new version of the same tool, but with too many extra whiz bang
features to suit their fancy.


But hey, Bryan Warnock said it best:

> >Perl6 isn't going to make everyone happy.
>
> That's right, it isn't.  Nor should it strive to.

This isn't Aesops fable about "The Miller, His Son, And Their Ass".
http://www.literature.org/authors/aesop/fables/chapter-281.html

RE: Perl6 -- what is in a name?

[Garrett Goebel]

From: Brent Dax [mailto:[EMAIL PROTECTED]]
> Aaron Sherman:
> #
> # I think the first guy that gets hired to maintain Perl6 code,
> # and think "hey, I know Perl, no sweat" will disagree with
> # you.
> 
> I disagree.  He'll see stuff he doesn't understand and try to
> consult perldoc on it, at which point he'll realize that he's
> working with Perl 6.  Then he'll run out, get Camel IV, read
> it, and go back to work. Programmer is working with a better
> version of language, program is fixed, and ORA made fifty
> bucks.  Everybody's happy.  :^)

Perhaps. Or perhaps he'll be like our company's lead C++ developers. They
liked Perl4 well enough for a certain problem domain, saw some Perl5 code...
and have tried to stay away from it ever since.

Perl6 isn't going to make everyone happy.

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: Larry Wall [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel writes:
> : And this is just looking at it in the simple case. When 
> : multiple-dispatch comes into the picture, then we'll
> : have different invokations of the same method being
> : dispatched to different implementations depending on
> : the parameter list. I wonder how PRE/POST will work
> : once that can of worms has been opened?
> 
> I strongly suspect that DbC and multimethods are, at best, orthogonal.
> My gut level feeling is that multimethod calls look like ordinary
> subroutine calls, and the "method" eventually selected evaluates only
> its own PRE/POST conditions, which could perhaps explicitly 
> delegate to other PRE/POST conditions.  If you want more than that,
> you'll have to give me a PhD.  :-)

I thought I had ;)

That is after all, one of the reasons why I'm a continuing contributor to
the Damian Conway fund.

Would it be as easy as allowing "global" PRE/POST condition blocks to be
associated with an abstract method, and having a derived multimethod's
implementation inherit the PRE/POST conditions from those inherited
implementations which match the same parameter list? Er... for some
definition of match. That's a gross oversimplification isn't it?

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: Garrett Goebel [mailto:[EMAIL PROTECTED]]
> From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
> 
> > So maybe your point was that when you replace a method from a 
> > base class that you only have 1 subroutine for that method,
> > the replacement one, because there wasn't really one there
> > in the interface class to inherit?
> 
> Exactly.

Well, I should probably qualify that a bit. There'd still be only one
implementation for a single-dispatch method in the derived class, even if
the one derived from the super wasn't just an abstract.

And this is just looking at it in the simple case. When multiple-dispatch
comes into the picture, then we'll have different invokations of the same
method being dispatched to different implementations depending on the
parameter list. I wonder how PRE/POST will work once that can of worms has
been opened?

So which Apoc will be the OO one?

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: Glenn Linderman [mailto:[EMAIL PROTECTED]]
> 
> Graham Barr wrote:
> > But the base class may be just an interface class. And thus 
> > by inheriting the pre conditions you are enforcing the API.
> > So I can see a use for it, but I can also see where you
> > don't want it too.
> 
> So if the base class is just an interface class, then you cannot
> usefully inherit the methods, without winding up with just another
> interface class.  Of course, that sometimes is useful too.

Yes. For instance when making an implementation of the interface. The
interface class can define the interface using abstract methods with
PRE/POST conditions to specify what inputs are required and guarantee the
output that will result. The implementation classes pick it up and go on
from there.


> So maybe your point was that when you replace a method from a 
> base class that you only have 1 subroutine for that method,
> the replacement one, because there wasn't really one there
> in the interface class to inherit?

Exactly.


> I'd still like to hear Larry comment on the benefits vs dangers of
> having the PRE and POST conditions defined within the implementation
> block of a method, as opposed to defined outside.  The more I think
> about it, the more convinced I am that the natural place to define the
> pre and post conditions is outside the implementation block, 
> to prevent them from referencing lexically scoped variables of the
> implementation... or have a compiler rule preventing it.  
> Otherwise they could be impossible to evaluate in the context of an
> inherited (replacement) method.

I think this has already been covered by the "no-side effects" rule for
PRE-/POST- Conditions. Which Damian suggested could be implemented by:

Damian Conway wrote:
> By prohibiting mutation of variables not lexical to the block,
> forbidding I/O, allowing calls only to already-defined subs, and
> applying the same restrictions recursively to those subs.

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> > "Larry" == Larry Wall <[EMAIL PROTECTED]> writes:
> 
> Larry> I think our terminology is getting sloppy here.  What 
> Larry> do you mean by "inherit from that method"?  If the
> Larry> derived method overrides the base method, it will
> Larry> manage its own resources, and doesn't need the base
> Larry> method's LAST.  If the derived method calls the base 
> Larry> method, the LAST of the base method will naturally
> Larry> come along for the ride.  If there is no derived
> Larry> method, the base method also calls its own LAST as
> Larry> a matter of course.  I don't see any problem here.
> 
> That's why I'm still puzzled about what it means to inherit PRE/POST
> as well.
> 
> A block of code doesn't have a superclass.  What exactly are you
> "inheriting from"?

I don't think PRE/POST are going to be part of the resources of a code
block. They are part of the resources of a method. I don't know if they have
any value in procedures. Perhaps only methods will be allowed PRE/POST?
 

> If you call "super" from a method, surely the super will have its own
> PRE/POST, and then there's no need to inherit it.  If you don't call
> "super", how do you know the PRE/POST of a similar subroutine in a
> superclass that you're completely overriding should even apply?

For DBC you want to inherit the SUPER's PRE/POST conditions even if you
override the method's implementation. I don't thing PRE/POST apply to
procedure subroutine, just the subroutines which are methods. Assuming we
confine talk of PRE/POST to classes and methods... I think the latter
statement about knowing when the PRE/POST of an inherited method/subroutine
applies resolves itself.

 
> So, does it make any sense at all to talk about "inheriting" PRE/POST
> as a separate act, other than the natural block start/end from calling
> "super" at the right time?

Yes. As you might override the super's implementation, but still need to
satisfy its PRE/POST conditions.

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: David Whipp [mailto:[EMAIL PROTECTED]]
> Peter Haworth [mailto:[EMAIL PROTECTED]] wrote:
> > This is all very sensible, and I completely agree with it. 
> > However, don't we
> > need some restrictions on what can go in PRE and POST blocks 
> > to ensure that they are still valid in inherited methods?
> 
> There's another issue: sometimes we don't want to inherit PRE
> conditions. DBC allows a derived method to strengthen (add)
> post-conditions; but to weaken (remove) preconditions. I
> haven't (yet) seen how this weakening would be accomplished.

In regard to Design-by-Contract, Larry did say more on that later. -Didn't
he?

In Class::Contract, pre-conditions are allowed to weaken by allowing either
the satisfaction of the subclassed method's pre-conditions or by satisfying
the pre-conditions of all classes from which it is derived.

RE: Some Apocalypse 4 exception handling questions.

[Garrett Goebel]

From: Me [mailto:[EMAIL PROTECTED]]
> 
> > The problem I see with inheriting subblocks such as
> > FIRST/LAST/etc, is that they are tied in with the logic
> > ... of their enclosing block...
> 
> Surely this is an argument *for* it being pretty odd
> *not* to inherit them.
> 
> Let's say you add a LAST block to a method. In the
> LAST block you write clean up code that frees some
> resources. If you inherit from that method, and do not
> inherit the LAST block, then you've got a leak. This is
> obviously a mild example.

Methods can be inherited. Their implementations may include LAST blocks,
which will be invoked along with the inherited method if the method is not
redefined in a subclass. However, if the method is redefined in a subclass,
neither the superclass' method's implementation or its associated LAST block
would be invoked. In contrast, pre- and post-conditions _are_ inherited and
separate from the method implementation itself. If an inherited method is
redefined in a subclass, it must still satisfy pre- and post-conditions.

RE: Apo4: PRE, POST

[Garrett Goebel]

From: David Whipp [mailto:[EMAIL PROTECTED]]
> 
> Apo4, when introducing POST, mentions that there is a
> corresponding "PRE" block "for design-by-contract
> programmers".
> 
> However, I see the POST block being used as a finalize;
> and thus allowing (encouraging?) it to have side effects.

It may very well be the case that a procedure's POST block could have side
effects. However, if Larry and Damian are on the same frequency... then a
_method_'s PRE/POST blocks will not have side effects. At least that is what
I perhaps incorrectly inferred from one of previous discussion which Damian
participated in on the perl6-language list about subroutine wrappers,
Hook::LexWrapper, or whatever the means to the ends were in that thread.


> I can't help feeling that contract/assertion checking
> should not have side effects. Furthermore, there should
> be options to turn off PRE/POST processing for higher
> performance. Perhaps we'll learn more about contracts
> (inc. invariants, inheritance) in a later apo?

I hope so. I am particularly interested to hear how PRE/POST blocks will
work in the context of methods and inheritence.


> Will we still use the Class::Contract module?

Your guess is as good as mine. It looks like there will be fewer reasons for
most people to use it. Especially if all you need is assertions. IMO: Its
nice just to hear Larry say "design-by-contract" programmers, and know that
he's still talking about Perl ;)

We'll just have to see how Perl6 DBC support works out with regards to
encapsulation, inheritence, and Class::Contract's other odds and ends. But I
imagine support for things like a POST block checking an object against its
previous state via &old, and things like shortening and flattening, etc.
will still require a Class::Contract.

RE: flex perl mess

[Garrett Goebel]

Piers Cawley writes:
: Damian Conway <[EMAIL PROTECTED]> writes:
: > Of course, that's not to say that the particular C that's returned on
: > failure-to-numerify mightn't have a property set that indicates the problem 
: > was not-a-numeric in nature.
: 
: Having more than one 'undef' value sounds like a recipe for internals
: madness. Or is the undef that gets slung around actually going to be a
: reference to the 'real' undef? 

NaN is merely the floating-point representation of undef when your
variable is stored in a bare num.  And if you declare a variable as
int, there may well be no representation for undef at all!  Similarly,
it may be impossible to taint an int or a num, unless we can figure
out a way to stuff such information into 0 bits.  But I'd like an
array of int or num to be compact.

Larry

RE: flex perl mess

[Garrett Goebel]

Piers Cawley writes:
: If currying magic works in subroutine parameter strings then you can
: just do 
: 
: sub assert_with_func (&^sub is constant, $^expected is constant,
:   $^got, $message)
: {
: &^sub($expected, $got) or die $message || $default_message;
: }
: 
: Here's hoping it will work.

That's my intention.

Larry

RE: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
>
> Here in the 10-step Perl 6 program we don't talk about
> resolution. We just learn to cope with change. ;)

;) I'm still working to grok the changes. I thought I was getting generally
clued in after reading the Apocalypses/Exegesises... but discussions on the
list have steadily been eroding that sense of understanding.


> there will probably be pragmas to disable run-time
> mucking with lexicals. Same thing for compilation.

I at some point possibly:  s/will probably/will/

Right now it looks like Perl6 will make it harder to encapsulate things in
the sense of data-hiding. 

 
> Re-defining constants is a simliar thing and I have
> similar reservations. It might make reading programs
> harder. It will definitely hurt compilation. The trouble
> will be that the compiler can't inline a constant.
 
my int $foo is constant = 'bar';

Just does compile-time typing for $foo? Not inlining the constant?

Exegesis 2 says you can't bless a reference to my int $foo, or ascribe
run-time properties to it. Doesn't this imply that the compiler would be
able to inline it?

I was thinking lowercase typed variables couldn't be rebound, because they
were compile-time optimized... Can they? Or are we back to the selective use
of yet to be named pragmas?

RE: Static Values and Variable Bindings [was RE: Perl 6 - Cheerleader s?]

[Garrett Goebel]

From: David M. Lloyd [mailto:[EMAIL PROTECTED]]
> On Thu, 1 Nov 2001, Garrett Goebel wrote:
> > On Wed, 31 Oct 2001, David Nesting wrote:
> > > On Tue, Oct 30, 2001, Aaron Sherman wrote:
> > > : Yep, but in Perl5, this was never very clean or obvious
> > > : to the casual programmer. Constants have been coming of
> > > : age in Perl, and they're kind of scary if they're not
> > > : constant.
> > >
> > > On one hand, one might say that a developer changing a
> > > constant's binding in order to change its value is probably
> > > doing so because he knows what he's doing.  As I understand
> > > things, constants are really just read-only variables.  Do
> > > we necessarily want to make a special case out of them and
> > > make the variable read-only as well as locking down the
> > > symbol itself against re-binding?
> >
> > One can always turn that argument around, and say that the
> > developer may want to lock down both the variable's binding
> > and the bound value... because he wants to depend on it
> > (always) doing what he wants it to do. What are we going to
> > have for variable bindings?
> 
> A developer shouldn't need to lock down that binding at least
> for lexically scoped vars, because what matters is the value
> in this case. And as for global constants, what about:

Except that in Perl6, I'll be able to easily mess with lexically scoped vars
in your modules if I want to. Remember Damian's discussion about injecting
and accessing lexicals in a caller's scope in the context of Aspect Oriented
Programming (AOP)?

Perhaps you want to nail some things down that you want to be able to depend
on? Maybe someone'll even put modules out on CPAN that mess with other core
modules' lexical vars? Then core module authors'll start getting bug reports
because someone abused their code in a manner they wish'd they could have
explicitly forbidden.

Isn't this basically a subset of the same topic that drove Ken Fox into
shock and dismay not that long ago? Though I believe KENFOX, was more
worried about the loss of data-hiding with Perl6's lexicals. Was that ever
resolved? Will there be a way in Perl6 to explicitly state that my $foo is
inaccessible outside its scope?

I know Perl isn't commonly associated with Bondage and Discipline... but
can't Perl make it possible for the BnD Perl programmers out there have it
if they want it? A lot of people think we're sadomasochists for programming
in Perl anyway ;) What's the addition of a little semantics to up the
dominatrix of unsafe constructs?

 
> sub MY_CONSTANT () { 1234; }
> 
> Using variables for constants in this sense seems weird to me. :-)

Put that way, I'd kind of agree. Constant variables? variable constants? Its
a pretty ugly oxymoron. But that doesn't matter if it's already writ in
stone for Perl6...

Exegesis 2 did say that:
>
> my int ($pre, $in, $post) is constant = (0..2);

Means that you are asking for compile time optimizations, and agreeing not
to bless references to, or ascribe run-time properties to those scalars. So
we've already got variables with constant values. 

I guess my question is, does the compile time optimization for the above
case imply that you can't later do:

  $pre := $post;

If it doesn't then I'll cease and desist... If it does, then wouldn't:

  my scalar $foo is constant = 'bar';

be the 'type' general way to make both a scalar variable binding and its
value constant?

Static Values and Variable Bindings [was RE: Perl 6 - Cheerleaders?]

[Garrett Goebel]

On Wed, 31 Oct 2001, David Nesting wrote:
> On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote:
> : Yep, but in Perl5, this was never very clean or obvious to the
> : casual programmer. Constants have been coming of age in Perl,
> : and they're kind of scary if they're not constant.
>
> On one hand, one might say that a developer changing a constant's
> binding in order to change its value is probably doing so because he
> knows what he's doing.  As I understand things, constants are really
> just read-only variables.  Do we necessarily want to make a special
> case out of them and make the variable read-only as well as locking
> down the symbol itself against re-binding?

One can always turn that argument around, and say that the developer may
want to lock down both the variable's binding and the bound value... because
he wants to depend on it (always) doing what he wants it to do. What are we
going to have for variable bindings?


>From Exgesis 2:
> 
> The type specification tells the compiler that $pre, $in,
> and $post will only ever be used to store integer values.
> And because int is in lower-case, the specification also
> tells the compiler that it's okay to optimize the
> implementation of the variables, because we promise not
> to bless them or ascribe any run-time properties to them.

Am I correct in inferring from this that:

scalar $foo is constant = 0;

Could not be blessed, rebound, or ascribe run-time properties?

RE: Perl 6 - Cheerleaders?

[Garrett Goebel]

From: Sam Vilain [mailto:[EMAIL PROTECTED]]
> 
> It would be a bit like Class::Contract merged with 
> Class::Tangram, but if Class::Contract is going into
> the core then it's a feature I'd like to see...

I'd like to see Class::Contract play nicely with Class::Tangram,
Class::Multimethods, etc. But Class::Contract as-is has a bit too much
rolled into it, and doesn't always play nicely with others. It needs to be
broken out and rebuilt upon shared building block classes, like some of
Damian's newer contributions: Hook::LexWrap, Attribute::Handlers, NEXT, etc.

As the current maintainer of Class::Contract, I'd love to hear your ideas
and better yet see some code to help Class::Contract work better with
Class::Tangram.

Perl 6 - Cheerleaders?

[Garrett Goebel]

Piers Cawley has written a nice article entitled: "Perl 6 : Not Just For
Damians".

If the hair on the back of your neck rises when thinking about Perl 6, or
even if it doesn't... give it a read.

http://www.perl.com/pub/a/2001/10/23/damians.html

General Feelings on Exegesis 3

[Garrett Goebel]

Thank you.

For those who aren't yet busy reading, you can find it at:
http://www.perl.com/pub/a/2001/10/03/exegesis3.html

RE: What's up with %MY?

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
> 
> I think we have a language question... What should the following
> print?
> 
>   my $x = 1;
>   my $y = \$x;
>   my $z = 2;
>   %MY::{'$x'} = \$z;
>   $z = 3;
>   print "$x, $$y, $z\n"
> 
> a. "2, 1, 3"
> b. "2, 2, 3"
> c. "3, 1, 3"
> d. "3, 3, 3"
> e. exception: not enough Gnomes
> 
> I think I would expect behavior (c), but it's not obvious to me.

I would have said (c) as well.

And if I can figure it out... it ain't that tricky.

RE: What's up with %MY?

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > I think you're also overestimating the freakout factor.
> 
> Probably. I'm not really worried about surprising programmers
> when they debug their code. Most of the time they've requested
> the surprise and will at least have a tiny clue about what
> happened.
> 
> I'm worried a little about building features with global effects.
> Part of Perl 6 is elimination of action-at-a-distance, but now
> we're building the swiss-army-knife-of-action-at-a-distance.

Would it be possible/desirable to have 'static' and 'dynamic' properties for
lexical scopes? Could we have static lexical scopes for things that can be
resolved before runtime, yet could be explicitly promoted to dynamic scopes
at runtime if needed?

Speaking from a solid position of ignorance, I must ask: does supporting one
exclude support for the other?

is static|dynamic {
  my $pop = 0;
  sub incr { ++$pop }
}

RE: What's up with %MY?

[Garrett Goebel]

From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> "Bryan C. Warnock" <[EMAIL PROTECTED]> mused:
> > Consider it like, oh, PATH and executables:
> > `perl` will search PATH and execute the first perl
> > found, but 'rm perl' will not.  It would only remove
> > a perl in my current scope..., er, directory.
> 
> But surely %MY:: allows you to access/manipulate
> variables that are in scope, not just variables are
> defined in the current scope, ie
> 
> my $x = 100;
> {
> print $MY::{'$x'};
> }
> 
> I would expect that to print 100, not 'undef'. Are your 
> expectations different?

Hmm, shouldn't that print something like SCALAR(0x1b9289c)?

If you meant ${$MY::{'$x'}} then I'd agree...

RE: What's up with %MY?

[Garrett Goebel]

From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> 
> If there is to be a %MY, how does its semantics pan out?
> 
> for example, what (if anything) do the following do:
> 
> sub Foo::import {
> my %m = caller(1).{MY}; # or whatever
> %m{'$x'} = 1;
> }

IMO: Sets the value of the lexical $x in the caller's scope to 1,
autovifying '$x' if it doesn't exist.

 
> sub Bar::import {
> my %m = caller(1).{MY}; # or whatever
> delete %m{'$x'};
> }

hmm... when:

{ my $x = 1; sub incr {$x++} }

is compiled, the $x++ in &incr refers to the lexical $x. So deleting it
would remove it from the scratchpad of &incr. But I would guess that future
calls to &incr would have to autovify $x in the scratchpad and start
incrementing it from 0. I.e., ignoring a package $x if it exists. I could
see people prefering it either way...


> sub f {
> my $x = 9;
> use Foo; # does $x become 1, or $x redefined, or runtime 
>  # error, or ... ?

do you mean Foo::import()? 'use' is handled like:

BEGIN {
  require Foo;
  Foo::import(@_);
}

So 'use Foo' would modify the caller, which being processed at compile time
would be 'main'. So this would create a my $x in the scope of the main_cv.
Which would then be removed by the later 'use Bar'.

Assuming Foo::import(), I would guess that the $x which is local to &f would
be assigned the value 1.


> {
>   # is this the same as 'my $x = 1' at this point,
>   # or is the outer $x modified?

If you indeed meant 'use Foo', then the lexical $x of 'main' would be
created and set to 1.

Or, assuming you meant Foo::import() the answer would be neither. It would
neither modify the outer $x or create a new my $x, but modify the value of
the $x which exists within the scope of &f.


>   use Foo;
>   ...
> }
> use Bar; # is $x now still in scope?

'use Bar' would occur at compile time, and would remove the $x from main's
lexical scratchpad which had been created when you did 'use Foo'.

Or had you said Bar::import(): My guess would be that at this point, $x
would be removed from the stash of &f.


> print $x; #compile error? or runtime error? or prints 9 
>   #(or 1...) 

If you used 'use Foo' and 'use Bar', it would print 9. Because the $x local
to &f would never have been touched.

If you meant Foo::import() and Bar::import() and had warnings turned on, it
would print:

  Use of uninitialized value in print at ...

 
> Bar::import(); # any difference calling it at run time?

Yes... as mention above. One happens at compile, the other at runtime so the
caller and consequently lexical scope is different in each case.


> }
> 
> and so on
> 
> IE what effects to do the standard hash ops of adding, modifying,
> deleting, testing for existence, testing for undefness, etc 
> etc map onto when applied to some sub's %MY, at either compile
> or run time.

I would hope that it would be identical to the current behavior we
experience when modifying a package's stash. Or however the new behavior for
stashes maps to Perl6.

RE: What's up with %MY?

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
> 
> Can we have an example of why you want run-time
> symbol table manipulation?

How about being able to dump and restore subroutines and closures along with
their lexical environment?

Perhaps this next example doesn't have to fall under the runtime category,
but I personally would like to be able to use Perl5 attributes to take the
argument from an attribute specification's parameter list and convert it
from q{} into an anonymous subroutine with the same lexical context as the
subroutine implementation of which it is an attribute. Here's a contrived
example:

{
  my $year = 2001;
  sub year
: Pre($_[0] >= $year or die q{can't go back})
{ @_ ? $year = shift : $year }
}


> If the alias gets more complicated, I'm not sure the
> symbol table approach works well at all.
> 
> >> Modifying the caller's environment:
> >> 
> >>   $lexscope = caller().{MY};
> >>   $lexscope{'&die'} = &die_hard;
> 
> This only modifies the caller's scope? It doesn't modify
> all instances of the caller's scope, right? For example,
> if I have an counter generator, and one of the generated
> closures somehow has its' symbol table modified, only that
> *one* closure is affected even though all the closures
> were cloned from the same symbol table.

In the example above, any future use of '&die' within the caller's lexical
scope would execute &die_hard instead of whatever &die used to refer to.

In your example it depends on whether by cloning you mean that each
generated closure has its own symbol table which is a copy of the values
from the original symbol table, or whether it is aliased to refer to the
same underlying values from the original symbol table.


> What about if the symbol doesn't exist in the caller's scope
> and the caller is not in the process of being compiled? Can
> the new symbol be ignored since there obviously isn't any
> code in the caller's scope referring to a lexical with that
> name?

My preference would be for autovification. That new symbols would be pushed
onto the scratchpad/symbol-table of the target lexical scope. Using another
contrived example in Perl5 syntax, what about:

{
  my $foo = sub {'hello'};
  sub say {
$foo;
my $a = eval qq{$_[0]};
eval(qq{\$$a})->();
  };
}
print say('foo');

What if you'd like to insert an anonymous $bar subroutine into the
scratchpad of &say?


> Do we favor expression too much over verification? I'm
> not qualified to answer because I know I'm biased towards
> expression. (The %MY issues I'm raising mostly because of
> performance potential.)

What are the performance problems? Don't Cv's already have their own
scratchpads which could potentially by modified by code using Inline.pm or
XS code at runtime? It's not like we're adding anything new here... are we?
Isn't this just making something that is currently very difficult to do
easier?


> This particular issue is causing trouble because it has a big
> impact on local variable analysis -- which then causes problems
> with optimization. I'd hate to see lots of pragmas for turning
> features on/off because it seems like we'll end up with a more
> fragmented language that way.

Is this really a pragma issue?

I thought part of the Parrot thing was to allow simpler objects and their
associated vtables to be promoted to more complex ones. So we can have bells
and whistles, without having them impact performance until you start making
use of them. And then only affecting the performance of those objects which
are promoted. So write access to a Cv's local scope might done with one of
those scary polymorphic function objects which is less efficent than the
base function object where a function call is 'just a function call'.

RE: Prototypes

[Garrett Goebel]

From: Bryan C. Warnock [mailto:[EMAIL PROTECTED]]
> 
> On Monday 03 September 2001 11:56 pm, Bryan C. Warnock wrote:
> > The third value is a "peek" value.  Do the runtime 
> > checking, but don't do any magic variable stuff.  As a
> > matter of fact, don't run any user-code at all.  Simply
> > return a true or false value if the arguments *would*
> > match. (This allows us to check incoming coderefs, to
> > see that they take the arguments that *they* expect.
> >  Similar to the whole "pointer to a function that takse
> > a pointer to a function, and an int."  Of course, no
> > checking the return value.  But they're supposed to
> > handle your want()s.)
> 
> Er, scratch this.  Blows up if the sub isn't prototyped.  A 
> much *better* way is to make the prototype of any sub a
> property (trait) of that sub.  We can always query for a
> property.

This is possible now:

$foo = sub ($) { print "hello world\n" };
print prototype $foo;

RE: Source/Program metadata from within a program

[Garrett Goebel]

From: Nicholas Clark [mailto:[EMAIL PROTECTED]]
> On Thu, Aug 30, 2001, Brent Dax wrote:
> > From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> > # On Fri, Aug 31, 2001, Bryan C. Warnock wrote:
> > # > Access to the source code.
> > #
> > # Already got that.
> > #
> > # use Fcntl qw(:seek);
> > # seek DATA, 0, SEEK_SET;
> > # @code = ;
> > 
> > IMHO, that's too hackish--just reading that doesn't make
> > what you're doing obvious.  An explicit $*CODE filehandle
> > would make more sense to the uninitiated.
> 
> perl -we 'print q(use Fcntl qw(:seek); seek DATA, 0, SEEK_SET 
> or warn $!; @code = ; print qq(Here is my source 
> code\n), @code;), "\n__DATA__\n"' | perl 
> Illegal seek at - line 1.
> Here is my source code
> 
> Who said that my source file handle was seekable?
> Particularly if it's coming in via an interesting PerlIO 
> layer (and not just a pipe as in my contrived example.)

This gets a little closer... but BEGIN, INIT, CHECK, END blocks are lost
except for subroutine definitions. Anyone know a way to get at them using
B::Deparse?

perl -we '$a++; BEGIN{$a=1} use B::Deparse; B::Deparse::compile()->(); my
$var=q{here}; sub hello {print qq{hello\n}}'

RE: explicitly declare closures???

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
> 
> > You forgot the other example that someone raised:
> > 
> > { my $x = 'X'; *h = sub { $H = sub {pr $h} }}
> > h(); $H->();
> > 
> > Which prints:
> > 
> > Z
> 
> Did you mean this?
> 
> { my $z = 'Z'; *h = sub { $H = sub {pr $z} }}
> h(); $H->();
> 
> Then I agree.

Yes, my example was one cut and paste too early...

;)

RE: explicitly declare closures???

[Garrett Goebel]

From: Dave Mitchell [mailto:[EMAIL PROTECTED]]
> Ken Fox <[EMAIL PROTECTED]> wrote:
> 
> > You're speaking in Perl implementation terms. I've already told you
> > that if Perl acts the way you say it does, then Perl has buggy
> > closures. You don't need to explain a bug to know that one exists!
> 
> Okay, to humour me for a mo', what should the following 2 examples
> output if Perl were doing the "right" thing?
> 
> 
> sub pr { print $_[0] || 'undef', "\n" }
> 
> { my $x = 'X'; sub f { $F = sub {pr $x} }}
> f(); $F->();
>
> { my $y = 'Y'; sub g { pr $y; $G = sub {pr $y} }}
> g(); $G->();

X
Y
Y

I'm hardly an authority, but a closure should reflect the environment at
runtime... not compile

You forgot the other example that someone raised:

{ my $x = 'X'; *h = sub { $H = sub {pr $h} }}
h(); $H->();

Which prints:

Z

RE: Expunge implicit @_ passing

[Garrett Goebel]

From: Ken Fox [mailto:[EMAIL PROTECTED]]
> Michael G Schwern wrote:
> > Any time you want to implicitly pass @_, you can just as easily
> > *explicitly* pass it or use goto.

goto does screw up caller... so I wouldn't say *anytime*
 
> I never thought of using goto actually. "goto &$method;" actually
> looks clearer than the code I'm using. (Although with re-directors
> we want to minimize cost so the 10% penalty should be eliminated.)

sub foo { &{ $_[0]->{_foo} || $_[0]->can(_foo) } }

works just as well as

sub foo { goto &{ $_[0]->{_foo} || $_[0]->can(_foo) } }

and doesn't mess up code which relies on caller...

Will subroutine signatures apply to methods in Perl6

[Garrett Goebel]

Any word from on high whether subroutine signatures will apply to methods in
Perl6? There's RFC128 and RFC97... but they both mostly dodge the issue of
methods.

The absense of method signatures for specifying required, optional, and
named parameters... not to mention type-checking for validation and dispatch
are why we've ended up with an assortment of parameter handling modules with
conflicting styles.

RE: Semi-OT: Good compiler book?

[Garrett Goebel]

And also on the introductory level:

Art of Compiler Design, The: Theory and Practice
http://www.amazon.com/exec/obidos/ASIN/0130481904

Constructing Language Processors for Little Languages
http://www.amazon.com/exec/obidos/ASIN/0471597546

what's with 'with'? (was: [aliasing - was:[nice2haveit]])

[Garrett Goebel]

From: Stuart Rocks [mailto:[EMAIL PROTECTED]]
> 
> Both the following would work:
> 
> with($foo){
>print "I am not a $foo\n";
>   # or:
>print "I am not a ";
>print;
> }

Okay... I've been mostly ignoring this thread. But can someone reiterate the
difference between the above and

for($foo){
   print "I am not a $foo\n";
  # or:
   print "I am not a ";
   print;
}

???

RE: Multiple classifications of an object

[Garrett Goebel]

From: David L. Nicol [mailto:[EMAIL PROTECTED]]
> "Mark J. Reed" wrote:
> 
> > But you're opening a big can of worms if you make such a
> > change.  The biggest impact would be in the way methods are defined.
> > Instead of just being members of a package, they would have to be
> > associated with particular objects (classes or instances).  A method
> > may still be associated with a class by being defined in its
> > package, but what about an instance?Do we give each
> > instance a package?
> 
> Rather, How Do We Do This With Vtables?

Aren't lexical subroutines on the table for Perl 6? Wouldn't they be well
suited for the task? And how do lexical subroutines hook in with vtables?


> I've been saying all along that I think class method names should get
> a number the first time they appear, which is the offset into the
> vtable (array of coderefs) for that name.  That would turn 
> the multiple hash lookup of current perl method binding into a single
> array lookup.

I'm still wishing people would consider having a separate namespace for
versions of classes. So that depending on module dependencies I could
simultaneously use modules with conflicting dependencies that require both
SOAP::Lite v0.50 and SOAP::Lite v1.X.

 
> So every class has a vtable, which is a copy of its parents except for
> what is overridden within it, and a instance that wishes to 
> deviate could make a local copy of its vtable and twiddle it.

Why not just fall back to the ancestor(s) unless it provides its own. What
good does flattening an instance accomplish that polymorphism doesn't?

RE: Properties and stricture

[Garrett Goebel]

From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> 
> Before anyone gets the wrong idea, I don't think the solution is a
> drastic scaling back in Perl's flexibility.  I just don't know what
> the solution is yet.  Maybe it should be possible for a class to
> completely seal off its namespace to the outside world on request.

How do you determine "the outside world"? Out of the package's namespace or
out of the file's?

When you say "seal off its namespace", do you mean that the symbol table
would be thereafter static... or that only code within the predeclared scope
could mess with the symbol table? What about lexicals?

How about:

  package_name.finalize();
  finalize package_name;

finalize could/should? probably be context-aware as to which BEGIN, CHECK,
INIT, or END phase it is in... Or would that be better as BEGIN.finalize(),
CHECK.finalize(), ... with package.finalize() implying:

  $_.finalize()  foreach(qw(BEGIN CHECK INIT END))

RE: properties

[Garrett Goebel]

From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001 at 10:10:55AM -0500, Garrett Goebel wrote:
> > What is UNIVERSAL::can($foo, 'new') going to return if 
> > there is a variable and/or value property 'new' set
> > on $foo?
> 
> undef if there is no "new" method.

Then what's the use of using object methods to override properties? 

print $sv.stringify  if $sv.can('stringify');

 
> > To my knowledge, no one has yet proposed how you can clear 
> > a user-defined property on a value?
> 
> delete $foo.prop{name};

How do you know if that is a value property you're attempting to delete?

$foo is Bar("loneliest") = 1 is Bar("ever");

Do delete and exists only work on value properties? I.e. and not for
variable properties?

delete $foo.prop{'Bar'}  if exists $foo.prop{'Bar'};


I suppose it is time to sit back and wait for the Apocalypse...

RE: properties

[Garrett Goebel]

From: Graham Barr [mailto:[EMAIL PROTECTED]]
> On Tue, May 22, 2001, Damian Conway wrote:
> > > if so, then wouldn't it be safer to put properties 
> > > inside a special object associated with each object
> > > (the 'traits' object) so there would be little
> > > namespace collision?
> > 
> > We actually want the possibility of that kind of namespace 
> > collision: for polymorphism.
> 
> Many people keep bringing this up as a confusion and you give 
> the same reply.
> 
> However there has not yet, AFAIK, been any description of how 
> having a method overload a property is useful.

What I don't understand is why we need properties as yet another layer of
polymorphism enabling pseudo OO-Perl? Why not use the "everything is an
object" paradigm and say that variable and value objects have default
"property" methods that can be called and/or overridden? Hell, why not do
tying by overloading default variable methods while we're at it? Or make
magic accessible to mere demigods by providing something akin to
$foo.value.magic.??? accessors.

What is UNIVERSAL::can($foo, 'new') going to return if there is a variable
and/or value property 'new' set on $foo?

Blurring properties and object methods screws with "\L$object" "\u$class"
method vs. "\L$built" "\u$user" property naming conventions.

To my knowledge, no one has yet proposed how you can clear a user-defined
property on a value?

RE: Properties, deleting them, and dump

[Garrett Goebel]

From: Carl Johan Berglund [mailto:[EMAIL PROTECTED]]
> 
> Other than that, I think I like Larry's idea to have one variable_is 
> and one value_is method. I would also very much have Data::Dumper 
> built in as 'dump', so that I could say

I would rather the bike shed be painted:

@var_prop = keys $foo.is;
@val_prop = keys $foo.value.is;

RE: properties

[Garrett Goebel]

1) It looks like properties proposed will introduce an inconsistency in
naming conventions. In OO-Perl programmers are advised to use leading
lowercase for object methods and leading uppercase for class methods.
Properties are lowercase for built-ins and uppercase for user-defined. Don't
we need to change the naming conventions on one or the other to avoid
confusion?  Could we do something like Python and make built-in properties
pre- and post-pend __?

sub foo is __lvalue__ { ... }


Larry Wall writes:
> 
> We're calling them properties now instead of attributes
> because we don't want people to confuse properties with
> object attributes (except to the extent that we do).

2) Are you sure you don't want people to confuse them? I certainly am, and
the blurred line between the two seems intentional to me. After all, isn't
it an explicit goal to make properties overloadable with object methods?
I.e., sharing the same object method call syntax.

Several people have posted messages asking that the distinction be made more
explicit and visible, and Damian has countered that doing so would defeat
the whole purpose.

Damian Conway writes:
> Er...yes...that's rather the point of the exercise: to be
> able to polymorphically override the behaviour of
> properties by defining methods.


Larry Wall writes:
> I've seen uses for compile-time properties on variables,
> and run-time properties on values, but I've not yet seen
> any decent use for run-time properties on variables.  So
> I'd be inclined to disallow properties on lvalues unless
> they're in a "my" or "our"

3) Can someone state what the purposes of properties are in the above cases?
Compile-time optimizations... and what else? And why do we need properties
to do this? I.e. why can't properties simply be variable and value
attributes in an OO sense.

4) In regard to disallowing properties on lvalue subroutines: What about
function signatures? Isn't that a necessary property of the subroutine? 

5) As a few people have mentioned, there seems to be a similarity between
"tying" <=> "variable properties" and "overloading" <=> "value properities".
Are these semantically different concepts, or is it possible that properties
vs. tying/overloading are 2 ways of doing the same thing? I.e., being able
to tie a scalar by defining FETCH STORE and CLEAR properties on the
variable? Create objects by calling a constructor which returns a value with
properties?

6) People have asked how you clear a property. I'm assuming that while you
might be able to clear runtime properties, that it would be impossible to
clear or modify compile-time ones at runtime.


Damian Conway writes:
>
> sub SCALAR::Purpose ($value) {
>   return "This scalar value's purpose is $value.prop{Purpose}"
> }

7) This example makes me wonder about the properties as actions question.
Which ties back into tying. Would it be possible to allow properties to
optionally have both "data" and an associated code block?

my $baz;
my $foo is
  FETCH ()  { $baz }
  STORE ($) { $baz = $_[0] };

8) Last... One thing that bothers me in the Perl 5 implementation of
attributes, is that there is no way for a subroutine's attributes to access
the lexical scope of the subroutine. Would this be on the table for Perl 6?
If we allowed properties to optionally include a code block, then could this
code block execute within the same lexical scope as the subroutine proper?

RE: Apo2: \Q ambiguity

[Garrett Goebel]

From: Larry Wall [mailto:[EMAIL PROTECTED]]
> Richard Proctor writes:
> : In Apocalypse 2, \Q is being used for two things, and I 
> : believe this may be ambiguious.
> : 
> : It has the current \Quote meaning admitibly \Q{oute} it is 
> : also being proposed for a null token disambiguate context.
> : As in $foo\Q[bar].
> 
> Hmm, yes, that's a problem.  I'd forgotten about the quotemeta kludge.
> I'll have to think about it.  Maybe quotemeta becomes \qm{} 
> or some such.

The problem with \Q quotemeta was the biggest thing to jump out at me when
reading A2... That is before my brain turned to mush. Seems like quotemeta
be serving its purpose if you have to consider escaping its contents...
What's the Perl6 equivalent to:

#!perl -w
# script.pl:
my ($match, $filename) = @ARGV;
local $/;
open FH, $filename;
$file = ;
print scalar @{[$file =~ m/(\Q$match\E)/gs]};
1;
__END__

file.txt contents:
{foo}\E{foo}\E{foo}

> script.pl {foo} file.txt
3
>

RE: apo 2

[Garrett Goebel]

From: Buddha Buck [mailto:[EMAIL PROTECTED]]
> At 03:00 PM 05-04-2001 +0100, Michael G Schwern wrote:
> >On Fri, May 04, 2001 at 09:51:53AM -0400, John Porter wrote:
> > > And btw . . .  Wouldn't
> > >
> > >   $thing has property
> > >
> > > make more sense than
> > >
> > >   $thing is property
> >
> >"$foo has true" doesn't flow as well as "$foo is true".  Dunno quite
> >what the other expected uses are.
> 
[...]
> 
>my Netfile $page has url("http://www.perl.com/";) is constant;

Maybe it is just my interpretation of Damian's OO-Perl book... but:

is  => typing, inheritance, etc.
has => composition, aggregation, etc.

RE: sandboxing

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> 
> At 05:22 PM 5/3/2001 -0400, John Porter wrote:
> >David L. Nicol wrote:
> > > is sandboxing something a language should support
> > > at all, or is it best left to the OS to provide
> > > a solid chroot facility?
> >
> >IMHO this is one of those things that should be kept firmly
> >in the front of our minds as we design the engine.
> >It is yet another area in which we could do right what java
> >got half-right.
> 
> The biggest problem I have with sandboxing is that to do it right is 
> apparently difficult, judging by the number of people that 
> get it wrong. We need to rope in a security expert, I think, for
> the design.

A Language-Based Approach to Security: 
http://www.cs.cmu.edu/~rwh/papers/langsec/dagstuhl.pdf

ResearchIndex is a fun site to explore:
http://citeseer.nj.nec.com/volpano98language.html

Java influenced papers:
http://www.cs.princeton.edu/sip/pub/

YAYAYA string concat proposal

[Garrett Goebel]

Suggestion: prepend a ~ or , to numeric comparison operators

Addresses the key concerns:
o  frees up .
o  spaces insensitive (though cmp, eq, ...do care about spaces)
o  using the , instead of ~ would be 1 keystroke on most keyboards
o  ~ and , visually intuit a string (~ more than ,)
o  avoids: $foo = "foo" + "$foo" + foo + foo()
o  easy to differentiate string and numeric ops
o  doesn't spill over into other syntax changes... (i think)

From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel <[EMAIL PROTECTED]> whispered:
> | Perl 5  Perl 6
> | --- ---
> | ->  .
> | +   +
> | .   ~+
> | .=  ~+=
> | ~=+
 [and possibly consider]
> | eq  ~==  or eq
> | ne  ~!=  or ne
> | gt  ~>   or gt
> | ge  ~>=  or ge
> | lt  ~<   or lt
> | le  ~<=  or le
> | cmp ~<=> or cmp
> |
> | You can leave aliases for eq, ne, gt... or depreciate them.
> | -But leave precedence as is...
 
> It's not bad enough that we're getting a proliferation of trigraph
> operators, now you want to add a quadgraph?  No thank you.

cmp requires typing at least 4 characters too:
  sort {$a cmp$b} qw(z y x);
  sort {${a}cmp$b} qw(z y x);

It has been suggested to me privately to leave the lettered ops eq, ne, cmp,
etc. alone since there is a history behind using lettered ops on strings and
symbol ops on numbers. That's fine. You might consider allowing either, or
possibly just dropping the trigraphs and/or quadgraphs.

YAYAYA string concat proposal

[Garrett Goebel]

Suggestion: prepend a ~ or , to numeric comparison operators

Addresses the key concerns:
o  frees up .
o  spaces insensitive (though cmp, eq, ...do care about spaces)
o  using the , instead of ~ would be 1 keystroke on most keyboards
o  ~ and , visually intuit a string (~ more than ,)
o  avoids: $foo = "foo" + "$foo" + foo + foo()
o  easy to differentiate string and numeric ops
o  doesn't spill over into other syntax changes... (i think)

From: Stephen P. Potter [mailto:[EMAIL PROTECTED]]
> 
> Garrett Goebel <[EMAIL PROTECTED]> whispered:
> | Perl 5  Perl 6
> | --- ---
> | ->  .
> | +   +
> | .   ~+
> | .=  ~+=
> | ~=+
 [and possibly consider]
> | eq  ~==  or eq
> | ne  ~!=  or ne
> | gt  ~>   or gt
> | ge  ~>=  or ge
> | lt  ~<   or lt
> | le  ~<=  or le
> | cmp ~<=> or cmp
> |
> | You can leave aliases for eq, ne, gt... or depreciate them.
> | -But leave precedence as is...
 
> It's not bad enough that we're getting a proliferation of trigraph
> operators, now you want to add a quadgraph?  No thank you.

cmp requires typing at least 4 characters too:
  sort {$a cmp$b} qw(z y x);
  sort {${a}cmp$b} qw(z y x);

It has been suggested to me privately to leave the lettered ops eq, ne, cmp,
etc. alone since there is a history behind using lettered ops on strings and
symbol ops on numbers. That's fine. You might consider allowing either, or
possibly just dropping the trigraphs and/or quadgraphs.

YA string concat proposal

[Garrett Goebel]

~ looks like a string to me Larry sycophant that I am.
, also looks a little like a string. And is keyboard friendly.

Its doubtless naive to suggest it, but why not:

Perl 5  Perl 6
--- ---
->  .
+   +
.   ~+
eq  ~==
ne  ~!=
gt  ~>
ge  ~>=
lt  ~<
le  ~<=
cmp ~<=>
.=  ~+=
~=+ (concat after)
=~  =~
!~  !~

You can leave aliases for eq, ne, gt... or depreciate them. -But leave
precedence as is...

Perl 5Perl 6
- 
$res = $var + $var2;  $res = $var + $var2;
$name = "This" . "that";  $name = "This" ~+ "that";
$name = "This" . $that;   $name = "This" ~+ $that;
print "Next is " . $i + 1;print "Next is " ~+ $i + 1;
$me = $name . getpwuid($<);   $me = $name ~+ getpwuid($<);   

RE: s/./~/g

[Garrett Goebel]

From: Russ Allbery [mailto:[EMAIL PROTECTED]]
> David M Lloyd <[EMAIL PROTECTED]> writes:
> > On 24 Apr 2001, Russ Allbery wrote:
> > >
> > > It seems relatively unlikely in the course of normal Perl 
> > > that you're going to end up with very many references to
> > > objects.
> >
> > Well, right now in Perl, an object *is* a reference.
> 
> Precisely.  So there's almost never any reason to create a 
> reference to an object, which would be a reference to a
> reference, and for those rare circumstances the existing
> dereference syntax is probably adequate.

How many classes uses a flyweight scalar reference to work around circular
references in garbage collection? Class::Contract does. Also, if it is
common enough to be covered in the Perl Cookbook (13.13)... it probably
isn't too uncommon.

Class::Contract provides a generic constructor which returns a reference to
a reference. 

my $key = \ my $undef;
my $obj = \ $key;
bless $obj, $class;

This is to avoid circular references while providing better encapsulation.
$obj is a flyweight reference to $key. Object attribute accessors lookup
object data in the Class::Contract lexical %data. There is no way to get at
an object's data except through the interface defined in the "contract".
When the $obj goes out of scope, the Class::Contract provided destructor
deletes $data{$key}.

Now all that that means, is that it isn't uncommon that an object might be a
reference to a reference. It is up to the user to decide to make a reference
to that object. But I'd venture to guess that that isn't an all too uncommon
thing.


> I would presume that objects will still be implemented as 
> references under the hood so that passing them around is
> efficient no matter what they contain.

I guess that falls back into Branden's thread of tying variables vs.
overloading values. Which to me is overloading accessors vs. methods. When
someone overloads @foo to be an instance of Foo, is that tying per Perl 5:
magic variables which redirect variable accessors to a class... or something
new? I certainly hope magic in perl 6 is reincarnated as something much more
accessible at runtime to users.

RE: Larry's Apocalypse 1

[Garrett Goebel]

From: Simon Cozens [mailto:[EMAIL PROTECTED]]
> On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
> >
> > I think he's saying that its annoying to have to write any 
> > sort of tag that says "Hey, I'm starting a new Perl 6 program
> > here!" at the top of every single program, much in the same
> > way its tiresome to write "int main(...)" in every C program.
> >
> >  Then again, we already have  to do the #! thing.

There's no need save portability for a #! on Win32.
 

> So have "#!/usr/bin/perl6" do an implicit "module main" in 
> the absence of any other module declaration.

I like that, assuming that:

#!perl6

and

#!perl6 -s -w

would work for Win32...


It is strange, but in perl 5 #!perl -w  turns on warnings, but #!perl -s
doesn't equate to use strict;

RE: Larry's Apocalypse 1 (RFC 73)

[Garrett Goebel]

[Note: This a plain text repost. The original came across as HTML...]

> [25]RFC 73: All Perl core functions should return objects 
[...] 
> I'm thinking that the solution is better abstract type support 
> for data values that happen to be represented internally by C 
> structs. We get bogged down when we try to translate a C 
> struct such a struct tm into an actual hash value. On the 
> other hand, it's rather efficient to translate a struct tm 
> to a struct tm, since it's a no-op. 
> 
> We can make such a struct look like a Perl object, and access it 
> efficiently with attribute methods as if it were a ``real'' 
> object. And the typology will (hopefully) mostly only impose an 
> abstract overhead. 

Neil Watkiss <[EMAIL PROTECTED]> and Brian Ingerson
<[EMAIL PROTECTED]> have been roughing out ideas for a Inline::Struct
module which sounds similar if not related to the this. It's primary
objective is simplifying passing structured data between Perl and C/C++. It
also makes a struct look like a Perl object. There is an unreleased module
implementing a C++ interface which works quite well. A C version is planned
as well. Others may follow. Right now, it works like this:

use Inline CPP => <<'END', STRUCTS => ['Foo']; 

struct Foo { 
  int inum; 
  double dnum; 
  char *str; 
}; 
typedef struct Foo Foo; 

END 

my $o = new Inline::Struct::Foo; 
$o->inum(10); 
$o->dnum(3.1415); 
$o->str('Wazzup?'); 

my %fields = %{$o->_HASH}; 
my @keys = @{$o->_KEYS}; 
my @fields = @{$o->_ARRAY}; 

package Inline::Struct::Foo; 
sub Print { 
  my $o = shift; 
  print "Foo {\n", (join "\n", map { $o->$_() } $o->_KEYS), "}\n"; 
} 

__END__ 



Anything that is typemap'd can be used. I'm hoping Inline::Struct will
evolve into the compiled complement to Class::Struct. If Perl 6 could do
this without requiring a compiler on hand, it would be the perfect
replacement/evolution of Class::Struct.

Garrett 

RE: pitching names for the attribute for a function with no memory or side effects

[Garrett Goebel]

From: John Porter [mailto:[EMAIL PROTECTED]]
> Dan Sugalski wrote:
> >
> > :contained. Or possibly :irrelevant, since generally 
> > speaking most people won't use it and the optimizer
> > will have to infer whether it's safe to not execute
> > the function every time...
> 
> It shouldn't necessarily have to.
> If I *tell* it it's safe, that should be the end of the story.
> It don't get much more optimal than that.

I think he's talking about the 90% of the time that no one explicitly
declares it, but the optimizer infers that it is "contained" anyway.

Speaking of which... how about: "immutable"

immutable adj : not subject or susceptible to change or variation in form or
quality or nature; "the view of that time was that all species were
immutable, created by God" [syn: changeless] [ant: mutable] --Source:
WordNet ® 1.6, © 1997 Princeton University

RE: Unicode handling

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 05:09 PM 3/23/2001 -0800, Damien Neil wrote:
> > So the results of ord are dependent on a global setting for
> > "current character set" or some such, not on the encoding
> > of the string that is passed to it?
> 
> Nope, ord is dependent on the string it gets, as those 
> strings know what their encoding is. chr is the one dependent
> on the current default encoding.

Are built-ins like chr going to be nailed to one encoding at compile time,
or will we be able to toggle the default encoding setting at runtime?

Besides having the ord opcode dispatched by the string tag, will it be
possible to have the chr opcode dispatched by the type of return value
wanted?

$foo:ASCII = chr(65);
@foo:ASCII = map chr($_), 80, 69, 82, 76;

I assume internals-wise that this is similar to whether a function was
called in a scalar, array, or void context... But further raises the spectar
of multiple dispatch to include typing.

Garrett

Things have paused... really?

[Garrett Goebel]

From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
> At 07:20 PM 2/19/2001 -0800, Edward Peschko wrote:
> >
> >The RFC project should be ongoing and more adaptive.
> 
> It's my understanding that this is, in fact, the plan. The 
> only reason things have paused (and it is a pause, not a
> stop) is that we're waiting for Larry to take what's been
> done so far and build something resembling a coherent base
> we can implement. After that's done then we'll have
> something to work from, which is a good thing.

This is perhaps the 3rd recent "waiting for Larry" comment posted in the
last week. I don't mind waiting... good things take time. But this mushroom
_is_ curious to hear if anyone has got wind of the current state of affairs?

I'm particularly curious to hear what if any ideas Larry will be
contributing beyond the herculean task of digesting, regurgitating, and
whipping Perl 5 + 361 RFC's of varying quality into a language
specification.

o  Will experiences from Ruby be assimilated back into Perl? 

o  What impact will C# and .NET have on Perl 6? Don't forget
   Larry's required reading recommendation:  
   http://windows.oreilly.com/news/hejlsberg_0800.html

o  Where will the foreign function interface be heading?

From: Larry Wall [mailto:[EMAIL PROTECTED]] 2000-11-01 7:06 PM
>
> The hope is to extend Perl's subroutine declaration
> syntax (via types and attributes) to the point where
> a "forward" declaration in Perl of a C, Java, or C#
> routine can supply all the glue information formerly
> supplied by XS.  While this will undoubtedly give us
> some rather strange looking Perl, I'd rather look at
> potentially strange Perl than certainly strange XS.

RE: RFC on Coexistance and simulaneous use of multiple module version s?

[Garrett Goebel]

From: Steve Simmons [mailto:[EMAIL PROTECTED]]
> Paul Johnson wrote:
> 
> > Has anyone considered the problems associated with XS
> > code, or whatever its replacement is?
> 
> Pardon my ignorance, but what's XS code?

Extra code is. Which knack had you obfuscation
for could left out have been. --Yoda

My personal preference is that we firmly entrench Inline.pm as a barrier
between your average Perl programmer and XS. -Or whatever it may become.
Then XS could be described as the extra stuff you never (thank God) need to
know.

Garrett

module versions coexistence in same program

[Garrett Goebel]

Dave Storrs <[EMAIL PROTECTED]> writes:
>
> On Fri, 2 Feb 2001, Garrett Goebel wrote:
>
> $Foo::VERSION eq 1.00 
>  |
>  |  $Foo::VERSION eq 2.00
>  |   |
> Bar Baz
>   \ /
> My::Module
>
> Ideally, it should be perfectly legit to have multiple
> versions of a given module on your system, which would
> resolve this problem nicely.
>
> One possible implementation for that would be to introduce
> a new special token, __VERSION__.  It would work something
> like this:
 
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> 
> You want this to work with multiple module versions side by side.  We
> have a disk namespace where we put every module version in its own
> directory, and the user can choose which version is required by
> specifying 'use lib'.  When a new version comes out, we install it
> without touching the existing files - which makes backing out an
> upgrade very easy.
> 
> If multiple versions of a module could co-exist in the same program,
> e.g. by extending the namespace by the module version number, that
> would solve some issues in e.g. mod_perl, or in Storable release x ->
> x+1 migration scripts.

Yes that is what came mind when I heard the vague references about Larry's
plan to support the coexistence of different module versions in Perl6. I was
wondering where the corresponding RFC was, but there doesn't appear to be
any.

I like your idea that all the modules would exist separately, but be
available by extending the namespace to incorporate module version numbers.

So that if one package explicitly required version 1.0, another 2.0, and the
third didn't require an explicit version... They'd get exactly what they
needed. The unqualified 'use' would use the highest installed version
number. We'd probably need a slight change in semantics to allow one to
specify a set/range of acceptable module versions.

package Bar;
use Foo 1.0

package Baz;
use Foo 2.0;

package My::Module;
use Bar >1.0;
use Baz;

Garrett

RE: Really auto autoloaded modules

[Garrett Goebel]

From: James Mastros [mailto:[EMAIL PROTECTED]]
> 
> Speaking of contract names, is Damien about?

In Class::Contract... the package name is the unique identifier.

Piers Cawley has been working on Interface::Polymorphism
http://search.cpan.org/search?dist=Interface-Polymorphism

Perhaps he has some insight to share?


This ties into a concern I have with Perl 6.

If I write a module that depends on the Bar and Baz modules, which
themselves require different incompatible versions of module Foo... How will
that work under Perl 6?

$Foo::VERSION eq 1.00 
 |
 |  $Foo::VERSION eq 2.00
 |   |
Bar Baz
  \ /
My::Module


Garrett

RE: Really auto autoloaded modules

[Garrett Goebel]

Dan Sugalski wrote:
> 
> It's the explicit exporting that I'm concerned about. 
> Perhaps I'm being overly worried, but it strikes me that
> if all a module needs to do to get on the autoload list
> is have an @EXPORT_AUTO declaration at the top (or 
> something similar) we're going to see it abused rather badly.

I'm a little confused:
o  Michael Schwern's AnyLoader allows you to autoload modules
   when you explicitly qualify a function from that module.
o  Dan Sugalski is talking about pre-registering certain 'core'
   functions so that their module is loaded if they are called
   _without_ explicity qualifying their package.

I like the idea of making it easier to load and import modules.
o  It is one less thing for the novice perl programmer to think about.
o  If the standard library has conflicting interfaces, i.e. overlapping
   function names... perhaps we could do this in a manner that would
   help us find them and 'fix' them faster
o  If you're worried about abuse, make use strict disallow it
   and no strict 'load' allow it.


Michael Schwern's AnyLoader is a bit strange though. To use an explicitly
qualified function if the only perceivable gain were to allow you to skip
needing an 'use'. After all, if the purpose is to mangle your namespace...
why are you explicitly calling a function in the first place?  But that
isn't the main reason for AnyLoader is it?

Perhaps it makes more sense in the context of things like:
o  Loading OO mods and oddballs like
   > Class::Contract->contract {};
   > $dbh = DBI->connect( ... );
o  Interfaces as in Tim Bunce's suggestion:

Tim Bunce wrote:
>
> Don't forget that it should tie in with the concept of defining
> 'interfaces' so
>
>   use Foo qw(bar);
>
> may actually just load an interface definition and that definition
> can be (lazily) bound to one of several alternative implementations
> of the Foo interface (one XS and one pure-perl, for example).
> 
> Basically I'm saying that transparent autoloading should be an
> attribute of the interface definition.


John Porter wrote:
>
> And it seems strange to suggest it for packages like Foo anyway;
> we already have autoloader.  And that just emphasizes that this
> feature was meant for core functions.

Incorporating something like Michael Schwern's AnyLoader for explicitly
qualified functions would be geared more at the standard and extended
libraries. Dan Sugalski's need to autoload modules from unqualified function
names is a slightly different problem domain. Those function names would be
determined and registered I assume when Perl itself is built / installed /
configured.

RFC on Coexistance and simulaneous use of multiple module versions?

[Garrett Goebel]

Discussion of RFC 271 and 194 on pre and post handlers for subroutines
reminded me of Larry's desire for Perl 6 to support the coexistance of
different versions of modules.

Besides http://dev.perl.org/rfc/78.pod, are there any RFC's which directly
or indirectly relate to this?