Re: Dallas.p6m

2009-03-19 Thread Graham Barr

On Mar 18, 2009, at 5:26 PM, fREW Schmidt wrote:
s1n and I decided that we would start Dallas.p6m as we are close to  
each
other geographically speaking.  We are meeting tomorrow (Thursday,  
March 19,
7:00PM) at a coffee shop with free wifi.  The address is 985 W  
Bethany Dr

Allen, TX 75013.


I live in Allen, so might be there. That address is where Market  
Street is right?

What is the name of the coffee shop?

Graham.



Re: Temporal changes

2009-02-24 Thread Graham Barr


On Feb 23, 2009, at 3:56 PM, mark.a.big...@comcast.net wrote:


Instant
Moment
Point
PointInTime
Timestamp
Event
Jiffy
Time


Juncture



Re: WTF? - Re: method calls on $self

2005-07-15 Thread Graham Barr
On Thu, July 14, 2005 10:47 am, Autrijus Tang said:
 If this were a straw poll, I'd say...

 1. Meaning of $_

 .method should mean $_.method always.  Making it into a runtime
 error is extremely awkward; a compile-time error with detailed
 explanataion is acceptable but suboptimal.

 2. Topicalization of $?SELF

 Neutral on this -- I can argue bothways. in my limited experience
 of writing p6 code, it is convenient but somewhat confusing
 to topicalize the invocant.

 3. Shorthand of $?SELF.method

 I find ./method to be very useful in practice, and my brain
 gets use to it rather quickly.  The association to pattern
 matching and division gradually fades away, at which time
 its novelty cease to be a problem.

I have been watching perl6-language from afar and not really
contributing. But I have to say that in this case I do agree
with Autrijus

Graham.




Re: Open and pipe

2005-05-05 Thread Graham Barr
On May 4, 2005, at 8:13 AM, Uri Guttman wrote:
  AS Why? Because IO::Socket.new takes parameters that are built out 
of its
  AS entire inheritance tree, so a change to IO::Handle might 
radically
  AS modify the signature of the constructor.

makes sense. we should look at the p5 IO:: tree and see what we want to
salvage/savage from it as well as io::all. each has its good and bad
points and hopefully we can figure out which is which. :)
Yes. p5 IO:: has evolved a bit over time and some things have turned 
out to be bad choices in hindsight.

For example, one thing I am still not convinced was the right thing was 
to create a hierarchy such that a given class only had methods that 
were valid for it. For example the recent issue on p5p with seek etc 
not being in IO::Handle but IO::Seekable and the core using IO::Handle.

Also the way IO::Socket::* was done instead of all sockets created by 
IO::Socket-new

these are all things that should be reconsidered and I am sure in all 
cases there will be people on both sides of the fence

Graham.


Re: use English

2005-04-28 Thread Graham Barr
On Apr 27, 2005, at 6:39 AM, Aaron Sherman wrote:
On Tue, 2005-04-26 at 10:48, Luke Palmer wrote:
Aaron Sherman writes:

The reasons I don't use English in P5:
  * Variable access is slower

Hmm, looks to me like $INPUT_RECORD_SEPARATOR is faster.  (Actually
they're the same: on each run a different one won, but just barely 
like
this).
Remember that I'm a Perl 3 programmer who has just gotten used to this
5 thing... ;-)
I sometimes lose track of the ugly hacks that have been rationalized
into workable practice over the versions. use English used to require
an extra level of indirection in the implementation, but clearly no
longer does. I don't have a perl older than 5.6.1 to test against, but
this was probably back in the 5.002 or 5.003 timeframe. I'm guessing.
It is also the fact that English.pm mentions $' and $` and that any 
mention
of those variables flips a global switch inside perl which causes 
*every*
regex with capturing parens to be slower.

See http://search.cpan.org/~nwclark/perl-5.8.6/pod/perlvar.pod#BUGS
Graham.


Re: Return with no expression

2004-08-24 Thread Graham Barr
On 24 Aug 2004, at 22:14, Aaron Sherman wrote:
You don't HAVE to use auto-topicalization. You CAN always write it
long-hand if you find that confusing:
for @words - $word {
given ($chars($word)  70) - $toolong {
say abbreviate($word) ?? $word;
}
}
But, I find:
for @words - $word {
say $word ~~ abbreviate($word) ?? $word;
}
much simpler! Overall, I would discourage the use of C$_ as topic in
most situations. We spent so long in Perl 5 wanting the ability to
default to whatever variable we wanted, to keep using C$_ in the
general case now that we have that is kind of a step backwards.
But you are re-creating the same problem that we had in Perl 5.
By only allowing $_ to decide which expression to evaluate you are
prohibiting the use of anything that acts on the default topic of
the enclosing block in those expressions. This is exactly the problem
of nested maps etc. in Perl 5.
Don't get me wrong, I like the idea. But it does not come without its
own set of limitations.
Graham.


Re: L2R/R2L syntax

2003-01-21 Thread Graham Barr
On Mon, Jan 20, 2003 at 07:27:56PM -0700, Luke Palmer wrote:
  What benefit does C ~  bring to the language?
 
 Again, it provides not just a null operator between to calls, but
 rather a rewrite of method call syntax.  So:
 
   map {...} ~ grep {...} ~ @boing;
 
 is not:
 
   map {...} grep {...} @boing;
 
 But rather:
 
   @boing.map({...}).grep({...});

This is not a for or against, but there is something that has been
bugging me about this.

Currently in Perl5 it is possible to create a sub that has map/grep-like
syntax, take a look at List::Util

If the function form of map/grep were to be removed, which has been suggested,
and the ~ form maps to methods. How would you go about defining a utility
module similar to List::Util that uses the same syntax as map/grep but
without making the subs methods on the global ARRAY package ?

Graham.



Re: L2R/R2L syntax

2003-01-21 Thread Graham Barr
On Tue, Jan 21, 2003 at 09:20:04AM -0800, Michael Lazzaro wrote:
 
 On Tuesday, January 21, 2003, at 02:04  AM, Graham Barr wrote:
  If the function form of map/grep were to be removed, which has been 
  suggested,
  and the ~ form maps to methods. How would you go about defining a 
  utility
  module similar to List::Util that uses the same syntax as map/grep but
  without making the subs methods on the global ARRAY package ?
 
 If you want the method to be available everywhere,

But I don't

 you probably 
 _should_ make it a method of the global Array class.

Thats like trying to wite a whole perl5 application in main
without any packages

  More typically, 
 perhaps, you'd only be using your new method to operate on certain 
 arrays that you use, in which case you would make a new class for those 
 particular arrays, so your new method would work only on the specific 
 arrays you intended it to:

Thats not always possible. Those Arrays may be passed to me from
somewhere else, so I have no control over thier class.

 I don't see any problem (other than maybe a philosophical objection) 
 with making them methods of Array, though, if they're valuable enough.  
 That certainly would seem the common Perl thing to do.

No, namespaces were invented for a reason.

Graham.



Re: L2R/R2L syntax

2003-01-17 Thread Graham Barr
On Fri, Jan 17, 2003 at 06:21:43PM +, Simon Cozens wrote:
 [EMAIL PROTECTED] (Mr. Nobody) writes:
  I have to wonder how many people actually like this syntax, and how many only
  say they do because it's Damian Conway who proposed it. And map/grep aren't
  specialized syntax, you could do the same thing with a sub with a prototype
  of (block, *@list).
 
 Well, I'll go record and say I think it's Bloody Silly. It's over-cutesy,
 adding syntax for the sake of syntax, doesn't do anything for the readability
 of code, and doesn't really actually gain very much anyway.

That I will agree with to some extent. But mainly because I think
that IF a pipe-like syntax is added then it should do just that,
pipe. What has been proposed is not a pipe, unless each part gets
converted to a co-routine and its arguments are really an interator
that calls the previous stage to get the next argument.

 But even so I dare say it'll go in because Damian likes it.

That statement I dont agree with. Yes Larry has put a lot of trust
in Damian, but that has not resulted in Damian always getting what
he wants, just most of the time :-)

Graham.



Re: purge: opposite of grep

2002-12-06 Thread Graham Barr
On Fri, Dec 06, 2002 at 09:33:14AM -0500, Miko O'Sullivan wrote:
 For example, suppose I want to separate a list of people into people who
 have never donated money and those who have.  Assuming that each person
 object has a donations property which is an array reference, I would want
 to classify them in this manner:
 
   (@nevers, @donors) := classify($_-[donations]) @people;
 
 According to the Cint model, that would give me people who have donated
 zero times, and people who have donated once, and the people who have
 donated more than once would be lost.

Then turn donations into a boolean.

   (@donors, @nevers) := classify(!$_-[donations]) @people;

I don't think there is the need to bloat the langauge with every special
case we can think of.

Graham.



Re: [RFC] Perl6 HyperOperator List

