Re: rethinking printf
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}
--
Bart.
Re: 123_456
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. -- Bart.
Re: Apoc4: The loop keyword
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. -- Bart.
Re: Apoc 4?
On Fri, 18 Jan 2002 12:33:48 -0500, Will Coleda wrote: http://www.perl.com/pub/a/2002/01/15/apo4.html David Whipp wrote: Michael G Schwern wrote: Reading this in Apoc 4 ... I looked on http://dev.perl.org/perl6/apocalypse/: 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. -- Bart.
Re: Perl 6 - Cheerleaders?
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 Damians. http://www.perl.com/pub/a/2001/10/23/damians.html I just hope that you don't really have to insert that many blank lines in your code just to make it compile. -- Bart.
Re: Indenting
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. FINIS 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. -- Bart.
Re: General Feelings on Apoc 3
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 operator. 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. -- Bart.
Re: EX3: $a == $b != NaN
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 is: 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? -- Bart.
Re: EX3: Adverbs and print()
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...
--
Bart.
Re: NaN semantics
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 temperature...) 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? -- Bart.
Re: reduce via ^
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.
--
Bart.
Re: Just a thought...
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
direction.
As in Lisp, you can use p.
sub is_visiblep { ... }
;-)
--
Bart.
Re: Customizable default hash and array values.
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.
--
Bart.
Re: ! and !
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 !. -- Bart.
Re: Semi-OT: Good compiler book?
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. -- Bart.
Re: new syntax idea: eval ...o;
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.
--
Bart.
Re: if then else otherwise ...
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. -- Bart.
Re: if then else otherwise ...
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. -- Bart.
Re: if then else otherwise ...
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. http://www.engr.umd.edu/~nsw/ench250/fortran1.htm#IFA -- Bart.
Re: as long as we are discussing 'nice to have's...
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 modules...it 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. -- Bart.
Re: aliasing - was:[nice2haveit]
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.
--
Bart.
Re: precision belongs in bigfloats, nowhere else.
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, http://www.mike95.com/c_plusplus/tutorial/algorithms/Euclid.asp, for how. (Changing the program from using recursion to using a loop is trivial.) -- Bart.
Re: nice2haveit
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
like:
my \%foo = \%bar;
(Now %foo is an alias to %bar.)
--
Bart.
Re: Multiple classifications of an object
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. -- Bart.
Re: ~ for concat / negation (Re: The Perl 6 Emulator)
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. -- Bart.
Re: Social Reform
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 Vijay. 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 kittens. -- Bart.
Re: Damian Conway's Exegesis 2
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.
--
Bart.
Re: Apoc2 - STDIN concerns
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. -- Bart.
Re: what I meant about hungarian notation
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
$bar[$foo]
would mean: that depends on what $bar contains.
(Aw! That hurt!)
--
Bart.
Re: A proposal for more powerful text processing to be built in to Perl: Flex and Pushdown Expressions.
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?
Sortof.
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.
--
Bart.
Re: Apoc2 - STDIN concerns
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 $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... 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. -- Bart.
Re: what I meant about hungarian notation
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. -- Bart.
Re: what I meant about hungarian notation
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. -- Bart.
Re: what I meant about hungarian notation
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. -- Bart.
Re: Apoc2 - STDIN concerns ::::: new mascot?
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 symbol. http://www.effectiveperl.com Scroll down to the heading Book Nickname (?). It took me a bit of thinking before I realized what this shiny ball represents. Odd. -- Bart.
Re: what I meant about hungarian notation
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. -- Bart.
Re: apo 2
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 away. 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 END 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. -- Bart.
Re: apo 2
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. NOD 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. -- Bart.
Re: Please make last work in grep
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()? -- Bart.
Re: Please make last work in grep
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. ;-)
--
Bart.
Re: Curious: - vs .
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() syntax. -- Bart.
Re: a modest proposal Re: s/./~/g
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 -3.4 and in 2-3.4 the - sign is a *different* kind of operator. No conflict. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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.
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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?
--
Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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.
--
Bart.
Re: Sane + string concat proposal
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 name. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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:
PATH=/some/long:/bunch/of:/stuff
PATH=${PATH}:/more/stuff
would really be a shame.
A backslash at the end of a line?
Kidding!
--
Bart.
Re: Tying Overloading
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. -- Bart.
Re: Tying Overloading
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. -- Bart.
Re: Sane + string concat proposal
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. -- Bart.
Re: Strings vs Numbers (Re: Tying Overloading)
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
interpolation!
$this$is$just$as$ugly$but$it$works
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
lexicals.
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.
--
Bart.
Re: Tying Overloading
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; or $a = $b cat $c; -- Bart.
Re: Schwartzian transforms
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! -- Bart.
Re: Schwartzian Transform
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: HoA HoH LoA LoH -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 example. So even with warnings on by default, Perl is still pretty mild. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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 languages. 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. -- Bart.
Re: Warnings, strict, and CPAN (Re: Closures and default lexical-scope for subs)
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};
--
Bart.
Re: The binding of my (Re: Closures and default lexical-scope
On 17 Feb 2001 20:53:51 -0800, Russ Allbery wrote: Could 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. -- Bart.
Re: End-of-scope actions: do/eval duality.
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 do FILE where file is a string containing a filename, while Tony is talking about the do BLOCK form. do FILE behaves just like eval() (except it reads its data from a source file), while do BLOCK doesn't. Neither. -- Bart.
Re: JWZ on s/Java/Perl/
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
that.
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.
--
Bart.
Re: Auto-install (was autoloaded...)
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. -- Bart.
Re: Auto-install (was autoloaded...)
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. -- Bart.
Re: JWZ on s/Java/Perl/
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.
--
Bart.
Re: assign to magic name-of-function variable instead of return
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" ...
scalar(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" ...
scalar(F)
POST {
close F;
}
}
The place where it would be put, would be irrelevant.
sub readit {
POST {
close F;
}
open F, " $f" ...
scalar(F)
}
--
Bart.
Re: Really auto autoloaded modules
On Mon, 05 Feb 2001 11:35:59 -0500, Dan Sugalski wrote:
use autoload { Bar = 'http://www.cpan.org/modules/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) CPAN.pm. Of course, it shouldn't upgrade,
i.e. replace, any previously installed modules without your explicit
consent.
--
Bart.
Re: Why shouldn't sleep(0.5) DWIM?
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+$/ ) {
sleep($time);
}
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
seconds.
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.
--
Bart.
Re: Why shouldn't sleep(0.5) DWIM?
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. -- Bart.
Re: Why shouldn't sleep(0.5) DWIM?
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 -- Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
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' b1d1 bd 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"). -- Bart.
Re: JWZ on s/Java/Perl/
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 Unix.'' **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 go. -- Bart.
Re: RFC195: Do not remove 'chop' PLEASE!
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+/,@_);
chop($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+/,@_);
chop($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
me.
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.
--
Bart.
Re: code name for perl 6
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.
--
Bart.
Re: RFC 124 usefulness implementation suggestion
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. -- Bart.
Re: renaming local to fornow (or maybe just now)
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
earlier?
In other words: I don't think it really works.
I'm all for renaming local(), mind you.
--
Bart.
Re: RFC 357 (v2) Perl should use XML for documentation instead of POD
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. -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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) -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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 google.com would turn it up) http://www.mincom.com/mtr/sdf/ It is based upon POD, which might help in lowering the entry threshold. -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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". -- Bart.
Re: RFC 357 (v1) Perl should use XML for documentation instead of POD
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. -- Bart.
redraft for v2: RFC 332 Regex: Make /$/ equivalent to /\z/ under the '/s' modifier
=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) =head1 ABSTRACT 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 /$$/ syntax =item * Added section about /z/ and /\Z/ =item * Expanded section on '/ms'. =item * Complete rewrite of "MIGRATION" section =back =head1 DESCRIPTION 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' modifier. 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. =back This seems simple enough. =head1 CONSIDERATIONS =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 =item let /./ match a newline too =back which now gets turned into: =over 2 =item treat "\n" as an ordinary character =back 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 cicumstances. 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. =head1 MIGRATION The Perl5 To Perl6 converter can replace every occurence of /$/s with /\Z/s 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. =head1 IMPLEMENTATION Under '/s', make '$' behave as /\z/ does now. =head1 ALTERNATIVES Some people, in particular Hugo, would r
redraft (v2) for RFC 348 Regex assertions in plain Perl code
=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)
=head1 ABSTRACT
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
indispensable
=back
=head1 DESCRIPTION
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
proceeds.
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
desired.
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:
Testing
Testing
Testing
Got a match: z
YES
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
character.
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
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)
--
Bart.
Re: RFC 229 (v2) Variable interpolation on demand.
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:
${foo}bar
$hash{blah}
$ary[blah]
\xFE
\123
\n\t
etc?
Some huge piece of cake.
--
Bart.
Re: RFC 327 (v2) C\v for Vertical Tab
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. -- Bart.
Re: RFC 290 (v3) Better english names for -X
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. -- Bart.
Re: RFC 348 (v1) Regex assertions in plain Perl code
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.
--
Bart.
Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching
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)?
Yes.
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
implementation?
* 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
/^\d+\.?\d*(?:E[+-]?\d+)$/
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
right.
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.
--
Bart.
Re: RFC 72 (v4) Variable-length lookbehind.
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: /(?!ab*c)x/ 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. -- Bart.
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
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". -- Bart.
Re: RFC 288 (v1) First-Class CGI Support
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 CGI.pm 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. -- Bart.
Re: RFC 288 (v1) First-Class CGI Support
On 25 Sep 2000 06:01:57 -, Perl6 RFC Librarian wrote: All of the other features offered by Lincoln Stein's CGI.pm should remain, but should not be deeply integrated into Perl6. No cookie support, please. Cookies should remain in a module. -- Bart.
Re: RFC 320 (v1) Allow grouping of -X file tests and add Cfiletest builtin
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
parens:
-{rwx()}
Need I still say that this one is my favourite? :-)
--
Bart.
Re: my and local
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 type". 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; Huh? -- Bart.
Re: RFC 355 (v1) Leave $[ alone.
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? -- Bart.
Re: RFC 288 (v1) First-Class CGI Support
On Sat, 30 Sep 2000 16:39:04 -0400, Adam Turoff wrote: I repeat: All of the other features offered by Lincoln Stein's CGI.pm 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. Good. I'm open to suggestions if the nominclature/distinction is too confusing. It *is* confusing. It sounded as if you wanted the whole CGI.pm 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. -- Bart.
Re: RFC 355 (v1) Leave $[ alone.
I should have said: file-scoped lexical. On Sat, 30 Sep 2000 21:56:43 +0100, Nicholas Clark wrote: If it's lexically scoped, would it be for arrays declared in that scope, or for arrays accessed in that scope? I'm not sure. I think I see potential breakage both ways. You don't declare Perl arrays. They just exist. Well... except for my'ed arrays. My idea is that if anybody sets $[ to 1 in a script, all accesses to array in that script would use 1 as the index of the very first item: $ary[1]. But if you pass this array (for example, a reference to it) to a function in a module that doesn't set $[, it would access the same first item through index 0: $ary[0] or $ref-[0]. And vice versa (swap "module" and "script"). -- Bart.
Re: RFC 288 (v2) First-Class CGI Support
On 27 Sep 2000 07:36:42 -, Perl6 RFC Librarian wrote: Perl6 make it *easier* to write CGI programs than Perl5. That is a strange sentence. But anyway: whould this imply that URL- and simple HTML escaping and back, will now be available through pack()/unpack()? Just like UUE? ;-) -- Bart.
Re: RFC 316 (v1) Regex modifier for support of chunk processing and prefix matching
On Fri, 29 Sep 2000 13:19:47 +0100, Hugo wrote:
I think that involves
rewriting your /p example something like:
if (/^$pat$/z) {
print "found a complete match";
} elsif (defined pos) {
print "found a prefix match";
} else {
print "not a match";
}
Except that this isn't exactly what would happen. Look, "1234E+2" is a
complete string matching the regex, but it could be that it's just a
prefix for "1234E+21". So, /^$pat$/z should fail. No? This doesn't seem
too intuitive, but that's a result from a minimal interface.
--
Bart.
Re: is \1 vs $1 a necessary distinction?
On Wed, 27 Sep 2000 10:34:48 -0500, Jonathan Scott Duff wrote: If $1 could be made to work properly on the LHS of s///, I'd vote for that being The Way. I disagree, because \1 is different from a variable $foo in at least two ways: * $foo is compiled into /$foo/ before anything is matched. \1 is a repetition of what was just matched; this is dynamic interpolation instead of static. * if $foo contains metacharacters, they are treated as metacharacters. for example, if $foo is "a.b", then /$foo/ can match "axb". /\1/, OTOH, can only match the LITERAL string that $1 captured. With $foo='a.b', /($foo)!$foo/ and /($foo)!\1/ will not match the same set of things. "\1" is more like equivalent to "\Q$1\E". Therefore, I don't want $1 on the LHS to be the standard syntax. -- Bart.
Re: RFC 290 (v1) Remove -X
On 27 Sep 2000 09:16:10 +0300, Ariel Scolnicov wrote: Another option is to stuff the long names into some namespace, and export them upon request (or maybe not export them, upon request). Can you say "method"? -- Bart.
