Re: rethinking printf

2002-03-06 Thread Bart Lateur

On Wed, 6 Mar 2002 17:57:07 -0500, Uri Guttman wrote:

how often will you need to interpolate a hash?

A whole hash: quite rarely. A hash item: a LOT. Don't forget that
$foo{BAR} will now become %foo{BAR}


Re: 123_456

2002-01-26 Thread Bart Lateur

On Fri, 25 Jan 2002 17:34:12 +, Simon Cozens wrote:

Should we be allowed to use _ to group numbers, now that _ is concat?
If not _, then what? (if anything?)

I don't really understand your question. Currently, . is used for
concat and that doesn't inhibit using it in a number, does it? Or what
would you suppose that 3.14 means?

Quite the countrary: (100 . 000) as a number is indeed 10, as is
100_000. So there's *less* of a conflict than today, in perl5.


Re: Apoc4: The loop keyword

2002-01-25 Thread Bart Lateur

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 beginners.

But it's handy. And that was, until now, what mattered with Perl.


Re: Apoc 4?

2002-01-19 Thread Bart Lateur

On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote:

David Whipp wrote:
 Michael G Schwern wrote:
  Reading this in Apoc 4 ...
 I looked on no sign of Apoc4. Where
 do I find this latest installment?

I thought I had just missed it... but there's no trace of it in the
archives of [EMAIL PROTECTED]. Or any other perl6 list.

Don't tell me that is normal.


Re: Apropos of nothing...

2001-12-13 Thread Bart Lateur

On Thu, 13 Dec 2001 12:17:44 -0500, Mark J. Reed wrote:

   @i = (0);
   @ary[@i] = foo();

How could one get that behavior without the intermediate array?

Parens, likely.

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


Re: Perl 6 - Cheerleaders?

2001-10-26 Thread Bart Lateur

On Thu, 25 Oct 2001 16:53:46 -0500, Garrett Goebel wrote:

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

I just hope that you don't really have to insert that many blank lines
in your code just to make it compile.


Re: Indenting

2001-10-16 Thread Bart Lateur

On Mon, 15 Oct 2001 20:53:24 -0400, Michael G Schwern wrote:

Not only is it a bit faster than the s/^\s+//gm regex, but it is also
more flexible.