2002-10-31 Thread Graham Barr
On Thu, Oct 31, 2002 at 12:16:34PM +, [EMAIL PROTECTED] wrote:
 Yesterday Aaron Crane wrote:
 
  Jonathan Scott Duff writes:
 
 @a `+ @b
 
  In my experience, many people actually don't get the backtick
  character at all.
 
 Yes.  I think that might be a good reason _for_ using backtick in vector
 operators:


 A pair of backticks could be used if the vector-equals distinction is
 required:
 
   @a `+`= @b;
   @a `+=` @b;

Thats ugly, IMO.

Now this is going to sound wild (probably) and I have not thought too much
about it and there are probably others who can see the pitfalls quicker
then me. But could () be available for hyper operators ?

I will sit back now and watch the firewaorks, as I wont be in the UK
on Nov 5 :-)

Graham.




Re: [RFC] Perl6 Operator List, Take 5

2002-10-30 Thread Graham Barr
On Tue, Oct 29, 2002 at 05:16:48PM -0800, Michael Lazzaro wrote:
 unary (prefix) operators:
 
\ - reference to
* - list flattening
? - force to bool context
! - force to bool context, negate
not   - force to bool context, negate
+ - force to numeric context
- - force to numeric context, negate
+^- force to numeric context, complement
~ - force to string context
~^- force to string context, complement

Noe that we have gained ^ back from being a hyeroperator, could we not
have ^ as a polymorphic complement operator. It can always be combined
with ~ or +  to force context, eg

  $a = ^ +$b;
  $a = ^ ~$b;

We would then have a complement operator that I would assume objects could
overload and do whatever they liked with.

Graham.




Re: [RFC] Perl6 Operator List, Take 5

2002-10-30 Thread Graham Barr
On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote:
 --- Larry Wall [EMAIL PROTECTED] wrote:
 
  Do these French quotes come through?
  
  @a «+» @b

Odd, I see them in this message. But In the message from Larry I see ?'s

Graham.




Re: plaintive whine about 'for' syntax

2002-10-30 Thread Graham Barr
On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote:
   *shrug*  You may not like the aesthetics, but my point still
 stands:  is rw is too long for something we're going to do fairly often.

I am not so sure. If I look back through a lot of my code, there are more cases
where I use the variable in a read-only fashion than I do for modifying
the value.

Graham.




Re: Perl6 Operator List, Take 3

2002-10-28 Thread Graham Barr
On Mon, Oct 28, 2002 at 03:30:54PM -0600, Jonathan Scott Duff wrote:
 On Mon, Oct 28, 2002 at 01:19:05PM -0800, Michael Lazzaro wrote:
  
  On Monday, October 28, 2002, at 01:09  PM, Larry Wall wrote:
   No.  unless reads well in English.  How do your read $a ! $b ! $c?
  
  nor?  Maybe it's $a nor $b?
 
 oh no!  You've said nor, so now I have have to ask about nand ...
 
 and the next thing you know perl takes over the world of circuit
 design. :-)

Then dont forget full tristate logic too :)

Graham.




Re: Private contracts?

2002-10-12 Thread Graham Barr

On Fri, Oct 11, 2002 at 05:50:55PM -0700, Larry Wall wrote:
 On Sat, 5 Oct 2002, Allison Randal wrote:
 : use Acme::N-1_0; # or whatever the format of the name is
 
 I don't see why it couldn't just be:
 
 use Acme::1.0;

I agree thats better. But why not separate the version more by using
a different separator than :: between the module name and the version.
Or even something like

  use Acme[1.0];

 After all, we don't have package names starting with numbers right now...

Er, we do.

  http://search.cpan.org?perldoc?Pod::Simple::31337

It would seem that (currently) only the top-level namespace may not start
with a number.

But I would also not that CPAN only has 3 such modules, all by the same author
and all ::31337

Graham.



Re: auto deserialization

2002-09-02 Thread Graham Barr

On Sat, Aug 31, 2002 at 01:52:18PM +, Damian Conway wrote:
 I'd suggest that redundancy in syntax is often a good thing and
 that there's nothing actually wrong with:
 
   my Date $date = Date.new('June 25, 2002');

I would say it is not always redundant to specify the type on both
sides

my Dog $dog = Greyhound.new('black');

 And, furthermore, that you could easily define special semantics
 for void-context constructor calls via undef'd but typed variables,
 so that you could just write:
 
   (my Date $date).new('June 25, 2002');

So that would be creating special case syntax for
a specific case of a general issue.

Graham.




Re: perl6-language@perl.org

2002-08-01 Thread Graham Barr

On Thu, Aug 01, 2002 at 06:02:14PM -0400, Miko O'Sullivan wrote:
 This is a small collection of ideas for the Perl6 language.  Think of this
 posting as a light and refreshing summer fruit salad, composed of three
 ideas to while away the time during this August lull in perl6-language.
 
 
 
 Give split an option to keep the delimiters in the returned array
 
 I often find that I want to split an expression, but I don't want to get rid
 of the delimiters.  For example, I've been parsing a lot of SQL lately, and
 I find myself needing to split expressions like this:
 
rank=?
 
 It would be really groovy if that expression could be split with the
 delimiters in place, something like this:
 
tokens = split _/[?=*-+]/, $sql, keep='all';

Try using

tokens = split /([?=*-+])/, $sql;

 and get back an array with these values: ('rank', '=', '?')
 
 But that raises a problem: what if the expression is this (note the spaces):
 
rank = ?
 
 In that case I would want the = and ? but I wouldn't want the spaces.  A
 slightly different option could keep just stuff in parens:
 
tokens = split /\s*([?=*-+])\s*/, $sql, keep='parens';

tokens = split /\s*([?=*-+])\s*/, $sql;

already does, in perl 5, what you want.

Graham.




Re: [PRE-RELEASE] Release of 0.0.7 tomorrow evening

2002-07-22 Thread Graham Barr

On Mon, Jul 22, 2002 at 11:14:15AM +0100, Sam Vilain wrote:
 Sean O'Rourke [EMAIL PROTECTED] wrote:
 
  languages/perl6/README sort of hides it, but it does say that If you have
  Perl = 5.005_03, $a += 3 may fail to parse.  I guess we can upgrade
  that to if you have  5.6, you lose.
 
 I notice that DBI no longer supports Perl releases 5.6.  Seems enough
 people are happy that 5.005 is obsolete.

I am not sure I agree with that. I have been met with a lot of resistance
from users todo the same with my modules. Some even still want 5.004,
but thats asking too much IMO.

Graham.




FIRST, BETWEEN, etc.. (was Re: Loop controls)

2002-05-07 Thread Graham Barr

I have been following this thread, but I would just like to inject a summary
of the various related UPPERCASE blocks

 PREExecutes on block entry.
Loop variables are in a known state

 POST   Executes on block exit.
Loop variables are in a known state

 NEXT   Executes on implicit block exit or call to next()
Loop variables are in a known state

 LAST   Executes on implicit loop exit or call to last()
Loop variables may be unknown

And I think this thread is proposing

 FIRST   A PRE block that is executed only on the first itteration
 of the loop

 BETWEEN A PRE block that does not execute for the first iteration
 of the loop.

So FIRST and BETWEEN are just shorthand for

 my $count;
 loop {
   PRE {
 if ($count++) {
   # BETWEEN code here
 }
 else {
   # FIRST code here
 }
   }
 }

Graham.




Re: FIRST, BETWEEN, etc.. (was Re: Loop controls)

2002-05-07 Thread Graham Barr

On Tue, May 07, 2002 at 12:27:08PM -0500, Allison Randal wrote:
 On Tue, May 07, 2002 at 03:15:48PM +0100, Graham Barr wrote:
  
   LAST   Executes on implicit loop exit or call to last()
  Loop variables may be unknown
 
 Not exactly unknown. It's just that, in a few cases, their values may
 have changed by the time the LAST block is executed.

OK, unspecified.

 
  And I think this thread is proposing
  
   FIRST   A PRE block that is executed only on the first itteration
   of the loop
  
   BETWEEN A PRE block that does not execute for the first iteration
   of the loop.
  
  So FIRST and BETWEEN are just shorthand for
  
   my $count;
   loop {
 PRE {
   if ($count++) {
 # BETWEEN code here
   }
   else {
 # FIRST code here
   }
 }
   }
 
 Almost. What people are pushing for is more like:
 
  BETWEEN A NEXT block that does not execute for the last iteration
of the loop.

IMO, it cannot. That is because you cannot always know if you are at
the end of a loop until you have executed the condition. Therefore BETWEEN
would have to be a PRE block.

 This may seem like a trivial difference at first glance, but it's a
 matter of scope. The latter interpretation means that code such as:
 
   for 1..3 - $thing {
   print $thing _ , ;
 
   BETWEEN {
   print $thing _ \n;
   }
   }
 
 Will output:
 1, 1
 2, 2
 3,
 
 Not:
 1, 2
 2, 3
 3,

But consider when this is a while loop, how do you stop BETWEEN being
called before the last iteration.

 Which seems intuitively right. 

Not to me :-)

Graham.




Re: // in Perl 5.8?

2002-05-01 Thread Graham Barr

On Wed, May 01, 2002 at 12:17:52PM -0700, David Wheeler wrote:
 On 5/1/02 12:11 PM, Brent Dax [EMAIL PROTECTED] claimed:
 
  It's far too late to make it into 5.8, but it looks like it'll be in
  5.10 when that comes out (in a year or two).
 
 I figured. Too bad. ;-) A year or two is long time to wait!

Well if the patch maintains binary compatability, I dont
see why it would not go into 5.8.1. But who knows when that will be.

Graham.




Re: // in Perl 5.8?

2002-04-17 Thread Graham Barr

On Wed, Apr 17, 2002 at 01:09:43PM -0700, David Wheeler wrote:
 Anyone know what the chances are that some enterprising C hacker
 can/will/did get the // and //= operator into Perl 5.8? Seems like it
 wouldn't be a huge deal to add, and I'd love to have it sooner rather than
 later.

It is not hard todo. If you look in the archives you can probably find it, although
it will be there as ??

The problem with // is that it already has a meaning and although perl6 will redefine 
it
can we do so in perl5 ? I don't think we can.

Graham.



Re: How to default? (was Unary dot)

2002-04-12 Thread Graham Barr

On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
 Trey Harris [EMAIL PROTECTED] writes:
 
  I think I've missed something, even after poring over the archives for
  some hours looking for the answer.  How does one write defaulting
  subroutines a la builtins like print() and chomp()? Assume the code:
 
for  {
   printRec;
}
printRec Done!;
 
sub printRec {
   chomp;
   print :$_:\n;
}
 
 You could take advantage of subroutine signatures and multi-dispatch
 
 sub printRec() { printRec($_) } # No args, therefore no new topic.
 sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg

Hm, I wonder if

  sub printRec($rec=$_) { ... }

or someother way to specify that the current topic be used
as a default argument, might be possible

Graham.



Re: Unary dot

2002-04-10 Thread Graham Barr

On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
 On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
  method m1
  {
 m2;  # calls method m2 in the same class
 Yes, but does it call it as an instance method on the current invocant
 or as a class method with no invocant?  If the former, how would you
 do the latter?

This may be a case of keep up at the back, but if that is a method call,
how do I call a subroutine from within a method ?

Graham.




Re: Some Apocalypse 4 exception handling questions.

2002-01-23 Thread Graham Barr

On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote:
 I think you just said the same thing I did.  To be more explicit, using
 the terminology you seem to want to use, I'll point out that I was only
 talking about the case of an inherited method, not a _replacement_
 method.  In other words, when you inherit a method, you are taking the
 base implementation for that method.  But if you replace a method, you
 are not inheriting that method, but rather replacing it; yes, the
 replacement method may choose to call the base implementation's method
 as part of the replacement implementation.  When you replace a method,
 you have 2 subroutines, the base implementation, and the replacement
 implementation, but when you inherit a method, you have only 1
 subroutine, which may be called 2 different ways.

But the base class may be just an interface class. And thus by inheriting
the pre conditions you are enforcing the API. So I can see a use for
it, but I can also see where you don't want it too.

Graham.





Re: Apoc4: The loop keyword

2002-01-21 Thread Graham Barr

On Mon, Jan 21, 2002 at 12:50:38PM -0800, Larry Wall wrote:
 : What's the chance that it could be considered so?  
 
 In most other languages, you wouldn't even have the opportunity to put
 a declaration into the conditional.  You'd have to say something like:
 
 my $line = $in;
 if $line ne  { ... }
 
 Since
 
 if my $line = $in { ... }
 
 is Perl shorthand for those two lines, I don't see how one can say that
 the variable is more related to the inside than the outside of the block.
 One can claim that the code after the Cif may not be interested in
 C$line, but the same is true of the block itself!  The conditional
 only decides whether the block runs.  It's not part of the block.

But are we not at risk of introducing another form of

  my $x if 0;

with

  if my $one = ONE {
...
  }
  elsif my $two = TWO {
  }

  if ($two) {
...
  }

Graham.



Re: Apoc4: The loop keyword

2002-01-21 Thread Graham Barr

On Mon, Jan 21, 2002 at 03:58:49PM -0500, Michael G Schwern wrote:
 On Mon, Jan 21, 2002 at 03:43:07PM -0500, Damian Conway wrote:
  Casey wrote:
  
   So you're suggesting that we fake lexical scoping?  That sounds more
   icky than sticking to true lexical scoping.  A block dictates scope,
   not before and not after.  I don't see ickyness about making that so.
  
  Exactly!
  
  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 beginners.
 
 In this case I'll take long-term simplicity over short-term
 easy-to-explain rules.  Otherwise we'll be writing this all over the
 place til Kingdom come.
 
 do {
 if my $foo = bar() {
 ...
 }
 }

If that is what you want then fine. But I have lost count of the number
of times I have wanted to do

  if ((my $foo = bar()) eq 'foo') {
...
  }

  if ($foo eq 'bar') {
...
  }

Personally I really don't see it as a problem.
  
Graham.



Re: Apoc4: The loop keyword

2002-01-21 Thread Graham Barr

On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
 Graham Barr writes:
 : But are we not at risk of introducing another form of
 : 
 :   my $x if 0;
 : 
 : with
 : 
 :   if my $one = ONE {
 : ...
 :   }
 :   elsif my $two = TWO {
 :   }
 : 
 :   if ($two) {
 : ...
 :   }
 
 Then it's just undefined.  It's no different from how , ||, or ??::
 work when you put a declaration in something that's conditionalized.

Right. So we need to make sure that the implementation does that. In Perl5
my has a runtime part, so if it is not actually run then the lexical
can hold the value of the previous time it was executed.

Graham.



Re: Apoc4: The loop keyword

2002-01-21 Thread Graham Barr

On Mon, Jan 21, 2002 at 01:38:39PM -0800, Larry Wall wrote:
 Graham Barr writes:
 : On Mon, Jan 21, 2002 at 01:01:09PM -0800, Larry Wall wrote:
 :  Graham Barr writes:
 :  : But are we not at risk of introducing another form of
 :  : 
 :  :   my $x if 0;
 :  : 
 :  : with
 :  : 
 :  :   if my $one = ONE {
 :  : ...
 :  :   }
 :  :   elsif my $two = TWO {
 :  :   }
 :  : 
 :  :   if ($two) {
 :  : ...
 :  :   }
 :  
 :  Then it's just undefined.  It's no different from how , ||, or ??::
 :  work when you put a declaration in something that's conditionalized.
 : 
 : Right. So we need to make sure that the implementation does that. In Perl5
 : my has a runtime part, so if it is not actually run then the lexical
 : can hold the value of the previous time it was executed.
 
 Well, true enough.  Perhaps undefined is too meaningful.  We could
 borrow a phrase from Ada culture and just call it erroneous.

Either that, or instead of my having a runtime element, we just initialize
all lexicals at the start of the block in which they are declared. So the
initialize step is not controlled by runtime effects.

I guess whether or not this (bug?) arises again depends on how parrot
implements lexicals.

Graham.




Re: [A-Z]+\s*\{

2002-01-20 Thread Graham Barr

On Sun, Jan 20, 2002 at 05:29:39AM -0800, Damian Conway wrote:
 On Saturday 19 January 2002 22:05, Brent Dax wrote:
   Is this list of special blocks complete and correct?
 
 Close and close. As of two days ago, Larry's thinking was:
 
   BEGIN   Executes at the beginning of compilation
   CHECK   Executes at the end of compilation
   INITExecutes at the beginning of run
   END Executes at the end of run
   PRE Executes at block entry.
   Inherited if block is a method. No side-effects 
allowed.
   POSTExecutes at block exit.
   Inherited if block is a method. No side-effects 
allowed.
   NEXTExecutes on (explicit or implicit) call to next()
 within current block

If a POST is inside a loop, is it executed at the end of each iteration
or only when the loop exits ?

If it is only when the loop exits, will it be possible to designate
a block to be multiple (eg both POST and NEXT)

Graham.

   CATCH   Executes on exception within current block
   LASTExecutes on any form of block exit. 
   Not inherited (c.f. POST), even if block is a method. 
   Side-effects allowed.
   KEEPSpecialized form of CATCH.
   Executes on control exception in the current block
   UNDOSpecialized form of CATCH.
   Executes on non-control exception in the current 
block
 
 Damian
 
 



Re: Apropos of nothing...

2001-12-13 Thread Graham Barr

On Fri, Dec 14, 2001 at 06:39:02AM +1100, Damian Conway wrote:
 
 In the following code fragment, what context is foo() in?
 
 @ary[0] = foo()
 
 Scalar context. @ary[0] is a single element of @ary.
 
 To call foo() in list context use any of the following:
 
   (@ary[0]) = foo();  # Assign @ary[0] the first element returned
   @(@ary[0]) = foo(); #
   @ary[@(0)] = foo(); #
   @ary[0,] = foo();   #
   @ary[[0]] = foo();  #
 
   @ary[0] = @(foo()); # Assign @ary[0] a ref to the elems returned
   @ary[0] =()= foo(); #   

Hm, thats a change from perl5. In perl5 that would assign the number of
elements returned from foo(). Is there a good reason for this change ?

Graham.

   @ary[0] = [foo()];  #   
 
 Damian



Re: flex perl mess

2001-10-24 Thread Graham Barr

On Wed, Oct 24, 2001 at 09:06:14AM -0400, Aaron Sherman wrote:
 On Tue, Oct 23, 2001 at 02:53:19PM +0200, Nadim Khemir wrote:
 
   Don't we already have that in Perl 5?
  
 if ( /\G\s+/gc ) {# whitespaces   }
  elsif ( /\G[*/+-]/gc )  { # operator   }
  elsif ( /\G\d+/gc )  {# term   }
  elsif ( /\G.+/gc )  { # unrecognized token   }
  
   Tad McClellan
  
  The answer is NO, regexes and a lexer are totally different. I would
  recommend Tad to study a bit more what parsing is before thinking  it's jut
  about writing regexes. Having a lexer allows perl do some kind of text
  processing (raw lexing and parsing) at a much faster. If it is of some
  interest I could benchmark a simple example.
 
 So, aren't you saying, yes, but it would be slow? I can't think of
 anything a lexer is capable of that I can't (and probably haven't) done
 in Perl with relative ease.
 
 Now, if you want a PARSER, that's a different matter, but a simple
 lexical scanner is trivial to write in Perl with logic and regular
 expressions.
 
 In terms of speed, this is particularly ideal because you can identify
 what parts of your Perl code slow the lexer down, and re-code those
 using C/XS. The best of all 2,384 worlds... that's Perl!

I have always found that the perl output from byacc (with a few tweaks)
generates a sufficient parser. The addition of a switch statement
will hopefully make it more efficient.

For a lexer I try to use a single regex with /g, but that does require the
text being parsed to be all in a single scalar. Although that could be
worked around if needed.

For an example, take a look at Convert::ASN1

Graham.



Re: Per-object inheritance in core a red herring?

2001-07-02 Thread Graham Barr

On Fri, Jun 29, 2001 at 08:59:59AM -0400, John Porter wrote:
 Michael G Schwern wrote:
  Second, and perhaps more importantly, we can do this perfectly well
  with a module.  No hacks, no tricks, no filters.
  Class::Object uses the mini-class technique (ie. auto-generated
  classes 
 
 Sorry, that sounds like a hack/trick if ever there was one.
 I would sure hope there would be a cleaner way to do it in
 perl6, if it's not part of the core language.

Maybe, but I think it is the way to do it, even if it is behind
the scenes.

My reason for that is method lookup. Right now we use the package (class)
stash as a cache so we don't have to search @ISA for every method call.
But if there is a case where not all objects that inherit from a given class
have the same superclasses, you cannot do this. This means that we will either
burn a lot more memory for the caches or method lookup will take longer.

 It's also not without its faults.  Having every instance of a
 class have different values of ref() could be obnoxious, for
 example.

That could be preserved by the object holding a pointer to it's blessed
stash and its method stash, which for the most case will be the same.

Graham.



Re: Coupla Questions

2001-06-12 Thread Graham Barr

On Mon, Jun 11, 2001 at 10:39:51PM -0500, David L. Nicol wrote:
 Hopefully, we'll get a with operator and everything:
 
   with %database.$accountnumber {
 
   .interestearned += $interestrate * .balance
 
   }
 
 anything short of that, in my opinion, is merely trading old ugly for
 new ugly.

Now I may be wrong here, but I thought I remembered something about

  .foo being the same as $_.foo 

In which case you could do

for (%database.$accountnumber) {
 
.interestearned += $interestrate * .balance
 
}

Graham.



Re: suggested properties of operator results

2001-06-11 Thread Graham Barr

On Mon, Jun 11, 2001 at 01:34:49AM -0700, Chris Hostetter wrote:
 
 For the record, bwarnock pointed out to me that damian allready proposed
 this behavior in RFC 25...
 
   http://dev.perl.org/rfc/25.html
 
 That RFC doesn't suggest having the comparison operators set properties
 on their result -- instead it recomends that multiple chained comparisons
 should be automagically expanded to the equivalent binary conjunction.
 ... I think I like his way better.  Mainly because I didn't consider the
 ramifications of scenerios like this...
 
$input = 4;
$bool = $input  22;# $bool = 1 is valueR(22)
print ok! if $bool == 1;  # whoops, '==' is looking at $bool.valueR

Well perhaps   $input  22   should yield  22 is true

Graham.



Re: Coupla Questions

2001-06-07 Thread Graham Barr

On Thu, Jun 07, 2001 at 08:15:46AM +0100, Simon Cozens wrote:
 On Wed, Jun 06, 2001 at 07:21:29PM -0500, David L. Nicol wrote:
  Damian Conway wrote:
   $ref.{a}can be  $ref{a}
  which can also be
  $ref.a
 
 Dereferencing a hashref is the same as accessing a property?

IIRC there was some suggestion of a class being able to declare
elements to be accessable as methods in this was.

So if $ref is of a known type and 'a' was declared in that way,
the parser would take $ref.a and turn it into $ref.{a}

This would have the benefit of not loosing encapsulation and
also the performance of not having to call a method which would
just look like

  sub a(Foo $self) :lvalue { $self-{a} }

(Did I get that syntax right ? probably not :)

Graham.



Re: Coupla Questions

2001-06-06 Thread Graham Barr

On Thu, Jun 07, 2001 at 06:37:26AM +1000, Damian Conway wrote:
 
 So, to match $foo's colour against $bar, I'd say
 
 $bar =~ /$foo.colour/;
 
 No, you need the sub call parens as well:
 
  $bar =~ /$foo.colour()/;

Hm, I thought Larry said you would need to use $() to interpolate
a method call. So this would be


  $bar =~ /$($foo.colour)/;

Graham.



Re: Coupla Questions

2001-06-06 Thread Graham Barr

On Thu, Jun 07, 2001 at 07:43:55AM +1000, Damian Conway wrote:
 
  So, to match $foo's colour against $bar, I'd say
  
  $bar =~ /$foo.colour/;
  
  No, you need the sub call parens as well:
  
   $bar =~ /$foo.colour()/;
 
 Hm, I thought Larry said you would need to use $() to interpolate
 a method call. So this would be
 
   $bar =~ /$($foo.colour)/;
 
 That was not my understanding. At least not for (pseudo-)method calls.

But with the above you still have abiguity, for example what does this do

 $bar =~ /$foo.colour($xyz)/;

I may be remembering about interpolation into strings as $file.ext is
going to be common. But I do think the $() approach is clean and
unambiguous

Graham.



Re: Coupla Questions

2001-06-06 Thread Graham Barr

On Thu, Jun 07, 2001 at 07:59:31AM +1000, Damian Conway wrote:
 But with the above you still have abiguity, for example what does this do
 
  $bar =~ /$foo.colour($xyz)/;
 
 Looks like a method call with parens, so *is* a method call with parens.
 

 I may be remembering about interpolation into strings as $file.ext is
 going to be common. But I do think the $() approach is clean and
 unambiguous
 
 I agree wholeheartedly. 

Good.

 But it's not as *convenient* as unadorned interpolation.

Sometimes convenient has to give way

 Expecially if we expect method calls to be frequently interpolated.

I don't hear people screaming because it's difficult in perl5, so I doubt
it will be very frequent. But even the $() is easier than the current
perl5 way to do it.

Graham.



Re: Coupla Questions

2001-06-06 Thread Graham Barr

On Wed, Jun 06, 2001 at 04:01:24PM -0700, Larry Wall wrote:
 [EMAIL PROTECTED] writes:
 : What should $foo = (1,2,3) do now? Should it be the same as what 
 : $foo = [1,2,3]; did in Perl 6? (This is assuming that $foo=@INC does what
 : $foo = \@INC; does now.) Putting it another way: does a list in scalar
 : context turn into a reference, or is it just arrays that do that?
 : 
 : Just arrays, I believe.
 
 That hasn't actually been decided yet.  There are good arguments on
 both sides.

Can someone post a few ? I am open to what are the pros/cons
but right now my mind is thinking  Whats the benefit of making
$a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
different, ie what it does in perl5

Graham.




Re: Coupla Questions

2001-06-06 Thread Graham Barr

On Thu, Jun 07, 2001 at 01:17:45AM +0100, Simon Cozens wrote:
 On Thu, Jun 07, 2001 at 12:24:50AM +0100, Graham Barr wrote:
  Can someone post a few ? I am open to what are the pros/cons
  but right now my mind is thinking  Whats the benefit of making
  $a=(1,2,3); be the same as $a=[1,2,3];  when it could do something
  different, ie what it does in perl5
 
 A reason against making the behaviours ($foo=array vs. $foo=list)
 different would be that you're then making lists and arrays more
 distinct than necessary. Does this make $foo a reference, or the number
 of elements:

But if you change () consider, how do you do 

  $min = (localtime(time))[1];

and if () creates a reference what does

  $x = (1 + 2) * 3;

it's still () in a scalar context.

IIRC when Larry covered this, he did not suggest changing (), but changing the meaning
of the , in the scalar context.

() is a grouping contruct, not a list generator.

Graham.




Re: properties

2001-05-22 Thread Graham Barr

On Tue, May 22, 2001 at 12:29:33PM +1000, Damian Conway wrote:
 if so, then wouldn't it be safer to put properties inside a special object
 associated with each object (the 'traits' object) so there would be little
 namespace collision?
 
 We actually want the possibility of that kind of namespace collision:
 for polymorphism.

Many people keep bringig this up as a confusion and you give the same reply.

However there has not yet, AFAIK, been any description of how having a method
overload a property is useful.

If there is some compelling reason that this is a must, then fine. But many
people seem to be finding this a point of confusion.

Personally I don't see that the gain is greater than the confusion. I would
rather see properties be accessed via a different operator other than dot (.)

If a class wants to manipulate a property via a method they still can, the user
just has to call the method instead of accessing the property directly

With the current approach I can see most code accessing properties with $var.prop{name}
because they want to make sure they get the property and not a method, whereas
it would be shorter, in the common case, to have something like  $var'name

Graham.



Re: properties

2001-05-21 Thread Graham Barr

On Sun, May 20, 2001 at 01:24:29PM +0100, Simon Cozens wrote:
 On Sun, May 20, 2001 at 12:46:35AM -0500, Jonathan Scott Duff wrote:
  my $a is true = 0;  # variable property
  my $a = 0 is true;  # variable property
  my ($a) = 0 is true;# value property
 
 Wow. Totally ETOOCONFUSING.

That has been exactly my thought as I have been reading this thread.

I have been trying to think what properties would make sensible variable
or value properties.

So far all I can think of for variable properties are actually compile time
properties like constant etc.

So I am left wondering how much of an issue this really will be ?

Graham.



Re: properties

2001-05-21 Thread Graham Barr

On Sun, May 20, 2001 at 06:19:35PM -0400, Uri Guttman wrote:
  DC == Damian Conway [EMAIL PROTECTED] writes:
 
 
   DC return undef Because($borked);
 
 hmm, that is poor code as returning a real undef will break in a list
 context.

I always balk when I see someone say that. This is perfectly valid thing todo.
If the sub is defined to return a single scalar value then Creturn; is
the WRONG thing todo as it will cause problems if the result is used directly
into a list.

 so how would a value property be attached passed back to an
 empty list? what happens below:

Thats a good point. But on the other hand an empty list is neither
a variable or a value. You are returning nothing, so there is nothing
to attach it too.

But with the ability to return arrays in perl6 you should probably return
an empty array with a property attached.

   perm_props( $foo, 'SortCode' ) = 'ST' ;
 
 the last one assigns the prop value with an lvalue call.

If perm_props returns a hash, then you could also do

perm_props( $foo ){'SortCode'} = 'ST' ;

Graham.




Re: 'is' and action at a distance

2001-05-19 Thread Graham Barr

On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
  print keys $foo.prop;   # prints NumberHeard
  print values $foo.prop; # prints loneliestever

This is an example of one of my concerns about namespace overlap
with methods. What would happen if there was a method called prop ?
Have we basically said that there cannot be a method called prop ?

Personally I would rather see something other than . for accessing
properties. As things stand the functionality of a working
program can be completely changed/broken by defining a sub that
conflicts with a property.

Graham.



Re: 'is' and action at a distance

2001-05-19 Thread Graham Barr

On Sat, May 19, 2001 at 06:41:29PM +1000, Damian Conway wrote:
 
 Graham wrote:
 
 On Fri, May 18, 2001 at 10:36:59PM -0400, John Siracusa wrote:
   print keys $foo.prop;   # prints NumberHeard
   print values $foo.prop; # prints loneliestever
 
 This is an example of one of my concerns about namespace overlap
 with methods. What would happen if there was a method called prop ?
 Have we basically said that there cannot be a method called prop ?
 
 No, we have basically said that there cannot be a method called prop if you
 want to access the object's properties through its prop property.

Which mean that any class which defines a method prop, prevents any user
from determining the properties of any of its object instances.

I am not saying that this is a bad thing, but it will need to be docuemnted
that doing this has such consequences. Unless there is another syntax
for determining all the properties of a value.

 Personally I would rather see something other than . for accessing
 properties. As things stand the functionality of a working
 program can be completely changed/broken by defining a sub that
 conflicts with a property.
 
 Er...yes...that's rather the point of the exercise: to be able to
 polymorphically override the behaviour of properties by defining
 methods.

I am just not conviced that it is a good thing todo. methods and properties
are different things.

Graham.




Re: 'is' and action at a distance

2001-05-18 Thread Graham Barr

On Fri, May 18, 2001 at 03:01:38PM +1000, Damian Conway wrote:
 Also, what's the difference between a 'property' and an
 'attribute', ie, are:
 
$fh is true;
 
 and 
 
$fh.true(1);
 
 synonyms?
 
 No. The former means:
 
 Set the true property to 1 and return an alias to $fh
 
 The latter means:
 
 Attempt to call the Ctrue method of $fh. If there is no such
  method, set the true property to 1 and return that value

This is something that concerns me. There is no real separation between
methods and properties. I can see it causing problems due to them sharing
namespaces. But I have not thought about it enough to say how much of a concern.

Graham.



Re: 'is' and action at a distance

2001-05-18 Thread Graham Barr

On Fri, May 18, 2001 at 08:31:21AM -0500, Jarkko Hietaniemi wrote:
 On Fri, May 18, 2001 at 06:22:10AM -0700, Austin Hastings wrote:
  
  --- Damian Conway [EMAIL PROTECTED] wrote:
   
   It's probably just a matter of coding what you actually mean. 
   In Perl 5 and 6 your version means if $fh is true in *any* 
   possible way..., whereas you seem to want if $fh is defined,
   which is:
  
  Hmm. I can easily see this producing incomprehensible code when spread
  across large systems. To wit, those developers used to 0 means false
 
 Any feature is incomprehensible if one is not used to it.  Pointers
 in C are incomprehensible if one has never met the concept before.

Right, consider overloading.

 As far as I understand one rationale behind the false (in Perl 5 terms)
 but true (in Perl 6 terms) is that you can write code like this
 
   if ($retval = func(@args)) {
   # it worked ...

Right. Which of course can be done in Perl 5 with either 0 but true (or 0E0)
or if the value is an object, the use of overloading.

Graham.




Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 12:32:37PM -0500, Me wrote:
  an ordered hash is common
 
 Arrays too.
 
 
  not wise ... to alter features just for beginners.
 
 Agreed.
 
 
  (PS  11 people isn't a statistic, its a night at the pub)
 
 Your round...
 
 
 The extra complexity of a separate hash syntax might
 be justified for other reasons, but not the ones given.

Hm, OK. What does this access and using what method ?

  $foo = '1.2';
  @bar[$foo];

Does it access the hash element 1.2 or the array element 1 ?

Its not obvious and you cannot depend on what is in $foo, $foo = 1.2
should give identical results. and having to write

  @bar[$foo] or @bar[int $foo]

is worse than what we have now. And solving this by saying that
each variable must be declared to be hash or array does not help
much as it moves the distinction from where it is useful to the
reader to somewhere out of site.

Having different brackets for accessing array or hash actually does
help when reading code. Using the same is just adding unnecessary
complexity

Graham.



Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
  Hm, OK. What does this access and using what method ?
  
$foo = '1.2';
@bar[$foo];
 
 This is an argument against conflating @ and %.

No it is not.

 It has nothing to do with using [] instead of {}.

Yes it does. I was asking if the above is equivalent to

  $bar[$foo]  or  $bar{$foo}  in todays perl.

  Having different brackets for accessing array or hash
  actually does help when reading code. Using the same
  is just adding unnecessary complexity
 
 I can't tell if you mean this as a summary of your
 earlier points, in which case please note response
 above, or a separate point. If it is a separate point,
 you don't say why, so, why?

I mean exactly what it says. Not using [] instead of {}
actually helps with readability.

Graham.



Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 03:23:56PM -0400, Buddha Buck wrote:
 At 08:10 PM 05-14-2001 +0100, Graham Barr wrote:
 On Mon, May 14, 2001 at 01:56:01PM -0500, Me wrote:
Hm, OK. What does this access and using what method ?
   
  $foo = '1.2';
  @bar[$foo];
  
   This is an argument against conflating @ and %.
 
 No it is not.
 
   It has nothing to do with using [] instead of {}.
 
 Yes it does. I was asking if the above is equivalent to
 
$bar[$foo]  or  $bar{$foo}  in todays perl.
 
 What is the meaning of the following four expressions in Perl6?
 
 @bar[$foo]; # A
 %bar{$foo}; # B
 @bar{$foo}; # C
 %bar[$foo]; # D
 
 You seem to be advocating A and B, Me is advocating A and D.
 
 Why is one set better than the other?

You forgot

 $bar[$foo]; # $bar is an array reference
 $bar{$foo}; # $bar is a hash reference

Graham.



Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 03:41:24PM -0400, John Porter wrote:
 Damian Conway wrote [and John Porter reformats]:
   
  @bar[$foo]; # Access element int($foo) of array @bar
  %bar{$foo}; # Access entry $foo of hash %bar
  @bar{$foo}; # Syntax error
  %bar[$foo]; # Syntax error
 
 And why is that superior to:
 
   @bar[$foo]; # Access element int($foo) of array @bar
   %bar{$foo}; # Syntax error
   @bar{$foo}; # Syntax error
   %bar[$foo]; # Access entry $foo of hash %bar

As I said in another mail, consider

  $bar[$foo];
  $bar{$foo};

Graham.



Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 03:58:31PM -0400, John Porter wrote:
 Graham Barr wrote:
  As I said in another mail, consider
$bar[$foo];
$bar{$foo};
 
 But if @bar is known to be one kind of array or
 the other, where is the ambiguosity that that is
 meant to avoid?

I did not say it was avoiding ambuguity, I said it helped
with readability when $foo held something like 1.2

But I really think this thread is going no where.

Is there REALLY a benefit in changing things to use only []
or is this change for the sake of change.

And rememeber this is still perl, so why change something unless
it gains extra benefit.

Graham.



Re: what I meant about hungarian notation

2001-05-14 Thread Graham Barr

On Mon, May 14, 2001 at 02:51:08PM -0500, Me wrote:
  survey ? I never saw any survey, 
 
 It was an informal finger-in-the-wind thing I sent to
 a perl beginners list. Nothing special, just a quick
 survey.
 
 http://www.self-reference.com/cgi-bin/perl6plurals.pl

As someone else pointed out (I forget who). But beginners are not
always the best people to ask. Beginner don't stay beginners for
long I think the quote was.

Graham.



Re: what I meant about hungarian notation

2001-05-09 Thread Graham Barr

On Wed, May 09, 2001 at 02:04:40PM -0400, John Porter wrote:
 Simon Cozens wrote:
  A scalar's a thing. 
 
 Just as the index into a multiplicity is a thing.

Yes, but as Larry pointed out. Knowing if the index is to be treated
as a number or a string has some advantages for optimization

Graham.



Re: Apoc2 - Context and variables

2001-05-07 Thread Graham Barr

On Mon, May 07, 2001 at 05:35:53PM -0400, John Porter wrote:
 Edward Peschko wrote:
  If 
  %a = @b;
  does 
  %c = map{ ($_ = undef ) }  @a;
 
 Yep... particularly considering something neat like
 
   keys(%a) = @b;

And what is wrong with

  @a{@b} = ();

which I use all the time. But I guess in perl6 that would
be written as

  %a{@b} = ();

Graham.



Re: Apoc2 - STDIN concerns

2001-05-05 Thread Graham Barr

On Fri, May 04, 2001 at 07:56:39PM -0700, Larry Wall wrote:
 Nathan Wiger writes:
 :  : This one. I see a filehandle in *boolean* context meaning read to $_,
 :  : just like the current while (FOO) magic we all know and occasionally
 :  : love. I'd expect $FOO.readln (or something less Pascalish) to do an
 :  : explicit readline to a variable other than $_
 : 
 :  It would be $FOO.next, but yes, that's the basic idea.  It's possible
 :  that iterator variables should be more syntactically distinquished than
 :  that.  One could, I suppose, make up something about $FOO or $FOO
 :  meaning the same thing thing as $FOO.next, for people who are homesick
 :  for the angles, but I haven't thought that out, and don't even dare to
 :  mention it here for fear someone will take it as a promise.  Er, oops...
 : 
 : So, just to clarify, the thought is:
 : 
 :print while ($FOO);# like Perl 5 FOO
 :$var = $FOO.next;  # like Perl 5 $var = FOO;
 : 
 : I assume that this is indicative of a more general iterator syntax, and
 : subject to indirect objects?
 : 
 :$FH = open $file or die Can't open $file: $!;
 :$line = next $FH;
 : 
 : If so, I can live with that.
 
 Yes, that's the reason it's Cnext, and not something more specific
 like Creadline, which isn't even true in Perl 5 when $/ is mungled.
 
 We do have to worry about the Cnext loop control function though.

I don't know. If it had to be written as  $FH.next then there
should be no ambiguity.

Graham.



Re: Apoc2 - STDIN concerns

2001-05-05 Thread Graham Barr

On Sat, May 05, 2001 at 02:46:46AM +0100, Michael G Schwern wrote:
 On Fri, May 04, 2001 at 04:42:07PM -0700, Nathan Wiger wrote:
  I'm wondering what this will do?
  
 $thingy = $STDIN;
  
  This seems to have two possibilities:
  
 1. Make a copy of $STDIN
  
 2. Read a line from $STDIN
 
 While perhaps inconsistent, I'd really rather it did #2.  Here's the
 basic argument... compare how often you dup a filehandle with how
 often you read from one.  Duping is swamped by several orders of
 magnitude.  Dup with $fh = $STDIN.copy; (or whatever).  $line =
 $STDIN.next should still work normally.

How would you pass a handle to a subroutine, or store it inside
a hash or array ?

sub my_read {
  my $fh = shift; # whoops
}

I don't think it should do a dup(), but we do need to pass file handles around

Graham.



Re: Please make last work in grep

2001-05-02 Thread Graham Barr

On Wed, May 02, 2001 at 11:10:22AM +0100, Michael G Schwern wrote:
 On Wed, May 02, 2001 at 11:13:13AM +0200, Alexander Farber (EED) wrote:
  I would like to propose adding the last statement
  to the grep, which currently doesn't work:
 
 For the record, I have no problem with this. :)
 
 
maas34: perl -e 'grep { print and $_ == 3 and last } (1,2,3,4,5)'
123
Can't last outside a loop block at -e line 1.
  
  This way it would be possible to use such constructs:
 
 FYI, its not hard to write a routine to do just that...
 
 first { some_condition } @stuff;

See List::Util in perl-current

=item first BLOCK LIST

Similar to Cgrep in that it evaluates BLOCK setting C$_ to each element
of LIST in turn. Cfirst returns the first element where the result from
BLOCK is a true value. If BLOCK never returns true or LIST was empty then
Cundef is returned.

$foo = first { defined($_) } @list# first defined value in @list
$foo = first { $_  $value } @list# first value in @list which
  # is greater than $value


Graham.



Re: Please make last work in grep

2001-05-02 Thread Graham Barr

On Wed, May 02, 2001 at 04:30:07PM +0100, Michael G Schwern wrote:
 On Wed, May 02, 2001 at 08:05:29AM -0700, Larry Wall wrote:
  Michael G Schwern writes:
  : (grep {...} @stuff)[0] will work, but its inelegant.
  
  It's inelegant only because the slice doesn't know how to tell the
  iterator it only needs one value.  If it did know, you'd call it
  elegant.  :-)
 
 I'd call it Haskel!  I've just installed it and have been skimming the
 docs.
 
 Would be neat if:  my($first) = grep {...} @list;  knew to stop itself, yes.

Yes. This could probably fall out of the suggestion that wantarray (or want)
return how many elements are wanted in a list context

Graham.



Re: Please make last work in grep

2001-05-02 Thread Graham Barr

On Wed, May 02, 2001 at 12:01:24PM -0400, Uri Guttman wrote:
  GB == Graham Barr [EMAIL PROTECTED] writes:
 
   GB On Wed, May 02, 2001 at 04:30:07PM +0100, Michael G Schwern wrote:
On Wed, May 02, 2001 at 08:05:29AM -0700, Larry Wall wrote:
 Michael G Schwern writes:
 : (grep {...} @stuff)[0] will work, but its inelegant.
 
 It's inelegant only because the slice doesn't know how to tell the
 iterator it only needs one value.  If it did know, you'd call it
 elegant.  :-)

I'd call it Haskel!  I've just installed it and have been skimming the
docs.

Would be neat if:  my($first) = grep {...} @list;  knew to stop itself, yes.
 
   GB Yes. This could probably fall out of the suggestion that wantarray
   GB (or want) return how many elements are wanted in a list context
 
 provided the list was literal. if it is created via a function or an
 expression then you have to pass the laziness and wantarray count up the
 line, etc. i don't know if we (or larry) wants to make all code have a
 maximum iteration/count value implicitly passed into them and have such
 lazy evaluation at all times.

wantarray-ness is already passed along the call stack today. Thats
the whole point of it. So what is the difference in passing a number
instead of a boolean ?

How this cooperates with lazy is a different matter entirely.

Graham.



Re: Please make last work in grep

2001-05-02 Thread Graham Barr

On Wed, May 02, 2001 at 06:29:51PM +0200, Bart Lateur wrote:
 On Wed, 2 May 2001 17:05:31 +0100, Graham Barr wrote:
 
 wantarray-ness is already passed along the call stack today. Thats
 the whole point of it. So what is the difference in passing a number
 instead of a boolean ?
 
 Because you might have a wantarray situation that expects no values?
 
   () = whateveryouwant();

I am sure that situation is handled by the 'want' RFC. I have not
read it recently, but I suspect in this case want('LIST') would
return that magical 0 but true or something similar.

 You can always expect one more than is on the LHS.
 
 How is this currently handled with split()?

split is special cased when it's assignment is directly to a list
of known length. The current perl does not pass wanted list lengths
around.

Graham.



Re: Lvaluability

2001-04-28 Thread Graham Barr

On Sat, Apr 28, 2001 at 03:11:08AM +0100, Simon Cozens wrote:
 substr($foo, 1, 3) = hi!; # We all know this.
 splice(@foo, 1, 3) = @bar;  # But the lack of this seems asymmetric

An originally we had

  splice(@foo, 1, 3, @bar);

but not

  substr($foo, 1, 3, hi!);

which are more useful, IMO, as they return what was replaced. Where
the assignment version returns what was assigned.


 $baz = $foo.bar;# Surely this is just overloaded . being a
 # subroutine in $foo's package called with a
 # bareword --- $foo-concat(bar)

 $foo.bar = $baz;# sub concat :lvalue { ... }

I will leave those :)

 $#array = 10;   # We can currently change an array's length
 length($scalar) = 10;   # But not this?

and we have keys(%hash) = 10 to set the number of buckets in the hash

 -s $filename = 0;   # calls trunc()
 -M $filename = 0;   # calls utime()
 
 #(And now, over to Abigail...)
 $_ = foobar;
 /foo/  = baz; # Now $_ = bazbar
 /ba./g = one two; # Now $_ = onetwo, using Larry's new  qw

I don't remember seeing anything about  as qw, can you give me a reference

 # Oh, why stop there?
 /../g  = sub { ... }# Calls the sub 3 times, replacing each pair of
 # characters with the return value.

I was going to respond to the lines above with do we need another way to do s///
but this one would probably make it an advantage. Or is this the same as s/../foo()/ge 
?

Graham.



Re: a modest proposal Re: s/./~/g

2001-04-26 Thread Graham Barr

On Thu, Apr 26, 2001 at 03:35:24AM +, Fred Heutte wrote:
 Bart Lateur's response summarizes well what I've heard so far
 from responses both to the list and privately:
 
 (1) Yes,  ~  *is* somewhat used in its current role as the bitwise
 negation (complement) operator.
 
 (2) No, that doesn't appear to overlap my proposal for its use
 as a successor to  -  as now used.

You don't get it.

We are not looking for a single char to replace -

We WANT to use .

Graham.



Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-25 Thread Graham Barr

On Wed, Apr 25, 2001 at 06:46:20PM +0100, Simon Cozens wrote:
 On Mon, Apr 23, 2001 at 12:59:54PM -0700, Nathan Wiger wrote:
   Doesn't ~ look like a piece of string to you?  :-)
  It looks like a bitwise op to me, personally.
 
 That's because every time you've used it in Perl, it's been a bitwise
 op. Sapir-Whorf, and all that.

Not just Perl. Many other languages use ~ the same as Perl
does now.

Graham.



Re: a modest proposal Re: s/./~/g

2001-04-25 Thread Graham Barr

On Wed, Apr 25, 2001 at 06:19:40PM +, Fred Heutte wrote:
 It seems to me that ~ relates to forces (operators, functions and methods)
 more than to atoms (scalars), so to speak.  It's the curve of binding Perl
 at work here.
 
 So why not leave  .  alone and have  ~  substitute for  -  
 
 $mydsn-Sql($mysqlstmt  . $moresql) ;
 $mydsn~Sql($mysqlstmt  . $moresql) ;
 
 Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?

Yes, I use it a lot. Whether you use it probably depends on the kind of
problems you try to solve with perl.

Graham.



Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-24 Thread Graham Barr

On Mon, Apr 23, 2001 at 05:19:22PM -0700, Larry Wall wrote:

 At the moment I'm leaning toward ^ for concat, and ~ for xor.  That

I think that would lead to confusion too. In many languages ^ is
xor and ~ is a bitwise invert. It is that way in perl now too, so
perl is already quite standard in that area. Changing these just
to get . for - so that we are more standard seems very strange
as you are loosing two standards to gain one.

To be honest though I don't think it is possible to get a single
char concat operator with loosing something else, which is a shame.
It would be good if we could somehow overload + to be both string
and numeric, but I not sure that is possible.

The other choice is not to have a concat operator but instead have
Cconcat LIST, but I guess not many people would like that either.

Graham.



Re: Tying Overloading

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 01:02:50PM +0100, Simon Cozens wrote:
 
 Or we change the concatenation operator.
 

 $a = $b  $c; # Do people really use Perl for bit fiddling?

Yes, all the time.

 $a = $b # $c; /* Urgh */
 
 $a = $b ~ $c; # Mmm!
 
 I like that last one a lot, because it doesn't disturb anything.
 You'd have to alter ~'s precedence so that binary ~ is higher
 than named unary operators. (It's print($a~$b), not print $a (~b).)

I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)

I am thinking that maybe it should be a 2 character operator with at
least one of then being + as + is common in many other languages
for doing concatenation.

Graham.



Re: Tying Overloading

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 02:31:55PM +0200, H.Merijn Brand wrote:
 On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr [EMAIL PROTECTED] wrote:
   $a = $b ~ $c; # Mmm!
   
   I like that last one a lot, because it doesn't disturb anything.
   You'd have to alter ~'s precedence so that binary ~ is higher
   than named unary operators. (It's print($a~$b), not print $a (~b).)
  
  I am not sure I do like the use of ~ here. It does not screan concatenate
  to me (but then again neither did . when I started perl)
  
  I am thinking that maybe it should be a 2 character operator with at
  least one of then being + as + is common in many other languages
  for doing concatenation.
 
 like ++ ?

I don't think that would be a good choice. Try translating these statements

  $c = $a.++$b;
  $d = $a++.$b;

Graham.



Re: Tying Overloading

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 12:36:47PM -0400, Dan Sugalski wrote:
 At 02:52 PM 4/23/2001 +0200, Davíð Helgason wrote:
 H.Merijn Brand wrote:
  
 $a = $b ~ $c; # Mmm!

 I like that last one a lot, because it doesn't disturb anything.
 You'd have to alter ~'s precedence so that binary ~ is higher
 than named unary operators. (It's print($a~$b), not print $a (~b).)
   
I am not sure I do like the use of ~ here. It does not screan concatenate
to me (but then again neither did . when I started perl)
   
I am thinking that maybe it should be a 2 character operator with at
least one of then being + as + is common in many other languages
for doing concatenation.
 
 Which of qw[~ ++ +~ + ] do we dislike the least?  Using + would be
 nice, but introduce no end of problems with number/sting behaviour. ''
 is too much like a certain unpopular language. And there was no end to
 the quabbling :(
 
 What's wrong with something like:
 
$foo = $a :+ $b;

I was thinking along those lines too.

In fact it made me think of something Larry said (I think) about operators
operating on whole arrays. So :+ might be the addition of all elements, eg

  @foo = @a :+ @b;

So if a leading : would mean the operator was an array operator, maybe we
could use something else for string operators (say ~). This would also help
disambiguate the difference of  when its operands are numbers or strings
as  would always be for numbers and ~ would be for strings. eg

  $foo = $a + $b;  # addition
  $foo = $a ~+ $b; # concat
  $foo = $a  $b;  # logical and of IVs
  $foo = $a ~ $b; # bitwise and of PVs
  @foo = @a :+ @b; # same as @foo = map { $a[$_] + $b[$_] } for 0..max($#a,$#b);
  @foo = $a :+ @b; # same as @foo = map { $a + $b[$_] } for 0..$#b;

  etc...

Graham.



Re: Tying Overloading

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 11:40:50AM -0700, Larry Wall wrote:
 I do expect that @() and $() will be used for interpolating list and
 scalar expressions into strings, and it is probably the case the $()
 would be a synonym for scalar().  @() would then be a synonym for
 the mythical list() operator.  Which probably, in Perl 6, turns out
 to be equivalent to [...] when used in a scalar context, and a no-op
 in list context.  That is, $() and @() would essentially be typecasts.

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.

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

Graham.



Re: s/./~/g

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 01:16:57PM -0700, Larry Wall wrote:
 Branden writes:
 : I'm starting to be a bit worried with what I'm reading...
 : 
 : 1) Use $obj.method instead of $obj-method :
 : 
 : The big question is: why fix what is not broken? Why introduce Javaisms and 
 : VBisms to our pretty C/C++-oid Perl? Why brake compatibility with Perl 5 
 : code (and Perl 5 programmers) for a zero net gain?
 
 It's not zero net gain, and I'm going to ignore the next person who says it.

I agree it is not a zero net gain. But perhaps it needs to be spelled out
for those who don't see the gain.


Graham.




Re: Tying Overloading

2001-04-23 Thread Graham Barr

On Mon, Apr 23, 2001 at 01:23:43PM -0600, Nathan Torkington wrote:
 Larry Wall writes:
  wanted, you still get the length.  If you're worried about the delayed
  operation, you can force numeric context with $x = +@tmp;, just as you
  can force string context with a unary ~.
 
 How often are you likely to do this?  Speaking as a reader of code,
 I've always hated unary + in that crocky this could be a block or an
 expression sense.  I'd prefer a word operator:
 
   $x = numeric @tmp;

Ig you are going to put a word there, then why not

  $x = length @tmp

or

  $x = @tmp.length

Graham.



Re: Larry's Apocalypse 1

2001-04-06 Thread Graham Barr

On Thu, Apr 05, 2001 at 10:10:47PM +0100, Michael G Schwern wrote:
  Then it might be easier to write modules that are testable without a test
  driver.  If you run the module directly, some distinguished block of code
  could be executed that wouldn't be if the module were "included" via
  "require" or "use" (or similar replacement constructs).
 
 See also SelfTest.pm

I have not looked at SelfTest, but I have always done this with

unless (defined wantarray) {
  # Self Test
}

This works because whenever a file is use'd, require'd etc. it is
evaluated in a scalar context. The main file is in a void context.

Graham.



Re: Larry's Apocalypse 1

2001-04-06 Thread Graham Barr

On Fri, Apr 06, 2001 at 01:31:40PM +0200, Paul Johnson wrote:
 On Fri, Apr 06, 2001 at 10:01:47AM +0100, Graham Barr wrote:
 
  unless (defined wantarray) {
# Self Test
  }
  
  This works because whenever a file is use'd, require'd etc. it is
  evaluated in a scalar context. The main file is in a void context.
 
 Although Gisle's recent patch changes this for "do" at least.

Hm, I did not see that. Can someone explain what the patch changed
or give me a link to the thread.

Graham.



Re: Larry's Apocalypse 1

2001-04-06 Thread Graham Barr

On Fri, Apr 06, 2001 at 03:52:47PM +0100, Simon Cozens wrote:
 On Fri, Apr 06, 2001 at 03:48:11PM +0100, Graham Barr wrote:
   
   Although Gisle's recent patch changes this for "do" at least.
  
  Hm, I did not see that. Can someone explain what the patch changed
  or give me a link to the thread.
 
 @foo = do "you"; 
 now works

Ah OK. So I assume that 

  do "you";

will do the file in a void context

Graham.

 
 -- 
 I will not suffer fools gladly, but I will gladly make fools suffer. -Bimmler
 



Re: Schwartzian Transform

2001-03-28 Thread Graham Barr

On Wed, Mar 28, 2001 at 09:13:01AM -0500, Mark-Jason Dominus wrote:
 
  So you can say
  
use Memoize;
# ...
memoize 'f';
@sorted = sort { my_compare(f($a),f($b)) } @unsorted
  
  to get a lot of the effect of the S word.
 
 Yes, and of course the inline version of this technique is also
 common:
 
@sorted = sort { my $ac = $cache{$a} ||= f($a);
 my $bc = $cache{$b} ||= f($b);
 my_compare($ac,$bc);
   } @unsorted;
 
 Joseph Hall calls this the 'Orcish Maneuver'.

That does have the (slight) disadvantage that if f(x) returns
a false value then f(x) may be called multiple times. Of course
this can be fixed by using exists. It also has the overhead of
computing the hash value of a and b on every itteration

Personally I have found the fastest sort tends to be

  my @f = map { f($_) } @unsorted;
  @sorted = @unsorted[ sort { $f[$a] cmp $f[$b] } 0..$#f ];

Graham.



Re: End-of-scope actions: Background.

2001-02-20 Thread Graham Barr

On Tue, Feb 20, 2001 at 03:49:13AM +, Simon Cozens wrote:
 On Mon, Feb 12, 2001 at 01:58:35PM -0700, Tony Olekshy wrote:
  Hi, it's me again, the guy who won't shut up about exception handling.
  I'm trying,
 
 I'm catching.

And I'm thowing (up :)

Graham.




Re: Autovivification behavior

2000-12-23 Thread Graham Barr

This has been discussed on p5p many many times. And many times
I have agreed with what you wrote. However one thing you did not mention,
but does need to be considered is

  func($x{1}{2}{3})

at this point you do not know if this is a read or write access as
the sub could do $_[0] = 'fred'. If this can be handled in someway
so that the autoviv does not happen until the assignment then OK,
but otherwise I think we would have to stick with perl5 semantics

Also we would probably need a use autoviv pragma so that perl5
scripts which are ported, and rely on the autivivify of hashes,
will still work as before.

Graham.

On Fri, Dec 22, 2000 at 03:26:03PM -0500, Deven T. Corzine wrote:
 Can the autovivication behavior be changed slightly for Perl 6?
 
 Specificly, can we suppress autovivication in read-only circumstances, and 
 evaluate the expression as "undef" immediately instead of autovivicating
 empty data structures that didn't exist before?
 
 The current behavior in Perl 5 is inconsistent.  Attempting to reference a
 hash or array element doesn't normally cause that element to spring into
 existence, but attempting to reference substructures DOES suddenly cause
 that substructure to spring into existence.  This behavior is desirable
 when writing to that substructure, but undesirable when reading from it,
 and inconsistent with the normal behavior of single-level perl structures.
 
 Referencing a nonexistent entry in a hash or array doesn't create that
 entry UNLESS it's autovivified as a reference.  "%x = (); $x{1};" does NOT
 have the same effect as "%x = (1 = undef);"; why does "%x = (); $x{1}{1};"
 have the same effect as "%x = (1 = {});"?  If the programmer has never
 stored any values into %x, it would be reasonable to expect it to remain
 empty; why violate this reasonable expectation just because of an attempted
 reference to a nonexistent structure?



Re: split() ideas

2000-09-28 Thread Graham Barr

On Thu, Sep 28, 2000 at 01:02:11PM -0500, Jonathan Scott Duff wrote:
 I thought I had sent this the other day, but it doesn't appear to have
 made it through...
 
 Here are a couple of ideas that I don't have time to RFC, but some who
 likes them might:
 
 1. Allow the first argument to split() to be a number such that
the string is broken into chunks of that many characters.
 
 2. Allow the first argument to split() to be an array of
numbers, such that split returns a list of strings each as
long as the corresponding number.
 
 Yes, I know this can be done with unpack() or substr(), but that's never
 stopped us before.

Ah, but with them you would need a loop.

One other way would be to allow \G to work in split() so you could do

  @ary = split(/\G(=..)/, $str)

but then we can already do this with

  @ary = $str =~ /\G(..)/sg;

 Note that if #1 is adopted, $foo in "split $foo, $str" will no longer
 really mean "split /$foo/, $str".

Right, and I think that the fact that there are already several ways to
do it, we don't need to add another.

Graham.



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

2000-09-21 Thread Graham Barr

On Wed, Sep 20, 2000 at 10:08:09PM -0700, Glenn Linderman wrote:
 Russ Allbery wrote:
 
  Why on earth would you want to do this in real code?
 
 I wouldn't, of course.  This is just a demonstration that I want both
 semantics available concurrently.

If you are not going to use it, why implement it ?

  I don't believe you actually need both semantics active at the same time;
 
 I do.  Need might be a slightly stronger word than necessary, but "want" and
 "convenience" sure come strongly to mind... the proposals to switch from one
 set of semantics to another just don't cut it for ease of use.

How can you convince anyoone if you say you would not use it. For any feature
enhancement to perl, unless there is a strong case for how it makes
the labguage easier and better it is just not going to happen.

Graham.



Re: RFC 266 (v1) Any scalar can be a hash key

2000-09-21 Thread Graham Barr

On Thu, Sep 21, 2000 at 03:38:50AM -0400, Michael G Schwern wrote:
 On Thu, Sep 21, 2000 at 03:54:27AM -, Perl6 RFC Librarian wrote:
  =head1 IMPLEMENTATION
  
  Dunno. With my vague understanding of the existing code and hash
  tables in general:
 
 I believe the main reason why hash keys can't be references is because
 they're not really scalars.  Internally they're just normal char
 strings IIRC, not SVs.

Sure, but that is just implementation detail.

  I'm sure at one point there were efficiency
 and memory arguments for this, but I don't know if they still hold.

Right. The hash function needs to be fast. If it has to determine
what type of SV it is then maybe call a sub it will be very
much slower.

However, that does not mean that there could not be two different
hash types internally.

No I am not saying that we want to do this, but it should not be impossible.

 The idea of promoting hash keys to true scalars has been knocked out
 before.  I'm sure you can dig up some p5p threads on the subject.

that beacause with the perl5 code base there is only one hash implementation,
so implementing this would have a huge performance hit.

Graham.



Re: Beefier prototypes (was Re: Multiple for loop variables)

2000-09-21 Thread Graham Barr

On Thu, Sep 21, 2000 at 03:38:59AM -0600, Tom Christiansen wrote:
 Could the prototype people please report whether Tim Bunce's issues with 
 prototypes have been intentionally/adequately addressed?
 
 I'm not a prototype person (in fact RFC 128 makes it a hanging offence
 to use that confusing word in connection with parameter lists! ;-)
 Could someone please recapitulate Tim's issues?
 
 The long story is here:
 
 http://www.perl.com/pub/language/misc/bunce.html
 
 The short story includes details that involve how to permit
 
 sub fn($$$)
 
 to work with
 
 fn(@foo)
 
 where @foo==3, which won't be known till runtime.

Well there could be some kind of attribute on the sub to allow
runtime instead of compile time checks.

But it would be nice if

  fn(@foo[0..2])

would actually work instead of getting

Not enough arguments for main::abc at - line 2, near "])"

I know why it does not work, but it seems like it should.

Graham.



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

2000-09-20 Thread Graham Barr

On Tue, Sep 19, 2000 at 10:11:23PM -0700, Nathan Wiger wrote:
undef null
  
$a = undef;   $a = null;
$b = 1;   $b = 1;
$c = $a + b;  $c = $a + $b;
 
$c is 1   $c is null

If you want different semantics for undef then use a pragma, that is
what pragmas are for.

  use tristate;

  $a = undef;
  $b = 1;
  $c = $a + b;

  $c is undef

I did mention this to Larry and his answer was, "you can do anything you
like with pragmas"

However I would suggest that many, including myself, would not like
to see perls values have yet another state of null

Graham.



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

2000-09-20 Thread Graham Barr

On Wed, Sep 20, 2000 at 12:00:05AM -0700, Russ Allbery wrote:
 Perl already has exactly the data value that you're looking for.  This RFC
 is proposing to fix the wrong problem; the things that need to be changed
 (conditionally) are the logical operators, not the data value.

Absolutley, although I would not limit it to just the logical
operators.

Graham.



Re: RFC 262 (v1) Index Attribute

2000-09-20 Thread Graham Barr

On Wed, Sep 20, 2000 at 08:05:20AM -0400, Webmaster wrote:
 David Nicol Wrote in RFC 262:
 foreach $item (@items){
 #print "$item was at location ",$item:n,"\n";
 print "$item was at location ${item:n}\n";
 };
 
 What would really be nice here is an Cindex function, similar to the
 scalar version, that returns the index of the matching entry in a list. For
 instance:
 
 my $n=0;
 foreach (@items){
  print "Found It at position $n!\n" if /$seek/;
  $n++;
 }
 Could be replaced by:
 if (my $n = arrindex( @items, $seek )) {
  print "Found It at position $n!\n" ;
 }

Well if there ever is a way to shortcut grep this could be genera;ized
to

  my $index = grep { break if $_ eq $seek; 1 } @items;

assuming `break' causes the shortcut

