Re: New variable type: matrix
Using semicolons is an interesting idea. But consider: @a[10:20; 30:40]; The ":"s and ";" are awfully hard to visually distinguish. c.f. @a[10:20, 30:40]; What do people feel about the whole replacing ".." by ":" issue? Karl
Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping
Consider @x[10:20, 20:40:2, 30:50] This ALMOST works in the current Perl. @x gives array context, then the , produces a list. If [] is overloaded on @a then the subroutine sees a list like "10:20", "20:40:2", "30:50" The only reason it does NOT work in the current perl is that "10:20" is a syntax error. What would be required to make this go away? i.e. to have 10:20 appear as a plain strring. What else would it effect? Sounds like almost a solution... Karl
Re: New variable type: matrix
Christian: You are right, it would not be best to confuse normal perl lists with compact arrays--they both have their purposes and can be combined usefully. What I meant to say (but failed, alas) was that I support the idea for a new perl variable type called compact array: $foo -- scalar @foo -- array %foo -- hash ^foo -- compact array (or whatever notation) Given this notation, you could have hashes of compact arrays, lists of compact arrays, etc. There are still sticky questions about how much should be done in the perl core and how much in modules. It would, of course, make no sense to hack deeply into the perl core to add a new fundamental type if everything useful that could be done with that type required a separate module... Just my $0.02 Doug Christian Soeller wrote: Doug Hunt wrote: But I would like to speak up in support of Baris' idea. I have long found it confusing (both to myself and to those I must explain my code to) the mix of pdl multi-dimensional lists (lists of refs to lists) and PDLs, which appear to be scalars. I was even asked once why some arrays look like arrays and other look like scalars. It seems to me that scalars are quite overloaded these days. I suppose the question is: Do we want to continue the perl4 tradition of syntactic markers for different data types, or do we want to lump everything together? Since I'm in the 'numeric' camp, I would vote for full membership of the compact array type in the set of perl types. I am not sure that PDL objects (piddles) are actually best represented by arrays. It is much better to think of what are now piddles as a rectangular region of nD space. The array '@' signals array context and we don't want every function that returns a piddle to signal array context. We now have functions that return lists of piddles ($fit,$fwhm) = fitgaussian $x, $y and the distinction between list context and scalar context is a good one to have with piddles as well. The other problem with arrays is: how do we deal with functions that take multiple piddle arguments if they are arrays: @result = integrate @x, @y, @bounds; Won't those all be clumped into one big input array? Does it mean we have to write @result = integrate \@x, \@y, \@bounds; which seems bad to me. Secondly I feel that the history of array indexing stands in the way of the flexibility that piddle-like things need. So we are probably better off asking for a $pdl(0:-1,:2) syntax for slicing. That leaves request for a default method and ';' as range operator. Christian -- [EMAIL PROTECTED] Software Engineer III UCAR - COSMIC Tel. (303) 497-2611
Re: New variable type: matrix
Doug Hunt wrote:
What I meant to say (but failed, alas) was that I support the idea for a
new perl variable type called compact array:
$foo -- scalar
@foo -- array
%foo -- hash
^foo -- compact array (or whatever notation)
Given this notation, you could have hashes of compact arrays, lists of
compact arrays, etc. There are still sticky questions about how much
should be done in the perl core and how much in modules. It would, of
course, make no sense to hack deeply into the perl core to add a new
fundamental type if everything useful that could be done with that type
required a separate module...
The other valid point is: How are you going to access $individual
elements? If the answer is to use $var[]'s still:
^foo = ([1, 2], [3, 4]); # I know, it's taken, I helped :-)
$foo[0,0];# uh-oh
Then adding a new fundamental type and syntax is not only unnecessary,
but silly. Since []'s and {}'s are already taken, and ()'s are
off-limits because of symbolic references to functions, you're going to
have to find a new set of characters:
$foo(0,0)# BAD idea
$foo^0,0^# uh-oh, this
$foo`0,0'# is just plain
$foo|0,0|# getting ugly
Blech!
I think the better way is to take Buddha's idea (soon to be RFC'ed, by
the sounds of it), and make current arrays a little more flexible. It
sounds like we'll just have to add an extra dimension somehow, and then
"arrays of compact arrays" will simply be "arrays with some compact
elements". This sounds more flexible and less bloated to me.
-Nate
Re: multidim. containers
At 10:28 AM 8/28/00 +1000, Jeremy Howard wrote: X-posted to [EMAIL PROTECTED] David L. Nicol wrote: If arrays as we know them implement by using a key space restricted to integers, I think a reasonable way to get matrices would be to open up their key space to lists of integers. I've been thinking along exactly the same lines. There's a lot of language issues to consider to get this to work consistently, such as interaction with reduce(), notation for slices across a dimension (and generalised slices such as diagonals), and so forth. I'm thinking that a n-dim array could just be a list of lists (of lists of lists of...) with the n-dim notation just being syntactic sugar (and perhaps helping with optimisation too). If you want efficiency, n-dimensional arrays really need to be a concrete data type all of their own. That way one big block of memory can be allocated and, if it's a typed array, properly sized. That doesn't mean that n-dimensional arrays won't be just sugar over the standard list-o-list structure to start, but they won't have to stay that way. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
On RFC 88: Serendipity while throwing a string.
I have been working on the Perl 5 reference implementation of RFC 88 functionality (Try.pm, which is currently available at: http://www.avrasoft.com/perl6/try6-ref5.txt ), and I stumbled across the following result. If you are writing some code, and there is a "throw" subroutine in scope, and there is a package Exception in scope and it has a "throw" subroutine, then Perl 5 can tell the following apart (search for the /!throw-3/ regression test in try6-ref5.txt): throw "A Message"; # Calls the subroutine. throw Exception; # Calls the method. throw "A Foo Message", tag = "ABC.1234"; throw Exception "Foo", tag = "ABC.1234"; I don't know about you, but I think this is cool. Talk about DWIM! Good old Perl. So now, in Try.pm, If you throw a string, you get an Exception anyway: throw "A Message", ...; is now the same as: throw Exception "A Message", ...; You can't say Cthrow $@ to re-raise an exception any more, but you can say $@-throw or use a simple bare Cthrow;! And Cthrow; with @@ == 0 raises a simple Exception! I'll modify RFC 88 to change the throw syntax from: throw := throw E message options ; E := class | object to: throw := throw class message options ; | throw string options ; | throw; and make the appropriate changes to the semantics. And of course, Ctry should accept an additional hook parameter that specifies the class into which to instantiate string throws. Seems obvious in retrospect; we already had class and string, why did E have to be class | object? Ah well, serendipity is like that, I suppose. Yours, c, Tony Olekshy
Re: Structured exception handling should be a core module.
At 10:13 AM 8/25/00 +0200, Bart Lateur wrote: You're citing my objection for merging in $@ with the rest of the error variables. $@ currently is the "eval failed" flag, irrespective of what else failed. We *must* have such a flag. If $@ and $! would be merged, $! will have to be cleared if the eval doesn't fail, just like $@ is now. Yes. Basically, you can think of the new $! as getting done to it whatever was last done to any of the set of $@, $!, $^E, and $? in the current Perl. Well, I doubt it will be that simple :-) -- Peter Scott Pacific Systems Design Technologies
Re: Structured exception handling should be a core module.
At 01:42 AM 8/25/00 -0600, Tony Olekshy wrote:
Peter Scott wrote:
If $@ and $! are merged, then in code like
try {
system_call_that_fails();
more_stuff_that_succeeds();
}
finally {
}
does the finally block think there is a current exception or not?
$! was set by the failed system call, but nothing died or threw.
If $@ is put into $! instead, how does the finally block know that
it's not an exception? ! ref($!) ...?
I think it is imperative that if Perl has die and eval then it must
have a flag that indicates *only* whether or not eval returned via
normal local flow control or via non-local unwinding started by a
die. Otherwise, I can see no way any quasi-reliable non-local flow
control can be extened by writing blocks of local flow-control code.
So if open, for example, can set $! without invoking die, then $!
and $@ must not be merged. As I read it, 151 would (as currently
promulgated) not meet my requirement for the unique nature of a
$@-style variable. I don't think overloading ref to pick off true
exceptions would make me happy either ;-)
Actually, think about it some more. Why not? If you want to implement RFC
88 as a module, then the ugliness, if there be any, of testing ref $!
instead of $@ is tucked away in one place only. The end user is not
bothered by any of this because if they inspect $! as a string, they'll get
the error message no matter what happened.
I think that RFC 151 should be *merged* into RFC 80.
RFC 151 seeks to simplify the space of error variables for people doing
very short things without exceptions. I really don't want to muddle the
issue with structured exceptions; I just want to make sure it doesn't
obviate any of RFC 88.
RFC 80
should define a simple set of lower-case system-reserved fields
to be used for signalling fault information by the Perl 6 core.
RFC 80 should also define a mapping from this simple fault-hash
into a proper Exception object (using, oh, say reference to a
blessed copy of said fault-hash).
Now, hold on to your hat, %@ should the name of this fault-hash...
$@{type}"IO::File::NotFound"
$@{message} "can't find file"
$@{param} "/foo/bar/baz.dat"
$@{child} $?
$@{errno} $!
$@{os_err} $^E
$@{chunk} That chunk thingy in some msgs.
$@{file}Source file name of caller.
$@{line}Source line number of caller.
This is just an object in sheep's clothing. Worse, you've not only not
merged $!, $^E, and $@, which was the goal of RFC 151, you've made their
names longer. Breaking out all those attributes is fine, for them that
wants it; but then do it in an object. I'm trying to define an independent
proposal in RFC 151 for the folk who don't want to use exceptions and don't
want to scratch their heads to figure out what error variable to look at.
%@ should not contain a severity or fatality classification.
*Every* call to a core API function should clear %@.
Internally, Perl can use a simple structured data type to hold the
whole canonical %@. The code that handles reading from %@ will
construct it out of the internal data on the fly.
If Cuse fatal; is in scope, then just before returning, each core
API function should do something like: %@ and internal_die %@;
AFAICT this isn't necessary. If a core function experiences an error, if
Fatal is in scope, it dies by throwing an exception in $! which stringifies
to the usual error text. If it isn't in scope, it sets $! to that error
text. Good backwards compatability karma.
The internal_die becomes the one place where a canonical Exception
can be generated to encapsulate %@ just before raising an exception,
whether or not the use of such canonical Exceptions is controlled by
a pragma such as Cuse exceptions;.
--
Peter Scott
Pacific Systems Design Technologies
Re: Are Perl6 threads preemptive or cooperative?
At 12:11 PM 8/28/00 -0500, David L. Nicol wrote: What if every subroutine tagged itself with a list of the globals it uses, so a calling routine would know to add those to the list of globals it wants locked? If you're looking for automagic locking of variables, you're treading deep into "Interesting Research Problem" territory (read: Solve the Halting Problem and win a prize!) if you want it to not deadlock all over the place. Been there. Tried that. Backed away *real* slowly... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 161 (v2) OO Integration/Migration Path
I've read over 161 again and I'm starting to see areas where I can clarify things greatly. I apologize for the confusion. I'll make mods to the RFC in the near future, after I get more feedback from you all. Here are my goals as they probably should have been stated in the RFC: - Concentrate responsibility closer to the basic data structures (currently scalar, list, and hash). - Allow customization of these structures by the user, though inheritance. - Reduce or eliminate the need for new keywords in Perl itself, since the basic data structures can be extended as needed. - Maintain a migration path for Perl 5 (so I can have all of this without touching my existing code). I shudder to think of something that prevents simple variable accesses and instead requires verbose method calls. That doesn't seem to be making anything easy. Ditto. Accessing data doesn't change. I'm not suggesting accessors be added to scalars. Rather, I'm suggesting that scalars be responsible for knowing their type, rather than Perl being responsible for that. Methods like 'asInt()' are intended to act as a switch that gets flipped so the scalar knows what type it is supposed to be. Optionally, they could also act as a cast mechanism when used as an rvalue. An overloadable cast mechanism at that. Do you mean that when we write: my int $intVal = 0; it gets turned into OO stuff? Or do you mean that we won't be writing my int $intVal = 0; any more? I don't like the latter option. It would seem to require more typing to allow something that a minority of people will use. Originally I was trying to avoid explicit typing through new keywords, like 'int'. So the latter option would have been the case. But after Nathan Wiger's reply to my RFC, I realized that either syntax would work. Under one scenario, 'int', as in your example, would simply be the name of a factory function, so that: my int $intVal = 0; could be equivalent to: my $intVal = Scalar-int(0); And with no more typing required than before. Matt
Re: RFC 161 (v2) OO Integration/Migration Path
On Sun, 27 Aug 2000 06:14:00 -0700, Matt Youell wrote: So an int gets stored as two bytes and not four or eight. Gee, I thought it was more like 30. The savings in bytes don't look too impressive in this case. 4 byte addition is as fast as 2 byte addition on most pmodern platforms -- and you definitely may ignore any difference with regards to Perl's general overhead. Actually I wouldn't mind a variable-length integer, BigInt, as a standard type. Take no more bytes than you need. But expand if it's necessary. -- Bart.
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
What I meant to say was more along the lines of "if this could be done as a macro, does it need to be a pragma, or could it be part of a standard macro package?" And, secondly, "if this *is* part of a standard macro package, wouldn't it be cool to let it shove arbitrary code around rather than just doing invocant access syntax?" Sure. *If* the hypothetical macro package comes to be, this and many other proposals could be subsumed by it. But that's a mighty big "if" :-) Damian
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
On Mon, Aug 28, 2000 at 08:12:22AM -0700, Nathan Wiger wrote:
Jonathan Scott Duff wrote:
I think that Csubst is too syntactically close yet semantically far
from Csubstr that the evil demons of confusion will rear their ugly
heads.
I agree too, any suggestions are welcome. The fact that 'sub' and
'substr' are already taken makes this tough...
Well, if s/// stays around, I imagine that's what people will use, so
we could call the function form Csubstitute. Only those weirdos
using the function form would have to pay the syntactic penalty. ;-)
Given the above, why not make a bare Csubst do something equally
useful? Here are some ideas:
subst; # removes leading and trailing whitespace
I like this one alot.
Me too. I put down the others to give people brain-food mostly :-)
But again, this doesn't seem to make much sense in what I would think
would be its common use (using the spelled out version):
while () {
substitute; # What the hell am I substituting?
...
}
Similarly with match:
while () {
next unless match; # Er, match *what*?
...
}
Both leave me hanging. I can't read Perl in english like I'm used to.
I wonder what happens when people start typing
$new = subst s/old/new/i, $old;
They get a syntax error! :-)
Honestly, I don't think that's a big problem. People don't do this with
split() now. I think people will either use the "backwards compat" s///
form or the function form.
But they might *accidentally* use both. I'd prefer that Perl ... you
guessed it ... DWIM here. I.e.,
$new = substitute s/old/new/i, $old;
would be equivalent to
$new = substitute /old/new/i, $old;
With a warning if they're turned on. Same for match.
Hmm. Does using the function form still give the ability to pick
delimiters? And what does *this* mean:
@stuff = split match /foo/, $string;
?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
Have you ever wanted to count the number of matches of a patten? s///g returns the number of matches it finds. m//g just returns 1 for matching. Counts can be made using s//$/g but this is wastefull, or by putting some counting loop round a m//g. But this all seams rather messy. It's really much easier than all that: $count = () = $string =~ /pattern/g; --tom
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
Simple solution. If you want to require formats such as m/.../ (which I actually think is a good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6 enhancement of strictness. That's like having "use strict" enable mandatory perlstyle compliance checks, and rejecting the program otherwise. Doesn't seem sensible. --tom
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
Michael Maraist writes: Compatibility is going to have to be maintained somehow. And we can either have some sort of perl6 designator (such as the pragma) to designate incompatible (and otherwise ambiguous) code, or we're going to have to continue tacking on syntactic sugar to legacy code. The compatibility path for perl5 to perl6 is via a translator. It is not expected that perl6 will run perl5 programs unchanged. The complexity of the translator and the depth of the changes will be decided by the decisions Larry makes. Nat
Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
On Mon, 28 Aug 2000 14:22:03 +1100 (EST), Damian Conway wrote: I don't get it. What makes it so hard? If you see a "/" when you're expecting an operator, or end of statement, then it's division. If you were expecting an expression, it's a regex. Ain't it? Yes. And that's what makes it hard. Because somethimes you can be expecting *either* of those :-) Consider the statement: wash / my / gimsox; Division or pattern match? Ah I see. Well, requiring m// doesn't really help, in the general case. foo -2 subtraction or function call with parameter -2? -- Bart.
Automated no status messages
I've just run a nasty hairy script over the RFC repository and sent email to those people who I think have language RFCs but haven't put statuses on them yet. My aim in this is to figure out which RFCs are still actively under discussion and which aren't. Some people haven't updated their RFCs in a few weeks, so now is the opportunity to fix them up. Some people will have got two copies of the email... my apologies for this. I've fixed the script now :) I'll be repeating this process again in a week or so. K. -- Kirrily Robert -- [EMAIL PROTECTED] -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: Further it should ignore any whitespace (and comments) that follow the terminator. All of these should work: print EOL ; EOL # this is the end of the here doc But currently, I like using: print "#EOT#2"; blah blah blah #EOT#2 For some silly reasons, I grant you. A: The leading "#" makes the whole thing look like a comment to my simple-minded syntax highlighting editor. It makes it stand out. And B: the "2" at the end makes the end-of-here-doc identifier unique, so that a small error somewhere in may script doesn't allow a "something" doesn't slurp in a too large a part of my script. I like the "#" between "EOT" and "2" because it stands out visually. In short: your "up to but excluding the comment" would disallow both. I don't see the use for the comment on the same line as the end-of-here-doc marker. Why simply not put the comment on the next line? -- Bart.
Re: RFC 162 (v1) Filtering Here Docs
On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: It only removes whitespace, and it measures whitespace with tabs=8. My editor is set to tabs=4. Perl's interpretation wouldn't agree with the visual appearance in my editor. This doesn't sound like a neat solution. Why not disallow merging of tabs and spaces as being equivalent? If you want to skip a leading tab, but a tab between '"' and the EOL marker. If you want to skip spaces, put spaces in. If you want to skip tabs and spaces, put that sequence in. The only consequence would be that you'd have to be consistent in what you put in front of the text lines (and in the whitespace prefix definition). -- Bart.
Re: Let's have a Standard for Module Configuration
That could be very nice. I would really prefer changing parameters through the API, by calling class functions or something, but I don't see why everyone should agree with me. Keeping source-editable parameters in a standard place would then be a win, especially considering your thoughts about the module install system. What about Foo::Configuration? /Cajo. At 13.35 -0400 2000-08-25, David Corbin wrote: There are several modules I've run across that require you to edit them after you've installed them. I consider this to be a very bad thing. What I'm thinking is needed, is a standard way to have a file in the module package that contains the editable parameters. The name of this file should be consistent relative to the module. The module install system should NEVER overwrite it, but should identify when some configurable item is needed by a new revision that isn't in the old one and warn the user. --- Carl Johan Berglund, [EMAIL PROTECTED], 0708-136 236 Adverb Information, http://www.adverb.se, 08-555 788 30
Nice to have'it
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
it must borrow some ideas from "switch/case" and Pascal
"with" it should be also easy to say :
if ( %a match %b )
or
%a assign_diff %b - assign and/or add all key and/or values from %b which
are
not in %a OR diff ... :")
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
3. min,max,avg !!!
$a = min(5,6,10,33,45)
if ( max(@b) 22 ) ...
4. op() - Prolog like operator/keywords precedence.
f - position of the op/keyword
x - if there are more operators in this operand they must be lower
precedence
y - if there are more operators in this operand they must be
equal or lower precedence.
yfx - left-associative evaluate from left to right
xfy - righ-associative evaluate from right to left
op(100,yfx,"*");
op(200,yfx,"+");
this mean that :
a+b*3 is (a+b)*c, but not a+(b*c)
More interesting will be redifining the keywords :")
5. Persistency and easy integration in other systems as example mod_perl,
deamons like stuff etc... THE CLUE
6. CPAN = module - bundle - distribution
Distriburion(many modules+many bundles) to be something that the OS vendors
will add to their OS's or other people do separately.
F.e..Perl Power Pack.
Primary task as small as possible interaction with the user...
many of the current CPAN modules can't install successfuly on the fly
'cause thay need some info for which they ask interactively.
In some extent this can be achieved for OS vendors 'cause they know
their Config better..
7. DBM f/locking support in standard Perl
8. The following syntax to be possible :
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
This is very usefull for fast searching in DBM for example.
9. 64-bit aware Perl - Merced is comming !!!
10. I know this is very hard or some may argue against this, but I think
it should be possible to hack perl itself easy by every "seasoned" Perl
programmer i.e. some possibility to change language on the fly.
(And not only by the Perl-core-hackers).
A good steps toward that direction are Filter and Inline modules...
further it will be very good if we can Lex/Yacc-ing in Perl,
preprocesing source etc..
11. "Gobble" parameters from both sides i.e.
sub add(x,y){ }
may act like this :
x add y
add x,y
add(x,y)
This should be some play with Prototypes. I think also that it is good as
mantioned in one RFC that there should be the way that we can have several
subs with the same name and depending on their number of params executed is
that one that match..i.e
sub add(a,b) {}
sub add(a,b,c) {}
If I call add(4,5) the first one is executed, if I call add($c,12,45)
second one.
12. CONTEXT - there should be a way to define different and new types of
contexts. Let we think what is a context ?
Shortly it is - THE WAY WE PASS PARAMETERS and THE WAY WE RECIEVE THE
RESULT.
So the context can be SUB that accept a reference to all the params and
return
reference - may be .. i.e.
sub add(a,b) { return $a+$b };
this SUB is supposed to handle the scalars, but when we use it in
array context it shold do whatever is expected she to do w/o
explictly code this in the SUB or to be more clear DWIM.
(the description again can be handled to some extent by the prototypes)
then :
{
context array;
@c = add @a,@b; # or better @a add @b
}
sub array
{
$sub = shift;
@refs = @_;#not the same but just example, leave details for you
my @res;$i=0;
#I dont care about the number of arrays passed here i.e foreach $v (@refs)
# we should care
while ( $#{$refs[0]} $#{$refs[1]})
{
my $a = shift @{$refs[0]};
my $b = shift @{$refs[1]};
$res[$i++] = $sub($a,$b);
};
return \@res;# !??!
}
Some EXAMPLES of contexts : scalar,array,iterator,boolean,matrix
That is in short, thanx for your attention
PS.
Perl6 should stay Perl, but must be more than Perl.
Perl6 should be fast as mentioned in one RFC - but most importantly it must
be featurefull and must continue its tradition - "writing less, doing much"
=
iVAN
[EMAIL PROTECTED]
=
Re: RFC 76 (v1) Builtin: reduce
Lightning flashed, thunder crashed and "Ed Mills" [EMAIL PROTECTED] whispe red: | So we establish a var $something=n where n is the array origin. You mean something like $[, which we've had for many, many years. And which for many, many years we've discouraged the use of? $[ The index of the first element in an array, and of the first character in a substring. Default is 0, but you could theoretically set it to 1 to make Perl behave more like awk (or Fortran) when subscripting and when evaluating the index() and substr() functions. (Mnemonic: [ begins subscripts.) As of release 5 of Perl, assignment to `$[' is treated as a compiler directive, and cannot influence the behavior of any other file. Its use is highly discouraged. Please, let's not. It was more confusing than it was worth the first time. -spp
Re: Nice to have'it
Hey Raptor et al:
Wow you did some homework! Nice ideas, but the consensus seems to be "roll
your own". I've noted that opertors working on arrays are generally
discouraged in favor of scalar ops in these discussions, so for example your
(min,max) (ceiling, floor) are coded thousands of times by hundreds of
people each year since there is no primitive. I assume, but may be
incorrect, that this is an offshoot of people never having coded in a
language resplendent in array and matrix ops, but once you have, its hard to
go backwards..
My take is that the lack of array/matrix operators reduce the productivity
of the Perl community. The language should be rich in array (and matrix)
operators so we don't waste our time coding our personal favorite ceiling
operator (yes I know its simple, that's why I don't want to waste time on
it).
As Larry said in Monterey this year (I paraphrase),
"Difficult things should become easy, and the impossible should become
difficult."
Following that logic- shouldn't easy (ceiliing) become trivial (a primitive
op)?
my 2c
From: "raptor" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Nice to have'it
Date: Mon, 28 Aug 2000 14:10:26 +0100
Hi,
I have couple of ideas which may or may not worth it, so I didn't
wrote the RFC but will list them here in short.
Here are the nice to have'it.
1. There will be good to have some sort of "match and/or assign" operator
for structures i.e. HASHES. Can't still figure out the syntax but may be
it must borrow some ideas from "switch/case" and Pascal
"with" it should be also easy to say :
if ( %a match %b )
or
%a assign_diff %b - assign and/or add all key and/or values from %b which
are
not in %a OR diff ... :")
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
3. min,max,avg !!!
$a = min(5,6,10,33,45)
if ( max(@b) 22 ) ...
4. op() - Prolog like operator/keywords precedence.
f - position of the op/keyword
x - if there are more operators in this operand they must be lower
precedence
y - if there are more operators in this operand they must be
equal or lower precedence.
yfx - left-associative evaluate from left to right
xfy - righ-associative evaluate from right to left
op(100,yfx,"*");
op(200,yfx,"+");
this mean that :
a+b*3 is (a+b)*c, but not a+(b*c)
More interesting will be redifining the keywords :")
5. Persistency and easy integration in other systems as example mod_perl,
deamons like stuff etc... THE CLUE
6. CPAN = module - bundle - distribution
Distriburion(many modules+many bundles) to be something that the OS
vendors
will add to their OS's or other people do separately.
F.e..Perl Power Pack.
Primary task as small as possible interaction with the user...
many of the current CPAN modules can't install successfuly on the fly
'cause thay need some info for which they ask interactively.
In some extent this can be achieved for OS vendors 'cause they know
their Config better..
7. DBM f/locking support in standard Perl
8. The following syntax to be possible :
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
This is very usefull for fast searching in DBM for example.
9. 64-bit aware Perl - Merced is comming !!!
10. I know this is very hard or some may argue against this, but I think
it should be possible to hack perl itself easy by every "seasoned" Perl
programmer i.e. some possibility to change language on the fly.
(And not only by the Perl-core-hackers).
A good steps toward that direction are Filter and Inline modules...
further it will be very good if we can Lex/Yacc-ing in Perl,
preprocesing source etc..
11. "Gobble" parameters from both sides i.e.
sub add(x,y){ }
may act like this :
x add y
add x,y
add(x,y)
This should be some play with Prototypes. I think also that it is good as
mantioned in one RFC that there should be the way that we can have several
subs with the same name and depending on their number of params executed is
that one that match..i.e
sub add(a,b) {}
sub add(a,b,c) {}
If I call add(4,5) the first one is executed, if I call add($c,12,45)
second one.
12. CONTEXT - there should be a way to define different and new types of
contexts. Let we think what is a context ?
Shortly it is - THE WAY WE PASS PARAMETERS and THE WAY WE RECIEVE THE
RESULT.
So the context can be SUB that accept a reference to all the params and
return
reference - may be .. i.e.
sub add(a,b) { return $a+$b };
this SUB is supposed to handle the scalars, but when we use it in
array context it shold do whatever is expected she to do w/o
explictly code this in the SUB or to be more clear DWIM.
(the description again can be handled to some extent by the prototypes)
then :
{
context array;
@c = add @a,@b; # or better @a add @b
}
sub array
{
$sub = shift;
@refs = @_;#not the same but just example, leave details for you
my
Re: RFC 133 (v1) Alternate Syntax for variable names
Bron Gondwana wrote:
In [EMAIL PROTECTED], you wrote:
count = array; # scalar context because of assignment to
scalar.
alt_array[] = array; # list context
and if array is a subroutine?
count = array();
count = array; # warning - special meaning in p5.
Either would be just as messy - and I like being able to say:
Either would be just as messy as what?
my $thingy = $object-subobject-value;
I must not understand. Your example here strikes me as
unrelated/unaffected.
I'm not the linguist that Mr. Wall is, but it strikes me that context should be
derrived automatically as much as possible.
An slightly different alternative would be that arrays and hashes are always
referred to with their trailing indicator ([] or {}). So, from the example
above, you'd have
count=array[];
alt_array[] = array[];
Yuck. Ugly as thingywhatsit, though it does have the advantage of making
syntax like array[2..5] for splice...
Ugly? What makes it ugly (to you)? Just having to type an additional
character?
Do you have a better suggestion for separating variable type from
context?
Um, don't know about hash{[a-c].*} though (apply regular expression and only
keep keys that match)
--
Bron ( but I don't think the ugliness is worth it in the end.. )
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
Re: RFC 162 (v1) Filtering Here Docs
Bart Lateur wrote: On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: It only removes whitespace, and it measures whitespace with tabs=8. My editor is set to tabs=4. Perl's interpretation wouldn't agree with the visual appearance in my editor. This doesn't sound like a neat solution. Why not disallow merging of tabs and spaces as being equivalent? If you want to skip a leading tab, but a tab between '"' and the EOL marker. If you want to skip spaces, put spaces in. If you want to skip tabs and spaces, put that sequence in. The only consequence would be that you'd have to be consistent in what you put in front of the text lines (and in the whitespace prefix definition). -- Bart. Why not make the details of this controlled by a pragma? -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
Bart Lateur [EMAIL PROTECTED] writes: On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: Further it should ignore any whitespace (and comments) that follow the terminator. All of these should work: print EOL ; EOL # this is the end of the here doc But currently, I like using: print "#EOT#2"; blah blah blah #EOT#2 Well, this would still be well-defined according to my reading of the RFC. To parse "#EOT#2", the lexer (or whatever part of Perl it is) has to scan the input stream until it encounters the stream "#EOT#2"; whitespace may appear before it on the line, and it may be followed by more whitespace and comments. So even this should work: print "#EOT#2"; This is a line of text. # This isn't a comment; it's part of the here-document! #EOT#2#This is a comment I'm not sure if this is a good idea. However, bear in mind that if you want a comment on the end-of-here-document line, you probably aren't going to add more `#' characters to it. [...] -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-6795059 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
Richard Proctor proposed: All of these should work: print EOL; EOL print EOL; EOL print EOL ; EOL # this is the end of the here doc People may throw rocks at me for this, but I'd like to suggest that not only is a comment allowed on the terminator line, but a semicolon also be allowed. Vis: print EOL; EOL; # This should work, too Yes, I know that it can be done as: print "EOL;"; EOL; but (imho) the prior example has high DWIM value, and is keeping with the spirit of the RFC. Just my two cents. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
RE: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.
By the way, for all you thesis writers and thesis advisors out there -- I suspect that a separate implementation of the Perl6 lexer and/or Perl6 parser might make a dandy thesis topic... By the way, this message makes more sense if you s/a separate/an independent/... :( === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote: People may throw rocks at me for this, but I'd like to suggest that not only is a comment allowed on the terminator line, but a semicolon also be allowed. Vis: print EOL; EOL; # This should work, too Let me throw the first rock. I think this is confusing for the reader of your code. This looks like a statement, not an end-of-doc marker, so they'll search for the definition of the sub EOL. Next you'll propose that print EOL; blah EOL; print "OK!\n"; should work too, and print "OK!\n" as well. OTOH, what about this... print EOL blah EOL; which makes this a full blown statement (note the missing semicolon in the first line)... Nah! -- Bart.
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
Bart Lateur wrote: Next you'll propose that print EOL; blah EOL; print "OK!\n"; should work too, and print "OK!\n" as well. Why not?! This seems like a good thing. ;, #, or \n are all valid end-of-lines for here string delimiters. Sounds easy enough, and consistent. OTOH, what about this... print EOL blah EOL; which makes this a full blown statement (note the missing semicolon in the first line)... No it doesn't! perl -e ' print EOF Hello world! EOF; ' Can't find string terminator "EOF" anywhere before EOF at -e line 2. Even Perl 5 is smart enough to DWIM here. Granted, sometimes this doesn't work, but then it's just a Perl 6 syntax error that's identical to the current Perl 5 syntax error. -Nate
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon, 28 Aug 2000 08:46:25 -0700, Nathan Wiger wrote: OTOH, what about this... print EOL blah EOL; which makes this a full blown statement (note the missing semicolon in the first line)... No it doesn't! perl -e ' print EOF Hello world! EOF; ' Can't find string terminator "EOF" anywhere before EOF at -e line 2. Gee, you already have a working copy of this hypothetical perl6 interpreter? Neat! Of course it doesn't work now. But if you insist on allowing, say, another statement on the same line as the end-of-doc marker, than at least allow the statement terminating semicolon, too. -- Bart.
Re: Nice to have'it
David Corbin wrote:
raptor wrote:
$hash{/re/} i.e. this is the same like
my @res;
foreach my $k (keys %hash)
{
if ($k =~ /re/) {push $hash{$k},@res}
};
OR
keys %hash{/re/}
values %hash{/re/}
each %hash{/re/}
Way cool. I'd love this.
Well, $hash{/re/} would only evaluate to a single scalar.
More likely, you'd want @hash{/re/}, which would be
equivalent to @hash{ grep { /re/ } keys %hash }.
So values %hash{/re/} is unnecessary, since it would
be the same as @hash{/re/}.
And keys %hash{/re/} would be the same as
grep {/re/} keys %hash -- a very small gain, imho.
The proposed each %hash{/re/} wouldn't work, even given
hash slices like %hash{@keys}, since each needs an actual
hash object to attach to; and slices aren't.
--
John Porter
We're building the house of the future together.
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon 28 Aug, Eric Roode wrote: Richard Proctor proposed: All of these should work: print EOL; EOL print EOL; EOL print EOL ; EOL # this is the end of the here doc People may throw rocks at me for this, but I'd like to suggest that not only is a comment allowed on the terminator line, but a semicolon also be allowed. Vis: print EOL; EOL; # This should work, too Yes, I know that it can be done as: print "EOL;"; EOL; but (imho) the prior example has high DWIM value, and is keeping with the spirit of the RFC. I like it... I think I will add this to the next version. Richard -- [EMAIL PROTECTED]
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
On Mon 28 Aug, Bart Lateur wrote: On Mon, 28 Aug 2000 10:38:42 -0400 (EDT), Eric Roode wrote: People may throw rocks at me for this, but I'd like to suggest that not only is a comment allowed on the terminator line, but a semicolon also be allowed. Vis: print EOL; EOL; # This should work, too Let me throw the first rock. I think this is confusing for the reader of your code. This looks like a statement, not an end-of-doc marker, so they'll search for the definition of the sub EOL. I will catch the rock as this is getting ever closer to DWIM. Next you'll propose that print EOL; blah EOL; print "OK!\n"; should work too, and print "OK!\n" as well. Yes why not, though it might be bad style. OTOH, what about this... print EOL blah EOL; which makes this a full blown statement (note the missing semicolon in the first line)... Yes as well. Nah! I think we are likely to disagree... Richard -- [EMAIL PROTECTED]
Re: RFC 162 (v1) Filtering Here Docs
On Mon 28 Aug, Bart Lateur wrote: On 27 Aug 2000 19:23:51 -, Perl6 RFC Librarian wrote: It only removes whitespace, and it measures whitespace with tabs=8. My editor is set to tabs=4. Perl's interpretation wouldn't agree with the visual appearance in my editor. This doesn't sound like a neat solution. This is a problem, there may not be a general solution (use tabs qw(4)? for tabs != 8 ?) Why not disallow merging of tabs and spaces as being equivalent? If you want to skip a leading tab, but a tab between '"' and the EOL marker. If you want to skip spaces, put spaces in. If you want to skip tabs and spaces, put that sequence in. Editors and people are inconsistent. I can indent with spaces then when the next lines is autoindented the editor uses tabs. trying to ensure consistent behaviour is like trying to get consistent behaviour on this list... The only consequence would be that you'd have to be consistent in what you put in front of the text lines (and in the whitespace prefix definition). This leads back to my original "remove all whitespace". Somehow there is a compromise to extracted from this. -- [EMAIL PROTECTED]
Re: RFC 111 (v2) Here Docs Terminators (Was Whitespace and Here Docs)
Next you'll propose that print EOL; blah EOL; print "OK!\n"; should work too, and print "OK!\n" as well. Yes why not, though it might be bad style. Because it gains you nothing, and loses much. --tom
Re: Do we really need eq?
I'd like to see eq and it's brethen retained, as dammit there are times
I want to know (-w) if numbers are turning up when there should be
words and vice-versa. However, spinning off of something Randal wrote:
Yes, but what about:
$a = '3.14'; # from reading a file
$b = '3.1400'; # from user input
if ($a == $b) { ... } # should this be string or number comparison?
Since we have distinct comparison operators for strings and numbers, and
since we have explict casting for those who wish it, IMHO one can do
if ( int( $a ) == int( $b ) )
to force int (or float) compares, and
if ( "$a" eq "$b" )
to force string compares,
IMHO the code
$a = '3.14'; # from reading a file
$b = '3.1400'; # from user input
if ($a == $b) { ... }
should see the two args being tested in numeric context, do the numeric
casting, get floats, and do a floating compare. Durned if I know what it
does now.
Multiple for loop variables
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
i.e., more than one loop variable, assigned successively from the list. He
didn't have time to RFC it, but when I looked at it, a problem arose: if
the loop variables aren't declared lexical right there, how can the parser
tell in a case like
for ($a, $b, $c) (@list) { ... }
that it means multiple loop variables, and not
for $_ ($, $b, $c) etc
IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
was could say whether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Unfortunate that (I assume that) it couldn't extend to the modifier form as
well.
--
Peter Scott
Pacific Systems Design Technologies
Re: HERE construct
Steve Simmons wrote:
In all the straining at gnats over whitespace, filtering, etc, I have yet
to see a single proposal that isn't accomplished by just using variables
and manipulating them appropriately. And it avoids all the problems with
whitespace on the HERE word.
In many cases, I agree with you. But one thing I use Perl for -- A LOT
-- is generation of code in other languages; for example, javascript.
$snippet = CHUNK;
function dummy(s)
{
var str = "Here's a string";
CHUNK
# rest of javascript to be generated later
That's a contrived, but not far-fetched, example where single quote,
double quote, and qq{} won't work. Of course, one can always come up
with other qq variants, but having to remember which qq variant you're
using each time, and making sure that changes in the string don't
break your quoting, is a major PITA.
No, here docs are an extremely useful part of the Perl language,
and often times, quoted strings just don't cut it.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 168 (v1) Built-in functions should be functions
At 07:32 PM 8/27/00 +, Perl6 RFC Librarian wrote:
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.
I think you can't just leave it at that; the implication of this
requirement is that there should be a prototype for print's optional
filehandle. Not only is there no prototype for that right now, there's no
way for user code (AFAIK) to recognize such a beast. As long as the
optional filehandle syntax survives to P6, you'll have to address it.
I think it would be a good thing for user prototypes to be able to handle
this case and I wholeheartedly support the RFC; but it opens a can of worms
that should be addressed. Perhaps in another RFC. Do any other (Damian)
RFCs on (Damian) prototyping impact (Damian) this area?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 126 (v2) Ensuring Perl's object-oriented future
Object-oriented features were added to Perl with version 5, and in many ways still appear somewhat "tacked on", with perhaps undue respect for the Old Ways of Perl 4. [NB: This is not a serious missive.] Hey, that Perl uses packages for classes, subroutines for methods, and references for objects is in fact a shining examplar of that holy grail of OO -- "code reuse". :-) --tom PS: The standard retort to the "tacked on" noise on Perl's objects runs along the lines of `Python/Java's regex system wasn't integrated into the language -- it's just "tacked on" to the side.' :-)
Re: RFC 109 (v2) Less line noise - let's get rid of @%
My apologies for being too succinct. "lost" is a bit of an emotive word which is somewhat inaccuracte. I still believe in RFC 109 and I think I made a good case based on my own reasons. However the overwhelming majority of responses were negative, for their own very good albeit different reasons. It boils down to a question of philosophy I clearly felt Perl ought to be more like python, clearly the majority disagreed with me. I have no problem with that. That's fine. I still like Perl. I think the issue got talked out very well, some good points were made I see no point in pursuing that discussion any further - given some 90% of the people on perl6-language opposed losing the @%$ distinctions clearly it has no chance of being implemented! And there seems not much more to say on the issue. The only problem I had with the whole discussion, and with ongoing disucssions on other subjects on perl6-language-data, is nobody seems to have any idea how radical perl6 should be. Larry says "anything goes" which is fine, but unhelpful. We need some context into which to frame the whole discussion. Karl Jonathan Scott Duff wrote: On Mon, Aug 28, 2000 at 05:39:20PM -, Perl6 RFC Librarian wrote: =head1 TITLE Less line noise - let's get rid of @% ... I withdrew it on 28th August as I figured I had lost the argument! I'm sorry, but this just doesn't jive with me. There is no "argument". We are discussing proposed features for perl 6. If you were somehow convinced that your idea is a bad one, than that's a good reason for withdrawing an RFC. If you're withdrawing it because no one seems to agree with you, yet you still think it's a good idea (this is how I read your sentence above), then that's just plain *WRONG* IMHO. Ignore me if I'm reading between the lines a little too much. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: RFC 126 (v2) Ensuring Perl's object-oriented future
On 8/28/00 2:35 PM, Tom Christiansen wrote: Object-oriented features were added to Perl with version 5, and in many ways still appear somewhat "tacked on", with perhaps undue respect for the Old Ways of Perl 4. [NB: This is not a serious missive.] Hey, that Perl uses packages for classes, subroutines for methods, and references for objects is in fact a shining examplar of that holy grail of OO -- "code reuse". :-) I think I'll leave an analysis of the actual state of code reuse inside perl to the -internals folks... ;) -John
Re: Nice to have it
Damian Conway wrote:
I have a draft RFC that proposes that the LIST argument of a
grep be optional in a hash slice, and default to the key list
of the sliced hash. So:
@hash{grep /^[^_]/}
gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^_]/, keys %hash }
would be what? Brevity?
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Beefier prototypes (was Re: Multiple for loop variables)
Peter Scott wrote:
for my($x, $y, $z) (@list) { ... }
...
IANAPE (I Am Not A Parsing Expert). So I thought I would see if anyone who
was could say whether this construct would really give the parser problems
or whether looking ahead for the block will disambiguate.
Well, I think it's likely that the perl6 parser would be made to
handle this; but even if not, it shouldn't be too hard to get it
to allow a ref to such a list:
for [ $x, $y, $z ] ( @list ) { ...
for \@iters ( @list ) { ...
Btw, I hope that operators like Cfor will also be properly prototyped
in perl6. I expect that would mean that prototyping will be sufficiently
beefed up; including optional and alternative cases. Hmm, maybe something
regex-like would be needed: sub my(($|\@)?@); Heh.
You know, I would like to pass code blocks in any arg position;
I want sub foo(\@\@) to be callable as
foo { alpha() } @bravo { charlie() } @delta { echo() };
No Csubs, no commas.
--
John Porter
We're building the house of the future together.
Re: RFC 168 (v1) Built-in functions should be functions
Damian Conway wrote:
I think it would be a good thing for user prototypes to be able to
handle this case and I wholeheartedly support the RFC; but it opens
a can of worms that should be addressed. Perhaps in another RFC. Do
any other (Damian) RFCs on (Damian) prototyping impact (Damian)
this area?
I'll need to think about that issue. Can anyone think of an optional left
argument that *isn't* really an indirect object?
Well, as I mentioned in another recent parallel thread, if Cfor is to
be properly functionalized, provision must be made in the prototype for
its optional iterator:
for ( @a ) {
for $i ( @b ) {
And we could lose the parens, too.
sub for($?@); # shweet.
--
John Porter
We're building the house of the future together.
Re: Nice to have'it
Damian Conway wrote: I have a draft RFC that proposes that the LIST argument of a grep be optional in a hash slice, and default to the key list of the sliced hash. So: That's a waste of RFC paper, Damian. But let's generalize it a bit, and say that Perl6 should have a standard intrinsic mechanism -- perhaps just an extension of Ccaller -- which allows any sub to get whatever details it wants on its calling context. "Was I called in list context as the index of a hash slice? What hash?" This would allow any user func (not to mention built-ins) to decide for itself what its default arguments should be. -- John Porter We're building the house of the future together.
Re: Nice to have it
On Mon, 28 Aug 2000 14:43:08 -0400 (EDT), Eric Roode wrote:
Damian Conway wrote:
@hash{grep /^[^_]/}
gives you the public values of %hash.
And the advantage of that over
@hash{ grep /^[^_]/, keys %hash }
would be what? Brevity?
What if I want those keys of %hash? Or both keys and values?
Shortcuts that only work in half of the common cases don't seem very
useful to me.
--
Bart.
Re: RFC 168 (v1) Built-in functions should be functions
Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! --tom
Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)
Just to extend this idea, at least for the exercise of it, consider:
match; # all defaults (pattern is /\w+/?)
match /pat/;# match $_
match /pat/, $str; # match $str
match /pat/, @strs; # match any of @strs
subst; # like s///, pretty useless :-)
subst /pat/new/;# sub on $_
subst /pat/new/, $str; # sub on $str
subst /pat/new/, @strs; # return array of modified strings
For the takes-an-array variants of match and subst, what becomes of
back-references? Does
subst PAT, LIST
modify LIST in-place, or return the result of modification? What does
match PAT, LIST
return at all, and what of multiple back-references in PAT?
# These are pretty cool...
foreach (@old) { @new = subst /hello/X/gi, @old;
s/hello/X/gi;
push @new, $_;
}
foreach (@str) { print "Got it" if match /\w+/, @str;
print "Got it" if (/\w+/);
}
This implies that the subst keyword would *both* modify LIST in-place and
return a complete copy of the list as a return-value. Is this correct?
Additionally, the match example above is not identical on each side-- the
Perl 5 version would print "Got it" for *every* matching element of @str,
whereas the Perl 6 version would print it just once. While you could change
the Perl 5 example to fit (by adding "last"), I just don't know that the
blind application of a regex to a list has a place here.
Randy
--
---
Randy J. Ray | Programming is a Dark Art [...] The programmer is fighting
[EMAIL PROTECTED] | against the two most destructive forces in the universe:
415-777-9810 x246 | entropy and human stupidity. --Dr. Damian Conway
Re: RFC 143 (v1) Case ignoring eq and cmp operators
On Thu, Aug 24, 2000 at 03:40:00PM -, Perl6 RFC Librarian wrote: This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Case ignoring eq and cmp operators IMHO this problem is better solved by using =~ and its brethren, which already allow you to do the right thing for a far wider set of cases than just this one.
Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)
"Randy J. Ray" wrote:
# These are pretty cool...
foreach (@old) { @new = subst /hello/X/gi, @old;
s/hello/X/gi;
push @new, $_;
}
This implies that the subst keyword would *both* modify LIST in-place and
return a complete copy of the list as a return-value. Is this correct?
No, @old wouldn't be modified because $_ is a temporary value that has
no inherent connection to @old. So modifying $_ won't change @old. THAT
code is correct...
foreach (@str) { print "Got it" if match /\w+/, @str;
print "Got it" if (/\w+/);
}
Additionally, the match example above is not identical on each side-- the
Perl 5 version would print "Got it" for *every* matching element of @str,
whereas the Perl 6 version would print it just once.
But this example's broken. Sorry for the confusion. What I *meant* was:
foreach (@str) { print "Got it" if match /\w+/, @str;
if (/\w+/) { $gotit = 1 };
}
print "Got it" if $gotit;
Now if DWIM just worked for email as well... ;-)
v2 of the RFC should be out tomorrow and should make a lot more sense.
It will be posted to perl6-language-regex.
-Nate
Re: Multiple for loop variables
On Mon, Aug 28, 2000 at 04:10:01PM -0400, Eric Roode wrote:
Peter Scott wrote:
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
? (notwithstanding the destructive nature of splice)
Maybe not with 3 variables, but how many people do
my %hash = @_;
while(my($k,$v) = each %hash) { ... }
so that they can process named arguments ?
Having this would remove the need for the hash assignment. Also it hash been
suggested that it could potentially replace each
for my($k,$v) (%hash) { ... }
Also the ability to traverse multiple lists at once
for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
And I should think many more uses I cannot think of.
Graham.