if( $self-feeling_snooty ) {
print 'POEM';
form has to follow function
all over the page.

Which reminds me... one of the less attractive features of here docs is
the fact that the quoted document always has to end in a newline. That
is annoying at times.

For example, I often use here docs as a template mechanism: convert the
original text file to a here doc, split into three parts: intro, main
body (loop body), outtro; and you can generate such a doc with as many
repetitions as you like. If the three parts may be split right after a
newline, as commonly in HTML, there's no problem. But sometimes you want
to split in the middle of a line.

If there was an easy way to chomp() that newline and return the
remainder of the string, that would solve this too. Like this?

sub chomped ($) {
 chomp(my $s = shift);
 return $s;

I don't really like this solution much. And it's not worth an extra
keyword, for chomped() to become a built-in.

This, in turn, reminds me of the other common problem, where s///
modifies a string, instead of returning a modified copy, as some people
would like.

Ain't such a chain of thoughts lovely...  :-)


Re: Indenting

2001-10-14 Thread Bart Lateur

On Sat, 13 Oct 2001 16:30:08 +0200, raptor wrote:

I was looking at TPJ one-liners and saw this :

#32A trick for indenting here strings

($definition = 'FINIS') =~ s/^\s+//gm;
The five varieties of camelids are the familliar
camel, his friends the llama and the alpaca, and
the rather less well-known guanaco and vicuna.

Courtesy of The Perl Cookbook

It is very cool if we have a way to set this RegEx so that it executes in
compile time

I can remember that an even smarter version of this was discussed in an
RFC -- I don't remember which -- so it's not unlikely that it will be
part of Perl6.

Besides, if this is a fixed string, you can rearrange your source code
so that it executes only once. It doesn't really matter then if this is
at compile time, or at run time.


Re: General Feelings on Apoc 3

2001-10-10 Thread Bart Lateur

On Wed, 10 Oct 2001 15:42:29 +1000 (EST), Damian Conway wrote:

Brent asked:

If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a
low-precedence version of this?

I actually suggested exactly that to Larry a few weeks back.

He likes the idea, but is having trouble finding an acceptable name for the 

I'm not convinced it's that useful... The precedence of dor would be
lower than that of assignment. And it's precisely in assignment where
the // operator will come in very handy.

If you don't need to assign the value of the expression, you can just as
wel use defined():

defined($x = foo()) or die Got an undefined value!;

Plus there's the matter of the name...

Do we really need low and high precedence equivalents of every boolean
operator? Next, you'll want a low precedence ?: (or ??::). We have
one already: if/else, but except in do blocks, you can't really use them
for expressions.


Re: EX3: $a == $b != NaN

2001-10-10 Thread Bart Lateur

On Sun, 7 Oct 2001 12:27:17 +1000 (EST), Damian Conway wrote:

The step you're missing is that the non-numeric string hello,
when evaluated in a numeric context, produces NaN. So:

 hello == 0  0 != NaN


 Nan == 0  0 != NaN

which is false.

So to what does 123foo evaluate in numeric context? Now, it produces
123. Which is probably useful...

if 123foo produces Nan, which wouldn't really surprise me too much,
we'll need additional tools to extract the number from a string. We can
do it with a regex, but for the general case, it becomes a nasty beast
of a regex, and I don't want to rewrite it from scratch every time I
need it.A job for Regexp::Common?


Re: EX3: Adverbs and print()

2001-10-10 Thread Bart Lateur

On Sat, 06 Oct 2001 22:20:49 -0400, John Siracusa wrote:

So, in the … operator, the filter is the adverb:

$sum = … @costs : {$^_  1000};

WTF is that operator? All I see is a black block. We're not in ASCII any
more, Toto...


Re: NaN semantics

2001-10-10 Thread Bart Lateur

On Wed, 10 Oct 2001 11:52:16 -0400, Dan Sugalski wrote:

If people want base 10, let them use e syntax.

1e3 = 1000
1k = 1024

I'll leave that for Larry to decide. I'm just thinking of all the 60G hard 
drives I see at Best Buy that are really 60e9 bytes, and the 1K ohm 
resistors that are really 1000 ohms. (Well, give or take a bit for ambient 

You optimist! The precision of such resistors is often no better than 5
or 10%. That is more than 24 ohm.

But anyway... I hope a kg is still 1000 grams, not 1024 grams?

Re: reduce via ^

2001-10-10 Thread Bart Lateur

On Wed, 10 Oct 2001 14:23:33 -0700, Colin Meyer wrote:

  Does this mean that 
  @a ^+= @b;
  will add every value of @b to every value of @a?

What I'd expect is more like:

  foreach my $elem (@a) {
 $elem ^+= @b;

If you want that effect, apply scalar on the RHS.


Re: Just a thought...

2001-10-09 Thread Bart Lateur

On 09 Oct 2001 11:22:02 +0100, Piers Cawley wrote:

Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier?

I'm sure it won't be. The reasoning for replacing ? with  ?? is that
? is worth too much as a single character symbol, to sacrifice it on
such a rather lowly used operator. And now you want to reclaim it... for
no operator at all? That, I'm sure, is going into the entirely wrong

As in Lisp, you can use p.

sub is_visiblep { ... }



Re: Customizable default hash and array values.

2001-10-06 Thread Bart Lateur

On Fri, 28 Sep 2001 21:27:48 +0200, Johan Vromans wrote:

Michael G Schwern [EMAIL PROTECTED] writes:

 so if $key does not exist you'll get 'some default' instead of undef.

Except that a more common case is

  my $foo = $hash{foo} || 'some default';
  my $bar = $hash{bar} || 'some other default';

What about zero.

Oh, wait, we're back at that ?? discussion again.


Re: ! and !

2001-09-02 Thread Bart Lateur

On 01 Sep 2001 14:40:40 -0700, Russ Allbery wrote:

Sterin, Ilya [EMAIL PROTECTED] writes:
 From: Russ Allbery [mailto:[EMAIL PROTECTED]]

 How is ! different from =?

It's the same number of characters.  How can it be more convenient?

Why is it = and not =? Why = and not =? Simply trying to
remember the order of characters might be (a bit of) a pain. That
problem doesn't exist with ! and !.


Re: Semi-OT: Good compiler book?

2001-08-08 Thread Bart Lateur

On Tue, 7 Aug 2001 16:03:56 -0700, Brent Dax wrote:

I'm going on vacation soon, and I'd like to get a good book on writing
compilers--hopefully one that will help me when we actually start coding
Perl 6.  Any suggestions?  I have no formal education on compilers, and
I only know C, C++ and Perl (duh).

Unless you get a kick out of mathematical proofs, you probably won't get
too much out of the dragon book. It ain't very practical. I would look
out for a book that gives a *practical* introduction to compiler design,
i.e. one that builds a working compiler on the side.

Although I've really only browsed in them, I think I'd rather look into
Crafting a Compiler by C. Fisher and R. Leblanc, or A retargetable C
compiler, by D. Hanson and C. Fraser, which forms the basis for lcc
(one shoot-off is lcc-win32, an excellent, freely available C compiler
with IDE, for Win32).

Both books get good reviews.


Re: new syntax idea: eval ...o;

2001-08-07 Thread Bart Lateur

On Tue, 7 Aug 2001 09:27:43 -0400, John Porter wrote:

David L. Nicol wrote:
  eval ${code}o;

Another brilliant idea from David Nicol!

Not really.

What I would like is an option to just *compile* a piece of perl code,
without executing it. This kinda works:

$coderef = eval sub { $code };

and currently (5.6.0) even if $code contains sub definitions; but it's
still just a hack.


Re: if then else otherwise ...

2001-07-30 Thread Bart Lateur

On Sun, 29 Jul 2001 19:36:43 -0400, Bryan C. Warnock wrote:

$x = ($default,$a,$b)[$b=$a];  # Much like I did before

Note that

$x = cond? a : b

does lazy evaluation, i.e. the value for a or for b is only fetched when
it's actually needed. In your construct, they're all fetched anyway,
before the condition is even checked.


Re: if then else otherwise ...

2001-07-29 Thread Bart Lateur

On Sun, 29 Jul 2001 14:22:23 +0300, raptor wrote:

But at least the second shortcut is worth it, i think :

cond ? then : else : otherwise

This has a vague smell of Fortran.


Re: if then else otherwise ...

2001-07-29 Thread Bart Lateur

On Sun, 29 Jul 2001 18:08:00 +0300, raptor wrote:

But at least the second shortcut is worth it, i think :

cond ? then : else : otherwise

This has a vague smell of Fortran.

]- I don't know Fortran sorry :)

Then check this out.


Re: as long as we are discussing 'nice to have's...

2001-07-24 Thread Bart Lateur

On Sat, 21 Jul 2001 14:47:43 -0700 (PDT), Dave Storrs wrote:

I discovered today that I had forgotten to put 'use strict' at the top of
one of my was in the script that _used_ the module, but not
in the module itself.  Putting it in instantly caught several annoying
bugs that I'd been trying to track down.

It would be nice if there was...

No. Your script should not be responsible for debugging modules. Modules
are supposed to be debugged already, and are the responsibility of the
module author, not the script writer.


Re: aliasing - was:[nice2haveit]

2001-07-18 Thread Bart Lateur

On Wed, 18 Jul 2001 09:00:25 -0400, John Porter wrote:

 Does such a thing exist already?

A WTDI exists already:

for ( $XL-{Application}-{ActiveSheet} ) {
  $_-cells(1,1) = Title;
  $_-language() = English;

(presuming lvalue-methods, of course...)

So, in this case, a with synonym for for would work.

But this only works for scalars. You can't have a %foo alias to
%Some::Other::hash this way, or a @bar alias to @Some::Other::array.


Re: precision belongs in bigfloats, nowhere else.

2001-07-14 Thread Bart Lateur

On Thu, 12 Jul 2001 18:09:07 -0400, Dan Sugalski wrote:

Precision is a useful thing with bigfloats so something like 1/3 doesn't 
chew up all your available memory. 

1/3 would better be represented as a ratio, 1 over 3. 

We've been here before, haven't we?

Ratio's,  or whatever you'd want to call them, with both nominator and
denominator integers, would be a very useful internal representation for
many numerical applications. $1.23 can be represented as 123 over 100,
or EXACTLY 123 cents. You can't have that with floats. Multiplication
and division can happen without loss of precision. A Greatest Common
Divisor algorithm like Euclid's, can prevent nominators and denominators
from getting out of control. See for example this page,, for
how. (Changing the program from using recursion to using a loop is


Re: nice2haveit

2001-07-14 Thread Bart Lateur

On Fri, 13 Jul 2001 20:55:07 +1000 (EST), Damian Conway wrote:

Would you like to clarify what you mean here.
Are you talking about typeglob assignments?
Perl 6 will have:

   $Foo::{'$bar'} = \$baz; # Alias $Foo::bar to $baz

Are we back to globals only? What about lexical aliases? Something

my \%foo = \%bar;

(Now %foo is an alias to %bar.)


Re: Multiple classifications of an object

2001-06-28 Thread Bart Lateur

On Wed, 27 Jun 2001 13:48:38 -0400, Dan Sugalski wrote:

And the current @ISA stuff is MI, 
albeit on a per-class basis rather than on a per-object one.

Anyway, as Damian mentioned, setting the .ISA property is a perfectly 
reasonable sort of thing to do if the language supports this. 

Just one question. If an object would have both per-object inheritance
(.ISA), and per class inheritance (@ISA), which one would have
precedence? If there's a conflict, a method exists both for a superclass
and for an object superclass (i.e. through .ISA), which list would be
checked first? Which method would be picked, and executed?

FWIW, I think I'd vote for .ISA, as it is more individually tied to this
particular object. The other one is generic.


Re: ~ for concat / negation (Re: The Perl 6 Emulator)

2001-06-21 Thread Bart Lateur

On Thu, 21 Jun 2001 23:49:21 +0100, Simon Cozens wrote:

  Does anyone else see a problem with =~ ? 

Does anyone else see a problem with $negated=~$scalar; ? :)

You forgot the space between the = and the ~. And yes, that is a bit
of a problem.


Re: Social Reform

2001-06-12 Thread Bart Lateur

On Tue, 12 Jun 2001 08:54:13 +0100, Simon Cozens wrote:

On Mon, Jun 11, 2001 at 05:19:26PM -0700, Daniel S. Wilkerson wrote:
 I would say Simon was the one ignoring an issue and attacking a person, not

You are wrong. Go back through the archives. Vijay has posted four
messages: two of which are critical of Perl, two of which are pretty
heated personal attacks on me. None of those four does anything useful
for Perl 6.

Well, I *have* been following the discussion. And to me, it looks indeed
like you, Simon, were indeed attacking ME on non-technical grounds.
Vijay just jumped in for him, like a lioness trying to protect her


Re: Damian Conway's Exegesis 2

2001-05-16 Thread Bart Lateur

On Wed, 16 May 2001 13:49:42 +0200, Carl Johan Berglund wrote:

sub show {print 6}
print Perl ${show()}\n;

(That prints 6Perl, not Perl 6.)

If you want to call the subroutine in the middle of the string, you 
should make it _return_ something, not print it.

This person obviously expects a pipe effect, i.e. capturing of the
printed output.

Should Perl6 provide one? Is print() really easier to grasp, than
'return $buffer', with possibly lots of '$buffer.=$append' in the sub?
Actually, yes, the latter is annoying.


Re: Apoc2 - STDIN concerns

2001-05-14 Thread Bart Lateur

On Thu, 10 May 2001 17:15:09 +0100, Simon Cozens wrote:

 What you could do, is treat an iterator as something similar to reading
 a line from a file. Tied filehandles allow something like it in Perl5.

You know, if what you say is true, I'd expect to find a module on CPAN which
turns the exotic 'each' function into the friendly tied filehandle model.
But I don't see one. I think people are less confused by all this than you
imagine. :)

Perhaps it's because the people who are capable of writing such a
module, are the ones who don't need it. But, not everyone is a conway.

There must be some reason why a language like Sather isn't more popular.
I think that iters are part of the problem.


Re: what I meant about hungarian notation

2001-05-14 Thread Bart Lateur

On Mon, 14 May 2001 20:38:31 +0100, Graham Barr wrote:

You forgot

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

As to what the combined


would mean: that depends on what $bar contains.

(Aw! That hurt!)


Re: A proposal for more powerful text processing to be built in to Perl: Flex and Pushdown Expressions.

2001-05-11 Thread Bart Lateur

On Fri, 11 May 2001 08:29:07 -0500, Tad McClellan wrote:

On Thu, May 10, 2001 at 04:26:56PM -0700, Daniel S. Wilkerson wrote:

 Flex - Put all of flex right into Perl.

Don't we already have that in Perl 5?


What he is proposing, is again the age old proposal of putting the
notion of (simple) grammars into Perl's regex engine.

Part of what he proposes, namely the events, can/could be done with
embedded perl code into the regex, AKA the infamous (?{...})
construct. The advantage over doing this in plain perl, as you showed,
is that includes the possibility for backtracking, all without any help
from the outside.

The (??{...}) construct might likely be used to match nested
parentheses, for example. I'm not really sure, I'm not too familiar with
this crash-prone feature.


Re: Apoc2 - STDIN concerns

2001-05-10 Thread Bart Lateur

On Fri, 4 May 2001 18:20:52 -0700 (PDT), Larry Wall wrote:

: love. I'd expect $FOO.readln (or something less Pascalish) to do an
: explicit readline to a variable other than $_

It would be $, 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 $, 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...

Just my thoughts: this is sick.

I am having great difficulties in trying to wrap my mind around
iterators. I expect that I'm far from alone at that.

People are *very much* familiar with reading a line from a file. People
may steer clear from a language because it deeply relies on exotic stuff
like iterators.

So trying to turn read a line from a file into a special case for an
iterator, is the wrong way around.

What you could do, is treat an iterator as something similar to reading
a line from a file. Tied filehandles allow something like it in Perl5.
Doing the reverse is, er, insane.


Re: what I meant about hungarian notation

2001-05-09 Thread Bart Lateur

On Tue, 08 May 2001 20:21:10 -0500, David L. Nicol wrote:

What if, instead of cramming everything into scalar to the point
where it loses its value as a data type that magically converts
between numeric and string, as needed, we undo the Great Perl5
Dilution and undecorate references.

Undecorated if for function calls and methods. And buolt-ins, of course.

So what I am suggesting is, Scalar as catch-all for unclassifiables
that are neither strings nor numbers may have been a historic stopgap
measure in perl 5 which was seen to be unworkable given the profusion of
object types which became available in perl 6.

An object of type abstracted reference to a chair is _NOT_ an object of
type numeric or string that magicly switches between as needed

So what you're really saying is that references aren't really scalars,
but their own type. Thus they need their own prefix.

But we've sort of run out of possible prefixes.


Re: what I meant about hungarian notation

2001-05-09 Thread Bart Lateur

I really need to spell-check better.

Undecorated if for function calls and methods. And buolt-ins, of course.

Undecorated is for function calls and methods. And built-ins, of course.


Re: what I meant about hungarian notation

2001-05-09 Thread Bart Lateur

On Wed, 9 May 2001 09:47:56 -0400, John Porter wrote:

 Undecorated if for function calls and methods. And buolt-ins, of course.

No, that's the situation already.  David is proposing a change.

 So what you're really saying is that references aren't really scalars,
 but their own type. Thus they need their own prefix.

No, that does not follow.

What he is proposing is that Perl6 would have a kind of variable that
doesn't have a prefix. That isn't perlish IMO. We might just as well
drop all prefixes. At least, that'd be consistent.


Re: Apoc2 - STDIN concerns ::::: new mascot?

2001-05-09 Thread Bart Lateur

On Wed, 9 May 2001 10:24:26 -0400, David Grove wrote:

I remember someone (whether at O'Reilly or
not I don't remember) saying that, even if it looks like a horse but has a
hump, it's not allowed. Or was that an alpaca with a llama...

The RFC pleads for a community spirit from ORA. Barring that, it seeks a new
symbol for the community entirely. 

Several perl ports, and at least one book, use a shiny ball as a

Scroll down to the heading Book Nickname (?).

It took me a bit of thinking before I realized what this shiny ball
represents. Odd.


Re: what I meant about hungarian notation

2001-05-09 Thread Bart Lateur

On Wed, 9 May 2001 11:06:45 -0400, Bryan C. Warnock wrote:

At that
 point, Hungarian notation fell apart for me. Its strict use adds (IMO) as
 much confusion as MicroSoft's redefinition of C, with thousands of
 typedefs representing basic types (LPSTR and HWND come to mind as the
 most common).

Not mention the hoop-jumping required to keep variable names in sync with 
code changes.  (signed-ness, short-int-long, etc)

Which reminds me... One of the fundamental functions in the Windows API
is SendMessage. Here, one can give two parameters. They're call wParam
and lParam. Yes, originally, wParam was a word (16 bit), and lParam was
a long (32 bit).

But under the Win32 API, every kind of integer was turned into a long,
but the names wParam and lParam still stuck, despite the fact that both
are now 32 bit integers.


Re: apo 2

2001-05-04 Thread Bart Lateur

On Thu, 03 May 2001 22:14:47 -0500, David L. Nicol wrote:

I am going to miss doublequoting being the default quoting for
here strings.  I find that to be a very nice optimization and
would like to know more about the reasoning behind taking it

I was already panicking when I saw this message. Of course, I hadn't
seen Apo 2 itself, and I was really reliefed when I did.

For the record: I had assumed that double quotish interpretation for the
here docs was going to disappear. Not so. It's just that in

$heredoc = END;
foofoo foo foo

the double quotes around the end marker, END, will have to be
included. They may no longer be dropped.

I worry that official standard p6 will be more difficult
to use than official standard p5.

Heh? I *always* put quotes around them. But I hardly ever restrict
myself to word characters in the end delimiter, anyway. I fail to see
the problem.


Re: apo 2

2001-05-04 Thread Bart Lateur

On Fri, 4 May 2001 10:49:48 -0500 , Garrett Goebel 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 it is just my interpretation of Damian's OO-Perl book... but:

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


Thinking as in VB again... I associate a property with has, and a
default property with is. Something like:

$label is Click here;
$label has caption = Click here;

Jeezes, this is weird stuff.


Re: Apo2: \Q ambiguity

2001-05-04 Thread Bart Lateur

On Fri, 04 May 2001 15:05:12 -0400, Dan Sugalski wrote:

Have you considered allowing Unicode characters as alternatives to some of 
the less pleasant looking bits? $foo1 (where  and  are the double 
angle characters) as an alternative to $foo\Q[1] if the user's got the 
characters handy?

Until now, all characters with a special meaning for the syntax of the
language, are in the ASCII range. I see no reason to change that. This
is the case for most programming languages, with as a notable exception


Re: Please make last work in grep

2001-05-02 Thread Bart Lateur

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();

You can always expect one more than is on the LHS.

How is this currently handled with split()?


Re: Please make last work in grep

2001-05-02 Thread Bart Lateur

On Wed, 2 May 2001 11:41:32 -0500, Jarkko Hietaniemi wrote:

but I suspect in this case want('LIST') would
 return that magical 0 but true or something similar.

Hopefully the something similar, I hope in Perl 6 we will able to
bury the 0 but true workaround to the backyard on a moonless night :-)

Especially since you don't need it. 0E0 and 0., to name just two,
work just as well.   ;-)


Re: Curious: - vs .

2001-04-27 Thread Bart Lateur

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



Re: Curious: - vs .

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 15:52:47 -0600 (MDT), Dan Brian wrote:

the idea of a dereference operator dumbfounds lots
of folks. What's an object got to do with a reference, much less a
pointer? A p5 object is very confusing to others for this reason, and so
is the syntax.

So you want a method invocation syntax that doesn't remind people of
references. OK. But why does it have to be the dot? It is already taken.
Sorry. Use an operator that doesn't exist yet in Perl. For example, old
style VB used ! to connect objects and their properties:

label1!caption = Hi!

is the same as

label1.caption = Hi!

So why not

$object!method(foo, bar);


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

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 18:19:40 GMT, Fred Heutte wrote:

Yes, I know ~ is the bitwise negation operator.  Have you EVER used it?

Yes. A lot.

But there is no conflict. ~ is currently just an unary operator, while
your use would be as a binary operator (are those the correct terms?).
For example, in


and in


the - sign is a *different* kind of operator. No conflict.


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-26 Thread Bart Lateur

On Wed, 25 Apr 2001 06:09:56 -0700 (PDT), Larry Wall wrote:

Bart Lateur writes:
: Er... hip hip hurray?!?!
: This is precisely the reason why I came up with the raw idea of
: highlander variables in the first place: because it's annoying not being
: able to access a hash passed to a sub through a hash reference, in the
: normal way. Not unless you do aliasing through typeglobs.

: But, if there won't be full blown highlander variables, how does Perl
: know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
: hash referenced by the hashref $foo?

$foo{THERE} always means the hashref in $foo.  %foo{THERE} always means
the hashref in %foo.  %foo by itself in scalar context means a hashref.
@foo by itself in scalar context means an arrayref.  foo by itself in
a scalar context means a coderef.  It's gonna be pretty consistent.

Yeah. But no cheers then. The problem still remains: you can access a
hash in the normal way in plain code, but inside a sub, you can mainly
only access a passed hash through a reference.

It's annoying to basically having two ways of doing something, and one
of them can't be used half of the time.

Even though @foo and %foo may be two different structures, a scalar $foo
can only reference one of them at a time.

Are you going to provide a simpler aliasing mechanism to turn a hash
reference, for example as passed to a sub as an argument, back into the
full-blown hash? Simpler (and safer) than the much frowned upon
assignment to a tyeglob, that is.


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-25 Thread Bart Lateur

On Tue, 24 Apr 2001 18:39:09 -0700 (PDT), Larry Wall wrote:

Edward Peschko writes:
: I guess my question is what would be the syntax to access hashes? Would
: $hashref.{ }
: be that desirable? I really like -{  } in that case..

It won't be either of those.  It'll simply be $hashref{ }.

Er... hip hip hurray?!?!

This is precisely the reason why I came up with the raw idea of
highlander variables in the first place: because it's annoying not being
able to access a hash passed to a sub through a hash reference, in the
normal way. Not unless you do aliasing through typeglobs. A highlander
variable would get you that: that if a hash %foo exists, the scalar $foo
would automatically be a reference to that hash.

But, if there won't be full blown highlander variables, how does Perl
know if by $foo{THERE} you mean an item of the hash %foo, or a item in a
hash referenced by the hashref $foo?


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-25 Thread Bart Lateur

On Tue, 24 Apr 2001 21:06:56 -0700 (PDT), Larry Wall wrote:

: Ok, so what does:
: my %hash = ( 1 = 3);
: my $hash = { 1 = 4};
: print $hash{1};
: print?

4.  You must say %hash{1} if you want the other.

Ok. So how about hash slices? Is $hash{$a, $b}, the faked
multidimensional hash, going to go? Otherwise %hash{$a, $b} is going to
be ambiguous.


Re: Sane + string concat proposal

2001-04-25 Thread Bart Lateur

On Wed, 25 Apr 2001 08:25:40 -0400, Stephen P. Potter wrote:

| I'm really beginning to like
|  $string3 = $string1 _ $string2;
| The underscore indeed connects the two strings.

This still breaks because _ is a valid word character.

So are cmp, and, lt, and the proposed cat and cc. Having
operators consisting of word characters doesn't really seem to be any
problem, except that you may not attach them at the end of a variable's


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-24 Thread Bart Lateur

On 24 Apr 2001 00:29:23 -0700, Russ Allbery wrote:

How do you concatenate together a list of variables that's longer than one
line without using super-long lines?  Going to the shell syntax of:


would really be a shame.

A backslash at the end of a line?



Re: Tying Overloading

2001-04-24 Thread Bart Lateur

On Tue, 24 Apr 2001 10:49:18 +0100, Simon Cozens wrote:

While that's true, concatenation is quite a common operation 
that I'd be really
uncomfortable with it necessitating 4 keystrokes ( cat) instead of one.

Er, ~ is an extremely annoying character to type at many keyboards. It
may depend on your keyboard localization. On my Belgian keyboard, I have
to press Alt-Gr (the second Alt) and keep it down, then the ~ button,
release Alt-Gr, then a space. I don't find this handy, because it's far
too easy to mess up. Just the word cat (or cc) is a lot less work,
simply because it requires no special keypresses.


Re: Tying Overloading

2001-04-24 Thread Bart Lateur

On Tue, 24 Apr 2001 14:37:02 +0100, Simon Cozens wrote:

Let's put it a different way - if we can find a short operator which
is readily accessible on most people's keyboards, then that would
score over a longer operator which is readily accessible on most 
people's keyboards. Maybe ~ isn't that operator. Maybe  is, or ^ or
#, or whatever.

'~' is not good because it's very hard to reach. But ^ is a deadkey
too, so this one also needs pressing a space.

If you want something that's easy to type and that won't conflict with
current Perl, try !.

Too bad _ is a word character.


Re: Sane + string concat proposal

2001-04-24 Thread Bart Lateur

On Wed, 25 Apr 2001 00:37:53 +0100, Simon Cozens wrote:

$string3 = $string1 . $string2;
$string3 = $string1 + $string2;
That's now *five* characters required to perform a very common operation.

Rather than one.

I'm really beginning to like

$string3 = $string1 _ $string2;

The underscore indeed connects the two strings.

But: as somebody else wrote: why on earth do we need to reserve the dot
for OO? Why do we have to be compatible with everybody else in the
world? Because we're not, anyway.

Recently, there was a question about polymorphism in Perl. This person
did not understand that it is possible that you can use the same method
for two different classes, without them having a common superclass. It's
perfectly possible in Perl (because method resolving actually is a form
of symbolic dereferencing... heheh...), but most definitely not in most
other OO languages.

So, perl is different anyway. What does one tiny extra superficial
difference of notation FGS make any difference. I think backward
compatibility with Perl5 is far more important, than having the
*appearance* of doing the same as other OO languages.


Re: Strings vs Numbers (Re: Tying Overloading)

2001-04-23 Thread Bart Lateur

On Mon, 23 Apr 2001 16:14:50 -0400, John Siracusa wrote:

Using + for concat: no!

My vote is to use . and require space before and after.
$this.$is.$ugly.$anyway ;)

My vote is to ditch the concat operator altogether. Hey, we have


Which reminds me... one problem I have with it is that it's too hard to
separate a variable name from the rest of the string, if it also
consists of word characters:

my $bar = BAR;
print foo${bar}baz;  - fooBARbaz

Since $bar is a lexical variable, this syntax doesn't make much sense
anyway: it reeks of symbolic references and those don't work for

I think I'd like something incorporating a backslash would be nicer:

print foo$bar\Ebaz;

It works, but it may have unwanted side effects -- in case the \E
actually serves a purpose.

But, you may completely forget about it. I just had to say this one day.


Re: Tying Overloading

2001-04-23 Thread Bart Lateur

On Mon, 23 Apr 2001 13:19:24 +0100, Graham Barr wrote:

 Or we change the concatenation operator.

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.

Or, in analogy to cmp, gt etc:

$a = $b plus $c;
$a = $b cat $c;


Re: Schwartzian transforms

2001-03-29 Thread Bart Lateur

On Wed, 28 Mar 2001 11:11:20 -0500, Dan Sugalski wrote:

   "Can perl automatically optimize away function and tie calls inside
a sort function, and under what circumstances?"

It doesn't really matter if the functions inside the sort function are 
idempotent--what matters is whether it's OK for us to go and memoize the 
things (or whatever else we might choose to do)

Exactly. This whole discussion borders on the edge of the ridiculous.
Any sort algorithm ALWAYS assumes that comparisons are constant, i.e.
return consequent results on subsequent calls. They always infer sorting
information out of what they got yet. That's why they hardly ever need
to compare every item with every other item. The fewser comparisons, the
better the algorithm.

As MJD very recently wrote:

An optimal sort function will not call the comparator if it
already knows what the result should be!

So true.

That implies that side effects and otherwise unmemoizability of sort
functions may *always* safely be ignored. If not, the programmer has a
personal problem, i.e. a bad starting point. Otherwise, the results of
sort would largely depend upon which sort algorithm was used internally!


Re: Schwartzian Transform

2001-03-21 Thread Bart Lateur

On Wed, 21 Mar 2001 15:40:20 -0500, John Porter wrote:

Uri Guttman wrote:
   JP y/L/A/;
 tell that to perllol :)