An therefore allowing more comparisons than just eq

Graham.



Re: RFC 262 (v1) Index Attribute

2000-09-20 Thread Graham Barr

On Wed, Sep 20, 2000 at 09:03:39AM -0400, Webmaster wrote:
 Graham Barr Wrote:
 Well if there ever is a way to shortcut grep this could be genera;ized
 to
 
   my $index = grep { break if $_ eq $seek; 1 } @items;
 
 Wouldn't this also assume that grep return the number of times the block was
 NOT true,

But in that example the block is always true, thats what the 1 is for.

Graham.



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

2000-09-20 Thread Graham Barr

On Wed, Sep 20, 2000 at 10:00:56AM -0700, Damien Neil wrote:
 On Wed, Sep 20, 2000 at 04:12:09AM -, Perl6 RFC Librarian wrote:
  Add null() keyword and fundamental data type
 
 I think that this is better done as a special overloaded object used

 Incidentally, I'm surprised that DBI hasn't added an option to use
 an overloaded null object, if this feature is in demand.

Probably because of the performance hit it would have.

Graham.



Re: RFC 76 (v2) Builtin: reduce

2000-09-19 Thread Graham Barr

On Tue, Sep 19, 2000 at 07:29:56PM -, Perl6 RFC Librarian wrote:

 This RFC proposes a builtin Creduce function, modelled after Graham Barr's
 Creduce subroutine from builtin.pm

