Re: dimensionality in Perl 6

2010-11-18 Thread Buddha Buck
Jon Lang asked me if I intended to send this message to him privately.
 The answer is No...

-- Forwarded message --
From: Buddha Buck
Date: Thu, Nov 18, 2010 at 10:39 PM
Subject: Re: dimensionality in Perl 6
To: Jon Lang

On Thu, Nov 18, 2010 at 7:58 PM, Jon Lang wrote:
 Here's my proposal for how to handle dimensionality in Perl 6:

 Create a units trait that is designed to attach to any Numeric
 object.  Dimensional information gets stored as a baggy object - that
 is, something that  works just like a Bag, except that the count can
 go negative.  (I don't know if the count should be a signed integer or
 a Num; what happens in dimensional analysis when you try to take the
 square root of two inches?)  Overload the Numeric operators to
 properly track the units as well as performing their normal
 activities.  Add one or two methods that allow you to easily extract
 the raw number and/or the units.

An added complication is dimensionality.  ergs, joules, btu and eV
are all units of energy, and it isn't unreasonable to want to add or
subtract energies of different units (my house used (100 therm +
8000kWh) of energy last month, for example).  However, it is incorrect
to add ergs and Newtons, since they are of different dimensionality.

The more robust units/dimensional analysis packages I've seen might
not allow one to add therms and kWh, but they do know that therms and
kWh are both [ML^2/T^2],  I believe at the time I was looking at
JScience's work on JSR-275.  In this setup, when units are registered,
they are given a dimensionality (essentially, a baggy of
dimensions), and values are given a baggy of units (and thus an
implicit baggy of dimensions, the union of the dimensions of the

I don't think a Num is necessary, but I could see a Rat.

 If this is implemented, Duration should be an alias for something to
 the effect of Num but unitssecond.  Otherwise, Instant and
 Duration remain unchanged.


 Jonathan Dataweaver Lang

Re: dimensionality in Perl 6

2010-11-18 Thread Buddha Buck
On Thu, Nov 18, 2010 at 11:53 PM, Jon Lang wrote:
 Buddha Buck wrote:
 I don't think a Num is necessary, but I could see a Rat.

 As is, is Duration implemented by means of a Num, or a Rat?  Whichever
 it is, that's the type that the difference of two Instances would
 return (properly tagged with seconds, of course).

Clarification:  I didn't mean to imply that a Rat would be sufficient
for Duration, but rather that it would probably suffice for
dimensioned values to have a RatBag of units, each with a RatBag of
dimensions, rather than NumBags.  SBags might be too restrictive.

(sent both publicly and privately on the first try, this time)

 Jonathan Dataweaver Lang

Re: Tweaking junctions

2010-11-01 Thread Buddha Buck
On Mon, Nov 1, 2010 at 7:24 AM, Moritz Lenz wrote:
 On 10/22/2010 06:16 AM, Damian Conway wrote:
 That is, a C$value is an eigenstate of a C$junction if-and-only-if:

     $value !~~ Junction    $value ~~ $junction

 In general this definition makes it impossible to return a list of
 eigenstates from the junction. Just think of junctions containing Code
 objects. Or anything more complicated than the built-in value types.

[Originally sent to Moritz alone because of Reply not sending to the list]

Is it too late in this discussion to point out that, in non-perl
usage, eigenstates are associated with the operator, not with the
value fed into the operator?

[Added at Moritz request]

In linear algebra, eigenvectors and eigenvalues are non-trivial
solutions to the equation Ax=λx, where x is a vector in a vector
space, A is a operator (a function from a vector space to itself) and
λ is a member of the field the vector space is defined over.  For a
given operator A, only certain values of λ allow that equation to be
solved, and those values are called the eigenvalues for A.  Also,
for a given operator A, only certain vectors x will solve the
equation, and those vectors are called eigenvectors.  It should also
be clear that different values of λ work with different sets of
vectors x  (the solutions to Ax = ax and Ax=bx are different if a !=
b), so it's typical to talk about the eigenvectors of A associated
with a given eigenvalue λ.

Since A is linear, if Ax=λx  and Ay=λy, then A(ax) = a(Ax) = a(λx) =
λ(ax) and A(x+y)=Ax+Ay=λx+λy=λ(x+y), so fir a given eigenvalue λ,
there are typically multitudes of eigenvectors which form a vector
space of their own.  Eigenvectors for different eigenvalues are
orthogonal, and any eigenvector can be scaled to be a unit
eigenvector.  If an operator has a full set of eigenvalues, one can
pick a set of unit eigenvectors to act as a natural orthonormal basis
for the operator.  If operator A has three eigenvalues a, b, c, and
three unit eigenvectors x, y, z, such that Ax=ax, Ay=by, and Az=cz,
then if w = dx+ey+fz, Aw = a(dx)+b(ey)+c(fz), which is really easy to

In quantum mechanics, especially the Heisenberg matrix formulation
(but by analogy, also every other formulation, including wave
mechanics), quantum states are represented by vectors in a complex
vector space, and vectors which differ by a real-valued scaling factor
are generally considered equivalent.  Transformations (i.e., anything
which modifies the quantum state of the system, including but not
limited to the passage of time) are represented by (unitary) operators
on the state space.  (Unitary in this case means that the norm of Ax
is the same as the norm of x, for all x.)  The standard notation is a
bit odd, where the 'ket' |x represents a system in state x (and
therefore |x+y a state in a superposition of x and y), The 'bra' x|
is the complement of the ket |x, and can be multiplied by a ket to
get a braket x|y which represents the probability that a system in
state y is also in state x.  |x is, naturally, usually normalized
such that x|x = 1.  Operators act on kets and return kets, so A|x
is the braket notation way of writing the linear algebra Ax.
Naturally, that means that y|A|x is the probability that a system
that starts in state x will be in state y after the transform A.

Since A is a linear operator, it has eigenvalues and eigenvectors.  In
the quantum mechanical world, where vectors represent states, the
eigenvectors are called eigenstates.  Eigenstates |i, |j of an
operator A have the property that i|A|i = j|A|j = 1, but i|A|j =
0 (informally, if you start in an eigenstate of A, then the transform
leaves you unchanged).  However, A|i+j = |ai+bj, so A can change the
nature of a superposition of states.  i|i+j = 1/2, j|i+j = 1/2,
but i|A|i+j = a/(a+b), j|A|i+j = b/(a+b).

Schrodinger's Wave Equation, in matrix notation, is of the form Hx=Ex,
where H is the Hamiltonian operator of the system, and E is the
energy of the system, so the only allowed solutions of the wave
equations are for energy levels E which are eigenvalues of H,and for
quantum states which are eigenstates of H.  Similar equations exist
for virtually every observable, so the only allowable momenta are
the eigenvalues or eigenstates of the momentum operator, the only
allowable positions are the eigenvalues or eigenstates of the position
operator, etc.

So asking for the eigenstates of a quantum superposition is asking the
wrong object for the property.

Re: Temporal seems a bit wibbly-wobbly

2010-02-22 Thread Buddha Buck
On Mon, Feb 22, 2010 at 4:38 PM, Daniel Ruoso wrote:
 The biggest difference proposed by the use of TAI is that when you ask
 for the number of seconds between 2008-12-31T23:59:59+ and
 2009-01-01T00:00:00+ you'll get 2 because of the leap second. But
 you don't need to know how many seconds there were in the TAI scale
 since the 1958 epoch to find that out, you just need to know when we had
 leap seconds.

What do you mean?  The number of seconds between
2008-12-31T23:59:59+ TAI and 2009-01-01T00:00:00+ TAI was 1
because TAI doesn't have leap seconds.  UTC does, but TAI doesn't.

Re: time complexity of searching elements in hash tables in Perl

2009-08-22 Thread Buddha Buck
On Sat, Aug 22, 2009 at 5:07 PM, Forrest Sheng wrote:
 Oh, I mean both Perl 5 and Perl 6. I couldn't find proper list to ask this
 question. So I asked in this list.

I'm not sure perl6-language is the proper place to be asking about the
time-complexity of hashes in Perl6, or at least, not the way that you

Here's another way to ask, which might yield a more useful reply..

In C++, the STL guarantees that lookup operations in a map data
structure are guaranteed to have a time complexity that is at most
logarithmic in the number of key-value pairs in the map.  Does the
Perl-6 specification make any similar guarantees regarding hash
lookups?  If not, does anyone know, offhand, what the time complexity
is for current implementations if hash lookup?


 Forrest Sheng Bao, BSEE, Graduate Student
 Dept. of Computer Science/Electrical Engineering, Texas Tech University
 Sent from Lubbock, TX, United States

 On Sat, Aug 22, 2009 at 4:04 PM, Nicholas Clark wrote:

 On Sat, Aug 22, 2009 at 04:01:13PM -0500, Forrest Sheng Bao wrote:
  Does anyone know the time complexity of searching elements in hash tables
  Perl? Suppose the number of elements is n.
  I have no idea on how Perl automatically builds the hash function and the
  table. If you can tell me how it works, that is also helpful. I can
  the algorithm myself.

 You're asking the question on the Perl 6 language list, but it's unclear
 whether you're asking about hashes in Perl 6, or in Perl 5. It's not
 possible to answer until you clarify that.

 Nicholas Clark

Re-thinking file test operations

2009-07-09 Thread Buddha Buck
Resent to list as I intended to in the first place

On Thu, Jul 9, 2009 at 9:32 PM, Darren wrote:
 Mark J. Reed wrote:

 A few months ago (or maybe more) I proposed making pathnames their own
 type, distinct from (or perhas a subclass of) strings, but easily
 constructed from strings, maybe with an operator.  Having those 29
 single-letter methods on such a class would not bug me as much as
 having them on Str.

 On 7/9/09, Aristotle Pagaltzis wrote:

 * Moritz Lenz [2009-07-10 00:25]:

 stat($str, :e)          # let multi dispatch handle it for us

 This gets my vote.

 I agree.  The built-ins of basic types like Str or Int etc need to stay pure
 and just be about dealing with local data.  Having methods on basic types
 for going out into the wider environment like the file system is just plain
 wrong.  There should be separate IO classes for things like stat, which
 *use* basic types like Str for their interface definitions, and the full
 definition of Str/etc should not include any file-system operations.

It's unclear which you are agreeing with.  By reference, it sounds
like you agree with the idea of a separate pathname type, but by
context, it sounds like you are agreeing with stat($str, :e)

Both the separate pathname type and the stat($str, :e) proposal
salvage the purity of Str, so either would be acceptable to your

I have seen other language APIs have a pathname class, usually called
FilePath or Path or similar.  Generally, I like the idea because it
allows one to abstract away from the specific form of a filename (be
it the /home/blaisepascal/.emacs/emacsrc of Unix, the C:\Documents and
Settings\Users\Blaisepascal\Local Settings\GNUEmacs\emacs.rc of
Windows, the BootDisk:Users:BlaisePascal:Settings:GNUEmacs:emacsrc of
of VMS) to the basic components (devices, directories, and files).

Most of the FilePath APIs I've seen allow virtual traversal of the
path (e.g., given a FIlePath corresponding to
/home/blaisepascal/.emacs, you can ask it for the directory portion to
get /home/blaisepascal, or ask it to specify another layer, to get
/home/blaisepascal/.emacs/22.18), conversion of relative paths to
absolute paths, and perhaps even conversion of one path representation
(like Unix-style paths) to another (like HFS-style paths).

The annoying bit I've found with some APIs is that some of them force
you to use a FilePath as an argument to File.Open(), and don't always
provide an easy way to get from a string to a FilePath, forcing you to
do things like File.Open(FilePath.CurrentWorkingDirectory.AddFileName(myFile))
to open ./myFile.

I support the idea of a separate pathname type, and I trust the Perl6
developers to make it robust but easy to use.

 If you go ahead and put stat ops in Str anyway, then you might as well put
 things like a delete_from(Hash $arg) method on Object, which is a less
 objectionable version of such backwardness.

 -- Darren Duncan

Re: Amazing Perl 6

2009-05-29 Thread Buddha Buck
On Fri, May 29, 2009 at 10:23 AM, Jon Lang wrote:
 On Fri, May 29, 2009 at 6:52 AM, John Macdonald wrote:
 Yep, I've done that.

 But comparing the difference in effort between:

 - press a key
 - Google for a web page that has the right character set, cut, refocus, paste

 means that I don't bother for the one or two weird characters
 every few months that is my current Unicode usage.  If I were
 working with Unicode frequently, it would be worth setting up
 links and mechanisms, or learning the keyboard compose sequences
 for frequently used characters.  I'm sure that there are many
 people in a similar situation.

 Agreed.  Given the frequency with which « and » come up in Perl 6, I'd
 love to be able to have a simple keyboard shortcut that produces these
 two characters.  Unfortunately, I am often stuck using a Windows
 system when coding; and the easiest method that I have available to me
 there (that I know of) is to pull up Character Map.

In response to this thread, I activated the US International
keyboard layout, and once that's done theoretically one can get
Spanish style quote mark with RightAlt+[ and RightAlt+] like so: «
and ».

The questions which remain (for me, at least) is if (a) the symbols
survive in email, and (b) if they really are the proper marks for

 Jonathan Dataweaver Lang

renaming or adding some operators

2009-05-29 Thread Buddha Buck
Resending to list

On Fri, May 29, 2009 at 9:53 PM, Darren Duncan wrote:
 I had some thoughts lately about the Perl 6 operators, and wanted to bounce
 some ideas.


 Secondly, regarding the Bool type, I think it would be useful for Perl 6 to
 define the full complement of dyadic logical operators, of which I count a
 few that you don't appear to already have.  Probably the best place is in
 Synopsis 32.

There are 16 dyadic logical operators, not all of which make sense to
have.    You name 10.

 Note that all the dyadic ops I am discussing are meant to be read as infix
 ops only.

 These are the boolean/logical ops you already have:

 Niladic ops aka value literals / constants:
 * Bool::False
 * Bool::True

 * not aka !, but ¬ alias could be added

 * and aka , but ∧ alias could be added
 * or aka ||, but ∨ alias could be added
 * xor aka ^^ aka !===, but ⊻, ↮ aliases could be added
 * ===, but xnor, ↔ aliases could be added

I'm certain I know the semantics of these (and chooses the minimum of
the two, or the maximum, xor checks for difference, xnor checks for
sameness), but I'm uncertain of some of the rest...

 But here are a few more dyadic:
 * nand aka ⊼ aka ↑
true unless both operands are true

 * nor aka ⊽ aka ↓
true if both operands are false

 * implies aka imp aka →
true unless left operand true and right operand false.

 * nimp aka ↛
true if left operand true and right operand false?

 * if aka ←
true unless left operand false and right operand true

 * nif aka ↚
true if left operand false and right operand true?

The other six, which don't depend on the value of both operands, would
(if they existed) have the names false, left, right, nright, nleft,
and true.

 For that matter, as you know, every single boolean/logical operator could
 also have a bitwise analogue, if people were so inclined.


 Thirdly, there are I'm sure a number of other aliases that could be added to
 other ops, such as ≤ and ≥ for = and =, and ≠ for one of the inequality
 operators, although that last one would probably make more sense if = was
 the equality test operator, so maybe best to avoid ≠ then.

Perhaps ≡ and ≢ as aliases?

Re: MMD thoughts 2008

2008-05-06 Thread Buddha Buck
Sorry to reply to the wrong comment, but I lost the original thread in
my mail archives and didn't notice this until now.