I do, through clenched teeth, every time I see it.

IMHO, it is:



Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-22 Thread Bart Lateur

On Wed, 21 Feb 2001 16:01:39 -0500, [EMAIL PROTECTED] wrote:

Has anyone actually used a language which has run-time warnings on by
default?  Or even know of one?

Actually, it's pretty common. Only, most languages are not as forgiving
as perl, and what is merely a warning in Perl, is a fatal error in those
languages. Trying to read the value of an uninitialized variable, for
example, that's commonly a fatal error. Failing to chdir, is another

So even with warnings on by default, Perl is still pretty mild.


Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-22 Thread Bart Lateur

On Wed, 21 Feb 2001 17:32:50 -0500 (EST), Sam Tregar wrote:

On Wed, 21 Feb 2001, Bart Lateur wrote:

 Actually, it's pretty common. Only, most languages are not as forgiving
 as perl, and what is merely a warning in Perl, is a fatal error in those

Examples?  I know you're not talking about C or C++. 

Visual Basic, for one, or any other BASIC in history. It looks like a
compiled vs. interpreted thing. C doesn't do any runtime error checking,
because of speed reasons. There's no array bounds checking. You can use
a null pointer when copying a string, which results in an untrappable
program error ;-). Virtually all interpeted languages, where safety
reigns over speed, do all of those. Anything out of the ordinary is a
fatal error.