Please refer to List::Util rather than builtin.pm

the module name was changed as many did not like the name builting, as it was not.

Graham.

 In all cases, the elements of the list are lazily evaluated. That is,
 any element of the list that is not a literal value is only evaluated
 when that element is passed to (and actually used by) the reduction
 subroutine.

Should lists be lazy by default ? I would suggest that is a separate
language issue then reduce and reduce should follow what all other
list operators do.

 If the original list has no elements, Creduce immediately throws an
 exception.

What do you mean by exception, die ? No other builtin dies like that at
runtime. Perhaps a return of undef would be more like other operators.

 If the original list has a single element, that element is
 immediately returned (without ever calling the reduction subroutine).
 Otherwise, in a scalar context, the result of the final reduction call
 is the result returned by Creduce. In a list context, a list of all
 the interim values, plus the final value, would be returned.

Um, if it is returning a list then it is not reducing, is it ?

 If the reduction subroutine is ever terminated by a call to Clast, the
 enclosing Creduce immediately returns the last reduction value -- or
 list of partial values -- to that point. If the Clast occurs during
 the first reduction, an exception is thrown.

Again, no other builting currently throws an exception. If throwing an
exception is to become the norm then that should be a separate RFC suggesting
that builtins throw exceptions, but reduce should do what others do.