On Tue, May 6, 2008 at 1:54 PM, John M. Dlugosz
 TSa |Perl 6| wrote:

  The fundamental flaw of metric mmd is that it trades degrees of
  specificity. Consider the subtype chain E : D : C : B : A
  where the rule is that having an E it is better handled by a
  method dealing with a D than one dealing with an A. The same
  is the case for having a D being better handled by a C than an
  A method. Now consider a multi with the two signatures :(A,C,C)
  and :(D,A,A) and a call with (E,D,D) that goes to :(D,A,A) since
  7  8. But note that it handles the two Ds as As instead of Cs
  as in single dispatch.

Is this right?  (E,D,D) to (A,C,C) is (4,1,1), with a L1 metric of 6.
(E,D,D) to (D,A,A) is (1,3,3) with an L1 metric of 7.  Are you sure
(E,D,D) would bind to (D,A,A)?

Re: Closures, compile time, pad protos

2006-11-24 Thread Buddha Buck

On 11/22/06, Anatoly Vorobey [EMAIL PROTECTED] wrote:

First of all, thanks a lot for your comments.

On Wed, Nov 22, 2006 at 06:43:12PM -0500, Buddha Buck wrote:
   my $x = something();
   if $x==1 {
 My experience with other statically typed by extremely flexable
 languages is that the pads tend to be arranged in (possibly
 interconnected) linked lists.  In this example, I see potentially
 three pads linked by the time ...code... is called:  One containing
 the local variables defined in ...code..., one containing the visibly
 defined $x, and one visible outside that scope.  A reference to $x in
 ...code... will traverse the linked list until it finds an $x,
 presumably finding the one defined in the sample code.

Agreed. By the way, can you offer a perspective on how the pads get
linked up, at runtime? I see each block as having a compile-time pad,
or proto-pad, filled with values known at compile-time; and every time
the block is entered, a new pad is cloned from the proto-pad. At that
point its OUTER reference leads to the proto-pad of the outer block,
and we want to link it up to the real pad of the outer block.

The way I see it, everything which defines a separate lexical scope (a
block, a function, a closure.  I forget if in my $a; ... ; my $b $b
is visible in the ellipsis.  If not, then a my statement also
defines a separate lexical scope) effectively creates a separate pad,
at run-time, when it is entered.  The pad contains all the variables
defined in that lexical scope, and a link to the pad for the
surrounding lexical scope.  The search for a variable is done by
looking up the variable in the current pad, and if not found,
recursively searching all linked pads until it is found or you run out
of pads.

There are reasonable optimizations that can be made.  If a lexical
scope doesn't create any variables, it can reuse the same pad as its
enclosing lexical scope.  If a lexical scope uses only part of an
enclosing pad, the enclosing pad could be broken into two pieces,
linked together, such that only part of it has to be searched or
survives with the enclosed scope, etc.

I haven't read any implementation details as to how Perl6 handles it,
so I'm going to use the following notation:  if $p is a pad, then
$p.lookup('$var') returns the value of the variable $var in p,
$p.myvars is a hash containing the local variables defined in $p, and
$p.enclosing is the pad of the lexically enclosing scope.

I think in p6 notation, that would be...

class Pad {
 has %!myvars;
 has Pad $.outer;

 method lookup(String $var) {
   return %!myvars{$var} if exists %!myvars{$var};
   return $.outer.lookup($var);
 method set(String $var, $val) {
   %!myvars{$var} = $val if exists %!myvars{$val};
   return $.outer.lookup($var, $val);

One way to do it is to simply say: when we enter the inner block from
the outer block, at that point we can re-link the inner block from the
outer proto-pad to the outer pad we entered from. That by itself works,
but I'm having trouble understanding what happens during a sub call
rather than entering the block normally. For example:

  my $x = 1;
  sub foo { $x; }

sub bar() { foo(); }

Here we definitely want foo() to see $x==1 (I think), but we get to
foo() via criss-crossing through bar(), and so how would foo() know
where to find the right pad as its outer reference?

I did some experiments with pugs based on explicitly separating what
is visible at compile time from what is visible at run time.
Specifically, I used the following code:

my $x = 25;
sub bar {
 my $x = 1;
 sub foo {
   print ++$x;
 print $x;
print $x;  // 25
foo();  // 1
foo();  // 2
bar(); // 1
foo (); // 2
foo (); // 3
bar(); // 1
foo(); // 4

Let me call the protopads of foo and bar foo0 and bar0, respectively.

From what I see, foo is visible before bar is run (which was sort of

unexpected to me, but reasonable).   Let's see what happens...

The statement sub bar{...} appears to set up a protopad $bar0 which
contains an $x, but doesn't put in any values until bar is run.
Everything is undef.

The statement sub foo{...} also sets up a proto-pad $foo0 which is
empty.  It is linked, however, to the protopad for bar.  ($foo0.outer
= $bar0)

Running foo(); before the bar() instantiates a pad $foo1 (=
copy($foo0) for this invocation of foo, a copy of its proto-pad.
Since this links to bar0, when ++$x is done, it modifies the $x in
bar0 to 1.  At the end of the call, $foo1 is garbage, waiting on

The next call of foo(); does something similar...  $foo2 =
copy($foo0), $x in bar0 gets accessed and incremented to 2, and $foo2
goes poof.

Running bar(); instantiates a pad $bar1=copy($bar0) for this
invocation of bar.  In theory, the $x in this instantiation is 2, but
the my statement sets it to 1.  More importantly, finally the sub
foo{...} is encountered at run-time, and there is a current lexical
scope available for it.  Since the code is already

Re: Programming languages and copyright?

2006-10-23 Thread Buddha Buck

On 10/23/06, Markus Laire [EMAIL PROTECTED] wrote:

On 10/23/06, Smylers [EMAIL PROTECTED] wrote:
 Markus Laire writes:

  Does anyone know if programming languages are protected by copyright
  or not?

 Code can be copyrighted; ideas can't be.

Yes, but the syntax of the programming language is more than just an idea.

Copyright-article[1] at Wikipedia says that Copyright is a set of
exclusive rights regulating the use of a particular expression of an
idea or information.

So, for example, the idea of look-behind assertions can't be
copyrighted as it's an idea.

But what about a particular form chosen to express that idea (e.g. to
use before pattern to denote look-behind)? Can this be copyrighted
as it's more than just an idea?

Here's another example (which I can work through to completion, unlike the
look-behind example:

It is an idea (and an old one) to place a symbol between two parts of a
mathematical expression to indicate the two parts should be added together.
That idea is uncopyrightable.  Going further, it is also an idea that should
multiple parts be present separated by the addition symbol without anything
to group them into pairs, they should be added from left to right.

It is an idea that that symbol should be +, and is likewise

It is an idea that, when parsing such an expression, the rule to handle the
first idea should be that an expression can be a term, or a combination of
an expression, a '+' symbol, and a term.  This is also uncopyrightable.

The parsing rule (in BNF):

expression :== term | expression '+' term;

is a  particular expression of the idea we've been talking about, and as
such, is theoretically copyrightable.  However, it is also about the only
way to express that particular idea in BNF, so it may fail copyrightability
(in the US) on those lines anyway.

I wouldn't worry about stealing syntax from other languages, as long as you
don't steal their source code without permission.

Disclaimer:  I am not a lawyer, IP or otherwise, and the above should not be
construed as legal advice.

Look-behind assertions are an idea.
The use of before pattern as syntax to denote look-behind assertions is
also an idea.
The abstract grammar that


ps. I'm asking this because I'm thinking of creating a (simple)
programming language by myself, but I'm unsure about how much syntax I
could copy from any existing programming languages.

Markus Laire

Re: This week's summary

2004-09-23 Thread Buddha Buck
On Wed, 22 Sep 2004 21:11:02 +0100, The Perl 6 Summarizer
 The Perl 6 Summary for the week ending 2004-09-17
Another week, another summary, and I'm running late. So:
 This week in perl6-compiler
  Bootstrapping the grammar
Uri Guttman had some thoughts on bootstrapping Perl 6's grammar. He
hoped that his suggested approach would enable lots of people to work on
the thing at once without necessarily getting in each other's way. Adam
Turoff pointed everyone at a detailed description of how Squeak (a free
Smalltalk) got bootstrapped.

This link doesn't seem to be working, and doesn't have
the archives of perl6-compiler online yet.  Does anyone have a link to
the archives that works?

Re: A12: Conflicting Attributes in Roles

2004-04-21 Thread Buddha Buck
Originally sent to Austin alone by accident

Austin Hastings wrote:

-Original Message-
From: Jonathan Lang [mailto:[EMAIL PROTECTED]
role A {has Cat $.x;}
role B {has Dog $.x;}
class Foo {does Cat; does Dog;}
my Foo $bar;
$bar.x;  # Is this a Cat or a Dog?

If, however, two roles try to introduce a method of the same name (for some
definition of name), then the composition of the class fails, and the
compilation of the program blows sky high--we sincerely hope. It's much
better to catch this kind of error at compile time if you can. And in this
case, you can.
Since classes are autogenerating accessors based in data members, it's
doubly reasonable to assume that the same solution will apply: conflict -
From one C6PAN module:

role Dog {
  has $.collar;
From another C6PAN module:

role LawEnforcementOfficer {
  method arrest { ... }
From a third C6PAN module:

class PoliceDog does Dog does LawEnforcementOfficer { ... }

I use PoliceDog in my production code, without a problem.   I don't use
the collar attribute (it's unimportant in my application).
The author of the LawEnforcementOfficer role does an upgrade that fixes
an important bug but also.
role LawEnforcementOfficer {
  method arrest { ... }
  has $.collar;# for holding most recently arrested
So when my program fails to compile, who do I blame?  How do I fix it
quickly, preferrably without creating local branches of the C6PAN modules?


Re: Language Discussion Summaries

2003-02-04 Thread Buddha Buck
Miko O'Sullivan wrote:

The idea of discussion summaries has been well received, so I'm going to
push forward with a few.  I invite everyone here to join in.

The idea is *not* that Miko writes summaries of every thread.  The idea is
that the proponent of an idea, or someone very interested in an idea,
writes a summary as a clean final presentation of the idea and its

Hmmm...  I'm looking at this and I'm wondering

You suggest doing it in HTML.  Wouldn't it make more sense to do it in 
POD, the standard documentation language for Perl?

And how do these differ in concept to the RFC process Perl 6 has already 
gone through?  Wouldn't it make sense, assuming that clean, final 
presentations of proposed ideas or features in Perl are useful, to 
re-open the RFC process?

Re: Language Discussion Summaries

2003-02-04 Thread Buddha Buck
Miko O'Sullivan wrote:

And how do these differ in concept to the RFC process Perl 6 has already
gone through?  Wouldn't it make sense, assuming that clean, final
presentations of proposed ideas or features in Perl are useful, to
re-open the RFC process?

RFC's are proposals before the comments.  The summaries are, well,
summaries of the comments.  My main concern is that Larry, Damian, et al,
are likely to have a hard time reading through all the comments in the
language list (Damian isn't even in the list right now), so the summaries
are a way of letting them cut to the chase on the discussion of each idea.

You are aware the that RFCs went through a revision process, and the 
finalized RFCs that the Design Team are looking at are supposed to 
include the final form of the idea after discussion, and a summary of 
what was thought of it?  Many of the RFCs weren't written until after 
the idea had been discussed.

Re: Why Cmap needs work (was Re: L2R/R2L syntax)

2003-01-21 Thread Buddha Buck
Smylers wrote:

Michael Lazzaro wrote:

And it provides a very visual way to define any pipe-like algorithm, in 
either direction:

   $in - lex - parse - codify - optimize - $out;   # L2R

   $out - optimize - codify - parse - lex - $in;   # R2L

It's clear, from looking at either of those, that they represent data

Yes; that is nice.  I'm just not convinced that it's sufficiently nice
to require adding yet another way of passing data around to the
language.  I'm happy enough with the asymmetry that occurs just having
the arrows to indicate 'reverse flow' data.

The problem with this example is that the two lines deal with two 
different calling conventions, going by Damian's proposal...

Perl 5 has two different code calling conventions:  object oriented 
method calls, and procedural subroutine calls.

OO method calls are L2R already:


Procedural subroutine calls are R2L already:

  sub4 sub3 sub2 sub1 $variable;

But there is no way to do OO method calls R2L, and there is no way to do 
procedural subroutine calls L2R.

Damian's ~ and ~ proposal fills in this gap:

  method4 ~ method3 ~ method2 ~ method1 ~ $Xbject;
  $variable ~ sub1 ~ sub2 ~ sub3 ~ sub4;

To the best of my knowledge, the following two WILL NOT WORK:

  sub4 ~ sub3 ~ sub2 ~ sub1 ~ $variable;
  $Xbject ~ method1 ~ method2 ~ method3 ~ method4

The first one tries to invoke the sub1 method of $variable, while the 
second tries to call the method1 function with $object as an argument. 
If either of these works, it's either coincidence or careful planning.

So the apparant symmetry between ~ and ~ isn't really there.

I like ~ and ~, but I think that it will be a common mistake to think 
that $a ~ b~c~d can be reversed to give d~c~b~$a, when it can't. 
That, to me, is an argument against ~ and ~, at least as currently 

Re: L2R/R2L syntax

2003-01-20 Thread Buddha Buck
Michael Lazzaro wrote:

On Sunday, January 19, 2003, at 09:51  PM, Luke Palmer wrote:

From: Sean O'Rourke [EMAIL PROTECTED]
On Sat, 18 Jan 2003, Michael Lazzaro wrote:

So 'if' and friends are just (native) subroutines with prototypes like:

IIRC it's not that pretty, unfortunately, if you want to support this:

That is not a problem:


Yeah, a three-argument form would easily allow chaining.  But of course 
it still doesn't do the appropriate syntax checking (Celse outside of 
Cif, etc.).  (It's only speculation on our part, of course, but 
Damian's response was quite intriguing -- he seemed to imply they had a 
solution that would work.)

Would this work?

class True is Bool is singleton {
  method isTrue(block) { block.apply(); };
  method isFalse(block) { };

class False is Bool is singleton {
  method isTrue(block) { };
  method isFalse(block) { block.apply(); };

class ElseCode is Code {};

our True true is builtin;
our False false is builtin;

sub if (Bool $test, Code $block) { $test.isTrue($block); };
sub if (Bool $test, Code $ifblock, ElseCode $elseblock)
  { $test.ifTrue($ifblock); $test.ifFalse($elseblock); };
sub unless (Bool $test, Code $block) {$test.isFalse($block);};
sub unless (Bool $test, Code $ifblock, ElseCode $elseblock)
  { $test.ifFalse($ifblock); $test.ifTrue($elseblock); };

sub else (Code $block) returns ElseBlock { $block };
sub elseif (Bool $test is lazy, Code $block)
  { if $test, $block; };
sub elseif (Bool $test is lazy, Code $block, ElseCode $elseblock)
  {if $test, $block, $elseblock;};


Re: L2R/R2L syntax

2003-01-17 Thread Buddha Buck
Michael Lazzaro wrote:

So, to bring this thread back on track *again*, I hopefully offer this 

1) Damian's idea of using ~ and ~ as L2R and R2L is well-liked.  Thus:

  @out = grep { ... } map { ... } @in; # (1) (perl5)

becomes any of the following:

  @out  = grep { ... } ~ map { ... } ~ @in;  # (2) (perl6)

  @out ~ grep { ... } ~ map { ... } ~ @in;  # (3)

  @in ~ map { ... } ~ grep { ... } ~ @out;  # (4)

My impression was that this was _instead_ of (1), eliminating the 
specialized syntax of the map, grep, etc. functions in favor of this 
more generic piping syntax, but that wasn't explicitly stated.  Is that 

My impression was that ~ and ~ were more general than that, and mainly 
did syntax-rewriting.

So (4) above was translated in the parsing stage to be exactly identical 
to (1), by the following conversions:

  # original (4)
  @in ~ map { ... } ~ grep { ... } - @out;

  # Fully Parenthesized
  (((@in ~ map { ... } ) ~ grep { ... } ) - @out

  # @a ~ function  becomes  function @a
  ((map { ... } @in) ~ grep { ... } ) ~ @out

  # @a ~ function === function @a
  (grep { ... } (map { ... } @in)) ~ @out

  # @a ~ @b  === @b = @a
  @out = (grep { ... } (map { ... } @in))

  # removal of duplicate parenthesis
  @out = grep { ... } map { ... } @in

So the syntax in (1) is still valid.

With (2) and (3), the situation is different, because they get 
syntax-converted into a different form:

  # Original (3)
  @out ~ grep { ... } ~ map { ... } ~ @in;

  # fully parenthesized
  @out - ( grep { ... } ~ ( map { ... } ~ @in));

  # function ~ @a   function :@a
  @out - { grep { ... } - { map { ... } :@in ));

  # function ~ @a = function :@a
  @out ~ grep { ... } :(map { ... } :@in)

  # @a ~ @b = @a = @b
  @out = grep { ... } :(map { ... } :@in)

which is horrible, and no one would want to use that directly as opposed 
to syntax (1).  But I can see beauty in (2) or (3).

Of course, since indirect-object syntax is syntactic sugar itself, this 
goes on to be:

  # function :@a === @a.function, applied repeatedly
  @out ={...}).grep({...});

which is yet another L2R syntax.

But it also implies that map(block) and grep(block) are methods on 
arrays (or Arrays).

The issue, as I see it, is that some people like to follow data flow 
from right to left through a chain of actions.  Perl 5 supported this 
fine when it came to chained function calls:

  sub byChar { $a cp $b }
  for @words {
my $anagram = sort byChar split //, $_;  # R2L flow of data.
push @$anagrams{$anagram}, $_;

Other people like to follow data flow from left to right through a chain 
of actions.  Perl 5 supported this fine when it came to method invocations:


But if you needed to have a chain of function calls, you couldn't easily 
do left to right, and if you needed to have a chain of method 
invocations, you couldn't easily to right to left.

The one saving grace for method invocation was the use of indirect 
object syntax, which says that if the first argument of a 
multi-argument function is an object and is not followed by a comma, 
then the function should be interpreted as a method on that object:

  print $filehandle $text;

is equivalent (in Perl 5) to


But that doesn't scale. You can do the block that evaluates to an 
object trick to do some chaining, which gets you:

  raiseSalary {select $employeeTable 'unionized'} 0.05;

But that is ugly as sin and not truely Right to Left; it's more Middle 
to Out.

To summarize (and, Piers, you can quote me on this)

Perl 5 allows you to do:

  $object-meth1-meth2-meth3;  # Perl5 chained method, L2R

Perl 6 will also allow you to do:

  $data  ~ sub1  ~  sub2 ~ sub3;# Perl6 chained subs, L2R

Perl 5 allows you to to:

  sub3   sub2   sub1  $data;   # Perl5 chained subs, R2L

Perl 6 will also allow you to do:

  meth3 ~ meth2 ~ meth1 ~ $Xbject  # Perl 6 chained methods, R2L

All four syntaxes will be available in Perl 6, modulo the fact that '-' 
is now spelled '.'

The additional functionality that when the last sub or method in the ~ 
and ~ is a variable an assigment is done is a convenience issue.

2) You might be able to combine L2R and R2L piping in one statement.  

(As an aside

I almost wish that calling a method with an incomplete argument list 
would return a curried function, because that means that

  $data ~ print ~ $filehandle;

would work!)

Re: L2R/R2L syntax

2003-01-17 Thread Buddha Buck
Brent Dax wrote:

Incorrect.  The translation sequence is:

	@in ~ map { ... } ~ grep { ... } ~ @out
	((@in ~ map { ... }) ~ grep { ... }) ~ @out
	(({ ... })).grep({ ... })) ~ @out
	@out=(({ ... })).grep({ ... }))
	@[EMAIL PROTECTED]({ ... }).grep({ ... })

The only difference between '~' and '.' is that '~' is taken as the
terminator of an unparenthesized argument list, while '.' is taken as
binding to the last term.

Hmmm, I must have misunderstood Damian's suggestion when he said

(quoting Damian Conway)

 Suppose ~ takes its left argument and binds it to
 the end of the argument list of its right argument,
 then evaluates that right argument and returns the result.
 So an L2R array-processing chain is:

 @out = @a ~ grep {...} ~ map {...} ~ sort;

I didn't read that as stating a semi-equivalence between '~' and '.'.
I guess I live and learn.

Re: L2R/R2L syntax (was Re: Everything is an object.)

2003-01-16 Thread Buddha Buck
[Note:  I originally sent this to Mr. Nobody alone, but that wasn't my
intent.  I'm re-sending it here, where I wanted it to go in the first
place. -- bmb]

Mr. Nobody wrote:

trigraphs are actually better, even if you are unicode capable. ~ is


easier to type than ctrl-u-15F9E2A01 or whatever it is.

Maybe, maybe not  On my machine right now, it is very easy for me to
type various accented letters, like a, e, etc, making words like resume
(or is that resume) nearly as fast to type as the non-accented version

I can also type  or  relatively easily as well.  (I have
no idea how well those will be transmitted on this list.  I typed
hiragana using the hiragana script, and katakana in katakana, two of
the standard character sets of Japan.  I'm not sure why I have my
computer at work set up to allow me to input Japanese, since I'm not ?
?? nor do I speak ???)

But the techniques for typing in funky characters is well known, and easy.

Most likely, in the future when I have to work in Perl 6, my editor will
be set up so that typing the Unicode squiggly-arrow character will be as
simple as typing the two characters '~' and '', just like typing a
Spanish N is as easy as typing '~' and 'N' right now.

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Re: This week's Perl Summary

2003-01-14 Thread Buddha Buck
Mr. Nobody wrote:

If you and Damian think you'll get me to leave p6l this easily, forget it.
I've seen far worse flames than that.

While you were the person that Damian lost his sense of humor at, Piers 
didn't identify you in this part of the summary.  So I don't think Piers 
was trying to get you to leave.

Re: L2R/R2L syntax (was Re: Everything is an object.)

2003-01-13 Thread Buddha Buck
Mr. Nobody wrote:

Unicode operators in the core are a very, very, very, very, very, very, very,
very, very, very, very, very, very bad idea.

We've already had this discussion.  We wouldn't be bringing up using 
unicode operators for this function if we hadn't already talked about 
unicode operators for other things -- like vector ops.

Re: L2R/R2L syntax (was Re: Everything is an object.)

2003-01-08 Thread Buddha Buck
Luke Palmer wrote:

I would, from the descriptions, imagine that:
 @keep ~ grep /good/ ~ @list ~ grep /bad!/ ~ @throw;

Would parse as:
 @keep ~ grep /good/ ~ @list;
 @list ~ grep /bad!/ ~ @throw;

Nope.  ~ and ~ only *rearrange* arguments, so if you only type @list
once, you can only do things that you could before when you typed
@list only once.

So what we have is (using a scalar for an arbitrary variable) is:

$a ~ subroutine $arg1;

is equivalent to:

subroutine $arg1, $a;


subroutine $arg1 ~ $a;

is equivalent to:

subroutine $arg1 $a:;  # or , equivalently, subroutine $a: $arg1;


.. ~ $a;

is equivalent to

$a = ...;

and similarly,

$a ~ ...;

is equivalent to

$a = ...;

~ is left associative, ~ right associative, have the same precedence, 
and can't be mixed in one expression because of conflicting associativity

That means that a standard chain like:

  @list ~ grep /good/ ~ map - { s/good/bad/ } ~ @badlist;

would parse as
  ((@list ~ grep /good/) ~ map - { s/good/bad/ } ) ~ @badlist;
  ((grep /good/ @list) ~ map - {s/good/bad/ } ) ~ @badlist;
  (map - {s/good/bad/}, (grep /good/ @list)) ~= @badlist;
  @badlist = (map - {s/good/bad/}, (grep /good/ @list));
  @badlist = map - {s/good/bad/}, grep /good/ @list;

(modulo possible regex sytax).

Re: L2R/R2L syntax (was Re: Everything is an object.)

2003-01-08 Thread Buddha Buck
Dave Whipp wrote:

Something else springs to mind. Consider the Cfor syntax:

  for 1,2,3 ~ foo - $a { ... }

Is there any way we could unify these two operators without creating
ambiguities? If we
could, then using straight arrows would be nicer to type than the squiggly

I think I see what you're saying...

$a ~ foo;

calls foo on $a, while

  $a - $x { ... }

um, does nothing...  OK, I didn't see what I thought I said.

Actually, I do see something like:

  $a ~ - $x { ... }

as having meaning, namely call the anon sub with $a as an argument.

Does syntax already exist for doing that?  Can one do:

  - $x { ... } ($a);


If not, then the ~ - construct has a use, perhaps a semi-common use, 
and perhaps it should be simplified.  Not to suggest another operator 
here, but $a ~- $x { ... } anyone?

But you were looking for a way to play off their similar meanings to 
avoid having to use a tilde

The BNF for anonymous subs is something like (I haven't read the 
existing grammars, so if I'm not using the standard terms...sorry):

anon_sub :== sub block
   | sub ( paramlist ) block
   | - block
   | - paramlist block

The BNF for left-to-right pipelines would be something like:

lr_pipe :== lr_pipe ~ variable
  | lr_pipe ~ function_call

If we were to combine - and ~, would it lead to any ambiguity?  I'm 
not sure.  Certainly we'd be talking about more than a one-token lookahead.

Actually, I'm not sure the lr_pipe is unambiguous in its own right.  I 
don't have it complete, obviously, but I see problems with the two calls 
as is...

What is the result of:

  $input ~ %functionTable{$state} ~ $state;

Is it equivalent to:

%functionTable($state) = $input;
$state = %functionTable($state);


$state = %functionTable($state).($input);

How does the grammar differentiate between the two?

Or would I have to type

  $input ~ %functionTable{$state}.() ~ $state;



Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))

2002-12-12 Thread Buddha Buck
(resent as requested)

James Mastros wrote:

Here's my basic defintion of ID: Two things should have the same ID 
if-and-only-if they will behave exactly the same, now and forevermore.

Thus, there should be one ID for all constants of the same value, which 
is different from all constants of different value.  (This is probably 
unimplementable if we gaurntee IDs are of some constant length.)

Two objects should only have the same ID if they are aliases of 
each-other: they always have the same instance values, and the same 
value (but) properties.

Promotable, but unpromoted, Ints should have different IDs, because they 
may at some point, have different values.

Any unconsidered cases?

What about value objects (objects with no methods to change state after

class Complex {
# Hmmm, what's the attribute syntax this week?
attr .real is ro is public;
attr .imaginary is ro is public;

sub new($r, $i) {
   my Complex $obj;
   $obj.real = $r;
   $obj.imaginary = $i;
   return $obj;

method .magnitude { return sqrt($.real * $.real
  + $.imaginary * $.imaginary);

method .conjugate ( return Complex::new($.real, -$.imaginary); }

sub operator::* (Complex $a, Complex $b) is exported {
  return Complex::new($a.real*$b.real-$a.imaginary*$b.imaginary,

If I wrote the Perl6 code correctly (and no guarantees that I hit this
moving target), then once created, a Complex object cannot be modified
and is indistinguishable by behavior from any other Complex object with
the same value:

  my Complex $a = Complex::new(5,4);
  my Complex $b = Complex::new(5,4);

Is it reasonable to have $ == $

Re: Superpositions and laziness

2002-11-08 Thread Buddha Buck
Jonathan Scott Duff wrote:

On Fri, Nov 08, 2002 at 05:30:00PM +0100, Paul Johnson wrote:

On Fri, Nov 08, 2002 at 03:04:16PM +, Nicholas Clark wrote:

On Fri, Nov 08, 2002 at 08:22:17PM +1100, Damian Conway wrote:

The name of the property is still under debate. Larry favours:

	sub square ( Num $n ) is same {...}

whereas others feel that:

	sub square ( Num $n ) is memoized {...}

is more appropriate.

We're looking for a word that tersely expresses has_no_side_effects_and_can_safely_have_its_results_cached_based_on_parameter_types_and_values_and_calling_context ?

The functional programmers will tell you that word would be pure.

I like memoize only because perl has made me used to the term.
But pure works too.

To me, pure described the function, but it doesn't imply any 
optimization.  cached or memoized implies optimization.

sub fib1(int $x) is pure {
  return 1 if $x  2;
  return fib1($x-1) + fib($x-2);

print time { fib1(1000); };
print time { fib1(1000); };

could print the same time for both operations.

   sub fib2(int $x) is memoize { fib1($x); }

   print time { fib2(1000); };
   print time { fib2(1000); };

should return a long time for the first call, and a very short time for 
the second call.

Actually, I can think of another use for 'pure', as an optimization hint.

  sub foo {
for 1..1_000_000 - {
return 10;


  sub bar {
for 1..1_000_000 - {
return 10;

Both foo() and bar() return 10, and both do a similar amount of work 
computing 100 fibonacci numbers.  But I can see that the optimizer, 
seeing that bar uses a pure version of fibonacci knows that it is 
side-effect free, so optimizes sub bar {...} to the much faster

sub bar {10};

(I still don't understand the rules for when and where the semi is 

I'm not sure that memoize works for that.  Imagine:

sub opendb($dsn, $user, $password) is memoize { ... };


Re: Superpositions and laziness

2002-11-07 Thread Buddha Buck
Luke Palmer wrote:

Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
From: Luke Palmer [EMAIL PROTECTED]
Date: Thu,  7 Nov 2002 13:49:14 -0700 (MST)
X-SMTPD: qpsmtpd/0.12,

Date: Thu, 07 Nov 2002 20:48:50 +1100
From: Damian Conway [EMAIL PROTECTED]

we could make it lazy thus:

	sub a_pure_func(Num $n) is lazy returns Num {
	return $n ** $n

which would cause any invocation of Ca_pure_func to cache
its arguments (probably in a closure) and return a proxy
Num that carries out the computation only when the proxy is

   sub a_pure_func(Num $n) returns Num {
   class is Num {
   method FETCH { $n * $n } }.new 

Whoops, I mean...

sub a_pure_func(Num $n) returns Num {
class is Num {
has Num $cache;
method FETCH { $cache //= $n * $n } } }

Wow, I've never seen such a compact implementation of such a thing.  I
love you, Perl 6  3]

This is better, but it doesn't deal with STORE or does it?  Nope, it 
doesn't.  You need to delegate to $cache.


sub a_pure_func(Num a) returns Num {
   class is Num {
  has Num $cache is delegate;
  method FETCH {$cache //= $n * $n } }.new }


sub a_pure_func(Num $a) returns Num {
  class is Num (
  has Num $cache;
  method FETCH { .cache //= $n * $n }
  method STORE(Num $x) { .cache = $x } }.new }

I think


Re: list comprehensions

2002-11-06 Thread Buddha Buck
Jonathan Scott Duff wrote:

On Wed, Nov 06, 2002 at 12:54:12PM -0500, Mark J. Reed wrote:

On 2002-11-06 at 11:43:20, Jonathan Scott Duff wrote:

Will there be some shorter-hand way to say these?

	a = grades[grep $_ = 90, grades];
	b = grades[grep 80 = $_  90, grades];
	c = grades[grep 70 = $_  80, grades];

I think what you mean here is just

   a = grep $_ = 90, grades;

etc.  grep returns the actual elements, not their indices, so it doesn't
make sense to use them as a slice.  

Er, yeah.   I must be subcaffienated right now.  :-(

What I was trying to get at was the ability to slice based on the values
instead of the indices. But maybe it's just the python programming that
I've been doing that makes me think it's useful.


I think that if there were a slice-based form of grep, it would most 
likely look like you are indexing by a subroutine (or method) reference 
that takes no arguments other than an element of the array.  Something like:

  a = grades[{$^x  90}];


  a = grades[- x { $x  90}];


  my StudentGrade grades;

  a = grades[.isPassing];

I could see that as being useful.

Of potentially more use would be:

%grades = { Tom = 85, Mary = 95 };
%a_students = %grades{- $name, $grade { $grade  90 } };
print keys %a_students;   # 'Mary'

Re: list comprehensions

2002-11-06 Thread Buddha Buck
Piers Cawley wrote:

Jonathan Scott Duff [EMAIL PROTECTED] writes:

Will there be some shorter-hand way to say these?

	@a = @grades[grep $_ = 90, @grades];
	@b = @grades[grep 80 = $_  90, @grades];
	@c = @grades[grep 70 = $_  80, @grades];

Granted, it's fairly compact as it is but I'm wondering if there's
some way to not have to mention @grades twice per statement.

What's wrong with 
  @a = grep { $_ = 90 }  @grades;
  @b = grep { 80 = $_  90 } @grades;
  @c = grep { 70 = $_  80 } @grades;

Or am I missing something? The examples you give seem to imply that
you should use the value of the things contained in @grades as indices
into @grades, and return the values thus indexed. There may be a good
reason for doing this, but one escapes me for now.

I don't see why I'd want to do it with arrays, but...

%a_students = %grades{grep /^a/i, keys %grades};

'for' clarification, summary...

2002-11-05 Thread Buddha Buck
Here's my current understanding of what's under discussion for for-loops:

Larry wants to eliminate the ; from the RHS of the -, so the only thing 
for needs to know about the RHS is the number and types of the 
arguments.  This puts the specification about how to generate those 
arguments on the LHS of the -, and only there.


# process array, one element at a time
for array - $x { ... };

# process array, in pairs
for array - $x, $y { ... };

# process all of a, then all of b, one element at a time
for a, b - $x { ... };

# process a, then b, in pairs (a[0] and a[1] first, etc)
for a, b - $x, $y { ... };

# process a and b in interleaved pairs (a[n] and b[n])
for zip(a, b) - $x, $y { ... };

# process in a[0], b[0], a[1], b[1], ... order
for zip(a, b) - $x { ... };

# triples from a, b and c, alternately
for zip(a, b, c, 3) - $x, $y, $z { ... };

# triples from a, pairs from b, together
for weave( a = 3, b = 2) - $v, $w, $x, $y, $z { ... };

What is undecided is the exact name and syntax of zip() and weave().
(Note:  in my sample syntax, zip(a, b, c, ...) is the same as
weave(a=1, b=1, c=1,...) and zip(a, b, c, ..., n) is the same 
as weave (a=n, b=n, c=n, ...).

My feeling:

It seems the real definition for 'for' is something like:

sub for(a is rw, s) {
   my $numargs = s.signature().length;
   for(a[$numargs...], s);

and zip(), weave(), or equivalents would be array generators.

This would mean that things like:

sub printproducts($x, $y) { print $x*$y, \n; }

for zip(multiplicands, multipliers), printproducts;

and it would print one product for each pair of factors.

Hmm, what (if anything) would this do, modulo minor syntax errors:

my $twoByTwo = - ($x, $y) {
   print Noah led a $x and a $y onto the ark\n; }

my $threeByThree = - ( $x, $y, $z) {
   print Shem led a $x, a $y, and a little baby $z off of the ark\n; }

my $arksubs = $twoByTwo | $threeByThree;

for a, pick($arksubs);

Re: [RFC] Perl6 HyperOperator List

2002-10-30 Thread Buddha Buck
Larry Wall wrote:

Maybe we should just say that you can put it anywhere that makes sense,
and let the perl parser sort out the sheep from the goats.  The basic
rule is that for any op, [op] is also expected in the same place.  So
if the user defines a postfix:! for factorial, they automatically get
_[!] for that as well.

I think we could also allow

a [??] b [::] c

But it's not clear whether we can parse

a = [undef][...]

How would you parse:

a = b[[5]];

(My intent:  for a; b - $x is rw; $y { $x = $y[5] }; # I think... )


Re: Private contracts?

2002-10-04 Thread Buddha Buck

Peter Haworth wrote:

 That *is* a logical weakening. Just because the inherited precondition is
 C x  10 , doesn't mean that the weakened condition has to be of the form
 C x  9  or any other value lower than 10. C a || b  is weaker than
 C a 

So what we are looking at is something like

class Animal {
   method eat($food) is abstract {
 PRE { $food.isa(Edible); }
 POST { !$stomach.empty; }

class Goat is Animal {
   method eat($food) {
 PRE { $food.isa(Can); }
 my $chewedfood = $teeth.chew($food);
 POST { $teeth.clean; }

class Teeth {
  method brush {...};
  method chew {
POST { .clean == false; }
my Animal $billy = new Goat;

$;   # succeeds because PRE for is met
$;  # succeeds because PRE for is met
$; # Fails because neither PRE is met

class DirtyTeeth is Teeth {
   method brush {};

$billy.teeth =;
$;   # Fails because POST for is not met


 Are there
other ways to do it, just to mull them over?

Re: auto deserialization

2002-09-03 Thread Buddha Buck

  From: Trey Harris [EMAIL PROTECTED]
 no strict 'refs';
  my Date $date;
  $date .= 'Sep 21, 1963';
 There is a method name there--'Date::Sep 21, 1963'.
  But that's my point.  You wouldn't have to put the method name or the 
  because the compiler would understand what to call.  It would see that
  $date is in the Date class, and 'Sep 21, 1963' is in the String class, so
  it would pretend the statement really reads
 $date = Date::new_from_String('Sep 21, 1963');

my Date $date;
$date .= getText(/Transaction/TransactionDTM);

does this call the locally visible function/method getText, take the 
string that results from that, and then does $date = 
Date::new_from_String() on the result, or does it try to do

$date = $date.getText(/Transaction/TransactionDTM);

My feeling is the latter.

$date += 4;  # $date = $date + 4;
$date -= 4;  # $date = $date - 4;
$date *= 4;  # $date = $date * 4;
$date .= foo; # $date =;

I suspect that, if it makes sense to say

$foo = $date.method;

then it would also make sense to say

$date .= $foo;

as well.

  mail2web - Check your email from the web at .

Re: sub/method refs (was Re: auto deserialization)

2002-09-03 Thread Buddha Buck

Trey Harris wrote:
 In a message dated Tue, 3 Sep 2002, Buddha Buck writes:
I suspect that, if it makes sense to say

$foo = $date.method;

then it would also make sense to say

$date .= $foo;

as well.
 Interesting, that first line
   $foo = $date.method;
 I need a bit of a refresher here, as my searches of the archives have
 turned up blank.  Ampersand replaces P5 C\ in taking a reference to a
 subroutine or method?  And ampersand is no longer used to call a
 subroutine, in any context? 

Actually, I think I got confused...  Most of my work recently has been 
in C++, which uses  for references.  Perhaps that should have been:

$foo = \$date.method;

 $foo = $date.method();
 Would call $date.method, and return a reference to (a reference to) the
 subroutine returned by Date::method()?
 I have a feeling that, as much nicer as Perl 6 references will be compared
 to the Perl 5 punctuation-salad, it will take a long time to do it
 automatically.  It'll feel like grabbing for the stick-shift and clutch
 that aren't there when you're driving an automatic

Re: A5: Is this right?

2002-06-06 Thread Buddha Buck

At 11:31 AM 06-06-2002 -0700, Brent Dax wrote:
#Preliminary Perl6::Regex
#  This does not have any actions, but otherwise I think is correct.
#  Let me know if it's right or not.

I'm not a regex guru, but...

use 6;

grammar Perl6::Regex {
   rule metachar { [{(\[\])}:*+?\\|]}

   rule ws   { [[\h\v]|\#\N*]*}

   rule atom { ws (!metachar | \\ . | group) ws }

I had gotten the impression that a literal string separated by whitespace 
was an atom, so

rule foofoobar { foo 1,2 bar }

would match 'foobar' or 'foofoobar'.  If so, I think !metachar needs to 
be replaced by !metachar+

 rule modifier { ws ([*+?] \?? \:?) ws  }

   rule molecule {
(  atom modifier

atom ends with ws, modifier begins with ws.  Does that mean that 
there must be two ws between an atom and a modifier?  (Possibly not, 
since ws can match null, so 'a*' would match ws with four nulls).  Just 
clarifying for myself.

|  ws \:1,4 ws
|  compound ws \| ws compound

   rule compound { [(molecule)]*  }

   rule group{ws
(  \( compound \)
|  \[ compound \]
|  \{ Perl6::Code \}
|  \ !? [ \w+ | \d+ , \d+ ] compound \

@roles=map {Parrot $_} qw(embedding regexen Configure)

Early in the series, Patrick Stewart came up to us and asked how warp
drive worked.  We explained some of the hypothetical principles . . .
Nonsense, Patrick declared.  All you have to do is say, 'Engage.'
 --Star Trek: The Next Generation Technical Manual

Re: Backslashes

2002-05-21 Thread Buddha Buck

At 01:10 PM 05-21-2002 -0400, Aaron Sherman wrote:
On Tue, 2002-05-21 at 12:57, Michael G Schwern wrote:

  Here's an easier one: backslash followed by the delimiter is that thing.
  Everything else is literal.
  print 'c:\it\'s\easier\to\write\win32\paths\this\way';
  print q{this is ok { and so is \} } C:\this };

I desire you print your statement above. Would it be:

 print 'print \'c:\it\\'s\easier\to\write...\';';

The quesiton here is that C\\', which means something different in
your recommendation than it means in Perl5, but still does the same

And the other question is how to get a string that ends in a \?

$hiddendirectory = q{C:\$ecret$tuff\mp3\don't tell the mpaa\};

Is there any gotcha, here? I'm not sure, but it's tickling my brain in
an odd way, and I keep wanting to say that it breaks down somewhere

Is the above the gotcha you've been looking for?

Re: Please rename 'but' to 'has'.

2002-04-26 Thread Buddha Buck

At 09:45 AM 04-26-2002 -0700, Larry Wall wrote:
Tim Bunce writes:
: For perl at least I thought Larry has said that you'll be able to
: create new ops but only give them the same precedence as any one
: of the existing ops.

Close, but not quite.  What I think I said was that you can't specify
a raw precedence--you can only specify a precedence relative to an
existing operator.  That way it doesn't matter what the initial
precedence assignments are.  We can always change them internally.

: Why not use a 16 bit int and specify that languages should use
: default precedence levels spread through the range but keeping the
: bottom 8 bits all zero. That gives 255 levels between '3' and '4'.
: Seems like enough to me!
: Floating point seems like over-egging the omelette.

It's also under-egging the omelette, and not just because you
eventually run out of bits.  I don't think either integer or floating
point is the best solution, because in either case you have to remember
separately how many levels of derivation from the standard precedence
levels you are, so you know which bit to flip, or which increment to
add or subtract from the floater.


So you'd have something like:

sub operator:mult($a, $b) is looser('*') is inline {...}
sub operator:add($a, $b) is tighter(+) is inline {...}
sub operator:div($a,$b) is looser(/) is inline {...}

assuming default Perl5 precedences for *, *, and / you would have the 
precedence strings for *, +, /, mult, add, and div to be S, R, S, 
S2, S1, S2 respectively?  So mult and div would have the same 

Hmmm  What problems would be caused by:

sub operator:radd($a,$b) is tighter(+) is inline is rightassociative {...}
sub operator:ladd($a,$b) is tighter(+) is inline is leftassociative {...}

Right now, all the operator precedence levels in Perl5 have either right, 
left, or no associativity, but they do not mix right and left associative 
operators.  Will that be allowed in Perl6?


Re: Please rename 'but' to 'has'.

2002-04-23 Thread Buddha Buck

At 08:58 AM 04-23-2002 -0700, Larry Wall wrote:
Precedence is set with the like' property:

 my sub operator:now ($a,$b) is like(but) is inline { $a but $b }
 sub operator:also ($a,$b) is like(and) is inline { $a and $b }

OK, but that limits you to the, um, 24 standard levels of precedence.  What 
do you do if you don't think that that's enough.  Let's say you want to 
define a nand operator:

my sub operator:nand ($a, $b) is inline { not ($a and $b) }

but you want nand to have a precedence lower than the existing 'and' but 
higher than the existing 'or' (for some reason I can't imagine 
offhand).  It isn't like() anything, since there isn't anything currently 
between 'and' and 'or'.  Would that be something like:

my sub operator:nand ($a, $b) is below(and) is inline {not ($a and $b) }

Re: Please rename 'but' to 'has'.

2002-04-23 Thread Buddha Buck

At 01:12 PM 04-23-2002 -0400, [EMAIL PROTECTED] wrote:

24 levels of precedence should be enough, else you can always resort to 

I would have agreed, except that I would have also said that the 14 
precedence levels of C should be enough as well -- yet we seem to have 
discovered uses for 10 more.


Re: Perl6 Macros

2002-03-27 Thread Buddha Buck

Michel J Lambert [EMAIL PROTECTED] writes:

  Macros could add something to Perl, but I don't see why having a macro
  return a string instead of looking and acting like a subroutine would be
  a bad thing. In fact, as I pointed out before, you can do almost all of
  the scoping stuff that you would want out of a macro in Perl with the
  existing subroutine/code ref syntax and a special property.
 I disagree here. How would I define foreach as a macro (assuming the
 following, simplified syntax).
 foreach $each, @array, {
   print $each;
 Since $each is being passed to the foreach macro, the macro needs to
 create a lexical scoping for $each, and place the third argument as a loop
 body, within the context of the scoping it just defined.

That suggested a similar example to me...

In Lisp (or, more likely, Scheme), you get constructs like:

(let ((a 'b) (c 'd) ... ) (...))

being defined as equivalent to:

((lambda (a c ...) (...)) 'b 'd ...)

and the macro system can convert the let into the evaluated lambda.

Suppose we wanted to have a Perl construct that was similar:

my $a = let ($b - 5, $c - $x) { $b + $c };

The most similar replacement for the let to the lisp case is:

my $a = (sub { my ($b, $c) = @_; return $b, $c; })(5, $x);

With the macro system (using qs() for things to be evaluated at
compile time), I could see something like:

macro let (%) 
  { (sub { my qs(keys @_[0]) = @_; return qs(@_[1]); })(qs(values @_[1]))};

I'm not sure that that would work perfectly offhand (I suspect some
syntax tweaking would be necessary) but it's the basic idea I think
you are going for.


I will not die an ironic death -- Scott Ian, lead singer for 
the metal band Anthrax, after bioterrorist attacks using anthrax.

Re: Apoc4: The loop keyword

2002-01-25 Thread Buddha Buck

At 11:40 AM 01-25-2002 -0600, Jonathan Scott Duff you wrote:
On Fri, Jan 25, 2002 at 11:57:25AM +0100, Bart Lateur wrote:
  On Mon, 21 Jan 2002 15:43:07 -0500, Damian Conway wrote:
  What we're cleaning up is the ickiness of having things declared outside
  the braces be lexical to the braces. *That's* hard to explain to 
  But it's handy. And that was, until now, what mattered with Perl.

No, handiness still matters with Perl. It's just that the balance has
tipped a wee bit towards the consistency/regularity/simplicity/whatever
side of the scale.

Besides no one has commented on Steve Fink's (I think it was him) idea
to store the result of the most recently executed conditional in $?. I
kinda like that idea myself. It makes mnemonic sense.

But then I'm sure that someone will come out of the woodwork and say
What about if ((my $a = foo())  ($b  4)) ? or something.  To
which I'd say Fooey!  I personally don't think that an extra set of
curlies are too high a price for getting rid of weird scoping rules.
But that's just me.

We have
  while (foo()) - $a {...}
doing the right thing.

Why can't

if foo() - $a { ... }

take the place of the perl5

if (my $a = foo()) {...}

Too bad we can't do

while (foo() - $a)  ($b  4) { ... }
and have it do the right thing.

Jonathan Scott Duff

Re: Math functions? (Particularly transcendental ones)

2001-09-08 Thread Buddha Buck

Dan Sugalski [EMAIL PROTECTED] writes:

 Okay, I'm whipping together the fancy math section of the interpreter 
 assembly language. I've got:


 Can anyone think of things I've forgotten? It's been a while since I've 
 done numeric work.

Uri mentioned exp(x) = e^x, but I think if you are going to include
log2, log10, log, etc, you should also include ln.

Re: Circular references

2001-08-01 Thread Buddha Buck

At 01:01 PM 08-01-2001 -0600, Sterin, Ilya wrote:
I was just wondering if there will be any solution for the circular
refernece memory leak (I guess you can call it a problem).  Can't we keep
information on the number of circular references in the SV structure and
then decrement the references count by one + the circular reference count at
the end of scope?

Dan has already answered (dead-object detection sweeps by the GC will take 
care of it), but I'm curious?

How do you detect a circular reference so you can update the circular 
reference count?


Re: Circular references

2001-08-01 Thread Buddha Buck

As a necrohipposadist (beater of dead horses), I'll add...

Sterin, Ilya [EMAIL PROTECTED] writes:

 Well guess not, since something like this...
   my ($a, $b, $c);
   $a = \$b;
   $b = \$c;
   $c = \$a;
 would definitelly be hard, resource consuming to implement a circular
 reference count.

Even that's not that difficult.  There's just one loop.  How about:

sub newgraph {
  my $noderef = shift;
  my @nodes = @$noderef;
  my $edgesref = shift;
  my @edges = @$edgesref;

  my %graph;

  foreach (@nodes) { $graph{$_} = [] }
  while (@edges) {
my $source = shift @edges;
my $dest   = shift @edges;
push @$graph{$source},$graph{$dest};

In this horrid little data structure, every reference of interest is a
reference to arrays of references, all of which are parts of circular
references.  This is not necessarily a good way to store a directed
graph, but it works (and some would think it has some benefits in some
cases).  But each push could introduce lots and lots of new loops that
would have to be accounted for.

However, more realistically, I could imagine someone coding a tree
where each node had pointers to its parent, its children, its
siblings, its next and previous nodes, etc.  All of which would
lead to numerous circuits.  Again, each addition to the tree would
introduce numerous, potentially hundreds or thousands, of circuits.
The same would happen on every delete, too.



2001-07-09 Thread Buddha Buck

At 03:07 PM 07-09-2001 -0400, Adam Turoff wrote:
On Mon, Jul 09, 2001 at 02:36:17PM -0400, Sam Tregar wrote:
  On Mon, 9 Jul 2001, Adam Turoff wrote:
   Don't laugh.  It's here now.  It's called XSLT.  :-)
  Um, that's not what the article was talking about  The proposal is to use
  an XML syntax to program in existing VHLL languages, including Perl.

...and we have a working example of what a bad idea that is with XSLT.

XSLT has, as a major failing, it's XML-based, lisp-like syntax which takes 
the Lots of Insideous Silly Parenthesis problem and makes it even 
worse.  The scheme code:

(define (addone x)
   (+ x 1))
(addone 3)

becomes in XSLT

xsl:template name=addone
xsl:param name='x'/
xsl:value-of select=$x+1/
xsl:call-template name=addone
xsl:with-param name=x select=3/

That is obviously horrid syntax, but it fits XSLT's goals of being embedded 
in XML and able to co-exist with other XML schemata.

But that doesn't have to be how a programming language and XML can interact:

Procedure iprime_the_change_buffer/i sets ichange_buffer/i in 
preparation for the next matching operation.
   change_limit = change_buffer; /* this value is used if the change file 
ends */
   insert section=Skip over comment lines in the change file; |return| if 
end of file/
   insert section=Skip to the next nonblank line; |return| if end of file/
   insert section=Move |buffer| and |limit| to |change_buffer| and 

(code gotten from CWEB 3.0 by Donald Knuth and Silvio Levy)

Running that though the proper processor (probably written in XSLT) could 
generate the same results as cweb (although rewriting cweb in XSLT seems a 
not-so-good proposition.

XSLT is a good idea in *it's* domain, but very bad for a general purpose
programming language.

True, agreed, and admitted.  So why can't a general purpose programming 
language be designed with XML-based syntax?  Why can't a general-purpose 
programming language be augmented with XML for internal documentation purposes?

What's your question?  XML Editors are not the limiting factor
preventing XML-based programming languages; that argument doesn't
stand up in the face of XSLT adoption.  The dubious value of those
beneifits (and the re-engineering cost) are the true limiting factors.

As has been admitted, XSLT sucks.  On the otherhand, take a look at a 
decent Smalltalk environment sometime.
The browsers which are use to examine and modify code completely isolate 
the programmer from the underlying representation.  Although the technology 
used in Smalltalk is older than XML, I could easily see it being done 
-today- using XML, and the programmer never being the wiser.



2001-07-09 Thread Buddha Buck

At 03:55 PM 07-09-2001 -0400, Adam Turoff wrote:
On Mon, Jul 09, 2001 at 03:48:27PM -0400, Buddha Buck wrote:
  Why can't a general-purpose programming language be augmented with XML for
  internal documentation purposes?

You mean like C#?  :-)

I wasn't specifically referring to that; I was thinking more along the 
lines of literate programming, or Javadoc, or POD.  I wasn't aware that C# 
used XML for doc purposes.


Re: 1 until defined(getvalue()); return it;

2001-05-30 Thread Buddha Buck

At 06:54 PM 05-30-2001 +0100, Michael G Schwern wrote:
On Wed, May 30, 2001 at 12:38:50PM -0500, David L. Nicol wrote:
  while pseudocoding something I realized that it would be really
  cool if there was another magical default shelf, like $_  or _ but
  subtly different, that stores, if lexically used, the object of the
  most recent defined or exists --
  or maybe even the most recently referred to scalar, just the way
  it works in English.  it would change much more often than $_

*quiver* Please god no.  Its difficult enough to follow the twists and
abuses of $_ when reading code.

That aside, could you put together a code example of what this wins?

I'd be interested in seeing how it would be better than what works now.

Why is:

1 until defined(getvalue()); return it;

better than

1 until defined($foo=getvalue()); return foo;



Michael G. Schwern   [EMAIL PROTECTED]
Perl6 Quality Assurance [EMAIL PROTECTED]   Kwalitee Is Job One
Death follows me like a wee followey thing.
 -- Quakeman

Re: Separate as keyword? (Re: 'is' and action at a distance)

2001-05-18 Thread Buddha Buck

At 01:34 PM 05-18-2001 -0700, Nathan Wiger wrote:
Dammit, I got the example exactly backwards. Try this:

 $Foo is true;
 $Foo = 0;
 print Stuff if $Foo;   # *WOULD* print - is assigns a
  # permanent true property
 $Foo as true = ;
 $Foo = 0;
 print Stuff if $Foo;   # *WOULD NOT* print - as is reset by
  # value assignment since is temporary

I tend to think of the temporary/permanant distinction being a 
rvalue/lvalue distinction.

Perhaps the rvalue/lvalue context of the property assignment could be used 
to determine whether it's temporary or permanant?

$Foo = 0 is true;   # $Foo has a true value
print $Foo is true if $Foo;   # prints 0 is true

$Foo = 0;   # $Foo has a false value
print $Foo is true if $Foo;  # does not print.

$Foo is true = 0;  #$Foo is true regardless of value
print $Foo is true if $Foo; # prints 0 is true

$Foo = 0; #$Foo is still true, despite false value
print $Foo is true if $Foo; # prints 0 is true

$Foo = 0 is false; # Hmm, lvalue $Foo is true, but assigned -declared- 
false value...  who wins?
print $Foo is true if $Foo; # ??

We'd also need to come up with better syntax for:

$Foo is true = $Foo;

for changing the lvalue properties of $Foo without changing the rvalue 


Re: Exegesis2 and the is keyword

2001-05-18 Thread Buddha Buck

Austin Hastings [EMAIL PROTECTED] writes:

 Let it be.
 Not a flame, but a suggestion:
 let $pi be constant;

Personally, I'd rather save let for:

(let ($x,$y,$z,...) = (1,2,3,...) in { ... })

which would be equivilant to:

  ((sub {my ($x,$y,$z,...) = @_; ... })(1,2,3,...))

Many functional languages use let to mean something similar.

On that note...  will there be any provision for formal arguments to
anonymous subs?

If I understand the brief mentions of subroutine signatures, we will
be able to use syntax like:

sub foo (@array, $scalar, %hash) { ... } ;

Will we also be able to do:

 $foo = sub (@array, $scalar, %hash) { ... } ;

to get a reference to an anonymous sub with the same signature?

If so, then

$foo = (let (...) = (...) in {...});

could be equivalent to:

$foo = ((sub (...) {...})(...));
 That any better?
 --- Dan Schmidt [EMAIL PROTECTED] wrote:
  Peter Scott [EMAIL PROTECTED] writes:
  | I've been reading is as a declarative imperative, something which
  | declares a property of something you are creating.  Here it's being
  | used to modify the properties of something that already exists, and
  | it reads funny to me.  Many properties that one can set at
  | declaration time are compile time only, yet this usage might
  | to many people that they can be changed at run time.  If you see
  | what I mean.
  Clearly we need 'becomes' and 'gets' for mutable properties, in
  addition to 'is' and 'has' for constant ones.
 Do You Yahoo!?
 Yahoo! Auctions - buy the things you want at great prices

Re: apo 2

2001-05-04 Thread Buddha Buck

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.

Maybe has and is, used in this context, could be synonyms?

   my NetFile $page has url(;);
   $page is constant;

or maybe

   my Netfile $page has url(;) is constant;

(can properties stack like that?)

I think it depends on the property whether has or is is grammatically 

Or we could have a policy that all example-properties have the 
has-nature.  Instead of:

   $foo is true;
   $foo is true(1);
   $foo is true(0);

we would have:

   $foo has truth;
   $foo has truth(1);
   $foo has truth(0);

Or some such...

RE: apo 2

2001-05-04 Thread Buddha Buck

At 10:49 AM 05-04-2001 -0500, Garrett Goebel wrote:
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(;) is constant;

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

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

True, but those are basic OO concepts, which don't neatly apply to 
property-lists (a very old Lisp concept that Perl6 is adopting).

Re: Curious: - vs .

2001-04-27 Thread Buddha Buck

Bart Lateur [EMAIL PROTECTED] writes:

 On 26 Apr 2001 23:19:49 -0400, Buddha Buck wrote:
 $bar  = [$obj method()   ];   # method call
   $bar = method $obj()
 would be more consistent with perl's current 
   $object = new Class()

Yes, well, some people want to get rid of the indirect object
syntax, not require it.  

I don't use it myself, but my understanding is that

   $bar = method $obj()

is legal right now, and that your second example isn't a special-case
but just one example of the general case.


Re: Curious: - vs .

2001-04-27 Thread Buddha Buck

Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
  Piers Cawley [EMAIL PROTECTED] writes:
   Buddha Buck [EMAIL PROTECTED] writes:

How about borrowing from Objective C?

   [$object method(foo, bar)];
   How do you create an anonymous list now then? Not that I object to
   borrowing from Objective C you realise.
  I thought ($one, $two, $three) was an anonymous list.
 Oops, meant anonymous array.

To be overly pedantic I thought [$one, 2, 3] was a ref to an anonymous array...
  Other than severe dependence on the comma, is there any reason why we
  couldn't have the following?


 Apart from the fact that we're adding one more meaning to [], one
 which has no mnemonic relationship with arrays, no reason at all.

Since it looks like we are going to be getting $object.method()
anyway, it doesn't matter much.  It was more of a facetious suggestion
to begin with -- although that doesn't mean that it wouldn't work,
it's just not going to happen, and I know it.

 Piers Cawley

Re: Curious: - vs .

2001-04-26 Thread Buddha Buck

Piers Cawley [EMAIL PROTECTED] writes:

 Buddha Buck [EMAIL PROTECTED] writes:
  Bart Lateur [EMAIL PROTECTED] writes:
   On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:
   So why not
 $object!method(foo, bar);
  In my opinion, because it doesn't provide sufficient visual
  distinction between $object and method().  At a glance, especially on
  a crowded page, it's similar in appearance to $objectImethod, for
  instance.  $object.method() has a visual separator (although I'd
  prefer $object-method()).
  How about borrowing from Objective C?
 [$object method(foo, bar)];
 How do you create an anonymous list now then? Not that I object to
 borrowing from Objective C you realise.

I thought ($one, $two, $three) was an anonymous list.

Seriously, I hadn't considered that their may be a problem with the
syntax I gave.

How would you, under Perl5, interpret the expression I used.  To me,
it looks like a syntax error.  '$object method(foo,bar)' isn't a
valid method call, so it can't be a ref to an anonymous list of one

Other than severe dependence on the comma, is there any reason why we
couldn't have the following?

$foo  = [$one];   # array ref
$baz  = [$obj,funcall()  ];   # array ref
$quux = [$one,$two,$three];   # array ref
$bar  = [$obj method()   ];   # method call
$bat  = [$one $two $three];   # syntax error

 Piers Cawley

Re: Dot can DWIM without whitespace

2001-04-25 Thread Buddha Buck

Edward Peschko [EMAIL PROTECTED] writes:

   beautiful. Then extending this is simple, consistent, easy to read,
   compatible with perl5..
  I'm not sure that that was the point I was trying to make.
  If nothing else, the '.' would then be responsible for *three* 
  different actions.
 Right, but what *I* am saying is that any given user is already conditioned to 
 the fact that it can mean different things in different circumstances.
 And like I said earlier, if we make $a . $b the only proper form for 
 concatenation, I don't think that there is going to be much of a learning curve.
 In any case, I like it better than yet another punctuation mark.

I see, and you would be willing to break the cases where I may want to
put spaces around the . used for method invocations for clarity?


  $foo . foobar (Test1);
  $foobar  . baz(Test2);
  $tmtowdi . quux   (Test3);


That specific use of whitespace I don't do often, but I could see
doing it.  I often do something like that when working with other
variable length identifiers.


Re: Tying Overloading

2001-04-23 Thread Buddha Buck

At 07:44 PM 04-23-2001 +0100, Graham Barr wrote:

Hm, I would expect @() in a scalar context to give the
same result as

   @tmp = @(...); $x = @tmp;

That is, yeild the number of elements in the list.

I can see this.  But unless there is a good reason, that seems like a 
less-than-optimal side-effect.

What would be the benefit of it being the same as [...] ? It would be
one more character.

I suspect that Larry is seeing that if @() in scalar context yielded the 
length of the resulting operation would result in vastly more uses of:

$sums = [@(@a+@b)];


$num_of_sums = @(@a+@b);

If that's the case, then it makes sense to use the shorter notation for the 
more common case, especially when there is an easy, shorter way to get the 
uncommon case:

$sums = @(@a+@b);
$sumcount = \@(@a+@b);
# assuming that $sumcount = @a isn't sufficient.

Re: Larry's Apocalypse 1

2001-04-14 Thread Buddha Buck

Paul Johnson [EMAIL PROTECTED] writes:

 On Sat, Apr 14, 2001 at 12:11:12PM -0400, John Porter wrote:
  Dan Sugalski wrote:
   I personally would rather that perl 6 handle perl 6 code only, and leave 
   the compilation and interpretation of perl 5 code to perl 5. 
  FWIW, I agree 100% with Dan.
 I'm curious to see how mutt will handle this thread when it gets off the
 right hand side of the screen, so would it be possible to have another
 couple of rounds of this?
 For those who aren't quite sure of the rules, post one of these messages
 at the appropriate time:
  - Larry said perl6 will parse perl5 code by default.
  - I don't want to have to put "module" in my one liners.
  - Let's have a switch -6.
  - What's wrong with -M6?
  - Just use the shebang line.
  - Can't perl determine whether it's perl5 or perl6?
  - perl6 should parse perl6 by default.
 Improvisation and embellishment is allowed, but don't get too far off
 the beaten track or people won't be sure which message they should post
 next and then the thread will die.

OK, I'm game...

Larry said perl6 will parse perl5 code by default.

He said this for the benefit of legacy perl5 code that we -can't- fix,
due to it being embedded in old shell scripts, etc, that we can't
expect people to hunt down and fix.  One-liners would be the hardest
hit by this, because they could be anywhere and changes in the
semantics of legal perl5 code when executed as perl6 code could cause
random breakage all over the place.

So /usr/bin/perl MUST assume that it is being fed perl5 code unless it
can explicitly tell otherwise.

Larry said that the official way to tell that perl code will be perl6
is by using a "module" keyword, which is otherwise identical to the
existing "package" keyword.  That captures most of the modules, but it
doesn't capture the main scripts -- which would be assumed to be perl5
unless something happens.

IF WE CAN MIX-AND-MATCH perl5 and perl6 scripts and modules, then I
don't see a big problem with assuming perl5 code unless

a) the code has a "module" declaration;
b) the code has "use 6";
c) the interpreter is called with -M6

I think we have to allow such mix-and-matching, because it is entirely
possible that a bit of legacy perl5 code may have a "use Foo;"
statement, and if foo is now perl6 code, we have to treat the main
script as perl5 and the module as perl6.

We could, I guess, restart the parsing as perl6 as soon as we run
across a perl6-specific feature (thus ensuring that the code is not
perl5 code), but what about code which is syntactically correct perl5
and perl6 code, but with different semantics (due to the differences
in how perl5 and perl6 handle IO, for instance)?  What do we do then?

 [ :-) for those who like such things ]
 Paul Johnson - [EMAIL PROTECTED]

Re: RFC 357 (v2) Perl should use XML for documentation instead of POD

2000-10-04 Thread Buddha Buck

At 08:36 AM 10/4/00 -0700, Nathan Wiger wrote:
  =head1 TITLE
  Perl should use XML for documentation instead of POD

  =head1 VERSION
Status: Frozen

I'm sorry, I was gonna bite my lip, but I've gotta say: Freezing RFC's
like this when the following is true:

  A lot of good, heated discussion was generated on the mailing lists. The
  majority seems against using XML-DTD documentation, but granted there are
  deficiencies in POD.

Is absolutely, 100% against the entire idea of the RFC process. They're
"Requests for Comments". The comments received were overwhelmingly "This
is a Bad Idea".

I gotta disagree.  You'll note that he requested comments, got comments, 
and reported the tone and results of those comments in v2.

Also, he made no other changes, and got v2 in place 4 days after v1, 2 days 
after the 1 October deadline.  Would you have been able to make the sort of 
revisions you are suggesting below under that sort of time pressure?  I 
know I wouldn't, based on my experience with my RFCs.

Retracting would have been easier, but could very well be seen as giving up 
on pointing out PODs deficiencies.

This RFC should either be retracted, or revised into:

POD to XML translation should be easier


POD should be made more flexible


Here are some deficiencies in POD that need to be fixed

But freezing something that everyone's against is a waste of everyone's
time. Sorry, but it is.

And yes, I've retracted 7 of my own RFC's because the community was
against them. The whole point of this Perl 6 process is to develop a
language that the community thinks is the right direction, right?
Sometimes that means accepting that no matter how much you like your
idea, other Perl'ers don't.

The RFCs are not the end-all of Perl development.  As you stated, they are 
"Requests For Comments", and not every frozen RFC will get accepted by the 
community.  Not every RFC -can- be accepted by the community; I think there 
are some pairs that are mutually exclusive, and intentionally so.  Compare 
RFC 126 (Ensuring Perl's Object Oriented Future) and RFC 137 (Perl II 
should not be fundamentally changed).  At most one of those two will "win", 
since they have different philosophies for Perl6 OO development.  Hopefully 
Perl6 will be the real winner.

Do you expect that your 7 retracted RFCs to be looked at by future 
developers?  Even if they had good, but unpopular, points to make?  Or do 
you expect that once retracted, they will be ignored?

I think retracted RFCs -will- be ignored.  Better to have a frozen RFC that 
says "no one liked my solution, but most agreed the problems existed", that 
gets those problems documented and -looked at- than to have the problems 
detailed in something most will summarily ignore.


Re: perl6storm #0050

2000-09-27 Thread Buddha Buck

At 03:35 PM 9/27/00 -0400, John Porter wrote:
Piers Cawley wrote:
  You know, I'm trying to see what's annoying about all those
  parentheses in the lisp function and what do you know, I can't see
  anything wrong. Okay, so it's not Perl syntax, but it's still clear
  what's going on.

Yes, but it's hard to read.  Lisp requires parens, because it
has no precedence rules. (Well, hardly any).  It has (almost)
no other syntax.  This is the situation we would like to avoid
in perl.  By letting every operator have well-defined precedence,
and every be function well prototyped, there should never be any
ambiguity (to the compiler, at least) as to what is meant, even
with no parens.  Ideally, anyway.

While Perl -lets- every function be well prototyped, it doesn't -require- 
every function to be well prototyped.  Because of this, it might be well 
nigh impossible to eliminate all ambiguity to the compiler.

John Porter

 Aus des Weltalls ferne  funken Radiosterne.

Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Buddha Buck

At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:

   Finally as an overload expert what do you think about the proposals
   to make arrays overloadable objects so one can say things like:
   @x = 3 * @y;

I can see that allowing expressions on @x would require considerable
changes to perl core.

Is there a nice way to resolve this problem?

What do you think of:

   $x[|i] = 3 * $y[|i];


   @x = 3 * $y[|i];

It's not as clean as @x = 3 * @y, but it is cleaner context-wise.

(Working on RFC207(v2) even as I write)


Re: RFC 231 (v1) Data: Multi-dimensional arrays/hashes and slices

2000-09-21 Thread Buddha Buck

At 03:35 PM 9/21/00 -0400, Buddha Buck wrote:
At 03:26 PM 9/21/00 -0400, Karl Glazebrook wrote:

   Finally as an overload expert what do you think about the proposals
   to make arrays overloadable objects so one can say things like:
   @x = 3 * @y;

What do you think of:

   $x[|i] = 3 * $y[|i];


   @x = 3 * $y[|i];

It's not as clean as @x = 3 * @y, but it is cleaner context-wise.

And one could argue that:

@x = map 3*^_, @y;

is cleaner yet...


Re: RFC 263 (v1) Add null() keyword and fundamental data type

2000-09-21 Thread Buddha Buck

At 02:39 AM 9/21/00 -0700, Glenn Linderman wrote:
Thanks, Paris, for your intervention, although I fear it was too late.

Well, since Tom claims to have put me in his kill file, he may never see
this.  But for the record...

Tom Christiansen wrote:

  Can't we all just play nice?
  Apparently not.   Several of us attempted to explain why this didn't
  make sense, for many reasons.  GL wouldn't hear any of it, stubbornly
  adhering to this notion despite what was said, often completely
  ignoring or apparently purposefully misunderstanding the points.

It's true that I think that NULL would be an extremely useful concept,
and until there is a cogent argument to the contrary, I will continue to
believe it.  I've been working with databases for 21 years, and with Perl
for 5, and I truly believe NULL would be a useful addition to using Perl
to work with databases.

Ok, let's see if I can make some sense of this...

You want a singleton scalar datatype in addition to the exising scalar 
datatypes of strings, numbers, references, filehandles, and undef that 
represents an unknown value, similar in semantics to the SQL notion of "NULL".

I'm going to call this prototypical datatype/value "unknown", in order to 
represent its meaning in a more perlish way, as well as to avoid the 
overloaded semantics of NULL (and it's related near-homonyms: SQL's unknown 
NULL, C's NULL invalid pointer, Lisp's NIL, ASCII's NUL, the null string, 
the null list, etc).  Calling anything NULL these days is likely to be 
confusing, so I'll avoid it.

This doesn't matter as far as database work goes because DBI can convert 
between SQL NULL and perl unknown just as easily as it can convert between 
SQL NULL and perl undef.

I just reread RFC 263, and I do have some unanswered questions.  How 
pervasive is this "unknown" value?  If $a is unknown, what about $a


$a = unknown;
print "\$a is ", ($a ? "true" : "false"), "\n";

What should print?

I think the example of:

   die "Fatal, \$name is unset!" if ($name == null);

is flawed.  It will never die, because as you said, two unknown values 
won't compare as equal.  Besides, the test would try to convert both $name 
and null to numbers before doing the numerical comparison, so it would 
depend on what the numerical value of unknown is.  You really need a 
"known()" built-in to go with this, such that known($a) is true if $a is 
NOT unknown.

What gets me is that the implementation of this would require virtually 
every operator, function, etc in core perl to be special-cased to deal with 
the unknown value, yet the RFC makes no mention of this.

With undef, it's simply a matter of having the internal representation of 
undef return 0 or "" when asked for a numerical or string value.  This 
makes most things deal with undef nicely -- even booleans.  With unknown, 
since it is specifically designed to propagate, everything would have to 
deal with unknown values, not just integers, or strings,  or booleans.

Importantly, unless you decide something arbitrary like "unknown is false" 
like the way that it was decided that "undef is false", then you throw out 
the law of excluded middle (every expression is either true or false), and 
make things like the ?:, ||, or  operators go all wiggly (not to mention 
if, while, unless, and so forth).  And if you do arbitrarily say "unknown 
is false", how do you deal with the cases where you want to say "I don't 
know if it's true or false"?

SQL gets away with this by saying that boolean contexts require a boolean 
value, which you get by using a relational operator.  People don't go "IF 
variable THEN..." unless they know that variable will be boolean -- and 
can't be NULL.  And they then decided that using a relational operator on 
NULL will always yield FALSE.  That works for them.

But that's not Perl.  Perl programmers like functions that return a useful 
but true value on success, or undef on failure, and are quite comfortable 

$var = f();
if ($var) { g($var) };   # f was a success

That won't work if $var can end up being unknown.  Worse, fixing it by saying

if (defined($var)) { g($var) };

doesn't help, because the RFC says that defined(unknown) is unknown!

Your unknown seems to be very special-case for doing SQL-based DB work.  In 
all my time programming it, I can't remember wanting it.  It doesn't seem 
to integrate with the rest of Perl all that well, requiring massive changes 
under the hood to integrate it and the potential for messing up lots of 
long-standing Perl idioms, for a relatively small benefit.

Damian mentioned that his Q::S package and RFC would/could provide 
something with similar semantics, and his RFC would also likely result in 
massive changes under the hood, but it also provides a large generally 
useful functionality (and in CONSTANT TIME, too ;-).  It is unclear as of 
yet if the benefit of Q::S will outweigh the probably cost of Q::S.  Can 
you make as strong a case for unknown?

Notice of intent to freeze RFCs 204, 206, and revise 207

2000-09-19 Thread Buddha Buck

Unless I hear otherwise, I plan on freezing RFC 204 and RFC 206 this 
evening (17:30 New York time), and issue a revised version of 207.  The 
frozen versions will be substantially identical to the versions ow 

On RFC 204 (LOL refs as indices), I have followed the discussion from 
Ilya that list references will have problems when objects that used 
blessed references to lists as their internal representation are used 
as indices.  This does indeed seem to be a problem, but I'm uncertain 
how big of a problem.

Would it help if the RFC stated that the index had to be either a 
scalar integer or an ARRAY ref of integers?  Since objects would be 
blessed as something other than ARRAY, they would need to be converted 
first.  If it was an object, it would try to call standard methods to 
convert to a scalar integer, a list of integers, or an ARRAY ref of 
integers.  Just an idea.

I will include Ilya's objections (and a more formal version of the 
above suggestion) in a "Summary of Discussion" section.

On RFC 206 (@#arr as bounds-fetcher), I have not really heard any 
substantive comments, but most of what I've heard is positive.  Please 
point out to me anything I may have missed.

I will freeze 206 as-is, unless someone has something to add.

On RFC 207 (efficient array loops), based on discusion and additional 
thought on my part, I want to clarify and change the syntax used in the 
RFC.  I also want to go into more detail about how the scope of the 
efficient array loops is derived.

Here is a summary of changes:

1)  Replace use of |i as a "list-like" expression to use of |i as a 
"scalar-like" expression.  This would prefer syntax like:

  @newarray = $a[|i]*$b[|j];


  @newarray = @a[|i]*@b[|j];

I originally viewed |i as being syntactically a replacement for a range 
(0..$max), but I think that view is potentially confusing.

2)  In v1, iterators converted the minimal expression containing all 
iterators in a statement into a loop (or nested loops).  This 
unfortunately led to such clumsiness as:

  {my @temp; $temp[|i] = dotproduct += $a[|i]*$b[|i];} # Not DWIMish

where it isn't clear why the @temp needs to be created and destroyed.  
The RFC also required the creation of a potentially huge 
multidimensional array even if such an array would then simply be 
thrown away.  Worse, in the "dotproduct" example above, both the 
implicit array and the @temp array would be created and destroyed for 
no good reason.

v2 will have iterator scope and implicit array creation dependant on 

Starting with the minimal expression containing all iterators in a 

a) If the expression is in list context, generate an implicit temporary 

b) If the expression is in void context, do not generate an implicit 
temporary array

c) If the expression is in any other context (scalar, lvalue, etc) 
expand the expression to the minimal proper superexpression (i.e., go 
up one level on the parse tree) until you have list or void context.

That would make

  dotproduct += $a[|i]*$b[|i];

Do The Right Thing.

I would also state that although some of the examples used can be 
better done under RFC 82, this RFC is not intended to compete with RFC 
82.  RFC207 and RFC82 provide two different sets of functionality that 
partially overlap.

Comments?  Criticism?  Complaints?


"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: pack/unpack is damn unperlish. Explain them as Perl.

2000-09-19 Thread Buddha Buck

At 07:29 AM 9/19/00 -0700, Dave Storrs wrote:
 I guess, if I had to write an explanation of pack/unpack based on
my limited understanding, it would be something like:

 "Unpack takes binary data in some particular format and
disassembles it, assigning various pieces of it to variables according to
formatting that you supply.  Pack does the opposite, using your supplied
formatting to crunch Perl scalar variables into binary data that is
represented in some specific way.  The binary data used by (un)pack will
belong to exactly one type of C numeric variable, meaning that it will be
limited in what kinds of numbers it can store and how it will represent

 Is this definition completely off-base?

I think you are on track, but I would probably have defined it the other 
way around:

"The perl function pack() takes Perl values and converts them to a compact 
binary representation based on a user-specified template.  This is useful 
for communicating with external data formats that expect data to be in a 
particular binary format that is not native to perl.  The perl function 
unpack() takes a compact binary representation of data and converts it to 
Perl values based on a user-specified template.  Pack() and unpack() are 
inverse-functions of each other: if used with the same template, unpack can 
be used to recover data that has been packed.


$Tudpheader = ""; # source, destination, length, checksum
$Tudppseudoheader = "NNxcn"; # source IP, dest IP, protocol (must be 17), 

$udplength = length($data)+8;

$udpcheck = (pack $Tpseudoheader, $sip,$dip,17, $udplength)
 . $(pack $Tudbheader,$sport,$dport,$udplength, 0)
 . $data;

$checksum = udpchecksum($udpcheck);

$udppacket = (pack $Tudbheader,$sport,$dport,$udplength,$checksum) . $data



Re: RFC 218 (v1) Cmy Dog $spot is just an assertion

2000-09-14 Thread Buddha Buck

At 08:13 AM 9/15/00 +1100, Damian Conway wrote:
Piers wrote:

 I'm kind of tempted to look at adding another pragma to go with 'use
 base' along the lines of:

  use implements 'Interface';

 Which is almost entirely like Cuse base 'Interface' but with
 'Interface' consisting of nothing but:

  package Interface;

  sub virtual_method;
  sub virtual_method2 (#prototype);



You and I must have been separated at birth, Piers.

Here's what I wrote to Nat just yesterday:


 Interfaces might also act like pure abstract base classes when
 inherited, so that:

 package Dog;
 use base 'Fetcher';

 would cause a compile-time error if Dog failed to actually provide
 a Cfetch method.

I don't like that at all...

Currently, Object implementations can be changed at will at runtime.  In 
particular, it is possible to create new methods and change the class 
hierarchy at run time.

package TextFilter;
use CryptInterface;
@ISA = qw(CryptInterface);

   my $self = shift;
   ($name = $AUTOLOAD) =~ s/.*://;
   # Cryptography is very hairy and we don't want to load it if we don't
   # have to.
   if ($name = any(qw(setkey setcrypt encode decode)) {
  require Crypt;
  import Crypt;
  push @ISA,"Crypt";
  $self-$name(@_);  # I've not tried this, it may be wrong.

I'd hate to have that break because TextFilter isn't derived from Crypt 
unless it needs to be.

I think calling a method declared in an inherited interface but not 
implemented would be a good reason to have a descriptive run-time error, like:

Method getkey in interface Crypt not implemented in TextFilter object at 

Well, perhaps written better...

If you'd like to run with it, be my guest (but check with Nat first, in
case he wants it).


Re: RFC 207 (v1) Array: Efficient Array Loops

2000-09-11 Thread Buddha Buck

At 12:00 AM 9/12/00 +1100, Jeremy Howard wrote:
  Reading through the examples left me wondering about some
 @t[|i;|j] = @a[|j;|i];  # transpose 2-d @a
  Written like this it would require that @a is exact 2-dim, i.e. it would
  not just swap the first two dims of any n-dim array? I suppose if I'd
  want that I'd write
  @t[|i;|j;] = @a[|j;|i;]; # trailing ';' implies there might be
  trailing dims
Not necessary. Since arrays support all the syntax of a plain old list of
lists, and the |i syntax just creates an implicit loop, the example quoted
from the RFC will work with other sized arrays. In fact, if it was only 2d,
it would more properly be:

   $t[|i;|j] = $a[|j;|i];  # transpose 2-d @a

I think it's fair to say that I goofed, and was probably inconsistent with 
my use of @ and $ in RFC207.  It was the hardest (conceptually) of the RFCs 
I wrote, and it was written late at night -- my thinking probably wasn't as 
clear as it could have been.  I know I delayed in writing it because it 
posed interesting challenges to syntax and semantics.

I think what I was thinking was that |i would act as a list, therefore 
@t[|i] is syntactically an array slice, and therefore uses @, not $.  I'm 
not so certain that that makes a tremendous amount of sense.

The problem is that the isolated expression ~a[|i;|j] (using ~ as a 
placeholder for $ or @) evaluates to a 2D array, so should use @, but the 
|i;|j syntax is used to refer to a single element, so it's sort of a 
scaler, and should use $.

While something like "$t[|i;|j] = $a[|j;|i]

With three dimensions, each implicit loop in

   @t[|i;|j] = @a[|j;|i];  # transpose 2-d @a

is assigning the _list_ (or 1d array) at @a[|j;|i] to the appropriate index
in @t. Ditto for 3 dimensions, except that it is a 1d array (or LOL) that
is being assigned at each index through the implicit loop.

Re: RFC 145 (alternate approach)

2000-09-06 Thread Buddha Buck

At 09:05 AM 9/6/00 -0400, David Corbin wrote:
I'd suggest also, that (?[) (with no specified brackets) have the
default meaning
of the "four standard brackets" :


Note also the subtle syntax change.  We are either dealing with strings
or with patterns.  The consensus seems to be against patterns (I can
understand that).  Given that, we need  to quote the right hand side of
the = operator I think.  The quotes on the left side would be optional,
I think.

It would be useful (and increasingly more common) to be able to match 
qr|\s*(\w+)([^]*)| to qr|\s*/\1\s*|, and handle the case where those 
can nest as well.  Something like

listmatch this with
   /list   not this but
/list   this.

Richard Proctor wrote:
  On Tue 05 Sep, Nathan Wiger wrote:
   Eric Roode wrote:
   Now *that* sounds cool, I like it!
   What if the RFC only suggested the addition of two new constructs, (?[)
   and (?]), which did nested matches. The rest would be bound by standard
   regex constructs and your imagination!
   That is, the ?] simply takes whatever the closest ?[ matched and
   reverses it, verbatim, including ordering, case, and number of
   characters. The only trick would be a way to get what "reverses it"
   means correct.
  No ?] should match the closest ?[ it should nest the ?[s bound by any
  brackets in the regex and act accordingly.
  Also this does not work as a definition of simple bracket matching as you
  need ( to match ) not ( to match (.  A ?[ list should specify for each
  element what the matching element is perhaps
(?[( = ),{ = }, 01 = 10)
  sort of hashish in style.
  Perhaps the brackets could be defined as a hash allowing (?[%Hash)

David Corbin
Mach Turtle Technologies, Inc.

Re: RFC 33 (v2) Eliminate bareword filehandles.

2000-09-06 Thread Buddha Buck

At 12:50 PM 9/6/00 -0500, David L. Nicol wrote:
I see barewords as being whatever the programmer wants them to be,
as long as he makes it clear what he expects the word to be before using

So, Copen becomes a legacy constructor and the perl6 version of it would
be something like

 my filehandle fh; fh-new("/tmp/appendablelog");

Ugh...  How about...

my filehandle fh;

or (using indirect object notation)

my filehandle fh;
open fh ("/tmp/appendablelog");

or even

open my filehandle fh ("/tmp/appendablelog");

with or without fh being syntactically singular, fh will from here to the
end of the enclosing block be seen as a filehandle if that makes sense in 

What advantage does this give over:

open my filehandle $fh ("/tmp/appendablelog");

besides the saving on one key stroke?

If it doesn't make sense, meanings from other contexts will be attempted 
autovivification or error.

   David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'@w=;for(;;){sleep print[rand@w]}' /usr/dict/words

Re: RFC 179 (v1) More functions from set theory to manipulate arrays

2000-09-01 Thread Buddha Buck

At 03:40 PM 9/1/00 +0200, Gael Pegliasco wrote:
  Arrays are ordered.
  Hashes are not.
  Neither are sets.
  Arrays can have repetitions.
  Hashes can not.
  Neither can sets.

Yes, this is true, but the natural syntax, for me, to manipulate sets,
is the one of arrays.

It is not natural to write :

%my_fruit_set = ( 1 = 'orange', 2 = 'lemon' );

You are right, that is not natural.  I don't know why I would ever want to 
use a hash keyed using integers instead of arrays.  But that's not how I 
would use  a hash for a set.

but it is natural to write :

@my_fruit_set = ( 'orange', 'lemon' );

I don't want to have to deal with keys of hashes because my set elements
don't care about them !

In a hash implementation, your hash keys -are- your set elements!

my %set;

# add elements to %set
$set{'elem1','elem2'} = 1;

# test for set memebership
print "elem1 in %set\n" if exists $set{'elem1};

# Compute union
$union{keys %set1, keys %set2} = 1;

# Compute intersection
for $elem (keys %set1) { $intersect{$elem} = 1 if exists($set2{$elem});}

# set difference
delete @set1{keys %set2};

How do you currently do these things with arrays?

so, I want new functions to manipulate arrays.

then, when manipulating arrays, without speaking about sets, you often
need in/union/intersection functions, even if arrays have duplicated
elements or if they are ordered.

Well, in fact I don't understand why you don't think that
union/intersection/difference are not usefull functions for arrays ?

Because I don't know what they will do with an array.  They are 
(reasonably) well defined for sets, but not for arrays.


Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

2000-08-31 Thread Buddha Buck

At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
   The array
   syntax would also be useful in multi-dimensional arrays.
  That is if multi-dimensional arrays are implemented as lists-of-lists,
  which they might not be.

Even if they aren't implemented as lol, they may appear as lol to the 

The language-data group is working on multi-dimensional array syntax.

I would like to have (in multidimensional arrays) the various dimensions be 
equally easy to access.  Using lol syntax imposes a hierarchy on the 
dimensions, which makes equal access hard.

For instance, using the syntax I proposed in RFC169, you can take the $ith 
row and $jth column of a 2-dimensional array with:

@row = @matrix[$i;..];
@col = @matrix[..;$j];

This can be naturally extended to greater dimensions, if need be.

How does one do this in LOL syntax?

@row = @{$matrix[$i]};  # this is easy!
for my $r (@matrix) {
   push @col,$$row[$j];
}   # this is easy?

I suppose one could do:

for (my $k = 0;$k  @matrix; $k++) {
push @row, $matrix[$i][$k];
push @col, $matrix[$k][$j];

but even that obscures what you really want to do.

   David Nicol 816.235.1187 [EMAIL PROTECTED]
"My baby done left me,
she done went to the drive-in movies with somebody else."

Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

2000-08-31 Thread Buddha Buck

At 05:35 PM 8/31/00 +, David L. Nicol wrote:
Buddha Buck wrote:
   The array
   syntax would also be useful in multi-dimensional arrays.
  That is if multi-dimensional arrays are implemented as lists-of-lists,
  which they might not be.

Even if they aren't implemented as lol, they may appear as lol to the 

The language-data group is working on multi-dimensional array syntax.

I would like to have (in multidimensional arrays) the various dimensions be 
equally easy to access.  Using lol syntax imposes a hierarchy on the 
dimensions, which makes equal access hard.

For instance, using the syntax I proposed in RFC169, you can take the $ith 
row and $jth column of a 2-dimensional array with:

@row = @matrix[$i;..];
@col = @matrix[..;$j];

This can be naturally extended to greater dimensions, if need be.

How does one do this in LOL syntax?

@row = @{$matrix[$i]};  # this is easy!
for my $r (@matrix) {
   push @col,$$row[$j];
}   # this is easy?

I suppose one could do:

for (my $k = 0;$k  @matrix; $k++) {
push @row, $matrix[$i][$k];
push @col, $matrix[$k][$j];

but even that obscures what you really want to do.

   David Nicol 816.235.1187 [EMAIL PROTECTED]
"My baby done left me,
she done went to the drive-in movies with somebody else."

Re: Out-of-core format syntax (was Re: Globs, (brrr) scalar filehandles, prototypes.)

2000-08-30 Thread Buddha Buck

 Actually this is pretty cool, add a = and turn it into a variable
my format $FORMAT = '.';
 @, @
 $stuff, $junk
 And that looks pretty similar to Perl 5. ;-)

Yah, but it's frought with the possibility of confusion.  I can easily 
see someone looking at your example, and then writing:

   my format $INVOICELINE = ".";
@ @ @ @ @
$qty, $partid, $desc{$partid}, $price{$partid}, $qty*$$price{$partid}

and wondering why all their invoice lines were identical -- and 

 Anyways, I went ahead and RFC'ed the thing, we should take a look at it
 again when it posts. My goal was to make formats look 90% like Perl 5
 without requiring any special syntax, and it works pretty well, but it's
 definitely not a complete RFC yet.

     Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Proposed RFC for matrix indexing and slicing

2000-08-29 Thread Buddha Buck

At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:

You should have a look at the PDL RFC 117 before submitting this.

It would be bad to have multiple RFCs suggesting the same thing.

I just read PDL RFC 117, and your current argument with Dan aside...

I don't see a problem.

Here is the core of what I see in my RFC:

1.  Use ';' as an index separator for matrices.
2.  Use lists as methods of getting slices of matrices
3.  Use ^var (or some other syntax) as a way of expressing
 relationships/constraints among different indices when writing
 matrix slices.

Here is what I see as the core of RFC 117:

1.  Use start:stop:step as syntax for complex ranges.

I see them as orthogonal.  You could just as easily use RFC 117 syntax to 
specify the lists I use to get slices as you could standard perl lists.

Much better to come to some agreement HERE on what the syntax
should be first, then submit consensus RFCs.

My view: I am pretty flexible I like most suggestions as long as
they are concise.

Don't forget we also need to support the equivalent of



that is, assuming my RFC and RFC117 are both accepted.  What's the problem?

i.e. use a non-unit stride


Re: RFC 177 (v1) A Natural Syntax Extension For Chained References

2000-08-29 Thread Buddha Buck

 On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
   $r-{{qw(a b c d e f g h)}}
  which is only one character longer than the proposal...
 Except in the case where you don't have the list until run-time.


 So the syntax would be useful; I'm not sure how useful, such deeply nested
 hashes requiring run-time key lookup like that are a rarity.  The array
 syntax would also be useful in multi-dimensional arrays.

That is if multi-dimensional arrays are implemented as lists-of-lists, 
which they might not be.

On language-data a counter-proposal to my RFC169 has been made, 
suggesting the use of array/list references for multidimensional 
indices.  In the simplest case, assuming list-of-list implementation, 
$a[[1,2,3]] would be the same under both proposals (unless this 
proposal would require $a[[(1,2,3)]], which is too much syntax for my 
taste).  But the list-ref idea would also allow @a[$point1,$point2] as 
a slice of two elements of the matrix @a, each point being a reference 
to a 4-element list of integers.

 Programmer, System Administrator

"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: New variable type: matrix

2000-08-26 Thread Buddha Buck

 Not being a PDL'er myself, but interested in learning more about it and
 making sure Perl 6 doesn't suck, I'd love to see a bulleted list of what
 doesn't work right, even assuming that @arrays were made more flexible.
 For example, if you could do this:
@c = @a * @b;
@c = @a + @b;
@c = (@a - @b) * (@d / @e);
 What other specific problems remain? TIA.

I'm not a PDL'er myself, either.  But I haven't noticed a syntax 
suggested for multidimensional arrays that looks good to me yet.

How are they indexed?  $matrix[$x][$y][$z] is (too me) too C'ish, and 
implies that @matrix is implemented as an array of arrays of arrays, 
instead of some more efficient, compact structure.  $matrix[$x,$y,$z] 
already has a reasonable meaning.  If we appropriate that syntax, how 
do you take slices of a matrix?

I'm thinking I like using ; as an index separator, as in 
$matrix[$x;$y;$z].  This -shouldn't- be a massive problem for parsing; 
we are already using ; in "for(;;)" as something other than a statement 

This would also allow us to do slices like: @matrix[1,3,5;2,4,6;3] to 
get a 3x3x1 resulting matrix consisting of $matrix[1;2;3],$matrix[1;4;3]
, etc.

How are literal multidimensional arrays written?  For this, I'm not 
sure...  My first thought was to separate the rows with ;, as in 
@matrix = ( 1,2;3,4).  But that doesn't scale well to more than 2d.  
Then I thought just using the standard list of list syntax:  @matrix = 
( [1,2],[3,4] ).  But is that a list of array references, or a 2-d 
array?  Next, I thought of combining the two:

@matrix3x3x3 = ( [[ 1, 2, 3];
  [ 4, 5, 6];
  [ 7, 8, 9]];   # row 0;
  [16,17,18]];   # row 1;
  [25,26,27]] ); # row 2;

I think parenthesis might be better, using [] for reference 
constructors, but any way you look at it.

Should explicit bounds and declarations take place before use?  Is "my 
@matrix:bounds(3,3,3);" necessary?  I don't know about you, but 
autovivication of array elements and boundlessness is a feature I like 
about perl.  Why should "$array[1000] = $x" work without predeclaration 
but "$matrix[1000;1000;1000] = $x" shouldn't?

Just my thoughts?


"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: ME

2000-08-23 Thread Buddha Buck

 Buddha Buck wrote:
  Perhaps someone should RFC the new special variable ME, which is
  predefined to be the whole program.  Who knows?  Perhaps it would then make
  sense to use @_ at the top level, as if the program was invoked as
 on -objects it has been proposed that ME is a call to the current subroutine
 or method; that would generalize out to this meaning at the top level only

Hmmm...  Could one then go main::ME() then? No, that's not 

How about a @CALLER array, with each element being a reference to the 
invoking function in the call-back stack.  $CALLER[0] would be 
equivilant to \ME, $CALLER[1] would be the sub that called ME, etc, 
and then $CALLER[-1] would logically be the main program.

Hmm...  I don't like @CALLER...  Is @ taken?  I know $ is...

     Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes

2000-08-17 Thread Buddha Buck

At 07:04 PM 8/17/00 +0200, Johan Vromans wrote:
Nathan Wiger [EMAIL PROTECTED] writes:

  Most of the places I've seen them used really well is if
  they walk and talk like other forms:
 $cgi-param($var, @val);  # traditional
 $cgi-param($var) = @val; # lvalue, but same thing

I do not think this is critical. When lvalue subs catch on, the
traditional way will soon be extinct.

However, if an lvalue sub is an lvalue, it must be an lvalue in _all_

 $cgi-param($var) = ...

This is a pure lvalue...

 $cgi-param($var) += ...

This is not a pure lvalue, but rather both an lvalue and an rvalue, 
equivalent to:

  $cgi-param($var) = $cgi-param($var) + ...

It should evaluate $cgi-param($var) twice, once as an rvalue, and once as 
an lvalue.

 $cgi-param($var) =~ s///

This is a tricky one...  What should the proper result of:

$cgi-param($var) = "Value constrained to less than 80 characters";
$cgi-param($var) =~ s/./FOO/g;

be?  Should it be allowed to change the value of $cgi-param($var) to more 
than 80 characters?  My though is that it should act like:

{ my $string = $cgi-param($var);
  $string =~ s/./FOO/g;
  $cgi-param($var) = $string;
and $cgi-param() can catch any constraint violations like normal.

 for ( $cgi-param($var) ) {
 $_ = ...

These I'm uncertain how to deal with...

and so on.

And, what would the lvalue routine return?

I would say, by -convention-, it should return the new rvalue of the lvalue:

{ my $inval = 0;
   sub foo : lvalue($val) {
 $inval = $val if defined($val)  $val  10;
 return $inval;

Currently, $a = $b = $c
implies that both $b and $a get the value $c. But with lvalue subs I
can write something like

 yech($foo) = $bar

that assigns $bar to $foo, and returns something else (e.g., the
previous value of $foo).

 $a = yech($foo) = $bar

now $a will no longer get $bar assigned.

Do we want that?

Sometimes it would be nice.  Why forbid it?

-- Johan

Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, and wantarray() changes

2000-08-17 Thread Buddha Buck

At 05:49 AM 8/18/00 +1000, Damian Conway wrote:

And I keep pointing out that this is only one aspect of lvalue subroutines.
The point of an lvalue subroutine is not to make assignment to the return 
work, it is to make the return value an *lvalue*. That's a much more general
thing, because it allows every other type of modification to work too.

The lvalue accessor *shouldn't* be doing the assignment (what if an assignment
isn't what I want?).

The (overloaded) operator = should do the assignment. To whatever lvalue
the lvalue subroutine returns.

Or the "assignment" should be done by operator += or operator++ or
whatever mutator I'm actually applying to the returned lvalue.

SO what you are saying is that the proper execution of "$p-foo(@args) += 
$val;" should be (equivalent to):

1. Evaluate $val and get an rvalue $rval.
2. Evaluate $p-foo(@args) and get an lvalue $lfoo.
3. Add $rval to the rvalue associated with $lfoo, to get $rbar.
4. call $lfoo-operator=($rbar) to do the actual assignment.

Is that about right?

When is your RFC about lvalue subs coming, Damian?


Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

2000-08-16 Thread Buddha Buck

At 10:37 AM 8/16/00 -0400, Chaim Frenkel wrote:
  "BB" == Buddha Buck [EMAIL PROTECTED] writes:

BB If we have to pick and epoch in an OS-neutral way, I think I for one
BB would be happy with something like this in the docs for the time
BB functions:

Would you be happy with the following edits?

BB All date and time functions, unless otherwise documented, assume the
BB use of the International Atomic Time (TAI) timescale. TAI differs from
BB standard time (UTC) in that TAI does not have "leapseconds".

BB It is likely that the OS clock was set to UTC, not TAI.  This slight
BB difference (22 seconds as of 2000) should not cause any problems unless
BB date computations of over 6-months with second accuracy are needed.

BB time() returns the number of seconds elapsed since the beginning of the
BB International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958.

time() assumes that the system clock is set to TAI, and does not correct 
for accumulated leap-seconds.  Arithmetic differences between time stamps 
made using time() may be off by the number of accumulated leap seconds 
between the two time stamps.

BB date($) returns a year-month-day-hour-minute-second representation of
BB the time passed to it (in seconds since the TAI epoch).  The
BB representation assumes the TAI timescale.
BB -

So if I understand you, the instantaneous time is correct. But
calculating backwards to what the instantaneous time would have been,
or calculating what the instanataneous time will be will not work.


But your blurb would be a lie. How would one ensure the correct
difference to the TAI? And what would be the translation to the
system time?

Unless you want to have to update perl (or a configuration option) every 
year, it's probably best to not bother correcting for leap seconds.

This is essentially what we do now.  The major change here would be a 
change of epoch (to the TAI epoch) and a documentation of the issues involved.

What do we do with stat(), utime(), sleep(), select(), events, etc.

stat() returns time stamps (made in the past).  utime() sets time 
stamps.  They should be compatible with time().  e.g., "utime 
time,time,@files" should still set the modify and access times of @files to 

sleep(), select() both take intervals.  The time scale is irrelevant.

Will events need time stamps, intervals, or other (please specify)?

Chaim FrenkelNonlinear Knowledge, Inc.

Re: RFC 99 (v2) Standardize ALL Perl platforms on UNIX epoch

2000-08-15 Thread Buddha Buck

 Why? What is the gain? Perl only runs on the local machine.
 As long as one can increment and take the difference what difference
 does the epoch make?
 What is of more interest would be knownig the valid range of time
 supported on each platform. Even if you standardize the epoch, the
 platform may be unable to calculate to the epoch.

Unfortunately, the valid range of time supported is easily determined, 
and disturbingly short:

Into the future:  to next December 31st or June 30th, whichever is 
Into the past  :  to past January  1st  or July  1st, whichever is 

Leap-seconds are a PITA for generic time routines.

"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 107 (v1) lvalue subs should receive the rvalue as an argument

2000-08-15 Thread Buddha Buck

 I assume you meant that :lvalue() takes a parameter list.  Either a
 singleton named variable $, @, or %. 

I'm proposing that an lvalue subroutine have access to the rvalue 
assigned through a channel other than the standard argument list @_.  I 
used, as an example, an explicit named parameter to lvalue, but I could 
also see a "line-noise" variable used ($= would be perfect, but it's 

I'm proposing that that rvalue be passed by perl as a reference instead 
of as a straight $, @, or %.

I'm proposing that subs in lvalue slots that aren't lvalue subs 
generate errors.

I think that that is all I'm proposing now...

By having the rvalue passed through a separate channel, the function 
does not have to worry about wondering which of @_ (if any) is the 
rvalue.  This prevents the confusion some are worried about with the 
idea that the assigned rvalue is simply tacked onto the end.  

$p-name = 'Mithrandir';

would not be directly equivilant to 


as $p-name() would be able to tell in the first case that it is called 
in lvalue-context, with 'Mithrandir' as an rvalue to assign.  It may be 
that $p-name() uses its first argument as a value to assign, but not 

Consider, for example, $mytensor-index(2,3,4,5,6).  Should that return 
the value of cell[2][3][4][5][6], or should it set cell[2][3][4][5] to 

 Or If it makes sense even a more complex parameter list could be

I don't think that's necessary.  I like the idea of passing the rvalue 
in as a reference because a) references can maintain their own type 
information (as per ref()), and b) the rvalue being passed in as 
"undef" would unambiguously indicate that it was not lvalue context (a 
reference to undef is defined).  Besides, I can't imagine the rvalue 
being multiple things -- an object, yes.  A reference, yes.  An array, 
yes, a hash even.  But not multiple objects, multiple references, 
multiple arrays, or multiple hashes.

 sub foo :lvalue(Dog $fido, int @array, %hash) {}
 foo() = ($name, 0..10, %bar);
  "BB" == Buddha Buck [EMAIL PROTECTED] writes:
 BB sub foo : lvalue($newval) {
 BB   # $newval is a lexical scaler in this block, initialised with a 
 BB reference
 BB   # to the value to be assigned to $self{foo}
 BB   my $self = shift;
 BB   return $self{foo} unless defined $newval; # rvalue context
 BB   # lvalue context
 BB   # verify new foo is in correct range
 BB   return $self{foo} if $$newval  $MINFOO;
 BB   return $self{foo} if $$newval  $MAXFOO;
 Chaim Frenkel  Nonlinear Knowledge, Inc.
 [EMAIL PROTECTED] +1-718-236-0183

"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC 91 (v1) Builtin: partition

2000-08-11 Thread Buddha Buck

At 05:33 PM 8/11/00 +0100, Graham Barr wrote:
On Fri, Aug 11, 2000 at 03:36:21PM -, Perl6 RFC Librarian wrote:
  This and other RFCs are available on the web at
  =head1 TITLE
  Builtin: partition
  =head1 VERSION
Maintainer: Jeremy Howard [EMAIL PROTECTED]
Date: 11 August 2000
Version: 1
Number: 91
  =head1 ABSTRACT
  It is proposed that a new function, Cpartition, be added to Perl.
  Cpartition($partition_size, \@list) would return @list broken into
  references to sub-lists, each one $list_size in size.
  In order to work with lists of arbitary size, it is often necessary to
  split a list into equal sized sub-lists. A Cpartition function is
  proposed that achieves this:
@list = (1,2,3,4,5,6);
@partitioned_list = partition(2, \@list);   # ([1,2],[3,4],[5,6])

How is this different to you other RFC for unzip() ?

  @unzipped_list = unzip(3, \@zipped_list);   # ([1,3,5], [2,4,6])

The difference is how they group:

@unzipped_list= unzip(3, (1,2,3,4,5,6));  # ([1,3,5],[2,4,6])
@partitioned_list = partition(3,(1,2,3,4,5,6));   # ([1,2,3],[4,5,6])

Or...  Let's say you had a 3x3 array implemented as follows:

@array = (  a1, a2, a3,
 b1, b2, b3,
 c1, c2, c3 );

unzip(3,@array) would return the columns.
partition(3,@array) would return the rows.

Re: RFC 91 (v1) Builtin: partition

2000-08-11 Thread Buddha Buck

 Buddha Buck wrote:
  Or...  Let's say you had a 3x3 array implemented as follows:
  @array = (  a1, a2, a3,
   b1, b2, b3,
   c1, c2, c3 );
  unzip(3,@array) would return the columns.
  partition(3,@array) would return the rows.
 Nice example! I think this better go in the RFC :-)

Feel free...  I'd recommend using a 2x3 matrix (or a 3x4) for the RFC.  
I couldn't decide if an NxM matrix would be properly split by 
unzip(3,@array) or unzip(4,@array), so I cheated and used a square 

"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: RFC: Rename local() operator

2000-08-06 Thread Buddha Buck

  What about Chide ?
 Here's yet another one - how about "here"?
   here $/ = "\n";   # what it is in here
 Not really any confusion on this - $/ is "\n" 'in here', but maybe
 something else outside.
 Unlike "hide" or others, this doesn't connote it's necessarily any
 different from somewhere else - just that it's this value inside the
 current block (which is what we're after, I think).

But it isn't "here" that's the problem.  If we just wanted to change 
the value "here", we could use my().  The problem is that local() 
changes the value for somewhere else as well as here.  Other names 
suggested (like "shadow", or "mask") convey that idea better than 


"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects."  -- A.L.A. v. U.S. Dept. of Justice

Re: Recording what we decided *not* to do, and why

2000-08-03 Thread Buddha Buck

At 01:11 PM 8/3/00 -0500, Jonathan Scott Duff wrote:

BTW, I propose that RFCs have a Status: field as part of the VERSION.
Here are some possible values that I can see:

Status: accepted # we all agree that it should go in
Status: rejected # we all agree that it shouldn't go in
Status: tabled   # shelved, put away for now

Since I have been lead to believe that in standard US practice, "to table" 
means to stop talking about something for now, and in standard UK practice 
"to table" means to bring up for discussion, I suggest that the last be 
"Status: postponed" instead of "Status: tabled".

But then, I'm so far behind on my perl6 mail that someone else may have 
suggested that.

Jonathan Scott Duff