AppleScript is an extreme example. There, if you're trying to get a list
all picture boxes of a certain type on a page, it works properly if
there is one or more. But if there is isn't one, you don't just get the
empty list. No: it's a fatal (but trappable) error. That kind of anal
behaviour in a language is extremely annoying.


Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)

2001-02-20 Thread Bart Lateur

On Tue, 20 Feb 2001 16:31:35 -0500, Bryan C. Warnock wrote:

Scalar value @foo[$bar] better written as $foo[$bar], for one.

I agree on this one (hash slices too), if this expression is in list
context. There is no error in

@r = map { blah } @foo{$bar};


Re: Warnings, strict, and CPAN

2001-02-18 Thread Bart Lateur

On Fri, 16 Feb 2001 21:03:54 -0800, Edward Peschko wrote:

It is one hell of a burden to find a missing 'use strict' or 'use warnings'.
'Well, type them then' you say. Right, and always type ';' at each line, or 1;
at the end of each file. Its as unavoidable as a *syntax error*, which is the 
point. syntax errors should be easy to fix, not hour-long treks through code.

It seems to me that *that* is your main problem. Not the fact that
strict and warnings aren't put in by the perl interpreter itself, but
that perl code is so difficult to debug. Something as simple as
requiring variable declarations or initializing variables ought not take
hours of debugging, assuming that for the rest, the source works
reasonably OK. So, 

 A) a code profiler that can verify use of variables and stick a limited