Graham.




Re: RFC 255 (v2) Fix iteration of nested hashes

2000-09-19 Thread Graham Barr

On Wed, Sep 20, 2000 at 07:06:21AM +1100, Damian Conway wrote:
 This RFC proposes that the internal cursor iterated by the Ceach
 function be stored in the pad of the block containing the Ceach,
 rather than being stored within the hash being iterated.
 
 Then how do you specify which iterator is to be reset when you wish 
 to do that? Currently, you do this by specifying the hash.

 If the iterator is no longer affiliated with the hash, but the opcode node,
 
 Just to note: in version 2 of the RFC, it's associated with the pad of
 the block in which the Ceach appears.

So you are suggesting that the first itteration of the loop reset
the iterator. THis is because currently

  %hash = ( aa = 1, bb = 2);

  while(my($k,$v) = each %hash) { print $k,"\n" }

is no different to

  foreach (1 .. keys %hash) {
while(my($k,$v) = each %hash) {
  print $k,"\n";
  last if $_ == 1;
}
  }

No if the iterator is associated with the scope how do I reset it
so that the itterator always starts at the beginning each time
and not only when it is called after having reach the end on the
previous time

 then what are you going to do?  
 
 The short answer is that there is no "manual" reset of iterators.

Then you loos the ability to exit and reenter a scope continueing where
you left off.

