Re: is it required to use type declarations?
On Wed, Dec 18, 2002 at 09:31:41AM +, Piers Cawley wrote:
Dave Storrs [EMAIL PROTECTED] writes:
It seems like Perl6 is moving farther and farther away from Perl5's
(almost) typelessness.
It depends what you mean by typed. Perl has always had strongly typed
*values* (which strike me as being a damn sight more useful than
typed variables).
No argument from me. When I want/need the abilities that come with
specifying type, I want the language to support it. I just don't want
to _have_ to do it, when I don't want/need those abilities.
In a language with typed values, being able to
declare a typed variable is useful for a few reasons:
* After watching things in a profiler, you sacrifice programmer
flexibility by typing a couple of variables as a way of giving the
Optimizer something to get its teeth into (if you have a typed
variable then you can limit the amount of runtime checking you have
to do in favour of compile time checks)
Agreed.
* For setting up multiply dispatched methods and functions. Consider
the example below (which I know I've used before).
sub grep ( (Rule | Block) $selector, @*args ) { @args.grep($selector) }
sub grep ( (Rule | Block ) $selector, Collection $collection ) {
$collection.grep($selector)
}
sub grep ( WeirdSelector $selector, @*args ) {
grep $selector.as_block, *@args;
}
Because we can declare the types of the function parameters we can
let the language sort out the dispatch for us. Without typed
parameters and multi dispatch those three function definitions
become:
sub grep ( $selector, $first, @*args ) {
if @args.length {
return [ $first, @args ].grep($selector);
}
else {
$first.grep($selector);
}
}
method Object::grep ($self: $selector {
[ $self ].grep($selector);
}
Hm. I'm way short on sleep today, so I'm probably missing something,
but I don't see why Perl can't sort this out without a specific
typing.
On a more nit-picky level, the first two subs in the top block seem to
show that arrays are not derived from Collection. Surely, if
everything is an object, they should be?
Which, to my way of looking at things is deeply ugly.
I certainly find the first version easier to read...which, given my
particular set of prejudices, makes it enormously preferably in my
eyes.
* And last and least, for 'strictness'. Personally I think this is
the least useful choice; the programmer sacrifices flexibility for
having the compiler catch errors that would be more usefully caught
in a test suite. And to make matters worse, if you want the
compiler to catch the errors you have to make *everything*
explicitly typed, and and life's too short for buggering about like
that thank you very much.
Agreed.
--Dks
Re: is it required to use type declarations?
Attribution lists are getting a bit complex. This is in response to what Piers wrote on Wed, Dec 18, 2002 at 03:50:44PM +. DKS [specifying types] Hm. I'm way short on sleep today, so I'm probably missing something, but I don't see why Perl can't sort this out without a specific typing. PC Well, you've got to specify the types *somewhere* when you set up your multimethods. The parameter list seems a better place than most. Ah! Ok, yes, I missed something. I thought you were saying that we would need to type the variables not just in the signature, but in every call to the function/method as well...and that second part is what I was objecting to. No, of course you need to mark the types in the signature. --Dks
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:32:02AM -0800, Michael Lazzaro wrote: $obj.ID; $obj.IDENTITY; FWIW, I favor the latter. --Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
Mind you (purely devil's advocate), I'm not entirely sure the R-to-L
syntax truly _needs_ to be in Perl6. It's true I use it all the time,
but I can retrain to use L-to-R method calls with little effort.\
Personally I really don't like the L to R style;
That's ok. Personally, I do. You find R2L easier to read, I find L2R
easier. TIMTOWDI. Perl6 should be smart enough to support both.
I know we've got it
for C for ... - $a { ... } , but I can see the logic behind
that, otherwise L to R looks worryingly like C++ to me.
I'm not convinced that language snobbery is a good reason to include
or exclude a feature from Perl6. And, if there is logic in having L2R
in one case (for), why shouldn't we generalize it to be useful (or at
least possible) in all cases?
If we have a post-given, e.g. Cmap {...} given @a or Cmap {...} is
given @a, I think that gives us R-to-L without any special {...}
rules at all.
No, just the addition of much ugliness to code for no gain in
readability. And one more area where Perl 6 fails to look like Perl 5
for no good reason.
Personally, I'm not fond of the specific syntax that MikeL is suggesting.
However, I think that L2R is valuable enough that it should make it
into the language, and I don't have a better suggestion.
--Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 08:26:25PM +, Piers Cawley wrote:
Dave Storrs [EMAIL PROTECTED] writes:
On Mon, Dec 16, 2002 at 06:47:39PM +, Piers Cawley wrote:
Michael Lazzaro [EMAIL PROTECTED] writes:
I haven't been arguing against his syntax for adding L to R
pipelines, but against the damage he proposes doing to R to L syntax.
Fair enough. I'd like to find a way for neither of them to go away,
or get damaged.
However, I think that L2R is valuable enough that it should make it
into the language, and I don't have a better suggestion.
Well, L2R is really easy:
@ary.map({...}).grep(rx/.../).whatever(...);
For ugly values of 'really easy' of course.
Yick. I'll definitely agree on the ugly part.
However, I'm curious--and I know this has been hashed over, I'm just
not clear on where we stand at this point--are you proposing that map,
grep, and whatever would be methods on Array? Because that seems
unnecessarily restrictive. And yet, having them be methods of Object
seems a bit TOO generous.
Perhaps the answer is to have an inheritance tree that goes
Object
|
v
Collection
|
+-Array
|
+-Hash
|
+-etc (maybe Set, or maybe junction)
...and map, grep, etc, would be elements of Collection, overriden in
sensible ways by the derived classes?
This is an off-the-cuff idea and I may well be full of it.
--Dks
Re: Everything is an object.
On Mon, Dec 16, 2002 at 03:44:21PM -0500, Dan Sugalski wrote: At 11:12 AM -0800 12/16/02, Dave Storrs wrote: You find R2L easier to read, I find L2R easier. TIMTOWDI. Perl6 should be smart enough to support both. Why? Yes, technically we can do both R2L and L2R. We can also support an alternative Scheme/Lisp form of perl's syntax, as well as a Forth/Postscript style. Heck, we can probably manage a prolog-style unification style for a not-insignificant subset of perl programs. That doesn't mean its a good idea. Just so I'm clear, are you saying that you think L2R is a bad idea, and should not be supported? Or just that it has not yet been demonstrated that this is a good idea? --Dks
Re: Comparing Object Identity
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote: Using the method/attribute named id for this is the same object comparisons is just plain bad Huffman coding. The this is the same object method/attribute should have a name that reflects the relative rarity of its use. FWIW, I have agreed with John throughout this entire thread, but I felt that he was stating things quite clearly and I didn't have anything further to add. I just want to chime in so he doesn't feel like a lone voice in the wilderness. --Dks
Re: is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Wed, Dec 11, 2002 at 12:13:49PM -0700, Luke Palmer wrote: [Dks wrote:] So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? Optional by request, but not explicit request. If you type a variable, you're asking for type checking on that variable. Excellent. That's the best of all worlds. Thanks; I am much relieved. --Dks
Re: REs as generators
On Thu, Dec 12, 2002 at 10:35:47AM +1100, Damian Conway wrote: Dave Storrs wrote: - the ability for the programmer to set limiters (??better name??) on the junction, which will specify how the junction should collapse--e.g. always collapse to the lowest/highest value that hasn't been supplied yet, or to the lowest/highest unsupplied value that causes a particular code block to return true, or whatever. Junctions don't collapse. They distribute. Remember: Junctions Aren't Quantum. Ah. Obviously, I don't know JAQ. (sorry) However, I don't believe this answers my question...or, more likely, I am just misunderstanding junctions. I believe that this code: my $i = one(7...); print $i; Is roughly equivalent to this English: - declare a lexical variable $i - create a junction. The states of the junction are (7..Inf). The type of the junction is one - assign the junction to $i - distribute the junction [that still doesn't sound right, but ok] by choosing one of the states (at random??) - print the number chosen in the previous step. First of all, am I correct about this? Second, what I was originally asking is this: could there be some way for the programmer to attach a (method/code block/sub/whatever) to the junction, such that when the state is chosen, the default method of choosing a state is overriden by the code supplied by the programmer. --Dks
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
On Wed, Dec 11, 2002 at 02:54:18PM -0800, Dave Whipp wrote: Michael Lazzaro [EMAIL PROTECTED] wrote: After thinking about it a little more, I'll set myself on the yes side. And propose either '===' or ':=:' to do it. Definitely '==='. Hopefully, this thread has been settled by Damian's pointing out the existence of id(), but could I put in a strong vote against the use of '===' for anything? It is far too easy to misread as ==, IMHO. --Dks
Re: REs as generators
On Tue, Dec 10, 2002 at 03:38:58PM -0800, Rich Morin wrote: On occasion, I have found it useful to cobble up a little language that allows me to generate a list of items, using a wild-card or some other syntax, as: foo[0-9][0-9] yields foo00, foo01, ... I'm wondering whether Perl should have a similar capability, using REs. Will Perl6 still have the increment a string ability? I can't count the number of times that's been my saving grace when I needed to portably and easily generate a unique filename. --Dks
is it required to use type declarations? (was Re: 'hashkey context/Str context')
On Mon, Dec 09, 2002 at 03:58:54PM -0700, Luke Palmer wrote: From: Dave Storrs [EMAIL PROTECTED] My understanding was that in Perl6, you could use pretty much anything for a hashkey--string, number, object, whatever, and that it did not get mashed down into a string. Did I have this wrong? By default they're keyed by strings. You can smack a property on them to key them by something else, though: my %sparse is keyed(Int); my %anything is keyed(Object); # or UNIVERSAL Hmmm...maybe this is a good time to bring up something that's been bothering me for a while. It seems like Perl6 is moving farther and farther away from Perl5's (almost) typelessness. All of a sudden, we are getting into ints, Ints, Objects, Strs, etc...more and more of the code examples that are being posted to these lists use type declarations in method signatures, variable declarations, and anywhere else that they might squeeze in. It isn't clear to me if this is being done because we are currently discussing the new types and type-safety mechanisms--all of which are optional, and only come into play when you request them--or if it is expected that this will be the new paradigm for Perl programming. So...are we intending that types and type safety will be like 'use strict' (optional and only on request), or will they be like sigils (mandatory, can't be turned off)? Or, perhaps, on by default but able to be turned off? --Dks
Re: [RFC] Perl6 Operator List, Take 5
On Wed, 30 Oct 2002, Larry Wall wrote: If no one saw them then it could well be a problem on my end. I'm trying to use a mailer (pine) that doesn't know about UTF-8 in a «+» b I'm using Pine 4.33 on FreeBSD 4.3, and I see these fine. --Dks
worth adding collections to the core language?
In the Re: Wh[ie]ther Infix Superposition ops thread
On Wed, 30 Oct 2002, Piers Cawley wrote:
But given a decent Collection hierarchy:
my $seen = Set.new($start,$finish);
for - $next {
print $next unless $next =~ $seen;
$seen.insert($next);
}
Just a thought...are sets (or other Collection types) something that we
use often enough that they would deserve to be in the core language? I
know I've used hashes as no-repeats-allowed sets many times, so clearly
they are commonly useful. On the other hand, since this can be done,
maybe there is no need to implement a new core feature for them.
I suspect the answer is no, we don't need them but I just thought I'd
ask; I'm curious about the design reasons either way.
--Dks
plaintive whine about 'for' syntax
In a different thread, Buddha Buck wrote the following code snippet:
for a; b - $x is rw; $y { $x = $y[5] };
And I finally had to whimper publicly about this.
I've been lurking around the P6 process since the very beginning of the
RFC process. I saw the new 'for' syntax come out, and I've watched it get
used by lots of people on this list. My first reaction to it was that's
counterintuitive and scary, and I don't like it. But, that was my
reaction to a lot of the new Perl syntax, and I found that if I just sat
back and pondered it for a bit, I would soon come to realize that the new
syntax was fine, just different--and usually an improvement.
I have honestly tried to have the same sort of reconciliaton with the new
'for' syntax, and I just can't. It's possible that I still just don't
understand it (I'm not sure I do), but I really believe that this syntax
is a Bad Thing and is going to cause a lot of bugs. I have the following
problems with it:
for a; b - $x is rw; $y { $x = $y[5] };
1) This is (AFAIK) the ONLY place in Perl where a semicolon that
is not enclosed in parens is used for anything other than end of
statement (semi is used to separate parts of a perl5 C-style for loop
control statement, but that's in parens, so there is an indication that
the statement isn't over yet).
2) The fact that the $x and $y variables are, by default,
read-only is (again, IMO) bad. Perl's design philosophy has always been
by default, all the freedom (and risk) that's available; if you want less
let me know. Therefore, by default, these variables should be rw, and
you should be able to ask to have them const.
3) Following that same idea, is rw is poor Huffman encoding
for something I'm likely to want fairly often. Could we at least come up
with a single character equivalent? Perhaps something like this:
a - $x # rw ($x can be an lvalue)
a - $x # r ($x can be only be an rvalue)
Either of these could be the default. Of course, what I'd really
like to see is:
a - $x# rw (default)
a - $x # rw (explicitly stated)
a - $x # r ($x can only be an rvalue)
I believe the parser should be able to separate '' used to mean
can be an lval from '' used to mean less than...after all, you would
never alias elements in an array to a _value_ (which is what is returned
by $x $y)...you would only alias elements to a variable. If I'm wrong,
please correct me. If it's going to be a problem, we could clarify it by
putting the bracket to the left of the variable, but then there is some
visual confusion with the head of the arrow operator.
3) While it's really convenient to be able to loop over multiple
arrays and have each one alias to a separate variable, right now the
connection between the array and its alias variable is tenuous at
best...you don't know that $b is aliased until you read down the entire
statement (passing over a semicolon in the way that makes it look like
things have ended). We explicitly moved regex modifiers to the front to
make them more visually distinct and easier to parse; shouldn't we
consider something similar here?
4) Finally, and related to #3, the current syntax makes it look as
though $x is being pulled out of b, when in fact it is being pulled out
of a.
I'm not a language designer and, usually, when I try to suggest
things I end up not seeing problems that they will cause with parsing.
However, just so this post does not consist entirely of negativism, I will
try to come up with a workable alternate syntax:
Current:for a; b - $x is rw, $y; $z { ...stuff... };
The above (IIUC) means loop over a, pulling out two elements at a time
and aliasing them to $x (which is rw) and $y (which is r).
Simultaneously loop over b, aliasing its elements to $z (which is r).
Suggested: for a - $x, $y __ b - $z { ...stuff... };
The above means the same thing, but instead of specifying that $x is rw,
we have specified that $y and $z are r.
At the bottom of this email are a bunch of other options, but the
one above is the one that I like best. My reasons are as follows:
1) Larry seems to have put a strong premium on not needing parens,
so I set that as an absolute requirement.
2) Although having all the streams on the left is very convenient,
I judged it more important to be clear about which stremas were
aliasing to which variable(s).
3) The new operator that I am proposing (__) serves two
purposes: for the human, it introduces a visual break which draws the eye
and makes you notice that there is another stream there, and for the
machine it says ok, we're done with the list of variables being aliased
from a...here's the next stream. I propose calling it the bridge
operator, because you use it to cross one stream in order to get to the
next. I deliberately made
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Michael Lazzaro wrote:
On Wednesday, October 30, 2002, at 12:48 PM, Dave Storrs wrote:
for a; b - $x is rw; $y { $x = $y[5] };
I agree that it's an eyeful. How many of your issues could be solved
if the above were just written:
for (a;b) - ($x is rw; $y) { $x = $y[5] };
Would that suffice to make it clearer?
Actually, yes, that would solve everything for me...and I knew
this was valid syntax. However, (A) the fact that Larry went to some
fairly serious lengths to eliminate the need for parens everywhere he
could says to me that we should find a system that doesn't require them
and (B) since it CAN be written in the 'eyeful' way (*) it WILL be written
in that way...and I and others are going to have to maintain code that
uses that and, as I said, I think it's going to lead to a lot of bugs.
Maybe I'm the only one who is bothered by this...if so, I'll cope and
deal.
--Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Austin Hastings wrote:
--- Dave Storrs [EMAIL PROTECTED] wrote:
for @a - $x; @b - $y { $x = $y[5] };
Yes!!!
(Except for the ''. That's feigen-ugly.
*shrug* You may not like the aesthetics, but my point still
stands: is rw is too long for something we're going to do fairly often.
Give me any one- or two- character marker you want that means rw (if
ro is the default) or r (if rw is the default).
I prefer default=ro, though,
because that let's the optimizer do more by default.)
I don't feel strongly enough about this to argue it. Personally,
I prioritize readablility over ease-of-optimization...I let Moore's law
take care of speed. Other people, who work in other problem domains than
I do, may need to have other priorities.
I proposed the multiple arrow thing a long while back, but it didn't
work out because of precedence with comma and because of
topicalizing/binding/etc.
But that was before semicolon which can have a different precedence
from arrow. And screw the binding -- it just looks right:
for @first - $a;
@pairs - $b is rw, $c;
{
print woo-hoo!\n;
}
You're right, that does look good...but you had to manually insert
whitespace in to make it look good. And (assuming that you used a TAB to
indent the '@pairs...' line), assuming that my TAB settings are the same
as yours.
The problem is, if we make those assumptions, I can even make the
current syntax look (reasonably) good:
for @a; @b
- $x is rw; $y
{
}
--Dks
Re: plaintive whine about 'for' syntax
On Thu, 31 Oct 2002, Damian Conway wrote:
Dave Storrs wrote:
Actually, yes, that would solve everything for me...and I knew
this was valid syntax.
So is this vertical layout, which I think will become fairly standard
amongst those who care about readability:
for a ; b
- $x is rw ; $y { $x = $y[5] };
To be honest, this just makes it less readable for me.
--Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Angel Faus wrote: Then let's make the parens required when there is more than one stream. Sane people will put them there anyway, and it will force the rest of us to behave. It also solves the ;-not-a-line-seperator problem. -angel Yes! Thank you, this is perfect. Minimal disruption of the syntax Larry designed, minimal exception to remember, and it completely resolves all my issues. See, I knew there had to be a simple, elegant solution I was missing. --Dks
Re: plaintive whine about 'for' syntax
On Wed, 30 Oct 2002, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:57:00PM -0800, Dave Storrs wrote: *shrug* You may not like the aesthetics, but my point still stands: is rw is too long for something we're going to do fairly often. I am not so sure. If I look back through a lot of my code, there are more cases where I use the variable in a read-only fashion than I do for modifying the value. Ok, fair enough. --Dks
Re: Perl6 Operator List, Damian's take
On Tue, 29 Oct 2002, Austin Hastings wrote: Hell, we might as well throw in multiple dispatch. Actually, I am really hoping we do. Any of you OO guys know of a case where $a = $a + $b; # A [+]= B; -- A = A [+] B; and $a += $b; # A [+=] B; should be different? Any time that evaluating $a produces a side effect--for example, if $a is a tied variable implementing a counter and increments itself by one every time its value is fetched. If it started with a value of 5, then $a += 3 leaves it with a value of 8, but $a = $a + 3 leaves it with a value of 9. Dave Storrs
Re: Wh[ie]ther Infix Superposition ops
On Tue, 29 Oct 2002, Dan Sugalski wrote: At 1:34 PM -0800 10/29/02, Brian Ingerson wrote: Every eigenbunny needs a supercozy! Absolutely. Eigenbunnies in supercozens. Sounds like we've found the mascot for Perl 6! I really want to work a pear pimples for hairy fishnuts reference in here somewhere, but I can't quite make it work. Dave Storrs
Re: Light ideas
Ah! Ok, yes, I had missed that. Thanks, this is exactly what I wanted. Dave On Mon, 5 Aug 2002, Stephen Rawls wrote: Doesn't the :w option do that? :w/one two/ translates to /one \s+ two/ Not exactly. The regex you showed would match any of these (using underscores for spaces for clarity): one_two, one__two, one__two Ah, ok. This is from Synopsis 5, this should be what you want: A leading ' indicates an interpolated literal match (including whitespace): / 'match this exactly (whitespace matters)' / cheers, Stephen Rawls
Re: Light ideas
On Sat, 3 Aug 2002, Damian Conway wrote:
don't know exactly what the syntax for adding /* */ will be
Something like this:
grammar Perl::With::Ugly::C::Comments is Perl {
rule ws { Perl::ws | ugly_c_comment }
rule ugly_c_comment {
/\* [ .*? ugly_c_comment? ]*? \*/
{ let $0 := }
}
}
caller{MY}.parser(Perl::With::Ugly::C::Comments);
I'm still having trouble getting my head around the new
grammar-construction rules. Three questions:
1) Am I right that anything inside a rule block is considered to be
inside a regex? If not, why didn't you have to write:
rule ugly_c_comment {
/
\/ \* [ .*? ugly_c_comment? ]*? \* \/
{ let $0 := }
/
}
2) As written, I believe that the ugly_c_comment rule would permit nested
comments (that is, /* /**/ */), but would break if the comments were
improperly nested (e.g., /* /* */). Is that correct?
3) The rule will replace the comment with a single, literal space. Why is
this replacement necessary...isn't it sufficient to simply define it as
whitespace, as was done above?
Dave Storrs
Re: Apoc 5 questions/comments
I assume that 'fatal.pm' is a new pragma. 1) What (if anything) does it do, aside from turning 'fail' into a fatal exception when used outside a regex? 2) Do you need to use it before you can (usefully) use 'fail' INSIDE a regex? (I would assume not, but thought I'd check.) Dave On Fri, 7 Jun 2002, Larry Wall wrote: On Fri, 7 Jun 2002, Dave Storrs wrote: Just to be sure I understood: you meant that (A) yes, you can use fail in a subroutine outside a regex, and (B) if you do, it is no different from die. Is that correct? Depends on the caller's use of use fatal. If they don't use fatal, it returns undef. Larry
Re: Apoc 5 questions/comments
On Mon, 10 Jun 2002, Larry Wall wrote: On Mon, 10 Jun 2002, Dave Storrs wrote: I assume that 'fatal.pm' is a new pragma. Already exists for Perl 5, actually. *blush* Must have missed it. Drat, and I just finished rereading Camel III. Apologies. Dave
Re: Apoc 5 questions/comments
On Fri, 7 Jun 2002, Luke Palmer wrote: Dave Storrs wrote: Can we please have a 'reverse x' modifier that means treat whitespace as literals? Yes, we are living in a Unicode world now and your data could /FATAL ERROR\:Process (\d+) received signal\: (\d+)/ I don't see how this example is nearly as flexible as this: m:w/FATAL ERROR\: Process (\d+) recieved signal\: (\d+)/ Yours will only match 4 spaces after FATAL ERROR:, whereas mine will match any number. [...] I see the :w modifier as a good flexibility enforcement. It will keep people away from matching things that very literally. Respectfully, Luke, I think you and I are discussing separate issues. You are talking about the best way to match multiple whitespace--and I agree with what you're saying, one should never assume that it will always be 4 spaces instead of 5. Were I writing that code in a real project, instead of as a demo for the list, I would use \s+ (in P5, anyway...in P6, whether I would use \s+ or \h+ would depend on circumstances). However, the point I was making was that, if I feel confident in only handling a limited subset of the possibilities because I know what I'm going to be getting (because, e.g., I wrote it out myself), then I would like a way to do away with the visual clutter involved in backwhacking or entity-izing every bit of whitespace. Perl has never been a nanny-language...one of its greatest strengths has always been that it trusts me to make my own decisions and, if I want to shoot myself in the foot, I can. : The suggestions that other people have been making about defining subrules and then building them up in order to make the entire match are good, and in general that's a very powerful technique. However, the lines devoted to those subrules still count as visual clutter, and I'd still like a way to do away with them. Dave
Apoc 5 questions/comments
Well, A5 definitely has my head spinning. The new features seem amazingly
powerful...it almost feels like we're going to have two equally powerful,
equally complex languages living side-by-side: one of them is called
Perl and the other one is called Regexes. Although they may talk to
one another, I really did come away feeling like they were completely
separate animals.
I admit I'm a bit nervous about that...so far, I'm completely sold on
(basically) all the new features and changes in Perl 6, and I'm eagerly
anticipating working with them. But this level of change...I don't know.
I've spent a lot of time getting to be (reasonaly) good at Perl regular
expressions, and I don't like the thought of throwing out all or most of
that effort. Somehow, this feels like we're trying to roll all of Prolog
into Perl, and I'm not sure I personally want to go there (note the
personally...YMMV).
For now, I'm just going to defer worrying about it until I see Exegesis 5,
since past experience has shown me that there is a good chance that all my
fears will be shown to be groundless once concrete examples are being
demonstrated.
In any case, I do have some specific questions:
-
Page 8:
s:3x:3rd /foo/bar/
That changes the 3rd, 6th, and 9th occurrences.
Just to verify, this:
s:3rd /foo3/bar/
would do the 3rd, 4th, and 5th, correct?
-
Page 8:
The u1-u3 mods all say level 1 support. I assume this was a typo, and
they should go (u1 = 'level 1', u2 = 'level 2', u3 = 'level 3').
-
Can modifiers abut the delimiter?
s:3x /foo/bar# most (all?) examples looked like this
s:3x/foo/bar # is this legal?
-
Can we please have a 'reverse x' modifier that means treat whitespace as
literals? Yes, we are living in a Unicode world now and your data could
theoretically be coming in from a different character set than expected.
But there are times when it won't...when (for example), you wrote the data
out yourself, or you're operating on files that are generated and
maintained purely in-house, so they are guaranteed to be in the same
character set as the Perl source code you're writing. I understand the
arguments for the way the defaults are set. I even agree with them. But
you will NEVER convince me that the first example below is not easier to
read than any of the alternatives:
/FATAL ERROR\:Process (\d+) received signal\: (\d+)/
/FATAL ERROR\:\ \ \ \ Process\ (\d+)\ received\ signal\:\ (\d+)/
/FATAL ERROR\: \h+ Process \h+ (\d+) \h+ received \h+ signal: \h+ (\d+)/
/FATAL ERROR\: \s+ Process \s+ (\d+) \s+ received \s+ signal: \s+ (\d+)/
(Yes, I know that the last one matches vertical whitespace and
therefore means something slightly different than the others.)
If this means that we need to store a byte or two to remember what
character set the originally-read-in code was in before being converted to
UTF-8 (or whatever we're using internally), so that we know what character
set to assume literal ws refers to...well, that seems like a small
price to pay for a lot of convenience.
-
Page 9:
my $foo = ?/.../; # boolean context, return whether matched,
my $foo = +/.../; # numeric context, return count of matches
my $foo = _/.../; # string context, return captured/matched string
This 'initial character to force evaluation' rule initially seemed
annoying, but the more I think about it, the more I like it; one
character isn't much to type, and it makes it extremely clear why you're
doing the match (i.e., what you're trying to get back). Kudos to our
Fearless Language Designer!
-
I am a little unclear on what the difference is between these two:
my foo = $rx;
my foo = m/$rx/;
If I understand correctly, it works like this:
my stuff;
$_ = foofoofoo;
$rx = /:each foo/;
for (0..2) { stuff = $rx }
# above line is equialent to following 3 lines:
stuff = ('foo', 'foo', 'foo');
stuff = ();
stuff = ();
for (0..2) { stuff = m/$rx/ }
# above line is equialent to following 3 lines:
stuff = ('foo', 'foo', 'foo');
stuff = ('foo', 'foo', 'foo');
stuff = ('foo', 'foo', 'foo');
Is that correct?
-
Page 10:
You could also use the {'...'} construct for comments, but then
you risk warnings about useless use of a string in void context.
Could we automagically turn off that warning inside such constructs, when
the only thing there was a string? (Perhaps there could be a switch
that prevented it from being turned off, if people really wanted to
see it; if so, make it be OFF by default, so it needs to be enabled,
much like 'use strict.')
-
Page 11:
/ pattern ::: { code() or fail } / # fails entire rule
Farther down:
A pattern nested within a closure is classified as its own rule,
however, so it never gets the chance to pass out of a {...}
closure.
If I understand
Re: 6PAN (was: Half measures all round)
On Tue, 4 Jun 2002, Luke Palmer wrote: On Tue, 4 Jun 2002, Miko O'Sullivan wrote: No configuration files (.e.g .cpan) are necessary. However, you can use a configuration file if you want tp indicate a .cpan-like file cpan --conf ~/.cpan load Date::EzDate What about no configuration file if ~/.6pan's not there, and ~/.6pan if it is. Personally, I'd like it to: 1) work just fine without a config file, 2) if I specify one, it uses that, 3) if I don't specify one, but the default exists, it uses that 4) if it uses a config file (specified or default) it shows the full path to what it's using, so that I have a chance of detecting Trojans and typos if I'm paying attention (I don't need or want it to ask for confirmation, just show a message and maybe 'sleep 1' before continuing) - Authors don't need to indicate dependencies. CPAN figures it out from the use's and require's. CPAN will not accept modules that depend on other modules that aren't on CPAN. (Yes, there might be a chicken and egg problem there, I'm sure we can find a solution.) This leads me to... Having it figure out the dependencies is definitely a major plus. As to how to solve the chicken-and-egg...just provide a way to upload multiple separate modules simultaneously. Dave
named params, @_, and pass-by-reference
On Thu, 11 Apr 2002, Damian Conway wrote:
Piers wrote:
one could always handle the first case
more explicitly by doing:
sub load_data ($filename; $version) {
$version = 1 if _.length 2;
...
}
Err...no. If you specify named parameters, you don't get _.
I'm a couple months behind on the discussion and haven't read
Apoc4 carefully yet, so my apologies if this has already been hashed out.
Something I've always wished for in Perl (which of course I didn't
think of during the RFC period) was a way to have self-documenting
parameter names inside a function, but still maintain pass-by-reference
semantics, and do it all without fancy, hard-to-read aliasing tricks.
Ideally, I want something like:
sub load_data ( \$filename; $version; _ ) {
$filename =~ s{/$}{}; # Affects $filename back in caller
my $protocol = shift || 'html'; # shift defaults to _
...
}
Note that here, $filename is pass-by-reference, $version is
pass-by-value, and, if extra arguments are passed, they will come in
through _ so that I can still take advantage of the fact that most list
operators default to _. (Whether the contents of _ are p-b-v or p-b-r
I'm not weighing in on.)
Perhaps using \ in the signature to indicate p-b-r is not the
best...it could confuse people into thinking that they will need to
manually dereference the variable, which they shouldn't need to do.
Is there a way to do this now? If not, will there be a way in
Perl6?
Dave Storrs
Re: named params, @_, and pass-by-reference
[Several people said something like $var is rw will do it) Ah, that's right. I had forgotten about this. Thanks to everyone who responded. Dave
Re: Apoc 4: The skip keyword
On Wed, 30 Jan 2002, Ted Ashton wrote: Thus it was written in the epistle of Dave Hartnoll, Oh, one other tweak. The RFC proposes to overload next to mean fall through to the next case. I don't think [...] I would like to suggest a different keyword that does not imply some `jumping' action. For years, I have used `nobreak' in my C code when I want to indicate that a case fall-through is intentional: [...] skip was uncomfortable when I read it (I at first took it to mean skip over the following rather than skip to the following), but I find nobreak also a bit strange. How about proceed? Ted First, a 'me too' to everything Ted said. Second, to me 'nobreak' is not sufficiently visually distinct from 'break'. Dave Storrs
Re: What can be hyperoperated?
Note: I'm actually not talking about hyperoperators below, or
map/grep/sort. Just 'for'.
On Sat, 26 Jan 2002 12:32:06 -0600, Jonathan Scott Duff wrote:
@result = for @a; @b - $a; $b { $a op $b }
I'd like to chime in withthe people who have already said that the
semicolons are a bit confusing.
I'd like to propose a slightly different syntax. Is this maybe valid, or
have I missed a gaping problem?
# Simplest case: one data source, pulling elements one at a time,
# operating against a constant
@result = for @a - ($a) { $a + 2 }
More formally, this would be:
for LIST - LIST [[, LIST - LIST]...] CLOSURE (returns: LIST)
So, you could write things like so:
# pull elements off two-by-two
for @a - $x, $y { ... }
# flatten @a, @b together, pull elements off two-by-two
for @a, @b - $x, $y { ... }
# pull one off @a, one off @b
for @a - $x,
@b - $y
{ ... }
# pull one off @a, two off @b
for @a - $x,
@b - $y, $z
{ ... }
Of course, all of these only DWIM if - knows that it takes exactly one
item on the left, and a list on the right.
As an extra bit of magic, perhaps, when the only thing to the left of -
is a scalar, it could reduce to this (in Perl5 terms):
# This Perl6:
for $_ - $x { ... }
# is the same as this Perl5:
{
my $x = $_;
local ($_);
{ ... }
}
Dave Storrs
Re: Source/Program metadata from within a program
On Fri, 31 Aug 2001, Bryan C. Warnock wrote: Access to the source code. Particularly comments and POD. I'd also like to be able to access information on the particular perl that is running this program...e.g., does it support 64-bit nums, what is the endianness of the native numbers, does it support threads and (if so) what threading model (though this is probably a moot point in P6, perhaps it is something that could be included into 5.8.x). Dave Storrs
Re: Semi-OT: Good compiler book?
The Dragon Book is (AFAIK) still considered the definitive book on the subject. It's called that because it has (or at least, had, for the edition that I bought) a red dragon on the cover. The official title is: Compilers : Principles, Techniques, and Tools by Alfred V. Aho, Ravi Sethi, Jeffrey D. Ullman (Contributor) ISBN: 0201100886 You can get it from Fatbrain: http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201100886vm= Dave On Tue, 7 Aug 2001, 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). (If this is too off-topic, let me know.) Thanks, --Brent Dax [EMAIL PROTECTED]
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001, Dan Brian wrote: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? I think that with a clean API, many third-party profilers could and would be created. I am skeptical of the value of putting it in the core, when a well-designed API would exist specifically with the end of getting some of that work out of the porter's pockets, and instead allow the World to develop their own, much as it currently happens with Java. A good point. There should definitely be a clean API so that other people can develop their own profilers which could then be plugged in. This still leaves the question though...should core provide a default profiler? Dave
Re: as long as we are discussing 'nice to have's...
On Sat, 21 Jul 2001 [EMAIL PROTECTED] wrote: On Sat, Jul 21, 2001 at 02:47:43PM -0700, Dave Storrs wrote: It would be nice if there was a use strict 'recursive'; option that you could set in a script or module (package, whatever) which would force all the modules it used to operate under strict. HUGE MASSIVE PROBLEM HERE! This might be useful if *all* the modules you use and *all* the modules which are then used are *all* under your control and that none of them are have elected to *not* use strict for some reason (like Exporter, which would be silly to use strict 'refs'). Otherwise, you're just causing unnecessary bugs. Please note that I addressed this in my original post. This was the specific reason that I suggested the exclude option. Second topic: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? You mean like Devel::DProf, the profiler that's already in the core? ;) And is this new debugger API like the current debugger API, DB.pm? (Actually, I hope it isn't. Just making sure you're aware of what's already there.) No, I do not mean something like Devel::DProf; that is a module. I mean something that is in the core binary, the same way that the perl debugger is in the core binary. Perhaps I should have made a distinction between 'core' meaning inside the perl binary and 'core' meaning distributed in the default bundle which includes the perl binary and a whole slew of Perl- and/or XS-based modules. I agree that it should be possible to use any debugger and/or profiler you choose. I am simply asking if we should provide a default profiler, in the core binary, which will be invoked when no other profiler is specified. Dave
Re: as long as we are discussing 'nice to have's...
On Sun, 22 Jul 2001, Johan Vromans wrote: Dave Storrs [EMAIL PROTECTED] writes: 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 a use strict 'recursive'; Good reasoning, although this occurs to me as trying to kill a fly with a nuclear bomb. Ah, but note that, while using a nuke as a flyswatter may be massive overkill, it is also very _effective_. : The essence of modules is that they are independent, and are unaffected by outside pragmata. This is what makes them reusable. A 'recursive' pragma would break that. True, a recursive pragma would break a module's ability to manage its own internals as it pleases. However, if I _want_ them to be affected, there is no reason they shouldn't be...it's like any other powerful technique; if I misapply it, I am responsible for the consequences. Dave
as long as we are discussing 'nice to have's...
First topic: 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 a use strict 'recursive'; option that you could set in a script or module (package, whatever) which would force all the modules it used to operate under strict. Perhaps we could even extend it to (something like): use strict 'recursive:except' qw(DBI, CGI, MyFoo); I don't care about the syntax, as long as it's clear what's intended (which I hope this is). ( PS As often happens with Perl, it may well be that this already exists and I've just never run across it. If so, I will happily RTFM if someone will just point me to the appropriate part of the FM. ) Second topic: The debugger API PDD that I submitted a couple of days ago suggested that we incorporate a profiler into the core. What do people think of this idea? Dave
Re: Feeding potatoes to dead horses
On Tue, 10 Jul 2001, Michael G Schwern wrote: We could assume untyped variables are untyped, but I'd rather they're considered mistakes. Again, the purpose here is to catch mistakes. I don't know if this will wind up being more or less annoying, we'll have to play with it a little. Fortunately, its a decision that can easily be reversed. You can always just do this: my Value $foo; And $foo will act like a normal scalar taking anything (your PMAW). If that's the goal, I'd vote that it be spelled: my Scalar $foo; --Dave
re: time travel paradoxes (was Re: Multi-dimensional arrays andrelational db data)
On Mon, 11 Jun 2001, Daniel S. Wilkerson wrote: For example, the going back in time and preventing your grandparents from having sex situation. Bah, who needs sex these days? A little in vitro here, a little cloning with genetic tweaking there...a whole new person, no sex involved! ... [freeze some eggs, then] Whenever you wish You thaw them out to romance wigglies In a Petrie Dish Then plant the little goober in a girl of seventeen Who's into natural living And prevention magazine No fuss, no muss, no stretch marks (Well not on *you*) Maternal instinct satisfied The modern thing to do. ... --Christine Lavin, Biological Time Bomb
Re: suggested properties of operator results
On Fri, 8 Jun 2001, Chris Hostetter wrote:
After reading the Apocalypse Exegesis articles, and seeing some examples
of properties and the is operator, I'd like to suggest that the
less-then operator be changed, so it is functionally equivalent to:
$v2 = VALUE2;
$v1 = (defined VALUE1.valueR ? VALUE1.valueR : VALUE1);
return ($v2-$v1 == abs($v2-$v1)) is valueR($v2);
which (assuming the operator's association was changed to left) would
cause the following code to mean what beginning programmers always think it
should mean:
if ($foo $bar $baz) { ... }
It should be obvious how = = lt gt le ge can similarly
be modified. Then even this would make sense...
if ($foo = $bar $yak lt $wak) { ... }
For certain definitions of sense. :
Seriously, I have several thoughts on this:
1) The do this because it will be more intuitive for beginners
argument comes up a lot, and is pretty appealing at first. However, as
someone (was it tchrist?) pointed out, beginners don't stay beginners for
long, so writing a language for beginners may cost you people when they
grow out of your language. I don't this we should do this just because
it would be better for beginners; if we're going to do it, let's do it
because it is a good feature.
2) This feature would be very prone to abuse (makes it easier to
obfuscate code), but that isn't a reason to disqualify something either.
3) Used for what it is intended for, it seems like a very concise,
expressive way to do multiple relationship tests without needing all those
s and such. If we assume that these expressions read from left to
right by overlapped pairs, so that these are equivalent:
($foo $bar $baz $jaz)
(($foo $bar) ($bar $baz) ($baz $jaz))
...then I don't think we're giving up any comprehensibility, and
we are gaining conciseness. I vote 'yes' (fwiw).
Dave
Re: Properties and stricture
On Tue, 5 Jun 2001, Michael G Schwern wrote: On Tue, Jun 05, 2001 at 01:34:35PM -0700, Daniel S. Wilkerson wrote: I cannot imagine running an enterprise critical application As a complete digression, can we please strike the term enterprise from the English lexicon? Completely redundant and drives me up the wall. Almost as bad as ecommerce. But if we did, how could we hope to get a good new Star Trek series? : Dave
Re: Properties and stricture
On Tue, 5 Jun 2001 [EMAIL PROTECTED] wrote: So I'd say no, Perl can't know at compile-time if your method is declared or not. Only in certain restricted cases, such as if you don't inherit from anything, or if *all* your parent classes are declared strictly. (By 'strictly', I think you mean 'all methods (etc) are declared explicitly in code, not generated by AUTOLOAD, etc'. If I'm not understanding you correctly, please correct me.) Couldn't we still have a 'be-super-strict' flag that would throw warnings upon encountering a construct that would interfere with compile-time checking? Make it be off by default, of course, but if people want Perl to help them check this kind of thing, it should be possible. Dave
Re: properties
On Mon, 21 May 2001, Jonathan Scott Duff wrote: So, if I have a Dog $spot, here's a little table where a 1 in the M column means $spot has a bark method that says 'woof', 1 in the V column means $spot has a bark variable (compile-time) property that says 'arf' and a 1 in the A column means $spot has a bark value (run-time) property that says 'yip'. MVA $spot.bark (+$spot).bark 000 Error Error 001 yip yip 010 arf Error 011 arf yip 100 woofwoof 101 woofwoof 110 woofwoof 111 woofwoof First of all, thanks for putting this table together; this is good way to clear all the up. Second: I'm afraid that even after all this discussion and puzzling over this table for a bit, I'm still a bit baffled by this stuff. Perhaps I'm just slow, but let's assume for the sake of argument that I'm not the only one still scratching his head. Could we revist the idea of alternate syntax to disambiguate between value and variable cases? Perhaps now that we've freed up the '-' we could use that to access properties on the variable, while '.' continues to be for the value (since that is more consistent with other usages of '.', such as $foo.callSomeMethod() ). Then the table above would look like this (note that this does away with the (+spot).bark syntax that some people feel is ugly): MVA $spot-bark $spot.bark 000 Error Error 001 yip yip 010 arf Error 011 arf yip 100 woofwoof 101 woofwoof 110 woofwoof 111 woofwoof Third, a question about the table above. (+spot).bark evaluates to the value properties, yes? So, shouldn't the 'arf' and 'Error' be switched for 010? Dave
Re: Separate as keyword? (Re: 'is' and action at a distance)
On Fri, 18 May 2001, Nathan Wiger wrote: Maybe there are two different features being conflated here. First, we have is, which is really for assigning permanent properties: my $PI is constant = '3.1415927'; So, those make sense, and we'd want them to remain through assignment. However, the true, error, false, etc, really are *temporary* conditions. Maybe we need a separate keyword - as - for this: return $zero as true; For stuff declared with this as keyword, it would last until next assignment or other value change. That is, these are value dependent and designed to pass extra information along. By definition, though, when the value changes we'll want these properties to change as well. I think you may be onto something here, but I get nervous about as and is being the chosen keywords...they are only one letter apart and the cognitive difference between them is very small(*); I think it would be very easy to mix them up. Dave * For an example of words that are only one letter apart but have a very large cognitive difference, try now and not.
Re: Damian Conway's Exegesis 2
On Tue, 15 May 2001, Simon Cozens wrote: On Tue, May 15, 2001 at 03:30:07PM -0700, Dave Storrs wrote: - A while ago, someone suggested that the word 'has' be an alias for 'is', so that when you roll your own properties, you could write more-grammatically-correct statements such as my $var has Colors(3). Since 'are' is being considered as a synonym, is there a possibility that 'has' will make it too? It would be disappointing if a substantial proportion of the built-in keywords were merely syntactic sugar for each other. is|are|has|: seem like far too many ways to express exactly the same concept. I understand your point, but I respectfully disagree with it. Consider that there are about 10 ways to do a loop (map, grep, for, foreach, while, and at least 4 others that I'm not remembering at the moment; before you say it, I grant you there are minor differences between the constructions, so they are not exactly the same concept, but they are very close). Perl has always put an emphasis on reading like grammatical English--see all the Perl poetry, or look at the 'unless' keyword, or the fact that conditionals can be prefix or postfix. Finally, is ':' actually sugar for is? I guess I missed that; I'll go back and read it again. Dave
Re: Exegesis2 and the is keyword
Ok, this is basically a bunch of me too!s.
On Tue, 15 May 2001, Nathan Wiger wrote:
Awesome. Simple, Perlish, easy to read, etc. Also, I see you took the
suggestion of:
Access through... Perl 5 Perl 6
= == ==
Array slice @foo[@ns] @foo[@ns]
Hash slice @foo{@ks} %foo{@ks}
Which is kewl since it makes a good amount of sense IMO.
Here's the first one.
$*ARGS is chomped;
I wonder if that wouldn't be better phrased as:
autochomp $*ARGS;# $ARGS.autochomp
[...] I don't think actions should be declared using is,
necessarily. [...] In particular, it puts the action in the passive
voice[...]
It seems actions should be active functions, so:
autoflush $STDERR; # $STDERR.autoflush
$var = read $ARGS;
print $STDOUT Hello, World!\n;
Here's the second one.
:
:$ARGS prompts(Search? ); # Perl 6
:while ($ARGS) {
I'd think I'd rather see that as:
prompt $ARGS Search? ; # $ARGS.prompt(Search? )
Without the extra new ambiguity. Thoughts?
Hmmm...the '$ARGS prompts(Foo?)' version actually works better
for me. I think that, in line with what you said above, 'prompt $ARGS
Foo?' should be interpreted as an action...that is, something that
should be done _right_now_. But I don't want the prompt to be printed
right now...I want it to be printed just before I do a read on the
filehandle. In this case, I really am setting a property, not setting a
property.
I'm not sure what the appropriate way to disambiguate the two is,
or if there even needs to be a specific mechanism (can perl be smart
enough to DWIM on this?). Definitely something to think about.
Dave
apology (was Re: Exegesis2 and the is keyword)
I recently received the following email from someone whose name I have snipped. * Dave Storrs [EMAIL PROTECTED] [05/16/2001 08:11]: Ok, this is basically a bunch of me too!s. Keep the snide comments to yourself. Thanks. This was regarding a reply I had made to one of Nathan Wiger's posts in the Re: Exegesis2 and the is keyword thread. This is a case of miscommunication; the bunch of me toos was referring to what _I_ was writing...that is, I was saying that the majority of my email consisted of agreeing with what Nathan had written, which I thought was very well constructed and well thought out. Obviously, I was not clear enough, for which I apologize. Dave
Re: Damian Conway's Exegesis 2
First of all: Damian, thank you for putting this together. This is a really good way to dispell the concerns/doubts/pick-a-word that people (including myself) have been having about whether Perl6 would be the language that we all know and love. There was a great deal of stuff in there and I for one am going to need some time to digest it. My initial reactions are as follows: at first I was alarmed and a bit appalled at a lot of the changes...e.g., the 'HASH $tree is rw' parameter declaration. Jesus, I thought if I wanted a typed languaged, I'd use C++. The more I read, however, the more I became convinced that these were actually elegant Perlisms...you can have exactly as much freedom as you want, if you carry the responsibility for it. Alternatively, you can have Perl do more of the work for you, if you are willing to live with constraints. Elegant. Perlish. Good. The only questions I have at this point are: - Is there a way to declare a property constant/final/choose your keyword? - Is there a way to do a read-only access on a property? - A while ago, someone suggested that the word 'has' be an alias for 'is', so that when you roll your own properties, you could write more-grammatically-correct statements such as my $var has Colors(3). Since 'are' is being considered as a synonym, is there a possibility that 'has' will make it too? - Might it be possible to make properties prefix-able when being used with types, so that it would be possible to say 'my constant int $foo = 0;' ?? It's a minor point, but it would make it easier for people from C-based languages to transfer (whether that's enough of a reason is a separate question.) I understand it would be difficult, since properties work off the 'is' keyword, which returns its left arg; still, I don't see why this is harder (from a programming view) than making 'if' and 'unless' capable of prefix or postfix usage. Dave
Re: Apoc2 - STDIN concerns
On Thu, 10 May 2001, Larry Wall wrote:
Dave Storrs writes:
: should stick with . Also, I'd prefer to use the 'x' operator for
: specifying multiples:
:
: @foo = $STDIN x 4;
: @foo = $STDIN x mySub;
:
: The parallel with $foo = 'bar'x2;, where bar is simply repeated twice,
: is obvious: '$STDIN' iterates the, uh, iterator, and repeating that
: operation iterates it multiple times. It even reads nicely Fetch a line
: from STDIN times four (or, more idiomatically, ...four times).
Um, I don't think so. What I wrote above was just a fancy trick with
straight Perl 5 overloading. You could do that today.
I'd think that what you wrote would have to input one line from $STDIN
and then dup that line 4 times. Either that, or because it's in list
context it inputs all the lines and duplicates each 4 times, just like
@foo = @bar * 2;
maybe ought to multiply each element by two, at least the way some
numericists look at it.
Hmmm...I see your point, but I think it depends on what you see as
the operatee that 'x' is operating on. If it's the string(s) produced by
, then you're certainly right. But if it is the act of iterating
itself, then I think my suggestion is still valid. And yes, I realize
that the current behavior is always to act on the string, not the act of
calling the function that produced the string, or whatever. I just think
that we could extend 'x' to have a general repetition meaning. Imagine
the following:
our $a = 0;
our $baz = 'jaz';
sub blah {
$a++;
return 'Hi';
}
$foo = 'bar' x 2; # $foo = 'barbar'
$foo = $baz x 2;# $foo = 'jazjaz'
$foo = blah() x 2; # blah() called twice,
# $foo = 'Hi', $a = 2
$foo = join '', (blah() x 2)# blah() called twice,
# $foo = 'HiHi', $a = 4
$foo = $STDIN x 2;# read two lines, discard first,
# stick second into $foo
@foo = $STDIN x 2;# read two lines, stick into @foo
Dave
Re: Apoc2 - STDIN concerns
On Fri, 11 May 2001, Larry Wall wrote: Dave Storrs writes: : calling the function that produced the string, or whatever. I just think : that we could extend 'x' to have a general repetition meaning. I think just patching one operator from verbal status to adverbial status is not sufficiently general. [...] $STDIN MUMBLE 2 # read twice 1 .. 100 MUMBLE 3 # count by threes `glob $x` MUMBLE /bin/csh # modify pseudoquote It has not yet been decided what form these MUMBLEs will take, [...but maybe the default] adverbial MUMBLE is simply :. Which might cause the above to reduce to: $STDIN : 2 # read twice 1 .. 100 : 3 # count by threes `glob $x` : /bin/csh# modify pseudoquote Wow. This is great; very powerful and very elegant...how Perlish. $verb = I cc 'tow'x2 cc ' admiringly'; $verb =~ s/t/k/; # ; Dave
Re: Perl5 Compatibility, take 2 (Re: Perl, the new generation)
All that follows is merely MHO, so feel free to disregard.
On Fri, 11 May 2001, Nathan Wiger wrote:
Well, I think we should take a step back and answer a few key questions:
1. Do we want to be able to use Perl 5 modules in a
Perl 6 program (without conversion)?
I would say it's absolutely mandatory that we be able to use perl
5 modules--half the power of Perl is CPAN.
2. Do we want to be able to switch between Perl 5 and
Perl 6 in a single file (by using module to dictate
P6 and package P5)?
This seems like something that could be left out without
outraging too many people.
3. Do we want to assume Perl 5 or Perl 6 code? If we
assume P5, then we have to look for module somewhere.
If we assume P6, we can look for a number of differences,
such as $foo[1], $foo{bar}, etc to identify P5 code.
It will probably be easier if we assume P6 code, but P5 policies
(warnings, strictness, etc).
4. Do we want to be able claim 100% compatibility, or
99% except typeglobs, in which case if *foo is
seen we just drop with Typeglobs not supported?
I don't see that we *can* claim 100% compatibility...there's
simply no way, in the real universe, that every P5 script ever written
will run flawlessly through the P6 interpreter (unless we simply swap to
the P5 interpreter upon recognizing P5 code, but even that might not work
in a mixed environment).
On a related topic, here's a crazy off-the-cuff thought...haven't
spent many cycles on it, not sure if it's worth anything, but I'll throw
it out to be shot at:
Can we break the p526 functionality out into a normal P6 module
and, for the first few versions of P6, have the interpreter automatically
load this modules and pass all other code through it before actually
starting to interpret it? This would keep core size down, make the
translator easily available as a separate system/API, and make it easy to
turn off the translation after enough time has passed that P6 is the
assumed standard.
Dave
Re: Apoc2 - STDIN concerns
On Tue, 8 May 2001, Larry Wall wrote: In this view, * and could just be two different kinds of expandable flags. But I'm uncomfortable with that, because I'd like to be able to say lazy_sub($STDIN, $STDIN, $STDIN, $STDIN) to feed four lines to lazy_sub without defeating the prototype, er, signature checking. Maybe you have to us *$STDIN to do both. But that would probably say to slurp the whole rest of the file. You know, it would be really cool if you specify the number of lines you wanted like so: $STDIN # One line *$STDIN# All available lines *4$STDIN # Next 4 lines Or even: *$num_lines$STDIN # Numifies $num_lines, gets that many *int rand(6)$STDIN # Gets 0-5 lines *mySub($bar)$STDIN# mySub returns num, gets that many Dave
Re: apo 2
On Tue, 8 May 2001, Me wrote: yes? And, despite perl5's use of no as the opposite of use, and given that there may be no use in perl6 (;), and thus perhaps no no, (on and off?), then maybe no could be used as not yes? no? Your Honor, I would like to stipulate that that sentence be taken out and shot. ; Dave
Safe signals, multiple signals?
There have been multiple mentions of the fact that we intend to have safe signals in Perl 6. I was wondering if it will also be possible to have more than one alarm() set at a time, or some other mechanism for having multiple pending signals. Dave
Re: Apoc2 - STDIN concerns
QUOTE LARRY Dave Storrs writes: : You know, it would be really cool if you specify the number of : lines you wanted like so: : : $STDIN # One line : *$STDIN# All available lines : *4$STDIN # Next 4 lines : : Or even: : : *$num_lines$STDIN # Numifies $num_lines, gets that many : *int rand(6)$STDIN # Gets 0-5 lines : *mySub($bar)$STDIN# mySub returns num, gets that many Given appropriate overloading on the iterator object: @foo = $STDIN * 4; Larry END QUOTE Actually, on more reflection, I'm going to side with the people who say that the single-character version is not an improvement, and that we should stick with . Also, I'd prefer to use the 'x' operator for specifying multiples: @foo = $STDIN x 4; @foo = $STDIN x mySub; The parallel with $foo = 'bar'x2;, where bar is simply repeated twice, is obvious: '$STDIN' iterates the, uh, iterator, and repeating that operation iterates it multiple times. It even reads nicely Fetch a line from STDIN times four (or, more idiomatically, ...four times). Dave
Re: Safe signals, multiple signals?
On Thu, 10 May 2001, Uri Guttman wrote: DS == Dave Storrs [EMAIL PROTECTED] writes: DS There have been multiple mentions of the fact that we intend to have safe DS signals in Perl 6. I was wondering if it will also be possible to have DS more than one alarm() set at a time, or some other mechanism for having DS multiple pending signals. if we have a proper core event loop as dan and i want, multiple timers will be part of that. and that will mean we can have timed out operations without the mess of eval/die (or whatever 6 will have for that). Cool. similarly, proper safe signals will store all pending signals and deliver each one. Cooler. a core event loop will support all of those features. delivery methods can be chosen by the coder, either polling in the op code loop or running a proper event loop with no polling (which will be faster). Completely frozen. (That's a compliment, in this context. :) Dave
Re: .NET
On 3 May 2001, Ilya Martynov wrote: You can serialize/deserilize object with Storable $foo = new Bar store_fd $foo, \*SOCKET; and on the other end $foo = retrieve_fd \*SOCKET; $foo-bar; It will work if you have Bar module on both ends. DS Right, but I want it to work if you don't... Then maybe SOAP::Lite? SOAP allows to serialize/deserialize objects and make remote call. SOAP::Lite makes it quite transparent. Errm...wasn't (something like) this discussed just recently and deemed a massive security hole? If I download a program, I don't want to have to inspect every line of source to make that it won't download some bizarre Trojaned module (or even an object instantiated from that module, which is worse because it leaves fewer traces by not writing to disk) from some far corner of Script Kiddie Land. Dave
recap on new operators?
For those of us who came in late...I gather that - is expected to be
replaced by '.', which means that we need to find something else for '.'.
Somehow, however, I missed out what the exact benefits are of this
replacement--I'm not saying that there *aren't* any, I just never saw the
message where they were spelled out. Could someone please give a recap?
Also, rather than trying to jam extra functionality into '+' or '=~' or
whatever, would it be possible to simply use - as the concat operator
(i.e., switch '-' and '.')?
Perl 5Perl 6
----
$mail_obj-{header} .= Hi, John!$mail_obj.{header} -= Hi, John!
The pros and cons that I see are:
Pro:
- requires the minimum amount of disturbance to the syntax
Con:
- You need to know whether you are looking at Perl5 or Perl6 before you
know how to read the operator (raises problems both for programmers and
for p526 translator script)
- Some of the permutations (e.g. -= ) look terrible.
Dave
Re: Larry's Apocalypse 1
On Mon, 9 Apr 2001, Peter Scott wrote: At 09:36 AM 4/9/01 +0200, Ariel Scolnicov wrote: One liners are supposed to be SHORT. `--cmd' is LONG. If we MUST go the multiflagged way, why not reflect `-e' to get the `-6' flag? At the very least, I want a short flag! But by the time people learned to use '-6' we'd have Perl 7 out. We could then just add a -7 flag. That's not necessarily bad; Perl 7 will probably face the same issue...it needs to be able to eat Perl [567] code without barfing, but it needs to know what it's getting. Also, the flag would be a good choice in that it's very human-readable. Dave
Re: Larry's Apocalypse 1
On Thu, 5 Apr 2001, Nathan Wiger wrote:
I'm unsure about the "module main" idea. I like that modules as a whole
are strict/-w by default. But the "module main" tag causes the same
problem Larry is opposed to with BASIC/PLUS "EXTEND". That is, every
Perl 6 program begins with "module main". Maybe there's a better way to
implement this? ("use 6.0" has much the same problem)
Not every p6 program...only the ones where you want the new
strict/warnings/whatever policies. And you can always put -ws on your
shebang line if you don't want to type "module main."
Dave
Re: Perl 5 compatibility (Re: Larry's Apocalypse 1)
On Thu, 5 Apr 2001, John Porter wrote: Nathan Wiger wrote: the more compatible with Perl5 Perl6 is, the more likely it is to be accepted. I don't believe that's necessarily true. If Perl6 proves to be a significantly better Perl than Perl5, people will adopt it, especially if they're inclined toward the Perl philosophy anyway. (And at first, those are the only people we have to convince.) To this end, sacrificing the Virgin of Perlish Power to the God of Backward Compatibility would be unwise in the extreme. You are correct, but being backwards compatible is unlikely to _cost_ us adherents and might well gain us some. *shrug* Dave
RE: Really auto autoloaded modules
On Sun, 4 Feb 2001 [EMAIL PROTECTED] wrote: "Dave" == Dave Storrs [EMAIL PROTECTED] writes: Dave When you want to install a new version, you simply prepend it Dave with its version number (or insert it at appropriate place). Dave The order is, of course, irrelevant...you can order it as 1.3, Dave 2.0, 1.0 if you want, but then 1.3 would be loaded by default Dave and you would need to explicitly request other versions. Dave I'm sure this idea can be improved on, but it's a first cut. Dave What do people think? You want this to work with multiple module versions side by side. We have a disk namespace where we put every module version in its own directory, and the user can choose which version is required by specifying 'use lib'. When a new version comes out, we install it without touching the existing files - which makes backing out an upgrade very easy. If multiple versions of a module could co-exist in the same program, e.g. by extending the namespace by the module version number, that would solve some issues in e.g. mod_perl, or in Storable release x - x+1 migration scripts. Hildo I see what you mean...I had only been thinking of how to handle it when you had base classes inherited from different versions of the same thing. I'd still like to suggest that we add the ability to consolidate versions into one file; I'm sure that some (many) people prefer to have their versions in separate files, but I (and, I imagine, at least some others) would find it easier if all versions were in one file, thereby making it easy to (e.g.) move all of Foo:: from one machine to another without accidentally leaving bits behind. Suppose you could do the following: use Bar::Quux::1.3; # Parses the file looking for __VERSION 1.3__, #ignores everything except that version use Bar::Quux::2.0; # Ditto for __VERSION 2.0__ Bar::Quux::1.3::do_stuff(); # Calls version 1.3 do_stuff() Bar::Quux::2.0::do_stuff(); # Calls version 2.0 do_stuff() Bar::Quux::do_stuff();# Calls version 2.0 do_stuff(), as that is #highest version currently loaded I believe that all of this could be done with a straightforward aliasing of namespaces at load time. Is this better? Dave
RE: Really auto autoloaded modules
On Fri, 2 Feb 2001, Garrett Goebel wrote: $Foo::VERSION eq 1.00 | | $Foo::VERSION eq 2.00 | | Bar Baz \ / My::Module Ideally, it should be perfectly legit to have multiple versions of a given module on your system, which would resolve this problem nicely. One possible implementation for that would be to introduce a new special token, __VERSION__. It would work something like this: package Bar::Quux; __VERSION__ 2.0 ...stuff... __VERSION__ 1.3 ...stuff... __VERSION__ 1.0 ...stuff... We then change the semantics of use slightly, so it becomes: use Bar::Quux; # Identical to current; nothing breaks; loads the #code in the first VERSION, then stops parsing use Bar::Quux 1.3; # Parses the file looking for __VERSION 1.3__, #ignores everything except that version When you want to install a new version, you simply prepend it with its version number (or insert it at appropriate place). The order is, of course, irrelevant...you can order it as 1.3, 2.0, 1.0 if you want, but then 1.3 would be loaded by default and you would need to explicitly request other versions. I'm sure this idea can be improved on, but it's a first cut. What do people think? Dave
Re: UNIX epoch issues (Re: Why shouldn't sleep(0.5) DWIM?)
On Tue, 30 Jan 2001, Nathan Wiger wrote:
Jarkko Hietaniemi wrote:
As I said the problem isn't the p52p6 doing that kind of transformation.
The problem is someone familiar with perl5 writing code in perl6:
if (my $fh = open("/tmp/$$".time())) {
and later something crashing and burning because some other place expects
to find a filename of the form /^\d+\d+$/, or someone printing into log files
like this
Well, FWIW, here are two suggestions on how to handle this, the
grouchy way and the helpful way:
1) (grouchy) If you're writing Perl6, you should be writing Perl6,
and you should know how time() behaves and handle it properly.
2) (helpful) time() returns an int-based time value (as now), but
time(something) returns a subsecond-value...if we wanted to get really
fancy, then the value of something as an int could be the number of
places of accuracy that would be returned.
Dave
Re: RFC 331 (v2) Consolidate the $1 and C\1 notations
On Mon, 2 Oct 2000, Bart Lateur wrote: On Mon, 2 Oct 2000 12:46:06 -0700 (PDT), Dave Storrs wrote: Well, the main reason is that @/ worked best for my particular brain. But you cannot use it in an ordinary regex, can you? There's no way you can put $/[1] between slashes in s/.../.../. BAckslashing it doesn't work. True...which means that either perl does Deep Magic to allow it (a solution I don't like) or (the solution I DO like) the programmer uses different delimiters on pattern matchs that will contain the @/ variable...which is a good hint that something unusual is happening, which is a good thing. @ wouldn't be quite the right match...after all, $ contains the _string_ No, but it's closer. $ is closer in meaning to $1 than is, for example, $/. *Much* closer. Hmmm...I see your point. I've frozen the RFC as per deadline...Nate, is it too late for me to make a minor semantic change and rename a proposed variable? Dave
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Sat, 30 Sep 2000, Bart Lateur wrote: I wrote this before, but apparently you didn't hear it. Let me repeat: You're right, I missed your email when I was incorporating things into the new version. Apologies. $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 I don't believe it matters...my version of $1 works exactly like the current \1 and my $/[1] works exactly like the current $1. Dave
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Thu, 28 Sep 2000, Hugo wrote:
:=item *
:/(foo)_C\1_bar/
Please don't do this: write C/(foo)_\1_bar/ or /(foo)_\1_bar/, but
don't insert C in the middle: that makes it much more difficult to
read.
Sorry; that was a global-replace error that I missed on
proofreading.
:mean different things: the second will match 'foo_foo_bar', while the
:first will match 'foo[SOMETHING]bar' where [SOMETHING] is whatever was
should be: foo_[SOMETHING]_bar
Um, yeah, it should...(jeez...I proofed this like three times,
honest!) *blush*
:captured in the Bprevious match...which could be a long, long way away,
This seems a bit unfair. It is just another variable. Any variable
you include in a pattern, you are assumed to know that it contains
the intended value - there is nothing special about $1 in this regard.
Fair enough; the point I was trying to make was that \1 was
captured right here, while $1 was capturd long, long ago in a pattern
match far, far away. The visual/cognitive difference is small, but the
programming difference is huge.
:=item *
:${P1} means what $1 currently means (first match in last regex)
Do you understand that this is the same variable as $P1? Traditionally,
perl very rarely coopts variable names that start with alphanumerics,
and (off the top of my head) all the ones it does so coopt are letters
only (ARGV, AUTOLOAD, STDOUT etc). I think we need better reasons to
extend that to all $P1-style variables.
I do understand that, and I agree with your concern. Actually, I
didn't think that ${P1} was a particularly good notation even as I was
suggesting it...I just wanted to get the RFC up there before the deadline
so that people could discuss it.
Having now thought about it more, I think that (?P1) is
better...in other words, make references to the previous pattern match be
a regex _extension_, not a core feature (if that's a valid way to phrase
the distinction).
What is the migration path for existing uses of $P1-style variables?
Wherever p526 sees a pattern that contains a $1, it should replace
it with (?P1).
:=item *
:s/(bar)(bell)/${P1}$2/ # changes "barbell" to "foobell"
Note that in the current regexp engine, ${P1} has disappeared by the
time matching starts. Can you explain why we need to change this?
Note also that if you are sticking with ${P1} either we need to
rename all existing user variables of this form, or we can no longer
use the existing 'interpolate this string' (or eval, double-eval etc)
routines, and have to roll our own for this (these) as well.
I'm a bit confused by the way this came out but, if I understand
what you're asking, then I believe your concerns are solved by the new
proposed syntax. Am I right?
:This may require significant changes to the regex engine, which is a topic
:on which I am not qualified to speak. Could someone with more
:knowledge/experience please chime in?
Currently the regexp compiler is handed a string in which $variables
have already interpolated. [...]
I know there are certain exceptions to this...my Camel III says
(something to the effect of--I don't have it in front of me) "if there is
any doubt as to whether something should be interpolated or left for the
Engine, it will be left for the Engine."
In any case, I don't think this needs to change. I'm simply
changing what the names of the variables and backreferences are...\1
becomes (the new) $1, and (the current) $1 becomes (?P1)
Changing the lifetime of backreferences feels likely to be difficult,
but it isn't clear to me what you are trying to achieve here. I think
you at least need to add an example of how it would act under s///g
and s///ge.
Good point. I'll do that.
:RFC 276: Localising Paren Counts in qr()s.
I didn't see a mention of these in the body of the proposal.
276 is rather tangentially related, I grant. However, I felt that
if my proposal went forward, it could impact on how 276 was implemented,
so I crossreferenced to it.
Dave
Re: RFC 331 (v1) Consolidate the $1 and C\1 notations
On Fri, 29 Sep 2000, Hildo Biersma 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. Sigh. That would remove functionality from the language. The reason why you need \1 in a regular expression is that $1, $2, ... are interpolated from the previous regular expression. This allows me to do a pattern match that captures variables, then use the results of that to create a second regular expression. (Remember: A regexp interpolates first, then compiles the pattern). Umm...with all due respect, did you read the RFC? Because what I proposed does not eliminate any functionality. Dave
Re: IDEA: lexically scoped subs anyone
On 29 Sep 2000, Piers Cawley wrote: Is it possible? Advisable? I haven't seen it yet, but that doesn't mean it's not in there somewhere...there's a bunch of RFCs I haven't had time to read. If it isn't there, it should be. I think this is definitely a cool idea. Dave
is \1 vs $1 a necessary distinction?
Both \1 and $1 refer to what is matched by the first set of parens in a regex. AFAIK, the only difference between these two notation is that \1 is used within the regex itself and $1 is used outside of the regex. Is there any reason not to standardize these down to one notation (i.e., eliminate one or the other)? Dave
Re: is \1 vs $1 a necessary distinction?
On Wed, 27 Sep 2000, 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. That was pretty much my thought?
Re: is \1 vs $1 a necessary distinction?
On 27 Sep 2000, Piers Cawley wrote:
Do we *want* to maintain \1? Why have two notations to do the
I'm kind of curious about what happens when you want to do, say:
if (m/(\S+)/) {
$reg = qr{(em|i|b)($1)/\1};
}
where the $1 in the regex quote is refering to $1 from the previous
regex match.
Well, how about this:
$reg = qr{(em|i|b)(${P1})/\1};
NOTE: ^
If you assume that $1 and ${1} are equivalent (which makes it
possible to have as many backrefs as you want), then you could say that,
if the first character after the { is a P, it means "in the previous regex
match."
Dave
Re: RFC 292 (v1) Extensions to the perl debugger
On Wed, 27 Sep 2000, Johan Vromans wrote: What I wanted to indicate is that the input and output handling of the debugger, currently line input and line output, should not be turned into a sophisticated user interface with command line recall/editing and fancy output paging (e.g. two independently scrollable windows, one for input and one for output). External tools should manage that. I mentioned the way the perl debugger runs under Emacs, ptkdb is another good example. BTW: the debugger already has command line recall/editing using Term::ReadLine. I disagree. I want to have perl provide reasonable default behavior for these extremely useful and commonly-desired functions, and I don't want it to be dependent on modules from outside the core or on requiring the user to configure something (after all, if the user must configure it, it's not default). I want perl to provide me with a standard interface which satsifies my basic requirements. I want this interface to be the same on all platforms so I don't need to get used to "oh yeah, today I'm on the Windows box, so it's Shift-UpArrow for the command history." I'm not saying that outside tools shouldn't be built to provide _better_ versions of the standard behavior, or nicer UIs. I'm just saying that the basic versions are not acceptable, and should be improved and standardized. Dave
Re: RFC 292 (v1) Extensions to the perl debugger
On 26 Sep 2000, Johan Vromans wrote: Perl6 RFC Librarian [EMAIL PROTECTED] writes: The ability to easily retrieve and edit your N most recent commands to the debugger (much like a bash_history). and A better default pager. The default pager should assume a 24x80 term window ... To me, these clearly indicates that the debugger should be run as a subsystem of some other tool that takes care of this. It is not part of the debugger itself. For example, take a look at how emacs runs the debugger. I'm confused...are you suggesting that the debugger should no longer be integrated into perl? If so, I disagree...I absolutely insist that, no matter what pathological distribution someone may put together for Perl, I will get the debugger so at least I have a chance of figuring out what's wrong. The only way to absolutely ensure this is to have it built into the interpreter itself. As to the history file...this is something that I've wanted since I first touched the debugger, and I suspect others would like it as well. As to the pager...the "default pager" is currently "no pager", which is silly. I distinctly remember having the following thought pattern, from back when I was learning how to use the debugger: "Ok, what commands are available? Let's type 'h' " "Hmm...it scrolls off the screen...aha! look, down here at the bottom it says I can do '|dbcmd' to pipe the output of a debugger command through the current pager! Excellent, that's just what I need." " '|h' " [it runs off the screen again] "DOH!" All humor aside, there is too much information in the debugger help screen to fit in 50 lines. That means that anyone trying to use the debugger through a DOS window, or a fixed-size telnet client, can't see the majority of the information. Dave
Re: RFC 290 (v1) Remove -X
On 25 Sep 2000, Perl6 RFC Librarian wrote: =head1 TITLE Remove -X The prefered mechanism for file tests should be more legible, using terms like 'readable(FOO)' and 'writeable(FOO)' instead of the =head1 MIGRATION ISSUES Perl programmers happy with the -X syntax will need to get used to the lengthier replacement. Why can't both remain in place? Have the short forms so that those of us who are used to them and don't find them confusing can use them (and so p526 does not need to address this issue), and have the new readability-enhanced ( : ) versions as well, for them's as want those. This seems like an excellent place to TIMTOWTDI. Dave
Re: RFC 288 (v1) First-Class CGI Support
On Sun, 24 Sep 2000, Nathan Wiger wrote:
Offer simple functions to set HTTP headers (e.g. content type, result codes)
How about %HTTP, which is just flushed on the first line of output?
use cgi;
$HTTP{'Content-type'} = 'text/html';
print "Hello!"; # flushes %HTTP first
I like this a lot, but you need to make sure that it flushes the
hash in the right order if multiple keys are present.
Dave
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
On Mon, 25 Sep 2000, Michael Fowler wrote: This RFC makes no mention of what happens to the following constructs: %foo = (bar = "baz"); This actually isn't a bareword (as I understand it), since the = operator quotes its LHS.
Re: RFC 277 (v1) Eliminate unquoted barewords from Perl entirely
I personally have never had problems with these issues and would just as soon that this RFC didn't do through. However, I don't feel particularly strongly about most of it. Specifically: As to autoquoting the lefthand side of - (thereby making it a class name), I don't particularly care. The only place I use the indirect object syntax if for calls to 'new', where they read very cleanly, so I won't particularly miss them if they go away. There are certain places that I would like to see auto quoting happen. These include: 1) In a 'use' statement. 2) Inside the braces of a hash access or hash slice These places are not ambiguous, and it's a pain to have to put quotes around them every time. Dave
Re: perl6storm #0050
On Sat, 23 Sep 2000, raptor wrote: On Thu, 21 Sep 2000, Tom Christiansen wrote: =item perl6storm #0050 Radical notion: consider removing precedence. Wrong precedence makes people miserable. What if we have these 2 rules or no rules AND we can set manualy the precedence of all operators... as in PROLOG (op(precedencePriority,associativity!,operator)). I think this would be very unwise. Whenever adding a feature, we need to ask if the power granted outweighs the potential pitfalls created; in this case, I don't think it does. The potential problems of being able to assign precedence as you see fit (talk about action at a distance!) are enormous, and it does not seem to lend the same kind of elegant power that, for example, Damian's HOFs do. Dave
RE: PERL6STORM - tchrist's brainstorm list for perl6
On Fri, 22 Sep 2000, Greg Boug wrote: =item perl6storm #0064 Do something about microsoft's CRLF abomination. Perhaps somehow allowing $/ to take multiple input delimeters (perhaps in a fashion similar to egrep)... How about: [snip] $/ = "seperator1|seperator2"; [snip] so you could conceivably end up with code like: $/ = "\||\\"; to delimit on '|' or '\'... Alternatively, we make it work like '-' in a character class...if it's the first character, the RE knows that you want it to a literal hyphen. If used between two characters, you want a range (or, in this case, an alternative). So: $/ = "||foo" would mean 'delimited by a pile for by the sequence foo' Similarly (although this one might be a lot nastier from an -internals viewpoint), we could say that, if the final " is immediately preceded by an '\', then clearly what you wanted was a literal backslash. (That is, "\" would not produce a runaway string...hmmm, that's a good idea all by itself, actually.) Assuming that both of these ideas were implemented, then you could write: $/ = "||\" and it would DWYM. Dave
Re: RFC 12 (v2) variable usage warnings
On Wed, 20 Sep 2000, Steve Fink wrote: 1 my ($x, $y, $z); 2 $z = 1; 3 my $logfile = "/tmp/log"; 4 $x = 1 if cond(); 5 print $x+$y; 6 undef $z; 7 print $z; -- use of uninitialized variable $y in line 5 (compile time) -- possible use of uninitialized variable $x in line 5 (compile time) -- variable $logfile defined in line 3 but never used (compile time) -- use of undefined value in line 7 (run time) Couldn't the error on line 7 be detected at compile time as well? After all, there is no execution path which will result in $z having a defined value. Dave
Re: RFC 12 (v2) variable usage warnings
On Wed, 20 Sep 2000, Eric Roode wrote: foo(); print $x; Generate a warning, or not? Which one? Remember, foo() may initialize $x. My suggest (FWIW) would be that, if there is no execution path which leads to $x being defined in the second line, then a "Use of uninit'd variable $x" warning should be thrown at compile time. If there is at least one path that will result in $x being defined AND at least one path that will result in it being undefined, the compile-time warning could be something like "Possible use of undefined variable $x" or "Not all execution paths leave $x defined". Dave
Re: RFC 212 (v1) Make length(@array) work
On Wed, 20 Sep 2000, Bart Lateur wrote: The argument against my reasoning would be if the bulk of people making this mistake are *not* coming from C. I don't know. I have a feeling we're either arguing the same side without realizing it, or we're just having a straight-up conversational rift. Let me restate my opinion and see if that helps: @a = (1, 2, 3); print (length @a); The result should be that 3 is printed. The concept of "(# of elements in array) == (length of array)" is a common one in many languages. It is intuitive to many people...I know that I tried doing it when I first started using Perl. It does not seem to particularly interfere with existing semantics (although, I'm sure someone will point something out that I have not considered)...by which I mean that "length @foo" does not currently have any frequently-used meaning. I like Perl because it generally DWIMs. This seems like a good way to make it DWIM more. Dave
Re: RFC 255 (v2) Fix iteration of nested hashes
On Tue, 19 Sep 2000, Tom Christiansen wrote:
This RFC proposes that the internal cursor iterated by the Ceach function
be stored in the pad of the block containing the Ceach, rather than
being stored within the hash being iterated.
Then how do you specify which iterator is to be reset when you wish
to do that? Currently, you do this by specifying the hash. If the
Suppose we change each to be:
each HASH
each ITERATOR
and create a new keyword,
iterator HASH
which creates a new iterator for the specified hash. This iterator can
then be eached, just like the hash, and reset using
reset ITERATOR
Usage would then look like this (stealing Damian's code):
%desc = ( blue = "moon",
green = "egg",
red = "Baron" );
$i1 = iterator %desc;
$i2 = iterator %desc;
while ( my ($key1,$value1) = each $i1)
{
while ( my ($key2,$value2) = each $i2 )
{
print "$value2 is not $key1\n" unless $key1 eq $key2;
}
}
print "(finished)\n";
This runs into problems if you currently have an iterator extant and you
modify the hash to which it points. Immediate suggestions on how to
handle this would be:
1) Do what the docs currently do; tell people "don't do that"
2) Have the iterator auto-reset when the hash is modified
(probably bad)
3) Make the hash unmodifiable while there is an iterator extant
(probably bad)
4) Make powerful magic in some way that isn't coming to mind
Dave
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Mon, 18 Sep 2000, Glenn Linderman wrote: This is an interesting comment to be made about an interesting side effect of this proposal. [snip] (1) array elements can be accessed by name (2) member data can be looked up quicker (by array index, rather than by hashed name) [snip] new RFC: [snip] my @foo; # empty array $foo ['month'] = 10; # $#foo == 1, $foo[0] == 10 $foo ['day'] = 20; # $#foo == 2, $foo [1] == 20 $foo ['year'] = 30; # $#foo = 3, $foo [2] == 30 This is an interesting idea, certainly...my question is, if we go with this idea, what will hashes be used for? Or are they simply rendered obsolete? (I find that hard to believe, but I can't offhand think of a usage that this doesn't cover.) This will require every array to carry around an internal hash mapping its symbolic names to the index at which they point. Dave
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easyprogramming
On Tue, 19 Sep 2000, Adam Turoff wrote: On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote: I think I would be guardedly in favor of changing the default scope from global to local (although I have the feeling there is something I'm not considering). What does everyone else think? [the following is shown out of original order] Really? You want a brand new $foo inside a while loop, distinct from the one inside the surrounding sub? That is lost when the while loop terminates? Urmm...I think maybe I just realized what it was that I wasn't considering. Never mind. Forget I said anything. *blush* Dave
Re: pack/unpack is damn unperlish. Explain them as Perl.
On Mon, 18 Sep 2000, Michael G Schwern wrote: I'm sure there are many times when pack should have been used but it got hacked together with something else. The prime example is [...] I must admit I'm with Michael on this one. I've been writing Perl on and off for two or three years; I consider myself minimally competent but certainly not great. I do not understand (un)pack and have never used them. Perhaps I could figure it out if I pored over the man pages and the book and sat and played with it for several hours, but there has never been sufficient motivation to do so; given that TIMTOWTDI, I have never *needed* to use (un)pack...and, as a result, I have probably written less efficient code as a result. I guess, if I had to write an explanation of pack/unpack based on my limited understanding, it would be something like: "Unpack takes binary data in some particular format and disassembles it, assigning various pieces of it to variables according to formatting that you supply. Pack does the opposite, using your supplied formatting to crunch Perl scalar variables into binary data that is represented in some specific way. The binary data used by (un)pack will belong to exactly one type of C numeric variable, meaning that it will be limited in what kinds of numbers it can store and how it will represent them." Is this definition completely off-base? Dave
Re: Pre-withdrawal notice for RFC184
On Tue, 19 Sep 2000, H.Merijn Brand wrote:
On 19 Sep 2000 09:23:00 +0300, Ariel Scolnicov [EMAIL PROTECTED] wrote:
I'm planning to withdraw RFC184 ("Perl should support an interactive
mode"), due to lack of interest. There was little discussion of it,
I seem to have missed this one, or I would have been in on the
discussion. Personally, I really like the idea. I have now read the RFC
and will think on it; if enough other people chime in with "wait!wait!",
I'll post some thoughts...otherwise, I'll be sorry to see it go.
Dave
Re: 'eval' odd thought
On Fri, 15 Sep 2000, Bart Lateur wrote: On Thu, 14 Sep 2000 18:14:49 -0400, Mark-Jason Dominus wrote: The perl 5 - perl 6 translator should [recursively handle eval] Blech, no. eval should stay eval. People are responsible for generating Perl6 compatible code, if they construct code as strings on the fly. I would disagree. If I'm using a program to translate my code from one version of Perl to another, I don't want to have to go in and hand-fix (possibly large) sections of it...it should just _work_. I'm with MJD on this one. Dave
Re: RFC 111 (v3) Here Docs Terminators (Was Whitespace and HereDocs)
On 14 Sep 2000, Ariel Scolnicov wrote: 1. It requires the perl parser know about indentation. Of course we all know that tabs are 8 characters wide (I myself make a point of bludgeoning anyone who says otherwise), but do we really want to open this can of worms? No, because for every person such as yourself who is into eight spaces, there is someone else like me who wants four. And don't even get me started on the really strong guys who want three spaces...you know, the Threeite Musclemen. print FIRST_HERE_DOC; print SECOND_HERE_DOC; This is on the left margin. This is indented one char. FIRST_HERE_DOC This is indented one char. This is on the left margin. SECOND_HERE_DOC RFC 111 specifically disallows statements after the terminator because it is too confusing. I would say that the same logic should apply to the start of the here doc; I'm not sure, just from looking at it, if the example above is meant to be two interleaved heredocs, one heredoc after another, or what. Dave
Re: Draft RFC: new pragma: Cuse namespace
On 13 Sep 2000, Piers Cawley wrote:
Hildo Biersma [EMAIL PROTECTED] writes:
Piers Cawley wrote:
I'd like to use shorthands for A::B::C's Foo and X::Y::Z's Bar at the
same time.
Well you can't. The patch that I pinched this RFC from is a lexically
How about if we added a list, @NAMES, into which you could assign
namespace shortcuts, something like this:
package main;
push @NAMES, ("A::B::C" = 'ABC',
"X::Y::Z" = 'XYZ',
"StupidlyLongMathThingie" = "SLMT",
"Bar::Baz" = ""
);
ABC::do_stuff(); # prints "ABC";
XYZ::do_stuff(); # prints "XYZ";
SLMT::do_stuff(); # prints "4";
# do_stuff(); # [1]
sub do_stuff() { print "main"; }
package A::B::C;
sub do_stuff() { print "ABC"; }
package X::Y::Z;
sub do_stuff() { print "XYZ"; }
package StupidlyLongMathThingie;
sub do_stuff() { print 2 + 2; }
package Bar::Baz;
sub do_stuff() { print "barbaz"; }
__END__
Whenever the interpreter saw a namespace usage, it would need to
check @NAMES in addition to checking the included modules list.
The problem comes when the user aliases two different namespaces
to the same alias (e.g., "Foobar" = "F", "Foxtrot" = "F")
In this case, if the usage is unambiguous (e.g., F::do_foxtrot(),
and the Foobar module does not contain a sub by that name), then perl
should raise a warning but go ahead and execute. If the usage is
ambiguous, this should be a fatal error.
Dave
Re: Draft RFC: new pragma: Cuse namespace
Scuse me...I just realized that I missed an edit in my previous post. The
[1] that you see was intended to be a footnote talking about the
possibility of conflicting namespace aliases. When I expanded that into
the final couple paragraphs, I forgot to take out the [1]. Sorry for the
confusion.
Dave
On Wed, 13 Sep 2000, Dave Storrs wrote:
How about if we added a list, @NAMES, into which you could assign
namespace shortcuts, something like this:
package main;
push @NAMES, ("A::B::C" = 'ABC',
"X::Y::Z" = 'XYZ',
"StupidlyLongMathThingie" = "SLMT",
"Bar::Baz" = ""
);
ABC::do_stuff(); # prints "ABC";
XYZ::do_stuff(); # prints "XYZ";
SLMT::do_stuff(); # prints "4";
# do_stuff(); # [1]
sub do_stuff() { print "main"; }
package A::B::C;
sub do_stuff() { print "ABC"; }
package X::Y::Z;
sub do_stuff() { print "XYZ"; }
package StupidlyLongMathThingie;
sub do_stuff() { print 2 + 2; }
package Bar::Baz;
sub do_stuff() { print "barbaz"; }
__END__
Whenever the interpreter saw a namespace usage, it would need to
check @NAMES in addition to checking the included modules list.
The problem comes when the user aliases two different namespaces
to the same alias (e.g., "Foobar" = "F", "Foxtrot" = "F")
In this case, if the usage is unambiguous (e.g., F::do_foxtrot(),
and the Foobar module does not contain a sub by that name), then perl
should raise a warning but go ahead and execute. If the usage is
ambiguous, this should be a fatal error.
Dave
Re: RFC 212 (v1) Make length(@array) work
On Wed, 13 Sep 2000, Hildo Biersma wrote: =head1 TITLE Make length(@array) work Counter-proposal: make length(@array) a syntax error. I don't feel like rewarding stupidity, I'd rather teach people how to do things properly. As a general rule, I agree with Hildo that we shouldn't reward stupidity. However, the beautiful thing about Perl, the thing that makes me prefer it over every other language on the planet, is that it generally DWIMs. For the most part, the natural, intuitive thing works (ok, first you have to wrap your head around context and a few other bits of weirdness, but THEN it's intuitive). So I ask...if many newbies do this, and not all of them are stupid (a very safe statement, statistically), then perhaps this is simply an example of "the intuitive way to do it" and we should make it work? Dave
Re: RFC 196 (v1) More direct syntax for hashes
On Thu, 7 Sep 2000, Michael G Schwern wrote: On Wed, Sep 06, 2000 at 06:40:10PM -, Perl6 RFC Librarian wrote: Cscalar(%hash) should return what Cscalar(keys %hash) currently returns. Good. I'll weigh in with a "me too" on this. Creset %hash should reset the hash iterator, instead of calling Ckeys or Cvalues as is currently the case. Sounds good, except the name. reset() already does something. Currently, reset() is for clearing large swaths of global variables (a dubious feature) and for reseting ?pattern? searches. Two weird features crammed into one keyword. Shoving a third in doesn't seem pleasent. I think my suggestion would be that we remove the other two features (which I doubt anyone uses all that often). However, if lots of people chime in with "no, no! We *must* have our reset as-is!" (or, more likely, if removing these features is too much of a pain for the p52p6 people), then here are some suggestions for alternate keywords: renew, restart, refresh, freshen, The parser should special-case the variations of Csort %hash so that it returns the keys and value, calling the comparison function for keys. I'm trying to think of a common case where I'd want sort() to treat a %hash like a list (as it currently does) but I can't really think of one. I would go so far as to argue that the current behaviour is actually _bad_...if I want a list, I'll use a list. If I put things into a %hash, that means that I want THESE keys to be associated with THOSE values. The way sort currently works destroys those linkages. What you proposed and what you put in your example doesn't quite play out. Csort keys %hash returns just the sorted keys of %hash, but your foreach example implies that both keys and values would be returned, sorted by key. Both would be useful. I'd edge towards the latter because the former is simple enough to reproduce (just explicitly say Csort keys %hash) and its use is mostly when you want to iterate over the keys of a sorted hash, which would largely be eliminated if your proposal returned a 'sorted' hash. Again, "me too". Dave
auto-initializing values
This is something fairly basic, but I haven't seen it in discussion or in
the RFCs. If I've missed it, my apologies.
In Perl 5, when a variable is created, it is given the "undefined" value.
This can lead to lots of spurious "Use of uninit'd variable" warnings.
Suppose you could specify the value with which all variables in the
enclosing scope should be initialized; for example:
{
# handle pensioners here
init_vars = 0;
my ($num_pensioners, $base_pension, $years_service); # all get '0'
}
{
init_vars = 'ERROR::NAME_NOT_FOUND';
my ($name_1, $spouse_name_1); # all get 'ERROR...' message
}
{
init_vars = (1,7,9);
my (@blarg);
}
{
init_vars = \{};
my ($rh_data_record);
}
...etc
An example of when you might use this is when working with a
DB...frequently, I do the following:
1) Set up a large number of variables
2) Put sentinel values in them
3) Fill them with info from the DB
4) Check to see if the sentinel value are still there
5) If so, do error handling
Dave
RE: auto-initializing values
On Mon, 11 Sep 2000, Myers, Dirk wrote:
Suppose you could specify the value with which all variables
in the enclosing scope should be initialized; for example:
I haven't seen this either, but I suggest that it should be a set of
pragmas:
use init_scalar 0 ;
use init_array () ;
... especially because I'm not sure what effect :
init_vars = \{} ;
my @foo ;
should have. (Probably none, but how do you specify default values if you
want to init multiple kinds of data in the same scope?)
My suggestion would be that it simply have no effect. On the
other hand, if a "initial size" attribute were added to arrays, then this
could be very useful...say that you have 50 employees, each of whose data
is stored in a hash. Here's an easy way to get a list of references to
all the hashes, with error handling built in:
init_vars \{name = 'NONE'};
my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
@employees = get_from_db('*');
for (@employees) {
if ( $_{name} eq 'NONE' ) {
die "Oops! DB error\n";
}
}
Dave
Re: auto-initializing values
On Mon, 11 Sep 2000, John Porter wrote:
Dave Storrs wrote:
init_vars \{name = 'NONE'};
my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
@employees = get_from_db('*');
for (@employees) {
if ( $_{name} eq 'NONE' ) {
die "Oops! DB error\n";
}
}
I still don't see any compelling benefit for new syntax here.
Old syntax works great.
my @employees = map { { name = 'NONE' } } 1..50;
Ok, this is a fine complaint. Which is why I started this thread
with the question "Would it be useful if"
By the way, regardless of how @employees gets initialized above,
that initialization gets blown away by the next thing you do:
@employees = get_from_db('*'); # only got 2 records???
Unfortunately, your approach in this particular case is flawed.
*Sigh* This, unfortunately, shows that you completely missed my
point. The point of the exercise was to set up some variables (the entries
in the array), initialize them with sentienl values (i.e., values that are
known to be invalid), fill them with information from a DB, and then check
to make sure that you actually got valid info into each variable. As
regards the imaginary function "get_from_db('*')"...I expected it to be
understood that that meant "get all records from the DB."
Dave
OT: pronouncing www (was: Re: ... as a term)
On Thu, 24 Aug 2000, Bart Lateur wrote: On Mon, 21 Aug 2000 18:21:00 -0700 (PDT), Larry Wall wrote: If you want to save the world, come up with a better way to say "www". (And make it stick...) "The world"? This problem only exists in English! We pronounce it something similar to "way way way". Personally, I've always said it "dub dub dub". Dave