scope onto every variable, plus optionaly initializing variables to ''
or 0, that might be handy at times.

 B) perl's error messages could be somewhat more helpful. If you have a
here doc with 30 lines of interpolated pure text, it's extremely
annoying that perl will only point you to this data block (actually to
the line containign the ""), and just say "use of uninitialized value"
without saying *which* variable it is talking about. But, this has been
brought of on the perl6 lists a few times already.

All this could help strictifying and warn-proofing otherwise properly
working modules, in say, oh, five minutes.


Re: The binding of my (Re: Closures and default lexical-scope

2001-02-18 Thread Bart Lateur

On 17 Feb 2001 20:53:51 -0800, Russ Allbery wrote:

people please take the advocacy traffic elsewhere where it isn't noise?

Advocacy is noise everywhere.

That doesn't mean that davocates for either side don't have anything
interesting to say. For starters, it's usually dissatisfaction with
certain aspects of some languages that causes the birth of yet another
new language, such as PHP (which is more a different programming
platform than really a different, full blown language) and Ruby.

When designing a new generation of a language, it can be interesting to
look what those alternative language designers have done. They just
might have done some interesting things. No language is an island.


Re: End-of-scope actions: do/eval duality.

2001-02-15 Thread Bart Lateur

On Tue, 13 Feb 2001 11:35:16 -0800, Glenn Linderman wrote:

In the perl 5 pocket reference 3rd edition page 63, it claims that $@ is
set to the result of an eval or do.  How does this impact exception
handling tests on $@ to determine if an exception was thrown, if $@ can
be set by a do ?  OR is that an error in the pocket guide?

No, it's a misunderstanding between you and Tony. The "do" your
reference is talking about, is of the form


where file is a string containing a filename, while Tony is talking
about the


form. do FILE behaves just like eval() (except it reads its data from a
source file), while do BLOCK doesn't. Neither.


Re: JWZ on s/Java/Perl/

2001-02-11 Thread Bart Lateur

On Fri, 9 Feb 2001 16:14:34 -0800, Mark Koopman wrote:

but is this an example of the way people SHOULD code, or simply are ABLE to 
code this.   are we considering to deprecate this type of bad style, and force
to a programmer to, in this case, supply a ref to %baz in the arguements to
this sub?

I think you're trying too hard turning Perl into just another C clone.
Dynamic variable allocation and freeing, like this, are one of the main
selling points for Perl as a language.

Note that %baz can, as values, also contain references to other
lexically scoped varibles, like \$foo and \$bar. No prototping around

  sub test {
  my($foo, $bar, %baz);
  return \%baz;

You could, theoretically, create special versions of "my", or a "my"
with an attribute, so that these declared variables are kept out of the
normal lexical pool, and garbage collected in a more elaborate way,
perhaps even reference counting.


Re: Auto-install (was autoloaded...)

2001-02-09 Thread Bart Lateur

On Thu, 8 Feb 2001 17:39:01 +, Nicholas Clark wrote:

On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote:
 (Including Archive::Tar as part of the base perl distribution's not 
 inappropriate, assuming we can get permission. )

Since it's already part of the "standard distribution" for Win32, both
ActiveState and IndigoStar, as both use it in order to install packages,
I guess that that won't be much of a problem.

Do we really want to use tar format (over say cpio) as tar rounds files
up to 512 block boundaries, and has some arbitrary restrictions on filename
lengths in the headers?

You don't need to use raw .tar. Archive::Tar works perfectly fine with
.tar.gz files. Compression effectively takes care of the padding with
nulls, because they get "compressed away". The compression is handled by
the Compress::Zlib module. So if there is any redistribution licensee
problem, I expect it to be there.


Re: Auto-install (was autoloaded...)

2001-02-09 Thread Bart Lateur

On Thu, 8 Feb 2001 17:49:45 -0200, Branden wrote:

I've never actually used PPM, only read about it in
the web. I guess their file format is a disguised .tar.gz, right?

It's a combination of an XML file, file extension "PPD", which describes
the properties and dependencies, and platforms, and a normal .tar.gz
file. The latter can come straight from CPAN.


Re: JWZ on s/Java/Perl/

2001-02-09 Thread Bart Lateur

On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:

There are two main reasons advanced garbage collectors are fast:

 1. Cheap allocations. Most fast collectors have a one or two
instruction malloc. In C it looks like this:

  void *malloc(size) { void *obj = heap; heap += size; return obj; }

It's easier to do alignments in a macro layer above the allocator
so the allocator doesn't have to constantly re-align to address
boundaries. There is basically no difference between the performance
of heap and stack allocations with a good collector.

That is not a garbage collector. That is "drop everything you don't
need, and we'll never use it again." Oh, sure, not doing garbage
collection at all is faster then doing reference counting.

 2. Work proportional to live data, not total data. This is hard to
believe for a C programmer, but good garbage collectors don't have
to "free" every allocation -- they just have to preserve the live,
or reachable, data. Some researchers have estimated that 90% or
more of all allocated data dies (becomes unreachable) before the
next collection. A ref count system has to work on every object,
but smarter collectors only work on 10% of the objects.

That may work for C, but not for Perl.

sub test {
my($foo, $bar, %baz);
return \%baz;

You may notice that only PART of the locally malloced memory, gets
freed. the memory of %baz may well be in the middle of that pool. You're
making a huge mistake if you simply declare the whole block dead weight.


Re: assign to magic name-of-function variable instead of return

2001-02-07 Thread Bart Lateur

On Tue, 6 Feb 2001 04:36:36 +1100 (EST), Damian Conway wrote:

RFC 271 handles this. Your example would be:

sub readit {
open F, " $f" ...
post readit {
close F;

The connection between these two things is not strikingly obvious. I'd
like it better, if you put the post thing inside the sub readit's
contents. It can even be anonymous.

sub readit {
open F, " $f" ...
close F;

The place where it would be put, would be irrelevant.

sub readit {
close F;
open F, " $f" ...


Re: Really auto autoloaded modules

2001-02-05 Thread Bart Lateur

On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:

  use autoload { Bar = '' },
   { Baz = 'ftp://my.local.domain/perl-modules/Baz', VERSION =
2 };

Very good idea indeed!!! Append the wishlist to add this module to perl6's
standard library!!!

Very *bad* idea. It sounds nice, but using a remote module without any sort 
of control is just begging for trouble.

I agree. Plus, it strikes me as asking for trouble. It sounds make-ish.
So every time you run a script, it could actually *upgrade* your module
behind your back, without you checking it!

But, this discussion gives me yet another idea. Think of a module,
somewhat like the B::* modules. This one could check your script, and
prevent perl from running it, but instead try to install any modules
that you're missing. The installation itself of the modules could be
handled by (an extension of) Of course, it shouldn't upgrade,
i.e. replace, any previously installed modules without your explicit


Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Bart Lateur

On Tue, 30 Jan 2001 04:13:39 -0500, Michael G Schwern wrote:

Is there any really good reason why sleep() doesn't work for
microseconds?  I mean, if I can do this:

sub sleep {
my($time) = shift;
if( /^[+-]?\d+$/ ) {
else {
select(undef, undef, undef, $time);

Why can't Perl?

One of your problems is that sleep(3) is NOT garanteed to sleep exactly
3 full seconds. It's only garanteed that the difference between time()
before, and after, will be (at least) 3. So sleep 3 actually just has to
wait for 3 time second rollovers. That may take for example only 2.5

Well, that's how it *used* to be. Maybe perl's behaviour has been
changed since then.

If you expect sleep(2.5) to work properly, then sleep(3) should be
fixed, too.


Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Bart Lateur

On Tue, 30 Jan 2001 21:39:25 +0100, [EMAIL PROTECTED] wrote:

Why the urge to move it out of the core? Should perl6 be like Python,
where you first need to do a gazillion imports before you can do anything
useful? Say goodbye to quick one-liners then.

It doesn't have to be like that. Functions that are not in the core can
still be automatically loaded, but only if your code actually uses them.
That could make the perl kernel a lot smaller than it is now, and
hopefully, make it load faster.


Re: Why shouldn't sleep(0.5) DWIM?

2001-01-31 Thread Bart Lateur

On Wed, 31 Jan 2001 08:53:13 -0600, Jarkko Hietaniemi wrote:

So nice of you to volunteer for being our help desk person man for
explaining to people why their time() just got broken :-)

I'd use the same function name for both the integer version of time(),
and the hires version. All you need is an optional parameter, whicch, if
true, makes time() return a float.

$a = time();#same as now
$b = time(undef)  # idem
$c = time(1)# hires


Re: RFC195: Do not remove 'chop' PLEASE!

2001-01-29 Thread Bart Lateur

On Mon, 29 Jan 2001 11:47:47 -0500, Uri Guttman wrote:

well, according to this

perl5.6.0 -le '%h = qw( a b c d ); $_ .= 1 for %h ; print values %h ; chop %h ; print 
values %h'

it doesn't appear to be a chop specific thing. unraveling a hash always
seems to use aliases for the values. chop just takes a list like it
always has.

If you're talking about values(%h) returning aliases to the values in
the hash: well, that's a pretty recent thing. It wasn't like that in pre
5.6.0 (or near) days. I remember complaining about this not being the
case in comp.lang.perl.misc, just one year ago (Deja finds a message
dated 01/16/2000, subject line "values() does not return LValues").


Re: JWZ on s/Java/Perl/

2001-01-28 Thread Bart Lateur

On Sat, 27 Jan 2001 18:16:52 -0500, Michael G Schwern wrote:

   o The architecture-interrogation primitives are inadequate; there is no
 robust way to ask ``am I running on Windows'' or ``am I running on

**We have $^O, but it requires parsing every time**

Uhm, I'm sorry, but that's not good enough. You cannot distinguish
between Windows 95/98/ME on one side, and NT/2k on the other, using $^O
alone. After all, $^O is just a constant burnt into the executable when
perl was compiled. You can run the same perl.exe on all platforms, and
indeed, most people do. Yet win9* and NT are different enough in
behaviour (e.g. flock) to warrant a test on platform. Er... which is: no


Re: RFC195: Do not remove 'chop' PLEASE!

2001-01-28 Thread Bart Lateur

On Sat, 27 Jan 2001 15:42:43 -0700, root wrote:

I read RFC195 suggesting to drop 'chop' and go with 'chomp'.
What does 'chop' have anything to do with 'chomp'?
I'm totally oppose to that. Consider:

my $s;
map { /\S/  $s .= "$_ " } split(/\s+/,@_);
return $s;

Excuse me, but you're using chop() for a task it wasn't invented for.
Think about joining your strings with more than one character.

my $s;
map { /\S/  $s .= "$_ - " } split(/\s+/,@_);
return $s;

That doesn't quite cut it, does it?

Here's how you should have written your code:

return join ' ', grep { /\S/ } split(/\s+/,@_);

I, too, once used chop() to get the last character of a string, in my
case to calculate a barcode check digit.

while(my $digit = chop($barcode)) {

The while loop should have continued until $barcode was empty, all
digitis consumed. Well, the fact that "0" is false really spoilt it for

And in case you're wondering why I wanted to process a barcode from the
back: because the total number of dogots isn't always the same, and the
last digit is the only one you're always sure of on how it ought to be
processed. For the following digits, you always have to toggle the
behaviour of the processing.

The full story is: chop() is not a generic operator, but one
specifically intended for one dedicated task: dropping the newline from
a string read from a file. If you use it for anything else, it probably
sooner or later will bite you. And it's not particularily good at what
it *was* designed for, e.g. with a file not ending in a newline.


Re: code name for perl 6

2000-10-20 Thread Bart Lateur

On 19 Oct 2000 22:01:23 -, [EMAIL PROTECTED] wrote:

the code name "omega" would be a fitting handle...after all, this will be
the last perl of all...i am obviously assuming perl 6 will not be still born.

Hey, why not something in the line of "2PI" ("P2PI"?). After all, 2 * PI
is what the version number should asymptotically head for, according to
that RFC that Larry Wall mentioned in his talk.


Re: RFC 124 usefulness implementation suggestion

2000-10-18 Thread Bart Lateur

On Mon, 16 Oct 2000 11:28:37 PDT, Carl Wuebker wrote:

  I'd like to put in a pitch for RFC 124 in Perl 6.  Balanced binary
trees (such as AVL or red-black trees) allow O(log2 n) insertion, searching,
outputting ranges of keys  deletion.  I wouldn't want to touch existing Perl
hashes, but it would be very useful to be able to associate a sort routine
with certain hashes  have those hashes maintained as balanced binary trees.
The speed advantage would be in not having to sort keys every time the hash
is changed.

But isn't there going to be a large overhead, in populating such a
"hash"? Doesn't the tree have to be reorganized every time you add a
single new entry?

The O(...) of the algorithm doesn't say everything. It doesn't mention
the multiplication constant.

Reading can be fast, I grant you.


Re: renaming local to fornow (or maybe just now)

2000-10-18 Thread Bart Lateur

On Wed, 18 Oct 2000 17:45:56 -0500, David L. Nicol wrote:

"Now" is regularly used in English to separate the present from the general,
for instance the temporary situation

   "The Chiefs have scored a touchdown, now they will try for the extra point"

could be expressed in gamerules::americanfootball as

   now $points{touchdown} = 1;
   now $points{fieldgoal} = 1;

If you're still using "now" as a replacement for "local", shouldn't the
Chiefs loose their points at the end of the match, or even some time

In other words: I don't think it really works.

I'm all for renaming local(), mind you.


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

2000-10-05 Thread Bart Lateur

On Thu, 05 Oct 2000 11:08:00 -0700, Peter Scott wrote:

May I point out that COBOL was designed by a committee.

That ain't bad enough.

Let me point out that we don't need another Ada or PL/1.


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

2000-10-04 Thread Bart Lateur

On Wed, 04 Oct 2000 03:15:22 -0600, Tom Christiansen wrote:

We did this for the camel.   Which, I remind the world, was 
written in pod.

You, masochist.

(duck, and run)


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

2000-10-02 Thread Bart Lateur

On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote:

But, why not suggest SDF instead of XML?  SDF addresses most of POD's
deficiencies whill still retaining readability.  (I don't have a URL
for SDF handy, but I'm sure a quick search on would turn it

It is based upon POD, which might help in lowering the entry threshold.


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

2000-10-02 Thread Bart Lateur

On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote:

 XML never had human writable simplicity and never will.

XML is intrinsically no more or less difficult to write than HTML.

The problem with XML is that it is so unforgiving; I think somebody
already mentioned that. Improperly nested tags, or one character it
doesn't recognize... and the parser says "nyet".


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

2000-10-02 Thread Bart Lateur

On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:

 Improperly nested tags, or one character it
 doesn't recognize... and the parser says "nyet".

I read that as "the machine will tell me when I messed up".

I'd rather have a machine tell me than have to figure it
out myself. I think I claim some of the Good Laziness there  :-)

That's not my experience with XML::Parser. It gives some weird error
message, mentions a line number and a column number that doesn't even
exist... and that's it. It's not very helpful. You usually don't even
get any output so you can see where and how you messed up.

It's the same Good Laziness that tells me it's no good.


redraft for v2: RFC 332 Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

2000-10-01 Thread Bart Lateur

=head1 TITLE

Regex: Make /$/ equivalent to /\z/ under the '/s' modifier

=head1 VERSION

  Maintainer: Bart Lateur [EMAIL PROTECTED]
  Date: 1 Oct 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 332
  Version: 2
  Status: Developing (redraft)


To most Perlers, /$/ in a regex simply means "end of string". This is
only right, if you're absolutely sure your string doesn't end in a
newline, as is commonly the case in a large part of all textual data:
ordinary strings don't contain newlines. Lines coming from text files
can generally only contain a newline as the very last character. The
'/s' modifier is usually only used in combination with the former class
of textual data.

However, this situation is basically a bug hole.

This RFC proposes to change the '/s' modifier so that under '/s', /$/
will only match at the very end of a string, and not also before a
newline at the end of the string.

=head1 CHANGES

=over 4

=item *
Added section about alternatives, such as the addition of the /$$/

=item *
Added section about /z/ and /\Z/

=item *
Expanded section on '/ms'.

=item *
Complete rewrite of "MIGRATION" section



To most Perl programmers, /^foo$/ is a regex that can only match the
string "foo". It's not, actually: it can match "foo\n", too. This
assumption is usually safe, because people know the kind of data they're
dealing with, and they "know" that it won't ever end in a newline.

However, this basically is a chance for bugs to creep in, if for some
reason this assumption about the data no longer holds.

To make matters worse, Perl doesn't even have a mechanism to prevent the
regex engine from matching /$/ at just before the last character if it's
a newline.

Originally, we had thought of adding Yet Another Regex Modifier; but to
be honest, having 2 modifiers just for the newline is already confusing
enough, for too many people. A third is definitely out.

Therefore, the proposal is instead to modify the behaviour of the '/s'

Under '/s':

=over 2

=item *

/./ can match any character, including newline;

=item *

/$/ can match only at the very end of the string, not also in front of a
last character, if it happens to be a newline.


This seems simple enough.


=head2 Mnemonic value of '/s'

'/s' originally stood for "single line". This can no longer be true, the
mnemonic value of the "s" is thereby reduced to zero.

However, the mnemonic value wasn't that great to begin with, especially
if you consider that combining '/s' and '/m' is not only possible, but a
useful option, too. How can a string both be a single line and
multiline, at the same time?

So, to most Perl programmers, '/s' simply stands for

=over 2

let /./ match a newline too


which now gets turned into:

=over 2

treat "\n" as an ordinary character


The change isn't that big, so it is just as easy to remember. Or not.

=head2 The $* variable

'/s' and '/m' also have a lesser known side effect: they both override
the setting of the $* special variable, which controls multiline related
behaviour in regexes.

Use of this special variable has already been deprecated at least since
Perl5 first came out, more than 5 years ago. It is a very good candidate
to be removed from Perl6 altogether, which would result in fewer
gotcha's in the language. That is a Good Thing.

Perlvar says:

Use of `$*' is deprecated in modern Perl, supplanted by the `/s'
and `/m' modifiers on pattern matching.

Therefore, any changing behaviour of '/s', with regards to $*, can
nowadays hardly be considered relevant, any more.

See also LRFC 347: Remove long-deprecated $*

=head2 '/ms': combined '/m' and '/s'

The '/m' option makes /$/ match either at the end of the string, or
before Iany newline. Adding the '/s' modifier won't change that. As a
result, '/ms' still works as before. Internally, '/m' has taken over the
job of matching before a newline at the very end of the string, simply
because /$/m can match before Ievery newline.

=head2 /\z/ and /\Z/

The behaviour of /\z/ and /Z/ will remain unaltered, under all

Currently, /$/ is a synonym for /\Z/, even under '/s'. With the modified
'/s', /\Z/ will retain its old meaning, thereby these will no longer be
synonyms under all circumstances.


The Perl5 To Perl6 converter can replace every occurence of




However, it's not unlikely that currently having /$/s in your regexes,
is actually a bug in your script, but you don't care because the data
won't ever make it visible. A warning if /$/ is found in combination
with a bare '/s' modifier, not combined with '/m', in addition to
replacing it with /\Z/, might be a nice idea.


Under '/s', make '$' behave as /\z/ does now.


Some people, in particular Hugo, would r

redraft (v2) for RFC 348 Regex assertions in plain Perl code

2000-10-01 Thread Bart Lateur

=head1 TITLE

Regex assertions in plain Perl code

=head1 VERSION

  Maintainer: Bart Lateur [EMAIL PROTECTED]
  Date: 28 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 348
  Version: 2
  Status: Developing (candidate for freeze)


Likely the most justifiable reason to want to be able execute embedded
Perl code while trying to match a regex pattern, is to include some
extra tests on the data just matched. The fact that the current
implementation of the "experimental" /(?{...})/ construct, doesn't do
just that, feels like a design mistake. So the proposal is to drop the
current implementation of (?{...}) in favour of code assertions.

=head1 CHANGES

=over 2

=item *
Removed stress on deleting "local" feature

=item *
Added examples on why other "advanced" features are or aren't



Likely the most justifiable to want to be able to execute Perl code in a
regex, is to have additional checks, to see if what you just matched is
indeed acceptable. Quite a few prominent Perl people have expressed
having been unpleasantly surprised when they found out that the current
implementation of /?{...}/ doesn't do that.

Assertions are already familiar to people writing regexes: for example,
/\b/, lookahead and lookbehind, and anchors, are all assertions, but
only in matching subpatterns, not in code. Adding the option to do
similar tests in code, seems like a powerful addition, while maintaining
the basic spirit of regexes.

The main problem with the current implementation of (?{...}) is that it
"always succeeds". In case of an assertion, it is the outcome of the
execution of the embedded code, that decides if the test succeeds
(return value is true), meaning it is safe to continue; or fails (return
value is false), in which case the regex engine should abort exploring
this branch, and immediately backtrack.

=head2 example

RFC 197 proposes a specific syntactic addition to regexes, just to check
if a number is in a specific range. This is just one of the many things
that could easily achieved using an assertion:

/(\d+)(?{$1256})/  # proposed syntax, recycling Perl5's syntax 

If your string = "1234", the subpattern /(\d+)/ initially matches all
digits, stuffs them in $1, and calls the assertion code. This code
additionally if what was matched is within range, in this case, less
than 256. If this fails, the submatch fails.

This feature might result in matching some unexpected substrings: both
"123 and "234" are acceptable matches according to this assertion. In
order only to match what you really want to match, you may have to add
some anchors, lookahead and/or lookbehind. So it will take some getting
used to. This does not make it less valuable.

=head2 Getting rid of the current (?{...}) construct

The current implementation for embedding code in regexes, is not aimed
at assertions. Instead, it's only useable for its "effect at a
distance", which is simply horrible. Basically, it simply provides a
means to pass data around between various parts of the regex. This is a
unhealty situation, since it makes regexes that use it, look incredibly
obfuscated, and it requires deep knowledge on how a match in a regex

In addition, it promotes changing global data structures. Since the code
is executed everytime something promising is matched, and not just after
a complete match, the code will probably be executed more often than

That is the reason why Perl5 has built-in support to Itemporarily
modify global data structures, so that the effect can automatically be
undone when backtracking. This makes the implementation very tricky. I
wouldn't be surprised if precisely this feature is the main reason why
the current implementation is so notoriously unstable.

Richard Proctor even wants to go further still: in his RFC 274,
"Generalised Additions to Regexs", he proposes to add support for
executing some embedded Perl code only while backtracking, specifically
to undo changes by hand. I think that this would make the situation even
worse than it is today.

Even knowing when and why the embedded code is executed, is far from
obvious. Take this example:

  $_ = "SKIP buzzer";
  if(/(?{print "Testing\n";})([a-z])\1(?{print "Got a match: $1\n"})/) {
  print "YES\n";
  } else {
  print "NO\n";

This prints:

  Got a match: z

The fact that the embedded code is called 3 times, not more, surely
suprised me. It probably will surprise many people. Apparently, it is
only executed once for every lowercase letter, not just for any

This inpredictability is yet another reason to discourage incrementally
modify global data structures.

=head2 enter assertions

The above considerations, which are annoying at least for executing
embedded generic code, are not hindr

Re: redraft (v2) for RFC 348 Regex assertions in plain Perl code

2000-10-01 Thread Bart Lateur

On Sun, 01 Oct 2000 18:43:27 +0100, Hugo wrote:

:This makes the implementation very tricky. I
:wouldn't be surprised if precisely this feature is the main reason why
:the current implementation is so notoriously unstable.

I'm not aware of any instability caused by this. The instability is
caused by various other factors, discussed at length on p5p.

I'll remove that in the final RFC. I'll just say that implementation of
"local" is nontrivial.

:=head2 /(?(condition)yes-pattern|no-pattern)/

The simplest form of this is (?(1)yes|no). This is rather harder to
emulate with other mechanisms without running to eval. OTTOMH it is
equivalent to (??{ defined($1) ? 'yes' : 'no' }).

You're forgetting about assertions. Now *that* is something starge to
overlook.  ;-)

(?:(?{defined $1})yes|(?{not defined $1})no)


Re: RFC 229 (v2) Variable interpolation on demand.

2000-10-01 Thread Bart Lateur

On Fri, 29 Sep 2000 15:30:46 -0500, David L. Nicol wrote:

it's not a new feature.  It's amazing the subtle control you
can get with s/(\$...)/$1/ge depending on your 

Wrapping such a critter up in a tied scalar sounds like a total
piece of cake

What will you do with:



Some huge piece of cake.


Re: RFC 327 (v2) C\v for Vertical Tab

2000-10-01 Thread Bart Lateur

On 29 Sep 2000 17:11:31 -0700, Russ Allbery wrote:

Just out of curiosity, and I'm not objecting to this RFC, has anyone
reading this mailing list actually intentionally used a vertical tab for
something related to its supposed purpose in the past ten years?

I agree. RFC's like this one seem like a complete waste of time to me.

It's a pity that writing a complete, thorough RFC on a valuable but
difficult feature, is a lot harder than this kind of simple, er, shit.
(No hard feelings towards the authors.) So we end up retracting a lot of
interesting RFC's, while keeping things like this.


Re: RFC 290 (v3) Better english names for -X

2000-10-01 Thread Bart Lateur

On 1 Oct 2000 06:48:11 -, Perl6 RFC Librarian wrote:

-r  freadable()
-R  Freadable()

This still doesn't sound like an improvement. I can remember that -r
stands for readable, but the difference between -r and -R is very
obscure. How to remember which is which? The "English" counterparts
still have the same problem.


Re: RFC 348 (v1) Regex assertions in plain Perl code

2000-09-30 Thread Bart Lateur

On Sat, 30 Sep 2000 00:57:47 +0100, Hugo wrote:

:"local" inside embedded code will no longer be supported, nor will
:consitional regexes. The Perl5 - Perl6 translator should warn if it
:ever encounters one of these.

I'm not convinced that removing either of these are necessary to the
main thrust of the proposal. They may both still be useful in their
own right, and you seem to offer little evidence against them other
than that you don't like them.

"local" promotes the idea of semi-permanently changes global data. That
is a very coding practice, it shouldn't be encouraged. The fact that
it's pretty hard to predict precisely when embedded code will be called
(see the example in the RFC), that too, conflicts with this.

It most definitely doesn't fit into the spirit of assertions.

There's an RFC requesting that *all* of these advanced features should
go. There's no justification there, either. I'm limiting myself here to
mentioning the features I do no consider essential for assertions to be
useful. It doesn't need local. Is that good enough for you? You may keep
it if you wish, but it is not essential.

And I do think that the semantics of "local" don't fit well into the
rest of Perl. Clearly, in

(?{local $c = $c+1 })

the scope of $c should be limited to this embedded code block!?!

I do like the idea of making (?{...}) an assertion, all the more
because we have a simple migration path that avoids unnecessarily
breaking existing scripts: wrap $code as '$^R = do { $code }; 1'.

Good. :-)

If you want to remove support for 'local' in embedded code, it is
worth a full proposal in its own right that will explain what will
happen if people try to do that. (I think it will make perl
unnecessarily more complex to detect and disable it in this case.)

Quite the contrary, I think. My guess is that this support for loacl
*complicates* implementation, and probably by a substantial amount.

Similarly if you want to remove support for (?(...)) completely,
you need to address the utility and options for migration for all
the available uses of it, not just the one addressed by the new
handling of (?{...}).

You're talking about conditional regexes? I am curious to see just *one*
good reason to keep them in. I've not yet seen anything using a  regex
that makes use of it (appart from Perl5's embedded code assertions),
that can't be done without it. Anybody is free to prove me wrong. 


Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching

2000-09-30 Thread Bart Lateur

On Tue, 26 Sep 2000 11:55:32 +1100 (EST), Damian Conway wrote:

Wouldn't this interact rather badly with the /gc option (which also leaves
Cpos set on failure)?


The easy way out is disallow combining /gc wit h/z. But, since this
typically one of the applications it is aimed for, I should find a
solution. A different interface, is one option.

This question arose because I was trying to work out how one would write a
lexer with the new /z option, and it made my head ache ;-)

Heheh. Your turn.   ;-)

I'm not sure I see that this:
is less intimidating or closer to the "ordinary program flow"  than:

   \*FH =~ /(abcd|bc)/g;

(as proposed in RFC 93).

Was that what was proposed? I think not. It was:

sub { ... } =~ /(abcd|bc)/g;

But I kinda like that syntax. But, in practice, it looks too much like
black magic:

 * where is the sting stored? It looks like it disappears into thin air.
 * What about pushback? Your proposal depends on it, but standard
filehandles don't support it, IMO. Does this require a TIEHANDLE

 * Your regex shouldn't consume any more characters friom the filehandle
than it matches? Where are the reamining characters pushed back into?

After every single keystroke, you can test what he just 
entered against a regex matching the valid format for a number, so that 
C1234E can be recognized as a prefix for the regex


Isn't this just:

   \*STDIN =~ /^\d+\.?\d*(?:E[+-]?\d+)$/
   or die "Not a number";


No. First of all, you can't override the behaviour of STDIN. That reads
a whole line, then checks it, and then your script dies if it's not

I want a test on every single keystroke, see if it's in sync with the
regex, and if it's not, reject it, i.e. no insertion in the uinput
buffer, and no echo on screen. Besides, you can't be sure your data
comes from a filehandle (or compatible handle). Not in a GUI.


Re: RFC 72 (v4) Variable-length lookbehind.

2000-09-30 Thread Bart Lateur

On 30 Sep 2000 19:50:27 -, Perl6 RFC Librarian wrote:

In Perl6, lookbehind in regular expressions should be extended to permit
not only fixed-length, but also variable-length lookbehind.

I see no mention of negative lookbehind.

As I wrote before, in:


The lookbehind should fail if *any* lookbehind string can be found
matching, and not succeed if there's a string to be found that doesn't
match! In the latter case, negative lookbehind would be useless.


Re: RFC 331 (v1) Consolidate the $1 and C\1 notations

2000-09-30 Thread Bart Lateur

On 28 Sep 2000 20:57:39 -, Perl6 RFC Librarian wrote:

Currently, C\1 and $1 have only slightly different meanings within a
regex.  Let's consolidate them together, eliminate the differences, and
settle on $1 as the standard.

I wrote this before, but apparently you didn't hear it. Let me repeat:
$foo on the LHS allows metacharacter matching, for example "a.*b" can
match "a foo b". But \1 only allows literal strings. If $1 captured
"a.*b", then \1 will only match the literal string "a.*b", as if the
regex contained "a\.\*b".

I don't see how you can possibly consider this a "tiny difference".


Re: RFC 288 (v1) First-Class CGI Support

2000-09-30 Thread Bart Lateur

On 25 Sep 2000 06:01:57 -, Perl6 RFC Librarian wrote:

Perl6 should be *easier* to write CGI programs than Perl5.

To make CGI programming easier, this option/pragma should:
Parse the CGI context, returning CGI variables into %CGI

I like that one.

Not take up gobs of memory

That too.

All of the other features offered by Lincoln Stein's should remain,
but should not be deeply integrated into Perl6.

Eek, no! I don't want no steenking p() functions etc. to generate HTML
on the fly! That is one feature I never ever use. It also conflicts with
the remark about memory usage. Plus, do we need a new Perl upgrade every
time a new HTML tag comes out? I think not. Keep HTML tags out of Perl.
If people want it, they can use an easiliy updateble module.

CGI::Minimal would be more like it.


Re: RFC 288 (v1) First-Class CGI Support

2000-09-30 Thread Bart Lateur

On 25 Sep 2000 06:01:57 -, Perl6 RFC Librarian wrote:

All of the other features offered by Lincoln Stein's should remain,
but should not be deeply integrated into Perl6.

No cookie support, please. Cookies should remain in a module.


Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin

2000-09-30 Thread Bart Lateur

On Tue, 26 Sep 2000 11:13:30 -0700, Nathan Wiger wrote:

   -{rwx};   # negation of a hashref

That's a weird hashref. Odd number of arguments, anyone?

If rwx is supposed to be a sub, we could say that this is an exception,
just like $hash{bareword} is an exception. So, if you want the sub, use


Need I still say that this one is my favourite?   :-)


Re: my and local

2000-09-30 Thread Bart Lateur

On Thu, 28 Sep 2000 10:18:34 +0100, Tom Christiansen wrote:

my is fine, but local
should be changed to something like "temporary" (yes, that
is supposed to be annoying to type) or "dynamic".

I like "temporary" best, because it says exactly what the purpose is:

temporary $x = $x+2;

This $$x is a temporary value. It's indeed long to type, which might
indeed be a Good Thing, because it discourages using it. I guess that is
what Tom means when he says that it "is supposed to be annoying to

Other words, like "save" etc. say how it works, not what it's for.
That's a Bad Thing.

"dynamic" is a bit vague in meaning.

dynamic $x = $x + 2;



Re: RFC 355 (v1) Leave $[ alone.

2000-09-30 Thread Bart Lateur

On 30 Sep 2000 20:13:55 -, Perl6 RFC Librarian wrote:

But setting $[ = 1 is the mathematically correct method for
array addressing and makes it easier for ordinary mortals to do
basic tasks with Csubstr(), array addressing and the like.

I sure don't want the fact that a scripter decides to change $[, make
used modules fail, because the module's author didn't anticipate that.

Does this not imply that $[ should become lexically scoped?


Re: RFC 288 (v1) First-Class CGI Support

2000-09-30 Thread Bart Lateur

On Sat, 30 Sep 2000 16:39:04 -0400, Adam Turoff wrote:

I repeat:

 All of the other features offered by Lincoln Stein's should remain,
 but should not be deeply integrated into Perl6.

The proposed 'use cgi;' pragma is concerned with gluing Perl into a cgi
context.  No more, no less.


I'm open to suggestions if the nominclature/distinction is too confusing.

It *is* confusing. It sounded as if you wanted the whole module
to be turned into a pragma.

I like taint. I like %CGI. I like %HTTP. Form processing, basic header
generation; I think that should be it.


  1   2   3   >