Graham.




Re: RFC 76 (v2) Builtin: reduce

2000-09-19 Thread Graham Barr

On Wed, Sep 20, 2000 at 08:35:20AM +1100, Damian Conway wrote:
 No other builtin dies like that at
 runtime. Perhaps a return of undef would be more like other operators.
 
 That was my original proposal, but it was howled down by the
 mathematical elite, who vigorously insisted that it would break the
 fundamental mathematical properties of the entire Cosmos, leading to
 catastrophic rifts in the timespace continuum. Or something like that.
 Eventually, I gave in.

Well mathematitions need to learn that not everything works in a mathematical
way. Some things are just chaotic by nature.

  If the reduction subroutine is ever terminated by a call to Clast, the
  enclosing Creduce immediately returns the last reduction value -- or
  list of partial values -- to that point. If the Clast occurs during
  the first reduction, an exception is thrown.
 
 Again, no other builting currently throws an exception. If throwing
 an exception is to become the norm then that should be a separate
 RFC suggesting that builtins throw exceptions, but reduce should do
 what others do.
 
 Even at the risk of Destroying the Entire Universe???
 
 What do others think?

Ask me again tomorrow, I might change my mind :)

Graham.



Re: RFC 76 (v2) Builtin: reduce

2000-09-19 Thread Graham Barr

On Tue, Sep 19, 2000 at 04:06:00PM -0600, Tom Christiansen wrote:
 Why not just check @numbers?

Well if the 'use trisate' pragma ever arises (did anyone RFC that ?)

  $a = 1;
  $b = undef;
  $c = $a + $b;

$c is undef, not 1.

Graham.



Re: RFC 223 (v1) Objects: Cuse invocant pragma

2000-09-15 Thread Graham Barr

On Thu, Sep 14, 2000 at 08:10:54PM -, Perl6 RFC Librarian wrote:
 This and other RFCs are available on the web at
   http://dev.perl.org/rfc/
 
 =head1 TITLE
 
 Objects: Cuse invocant pragma
 
 =head1 VERSION
 
   Maintainer: Damian Conway [EMAIL PROTECTED]
   Date: 14 September 2000
   Mailing List: [EMAIL PROTECTED]
   Number: 223
   Version: 1
   Status: Developing
 
 =head1 ABSTRACT
 
 This RFC proposes that, as in Perl 5, the invocant of a method should be
 normally available to the method as $_[0], but that it can be
 automaticaly stripped from @_ and accessed via either a subroutine
 or a variable, using the Cuse invocant pragma.

One of the benefits I was hoping to get from having a variable hold
the invocant is the ability for the invocant to be undef if the sub
was not called as a method. Sadly this proposal does not address that :(

Graham.




Re: Draft RFC: new pragma: Cuse namespace

2000-09-14 Thread Graham Barr

I would suggest that anyone want to contribute to this discussion should
first read the thread about the addition of this pragma to perl5 in
the perl5-porters archives

http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragmaerrors=0case=onmaxfiles=100maxlines=30

Graham.



Re: $a in @b (RFC 199)

2000-09-12 Thread Graham Barr

On Mon, Sep 11, 2000 at 04:41:29PM -0500, Jarkko Hietaniemi wrote:
 Allow me to repeat: instead of trying to shoehorn (or piledrive) new
 semantics onto existing keywords/syntax, let's create something new.
 The blocks of grep/map/... are special.  They are not quite looping
 blocks, they are not quite sub blocks, they are different.  Well, to
 be frank they are just very plain, ordinary, blocks that return their
 last value, but if we want to introduce both flow control
 (short-circuiting) and as a derived requirement, a return value
 (was the last test a success or a failure), they definitely begin to
 become not your ordinary blocks.  I do not think the existing arsenal
 of keywords/syntax is enough to cover all the behaviour we are after.
 The 'pass' keyword someone suggested has potential (when combined with
 allowing last -- and next -- to work on these mongrel blocks).

Also it should be possible for someone to write thier own looping
construct like map/grep as a sub and take advantage of this.

Graham.




Re: RFC 193 (v1) Objects : Core support for method delegation

2000-09-05 Thread Graham Barr

On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
 The proposed delegation mechanism would work via a pragma:
 
   use delegation
   attr1 = [qw( method1 method2 method3 )],
   attr2 = [qw( method4 method5 )],
   attr3 = [],
   attr4 = [],
   # etc.
   ;
 
 This would cause method calls whose names match an element in the first
 list to be delegated to the "attr1" attribute of an object. Likewise,
 calls to a method whose name appears in the second list would be
 forwarded to the "attr2" attribute of the object.
 
 That is, calls like:
 
 $obj-method3(@args);
 $obj-method5(@other_args);

Is this not just a module which creates the necessary subs in the calling
package ? The catchall can be done with an AUTOLOAD sub.

Graham.



Re: Change ($one, $two)= behavior for optimization? (was Re: RFC 175 (v1) Add Clist keyword toforce list context (like Cscalar))

2000-09-05 Thread Graham Barr

On Tue, Sep 05, 2000 at 11:16:48AM +1100, Damian Conway wrote:
 By RFC 21, it looks like the call would be
 
if ( want 'LIST' ) {
   $num_to_return = want;
   # do stuff
}
 
 or, more efficiently:
 
if ( ($num_to_return) = want 'LIST' ) {
   # do stuff
}

And more correct as I would assume that

  () = some_func();

  sub some_func {
if ( ($num_to_return) = want 'LIST' ) {
   # do stuff
}
  }

$num_to_return would be zero, but the assignment would cause the if() to
be true.

Graham.



Re: RFC 189 (v1) Objects : Hierarchical calls to initializersanddestructors

2000-09-04 Thread Graham Barr

On Mon, Sep 04, 2000 at 11:09:18AM +0100, Piers Cawley wrote:
 Damian Conway [EMAIL PROTECTED] writes:
 
  But I've gotta nitpick the name. I wonder if BLESS wouldn't be better?
  print calls PRINT, printf calls PRINTF, even if the subs don't do any
  printing. Sure makes it easier to see what's going on, to me at least.
  
  But BLESS doesn't do blessing. It does set-up. So it's called SETUP. :-)
  
  I'm certainly not averse to a better name -- INIT would be ideal, if it
  weren't already spoken for -- but I think BLESS would be misleading.
 
 How about ONBLESS? Which admittedly suffers from not being a verb, but
 conveys the meaning rather well. I'm not entirely sure I *like* it,
 just tossing out another suggestion.

Given that is happens when bless is called and that all other builtin
methods are anmed after what is being called, not what it is being used
for, then I would say that it should be called BLESS for consistancy reason.

this may seem confusing because you are thinking of one particular use
that you have in mind for this, but in a generic sense it is a method
that is called when bless is called.

Graham.



Re: RFC 175 (v1) Add Clist keyword to force list context (like Cscalar)

2000-09-01 Thread Graham Barr

On Fri, Sep 01, 2000 at 11:23:16AM -0700, Steve Fink wrote:
 I read your message and agree. Not that I liked the idea that much even
 before considering the ramifications. But do you agree that even
 seasoned perlers have trouble anticipating how a list/array is going to
 be converted to a scalar?

I would say the only place this is an issue is when the RHS is the return
of a sub. You may not know if it was  return (1,2,3)  or   return @a
and there seems to be no standard way people document the difference.

 I'd vote for no Clist operator, but for adding a count operator and a
 last element operator. I suggest ()= for the first and Cpeek for the
 second. I wouldn't mind if the first were spelled Ccount, either. Tom,
 does this make sense, or am I confusing "lists" with "the comma operator
 in parentheses" again?

perl already has a count operator, it is the only 4 charater non-alpha
operator it has   =()=   :)

Graham.




  1   2   >