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: RFC 159 (v1) True Polymorphic Objects
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
LOGHIGHAND Called in context
LOGHIGHOR Called in || context
LOGLOWAND Called in and context
LOGLOWOR Called in or context
LOGIFELSE Called in ?: context
I don't see that those should be any different from one another.
The essential feature in all of them is simply a Boolean test.
Boolean tests occur in many places. if/unless/while/until
also use them.
You can have your full if:
if ($whatever) { A }
else { B }
Why should that any of those be different than
$whatever ? A : B;
Why should the pairs
A B
A and B
and
A || B
A or B
be any different? It's simply a matter of precedence.
If someone wrote parens around (3+4)*5 to alter the default
precedence, I shouldn't expect a different operator overload
to trigger. Same here, whether the non-traditional grouping is
effected by parens are using a different operator:
(A) and (B)
(A) (B)
Please also consider this:
% perl -MO=Deparse -e 'B() if A()'
B if A ;
-e syntax OK
% perl -MO=Deparse -e 'A() B()'
B if A ;
-e syntax OK
The reverse if/unless tests are really just flow-control logicals
written funny (or vice versa, if you prefer). Since "A B" really
becomes "B if A", you'll have to tackle that there, too. And even
if it didn't, it would seem something to be addressed.
And what about the negations? Will !A trigger something special?
Is this different from an unless? I don't think it should be,
irrespective of the current op/byte codes generate:
% perl -MO=Deparse -e 'A() || B()'
B unless A ;
-e syntax OK
% perl -MO=Deparse -e 'B() unless A()'
B unless A ;
-e syntax OK
% perl -MO=Deparse -e 'B() if !A()'
B if not A ;
-e syntax OK
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
--tom
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 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
Nathan Torkington wrote:
Damian Conway writes:
sub foo :lvalue { $foo }
post foo { die if $foo == 5 }
eval {
foo() = 5;
};
Postconditions on lvalue subs are not tested until the end of the complete
expression in which the sub is called.
But that won't change the fact that they are called *after* the lvalue
has changed. If they detect a problem, they can't unroll the change.
When you are passed the new value as an argument, you can die before
a change is made.
Hold on - post conditions are not intended to veto a change, they're
intended to terminate the program if an assertion is invalid. Hence it
should not matter if they run before or after assignment.
Given that the assertion should be "now this and that should be true",
and you may want to call validation methods as part of that assetion,
the implementation of the checks becomes vastly easier if they are
applied to the new state of the object, instead of the old state and a
set of proposed changes.
Hildo
Re: RFC 120 (v2) Implicit counter in for statements, possibly $#.
On Thu, Aug 17, 2000 at 08:46:53PM -, Perl6 RFC Librarian wrote:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Implicit counter in for statements, possibly $#.
Having read over the entire discussion, I want to make a few comments
and throw one major monkey wrench.
The discussion of why the naive
my $i = 0;
foreach my $var ( @list ) {
$i++;
...action...
}
sometimes gives `incorrect' values for $i is tremendous and should be
added to the proposal as justification.
I am *strongly* opposed to creating another line noise variable for
this (speaking as the author of one of the `line noise variables bad'
RFCs). If a default var is to be created (and I think it should be)
it should have a meaningful name like `$loopindex'. But then we get
the wonderful problem of nested loops, which implies some syntax
like
foreach $a ( @alist ) {
foreach $b ( @blist ) {
...do something on matrix $m[$loopindex_a][$loopindex_b];
}
}
This is messy, and the idea of a default index var name probably falls
apart.
The proposed syntaxes for declaring the index on the line are good, but
defeat a feature I'll be pushing for In My Copious Spare Time,
multi-assigns in loops. Many times I'd like to do
foreach my ( $left, $center, $right ) ( @list ) {
}
such that #{left,center,right} are assigned the first *three* elements
of the list. (Yes, I know you can do this with data structures.
TMTOWTDI. I want one more.) I use this construct in tcl all the time,
and it's a huge timesaver for well-formatted lists of lists.
Therefore I'd like to see the resulting syntax be as follows:
Frist, preserve current code so that
foreach $scalar_listval ( @list )
works as current.
Second, allow for auto-created indexs by placing a second scalar
following the first
foreach scalar_listval @scalar_index ( @list )
such that the value from list is assigned to scalar_listval and the
variable scalar_index is the index into the list. This has the
advantage that it is currently a syntax error in perl, so no working
code is broken by this addition.
Third, allow for lists of scalars to be placed in the listval position
such that
foreach ( $a, $b, $c ) $i ( @list ) {
...
print $i;
}
such that on each pass through the loop 3 entries are consumed by the
assignment to $a, $b, and $c, and that $i is set to the index value
of the first element. Thus $i would print out as 0, 3, 6, etc. This
allows it to be used to index into @list cleanly should one want to
pick out things like predecessor, etc.
To tell the truth, this third item should probably should become
a separate RFC, and if you'd like to simply say one is forthcoming,
that'd be fine by me.
HERE construct
General comment on all the discussion of HERE docs. When HERE docs cause you a problem, don't use 'em. There is little win if any over print HERE; Dear Sir: You owe me bucks. Pay up. Me. HERE and $msg = 'Dear Sir: You owe me bucks. Pay up. Me. '; 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.
Re: RFC 161 (v2) OO Integration/Migration Path
Dan Sugalski wrote: If the vtable stuff goes into the core perl engine (and it probably will, barring performance issues), then what could happen in the my Foo $bar; case would be that all the vtable functions for Foo are taken as specially named subs/methods in the Foo package. So, for example, if you did: print $bar; then the core would vector through Foo's STRINGIFY sub, or if you did a: $baz = $bar + 12; the core would call Foo's ADD sub. But this shouldn't necessarily be Foo::ADD, right? my Foo $foo = BlueFoo-new(); print $foo + 3; should call BlueFoo::ADD, not Foo::ADD, no? (where BlueFoo isa Foo). But if so, then it seems like my Foo $x and my Bar $x are equivalent -- both of them just mean "use my actual class to look up vtable methods", maybe with some type checking to ensure that only subclasses of the declared class are put into $x. But then what does my $x = BlueFoo-new(); print "$x" do, assuming there is a BlueFoo::STRINGIFY? Print "BlueFoo=HASH(0x0b38134)"? As for non-vtable methods, were you planning on making my Foo $foo; $foo-method_not_in_Foo_package(); a compile-time error?
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Damian Conway wrote:
I wouldn't be averse to Cself as the default and Cuse invocant as a sop to
the Cthiserites and C$MEophiles. But *they* might be!
This is baloney. I agree, we need to *pick something*!!
What should we do, make a "rename" pragma so everyone can be happy?
use rename want = '$NEED', = 'THISTOO',
self = '$IAMALIVE', || = 'ORNEXT',
chomp = 'Ilovemymom', caller = '$CALLERFORTHIS',
my = 'var', $ = ')', = = 'assign',
- = '-member-', ; = '++', die = 'perishPolitely',
system = 'fork', { = '/*', } = '*/', $! = $boogeyman,
( = '[', ) = ']', if = 'checktosee';
Then we can write really flexible code that looks just like my
"religion" wants it to!
checktosee [ $NEED eq 'HASH' ] /*
var )name assign )DEFAULT ORNEXT
$IAMALIVE-member-getName++
perishPolietly "Couldn't get )name" unless )name++
ilovemymom )name++
var )user assign )name ORNEXT "user"++
fork "ls -l" THISTOO perishPolitely "ls failed: $boogeyman"++
*/
This is, obviously, complete insanity. And a load of shit.
We can pick self(). Or this(). Or me(). Or context(). Or invocant().
Or $ME. Or $SELF. Or $THIS. Or $CONTEXT. Or $INVOCANT.
But we have to f**king pick *something*!!! Someone's going to be unhappy
but:
1. They'll get over it.
2. It's for the greater good.
Anyone who counters and says "but it's crucial that the invocant *must*
be named X" is inflexible and full of shit.
The *only* decent point I've heard so far is that some people might want
$self still as $_[0]. We should accomodate this.
-Nate
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On Sun, Aug 27, 2000 at 07:54:35PM -0700, Nathan Wiger wrote: And why is passing $self in $_[0] a good thing? Because it eliminates a butt-load of translation to convert Perl5 programs to Perl6 programs. Rather than tracking down each and every sub and figuring out if it's used as a method or not, nothing is changed and things simply work. But the Cself or C$ME functionality is still there for people to use. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
Damian Conway:
My forthcoming proposal will be that invocants still be passed as $_[0]
by default, but that there be a pragma allowing $_[0] to be automagically
shifted somewhere else during dispatch. For example:
sub method { print "I was called through: $_[0]";
print "My args were: @_[1..$#_]"; } #default
use invocant '$ME';
sub method { print "I was called through: $ME";
print "My args were: @_"; }
Why couldn't(/shouldn't/wouldn't) this be more useful as a facility that
allows you to define a chunk of code that gets inserted in each sub routine?
I'm not sure what the general facility would look like, but it seems to me
like the "use invocant 'variable'" pragma is just essentially sticking a:
my variable = shift ;
as the first line in each method... wouldn't it be more fun to let people do
something like:
use invocation 'my $ME = shift; print "I was called through : $ME" ;
print "My args were : @_" ;'
... which, of course, means that duplicating the method above is as simple
as:
sub method { # use invocation stuff gets shoved in here
}
(Or, was it already intended that the implementation of 'use invocant' might
be some sort of compile-time macro?)
Dirk
Re: RFC 143 (v1) Case ignoring eq and cmp operators
Nathan Torkington wrote:
David L. Nicol writes:
Any subroutine declaration, for instance
sub Cmp:infix($$){
return uc($_[0]) cmp uc($_[1])
};
implicitly sets up a "catch unknown-keyword:Cmp" routine; that is,
it installs the name of the function in a place the clarifier will know
to look for the definition.
It doesn't convert it to opcodes, doesn't "parse" it yet, just stores
the token string.
Later, while parsing some expression or other, Cmp is encountered.
BAREWORD:Cmp is looked up in the whaddayaknow table, and there it is,
an infix subroutine taking two scalar arguments, so if that makes sense
with what is in front of and behind it, it gets evaluated as such.
Ooookay. I think there's compile-time and run-time confusion here.
Cmp will get *evaluated* at run-time. But the decision on what it is
is made at compile-time.
I'd just been picturing:
sub Cmp :infix { ... }
primes the parser to accept Cmp as an infix subroutine call.
When the parser sees:
SOMETHING Cmp SOMETHING
it rewrite it as
Cmp($foo, $bar)
I don't see the need for exceptions to manage that.
I also wonder how to specify the operator's precedence.
Nat
"primes the parser" is what I am talking about. I see
exceptions as a very small, constant thing. I'm very far away from
"main stream" in this but I have what I think is a clear idea of
how it would all work together.
Re: RFC 130 (v4) Transaction-enabled variables for Perl6
dLux wrote: /--- On Thu, Aug 24, 2000 at 12:30:25PM -0400, John Porter wrote: | Still not good. "trans" is too overloaded word. "transaction"? | "transactional"? (a bit too long...) "atomic"? | | "acid"? \--- "transactional" and "transaction" are quite long, I don't like that. "acid" could be misleading in this case: this is a different transaction mechanism that most db server has. No, it's misleading because it's only the C of ACID. (It's neither atomic nor durable, and only isolated if you ask for it.) "atomic" will not be true if you don't use "user transaction" (in multithreaded environment, and with objects). Other suggestions? I want a keyword, which expresses more the nature of the perl transaction: the value is permanent if the code runs correctly, and will be lost if the code has died. What about "onsuccess", "consistent", "? I personally prefer "trans", because it is short and clean-cut. Other idea? "cond" for conditional? Or how about "hopefully"? :-) Or maybe just "please", since it implies a request that could be denied? group "1" $x = $y + 1; defaulting to group $Package::TRANSACTION_ID $x = $y + 1? (I'm thinking there of having an arbitrary number of overlapping groups that can be individually committed or rolled back, with scope exits only having an effect if they aren't yet committed or rolled back.) Or what about a variable attribute: my $x : transactional and making the effect completely lexical? Why would other scopes need to see such variables?
Re: multidim. containers
Dan Sugalski wrote: 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. Yah, I did exactly this in Tie::Multidim... and it is *hairy*. And slow. -- John Porter We're building the house of the future together.
RE: RFC 146 (v1) Remove socket functions from core
Fisher Mark [EMAIL PROTECTED] writes: Leaping to conculusions based on no tests at all is even worse... Will anyone bite the bullet and write the "Internals Decisions should be based on actual tests on multiple platforms" RFC ? BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. If you want to get "in the mood" it would be good to fire it up on (say) perl5.6.0 and see where the hot-spots are. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_ -- Nick Ing-Simmons
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
RFC 109 (v2) Less line noise - let's get rid of @%
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Less line noise - let's get rid of @%
=head1 VERSION
Maintainer: Karl Glazebrook [EMAIL PROTECTED]
Date: 15 August 2000
Last Modified: 28 August 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 109
Status: Withdrawn
=head1 ABSTRACT
This RFC proposes that C$x, C@x, and C%x be ditched and
replaced with C$x for everything.
I withdrew it on 28th August as I figured I had lost the
argument!
=head1 DESCRIPTION
Back in the days of yore, Larry had a dream of a simple
typeless language. Variables were 'things', they could
hold numbers or strings, and manipulated without much
caring. The only important distinctions were whether they
were lists of things or hashes of things for which was
introduced the compact notation of C@ and C%. Perl4 was
the anti-object-oriented language in an age when there
were Real Computers and Bill Gates was still trying to
flog BASIC.
Those days are gone. Perl 5 introduced the idea of Objects
and now any variable can be one of ten million possible
types all of very different behaviours.
Also in modern programming, lists are not longer simple
lists, neither are hashes, we have multidimensional arrays,
FIFO stacks, LIFO stacks, semi-infinite lists, etc. Basically there
are innumerable ways of containing things and they are usually
represented by objects.
I argue in this Brave New World the distinction between C$x, C@x
and C%x are no longer useful and should be abolished. We might want
to use all kinds of array objects, why should @x be special? Rather
since there are infinitely many kinds of variable let's take the perl6
opportunity to make things simple and just use C$x for everything.
A RFC by Andy Wardley proposes `Highlander Variable Types' (`there can
only be one'). This addresses the same fundamental issues, but retains
C@x and C%x in the interests of backwards compatibility.
My proposal goes further: there should be NO C@x and C%x, only
C$x. This would make for a simplification of the language with
extreme prejudice.
=head1 PROPOSAL:
All variables should be C$x. They should behave appropriately
according to their object types and methods. ARRAY objects
and HASH objects would provide methods (inline, optimised
of course) to make $x[42] and $x{Fred} do the right thing.
See the pdl-porters RFC on 'default methods' for elegant
ways to do this.
The only distinction left would be between things which are
variables (prefixed by C$) and not-variables (subroutines and
keywords).
=head1 IMPLEMENTATION DETAILS
Considerable I expect. :)
Overloading should happen everywhere.
print $x
Ought to use string overloading and be able to print an array or hash
depending on type.
Similarly accesses such as C$x[42] or C$x{Fred} should function via
overloaded C[] and C{} operators.
$y = $x + 1
Ought to be able to execute appropriate code whether $x is a scalar, a
Perl array or a PDL array.
=head1 REFERENCES
PDL RFC on 'Default Methods' - PDL RFCs coming Real Soon Now
RFC 9: Highlander Variable Types
RFC 133 (v2) Alternate Syntax for variable names
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Alternate Syntax for variable names
=head1 VERSION
Maintainer: David Corbin [EMAIL PROTECTED]
Date: 20 Aug 2000
Last Modified: 28 Aug 2000
Version: 2
Mailing List: [EMAIL PROTECTED]
Number: 133
=head1 ABSTRACT
Many new users are confused by the use of $@% to represent context,
when it is also used to declare variables. This is a syntactic change
that introduces a bit more logic to the context/type confusion.
=head1 DESCRIPTION
Context is an essential part of Perl. When evaluating a symbolic
expression, $, @ and % are used to indicate the context of the
expression. However, when variables are declared (using local, my, or
simply implicitly as an lvalue) these same symbols are used. Cmy
@array; my %hash; $var=1 To many people, most notably programmers new
to Perl, the $@% is mistakenly believed to be part of the variable
name. This leads to such erroneous attempts to use them as
C@array[0], and C@%hash{key}.
Consider the following syntax:
my var;# declaring a scalar
my array[]; # declaring an array
my hash{}; # declaring a hash
Then, when it is necessary to distinguish context explicitly (it often
is not), you can use $@% as before. Consider:
count = array; # scalar context because of assignment to scalar.
alt_array[] = array; # list context
value = hash{key}; #
print $array," ",@array #Context must be clearly designated.
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[];
=head1 IMPLEMENTATION
Unknown.
=head1 REFERENCES
RFC 9: Highlander Variable Types
RFC 109: Less linenoise - let's get rid of @%
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: 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 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
Make your suggestions. But I think it is all off-base. None of this is addressing some improvement in working conditions, ease of use, problems in the language, etc. RANT You are addressing stylistic issues. Issues that effect the way _I_ want to work with the language. All of you are being fascist. Fine be fascist but don't impose them on me. I don't see anything broken here. MJD's // killer RFC is a headache. Named assignments in a regex solves a known problem. I don't see how this solves an already existing problem. /RANT *sigh* chaim "MM" == Michael Maraist [EMAIL PROTECTED] writes: If you want to change STUPID behaviour that should be avoided by current programs (such as empty regexes) fine. MM Simple solution. MM If you want to require formats such as m/.../ (which I actually think is a MM good idea), then make it part of -w, -W, -ww, or -WW, which would be a perl6 MM enhancement of strictness. MM Likewise, things like legacy Formats would not be allowed in -WW. This MM gives flexibility to the programmer, and can help the interpreter to make MM optimizations where necessary. MM If you needed legacy module compatibility, then maybe we should use pragmas MM like the following: MM use 6.0; MM or MM use 6.0 ':no-compat'; MM Programs and modules could assign themselves to a compatibility contract MM (lacking the require statement defaults to perl5 compat). The reason for MM having 'use' instead of 'require' is that the interpreter can turn on MM compile-time warnings / optimizations as it goes from module to module. MM Maybe this should be an RFC. MM -Michael -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Are Perl6 threads preemptive or cooperative?
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?
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 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 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On 8/28/00 3:09 PM, Damian Conway wrote: (Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. ...while also giving the compiler enough information to allow such invocant access to execute in an optimized manner...right? C'mon, I'm dying here thinking that all this (admittedly cool) stuff is gonna end up giving Perl 6 even more OO overhead than Perl 5! You don't want to have to revise that section of your OO Perl book to include an even *more* daunting performance degradation factor estimate for Perl OO design, do you? :) (What was it in the current edition..."up to 20x slower"? *sigh*) Anyway, I think that the "invocant" proposal is very Perl-ish...in both the best and worst senses of the word. Giving everyone the freedom to $ME and "self" to their hearts' content is TMTOWTDI up the wazoo. I'd probably be happier with a One True "self-thingie" decision...unless, of course, it's one of the ones I personally dislike ;) But I have faith that The Powers That Be would pick something sane like $self before a fanciful $THIS_IS_ME. I'm also a bit concerned about readability and interoperability of "Your Objects" vs. "My Objects." I guess invocant directives are self-documenting and should not cause any problems, functionally. But it still kind of creates a "...so we punted" feeling in me. Again, the dark side of Timmy's Toad... -John
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
The use invocant was proposed as a way to maintain backwards
compatibility and yet give everyone the invocant access syntax he
or she personally favours.
...while also giving the compiler enough information to allow such
invocant access to execute in an optimized manner...right? C'mon,
I'm dying here thinking that all this (admittedly cool) stuff is
gonna end up giving Perl 6 even more OO overhead than Perl 5!
Use invocant won't add any runtime overhead. In fact it might save a smidgeon.
(What was it in the current edition..."up to 20x slower"? *sigh*)
Out by a factor of 10! I said "20 to 50 percent slower".
I'm also a bit concerned about readability and interoperability of
"Your Objects" vs. "My Objects." I guess invocant directives are
self-documenting and should not cause any problems, functionally.
I think they would *improve* readability. Certainly over $_[0], and
even over:
sub method {
my ($self, @args) = @_;
...
}
I'm *forever* writing that and just it clutters up the code.
Damian
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
I was talking about the hypothetical situation where you're (re)using or modifying a bunch of code or classes written by different people and you constantly have to be aware of which self-thingie to use in which file or package or whatever. Yeah, you can just glance up to the use ... declaration, but it still seems a little like trying to make everyone happy by avoiding the naming decision entirely. Too much BD for a Monday? No. I *do* have sympathy with the desire for One True Way, but *only* if the access function is called Cself (my own religion ;-). And *that's* the problem. I wouldn't be averse to Cself as the default and Cuse invocant as a sop to the Cthiserites and C$MEophiles. But *they* might be! :-) Damian
Re: RFC 161 (v2) OO Integration/Migration Path
At 11:28 AM 8/28/00 -0700, Steve Fink wrote: Dan Sugalski wrote: If the vtable stuff goes into the core perl engine (and it probably will, barring performance issues), then what could happen in the my Foo $bar; case would be that all the vtable functions for Foo are taken as specially named subs/methods in the Foo package. So, for example, if you did: print $bar; then the core would vector through Foo's STRINGIFY sub, or if you did a: $baz = $bar + 12; the core would call Foo's ADD sub. But this shouldn't necessarily be Foo::ADD, right? my Foo $foo = BlueFoo-new(); print $foo + 3; should call BlueFoo::ADD, not Foo::ADD, no? Yes. (Assuming BlueFoo-new returns a variable blessed into BlueFoo, of course) Presumably each package will have a prebuilt vtable attached to it that gets smacked into any variable marked as blessed into it. (where BlueFoo isa Foo). But if so, then it seems like my Foo $x and my Bar $x are equivalent -- both of them just mean "use my actual class to look up vtable methods", maybe with some type checking to ensure that only subclasses of the declared class are put into $x. More or less, yep. It'll get funkier for builtin types, I think--if you do: my int %somehash; then stick a non-int into a hash entry, %somehash will probably get promoted to a full scalar hash rather than an int one. But then what does my $x = BlueFoo-new(); print "$x" do, assuming there is a BlueFoo::STRINGIFY? Print "BlueFoo=HASH(0x0b38134)"? That's a good question. Not my call--that's language design. (Says the man neatly ducking the issue... :) As for non-vtable methods, were you planning on making my Foo $foo; $foo-method_not_in_Foo_package(); a compile-time error? Also a language issue. There are AUTOLOAD things to take into account, amongst other things. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME)
On 8/28/00 3:53 PM, Damian Conway wrote: Too much BD for a Monday? No. I *do* have sympathy with the desire for One True Way, but *only* if the access function is called Cself (my own religion ;-). And *that's* the problem. Yeah, there'll never be consensus on this list or in the community as a whole, but I think I'd be happy with a small group of people (a group that includes Larry, obviously) just plain picking something in this case. I mean, hey, who got to vote on % for hashes and such? Rewind this list a decade or so and we might see something like: use prefix (hash = '%', array = '@', ...); being proposed because everyone can't agree on punctuation prefixes. Okay, dumb example maybe, but you get the idea. Choose or lose, as the kids say on the MTV. -John
Re: RFC 159 (v1) True Polymorphic Objects
Summary: I think these should all simply break down into a single
Boolification test of some sort, as occurs already with operator
overload.
Counter-summary: Although the high and low precedence binary ops could be
rolled together, the current version of operator overloading
is inadequate. An overloaded conjunction or disjunction
is *not* an instance of boolification unless I *define*
it to be so.
LOGHIGHANDCalled in context
LOGHIGHOR Called in || context
LOGLOWAND Called in and context
LOGLOWOR Called in or context
LOGIFELSE Called in ?: context
I don't see that those should be any different from one another.
The essential feature in all of them is simply a Boolean test.
Not necessarily. What if I am setting up a class that represents expressions
and want to be able to say:
$x = ExprNode-new();
$y = ExprNode-new();
$z = ExprNode-new();
$exprtree = $x + $y $z $z $x * $y;
I can currently overload + * to do this, but not . That's broken.
if ($whatever) { A }
else { B }
Why should that any of those be different than
$whatever ? A : B;
Because one is a control and one is an operator (i.e. yields a value).
What if I want that value to be another ExprTree?
Please also consider this:
% perl -MO=Deparse -e 'B() if A()'
B if A ;
-e syntax OK
% perl -MO=Deparse -e 'A() B()'
B if A ;
-e syntax OK
The reverse if/unless tests are really just flow-control logicals
written funny (or vice versa, if you prefer). Since "A B" really
becomes "B if A", you'll have to tackle that there, too. And even
if it didn't, it would seem something to be addressed.
Agreed. This is an internal optimization that that would need to be addressed
if boolean connectives were made overloadable.
And what about the negations? Will !A trigger something special?
Yes. NOT must be overloadable too.
BTW, this is not just theoretical yearnings. I have written three modules
in the past year that do not work as well as they could, simply because it
is not possible to overload and ||.
Damian
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
(Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. Damian
RE: RFC 152 (v1) Replace $self in @_ with self() builtin (not $ME )
(Or, was it already intended that the implementation of 'use invocant' might be some sort of compile-time macro?) No. I think a macro facility for Perl should be more general than just whacking some code in at the start of every subroutine. Yes. I didn't phrase my comments well. Sorry. The use invocant was proposed as a way to maintain backwards compatibility and yet give everyone the invocant access syntax he or she personally favours. Sure, but isn't this essentially a macro? (If it *isn't*, then I'm missing something... which could very well be the case). 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?" Dirk
Re: RFC 155 - Remove geometric functions from core
Nick Ing-Simmons [EMAIL PROTECTED] writes: But if perl6 bytecode does not need to be modified to be used I'd assume that. -- Johan
Re: RFC 130 (v4) Transaction-enabled variables for Perl6
Steve Fink wrote: "cond" for conditional? I was thinking along that line, too. But coopting "conditional" in any way is probably an ungood idea. Probly "trans" is good; it has multiple useful mnemonic values: transactional, transfer, transparent... -- John Porter We're building the house of the future together.
Re: Splitting core functions into multiple shared objects: A warning
I think the importance of splitting the core functionality into shared objects is more general than that. There was some discussion a short time ago about making a pared-down version for embedding, which would seem to require some sort of functionality reduction. There is also the desire of minimizing the footprint of the binary on heavily trafficked servers for obvious reasons, and a shared object scenario would address this directly. What I see as a typical installation would be similar to the means that Apache uses, in which the administrator has the option of: 1.) Statically linking all required objects 2.) Loading required objects at run-time 3.) Loading required objects as needed by the source. Item 3 is the most difficult to implement efficiently, but is not impossible. Item 1 is not all that different from the existing implementation, and Item 2, could be implemented using the Apache 1.3.x model. I'm not sure if it's possible with the last option, but it would be nice if the binary could have both Perl compile-time/run-time, and execution-time loading, allowing the core to have heavily used objects loaded at run-time, and allow less used objects to be loaded as needed. Another option might be to allow the core to be loaded as a daemon and the SO's to be loaded as necessary by the core. This could allow the core to spawn child processes to handle the individual tasks at-hand, and free the core to be a simple 'traffic cop' (Just a thought). Grant M. [EMAIL PROTECTED]
Re: RFC 110 (v3) counting matches
On Mon, Aug 28, 2000 at 12:23:48PM -0600, Tom Christiansen wrote: 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; Which I find cute as a demonstration of the Perl's context concept, but ugly as hell from usability viewpoint. I how to assign to an empty list to get a number of something? Hello? This harks back to the dirty (similarly cute, but still dirty) (c(a(s(t games of C. It may be an idiom but it still doesn't sing to me. -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: RFC 110 (v3) counting matches
Which I find cute as a demonstration of the Perl's context concept, but ugly as hell from usability viewpoint. I how to assign to an s/how/have/; $need_more_coffee++; -- $jhi++; # http://www.iki.fi/jhi/ # There is this special biologist word we use for 'stable'. # It is 'dead'. -- Jack Cohen
Re: Beefier prototypes (was Re: Multiple for loop variables)
On Mon, Aug 28, 2000 at 04:04:20PM -0400, John Porter wrote:
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 ) { ...
I'm wondering how we get both
for ($x,$y,$z) (@array) { ... }
and
for ($x,$y,$z) (@array1,@array2,@array3) { ... }
The answer seems to be to use either Cunzip() or Cpartition(), but
we still need that syntax where we have multiple iterators. Unless
we really want to write this:
for $threes (partition(3, \@list)) {
($x, $y, $z) = @{$threes};
}
for (partition(3, \@list)) { ($x, $y, $z) = @{$_};
The square bracket syntax is alluring since it implies referenceness,
but it goes the wrong way; squares enreference rather than dereference.
Random thoughts:
for @{$x,$y,$z} (partition(3, \@list)) { ... }
for ($x,$y,$z) = @{$_} (partition(3, \@list)) { ... }
for ($x,$y,$z) (@{partition(3, \@list)}) { ... }
for @three (@{partition(3, \@list)}) { ... }# arrays only
for @three (@{partition(3, \@list)}) @indices { ... } # arrays only
Ick.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
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 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. So don't do that. :set sw=4 ts=8. I am confident that were Dante were writing now, he'd reserve a special pit of Hell for those who alter the appearance of their physical tab stops, consigning to the flames all but the standard eight. 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? That would be wicked: this was one of the fundamental flaws of make. Let's learn from past mistakes, and not do that. Anything else would be extreme folly, and probably evil and wrong to boot. --tom
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
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 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 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
On Mon, 28 Aug 2000 09:11:39 -0400, David Corbin wrote: Why not make the details of this controlled by a pragma? TMFP Too Many Pragma's. We're trying to write ONE language here, not 150. Depending on what pragmas you're used to, you can no longer read, er, understand, other people's code! -- Bart.
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 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 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: Let's have a Standard for Module Configuration
While I think it is reasonable that all such configuration parameters be changeable by an API, there is clearly a place for system defaults. I've run across two such modules that I know. One wanted you to set the time-zone the system was running in, and the other was to set a default SMTP server. Both are reasonable to me for system installations. As for "Foo::Configuration", I could live with that, but that will tend to add another directory/namespace/module layer that can be a bit of a hassle. The only other logical approach I can see is to use FooConfigation; Carl Johan Berglund wrote: 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 -- David Corbin Mach Turtle Technologies, Inc. http://www.machturtle.com [EMAIL PROTECTED]
Re: Nice to have'it
raptor wrote:
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 ... :")
mildly nice...
2. "in" operator i.e.
$a in (5,6,10,33,45)
$a in @b
might be handy, but frequently when I need this type of functionality, I
just use a hash to start with.
snip
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.
Way cool. I'd love this. But I think you've got your push arguments
backwards.
snip
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]
=
--
David Corbin
Mach Turtle Technologies, Inc.
http://www.machturtle.com
[EMAIL PROTECTED]
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: Multiple for loop variables
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)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
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: RFC 130 (v4) Transaction-enabled variables for Perl6
"SF" == Steve Fink [EMAIL PROTECTED] writes: SF Or what about a variable attribute: SF my $x : transactional SF and making the effect completely lexical? Why would other scopes need to SF see such variables? You haven't handled the multiple variable variety. You will need to able to have a group of variables be transaction protected. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary
Stephen P Potter [EMAIL PROTECTED] writes:
At this point, should I go ahead and abandon the Math/Trig and/or
Sockets ones?
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require "sys/socket.ph"';
eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@;
and
$csock = pack('S n a4 x8', 2, 0, $caddr);
$ssock = pack('S n a4 x8', 2, $port, $saddr);
unless (socket(S,2,SOCK_DGRAM,$UDP_PROTO)) {
warn "$0 (socket): $!\n"; close S; return undef;
}
should be done away with for good.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary
I'm still in favor of moving the socket functions into Socket if for no
other reason than it may help beat into people's heads that code like:
eval 'require "sys/socket.ph"';
eval 'sub SOCK_DGRAM {-f "/vmunix" ? 2 : 1;}' if $@;
and
$csock = pack('S n a4 x8', 2, 0, $caddr);
$ssock = pack('S n a4 x8', 2, $port, $saddr);
unless (socket(S,2,SOCK_DGRAM,$UDP_PROTO)) {
warn "$0 (socket): $!\n"; close S; return undef;
}
should be done away with for good.
Agreed. As Nat put it, to do things socketish with anything even
approaching portability (readability), one has to load the bloody
module already anyway.
--
Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: RFC 155 (v2) Remove mathematic and trigonomic functions from core binary
Lightning flashed, thunder crashed and Nick Ing-Simmons [EMAIL PROTECTED] whispered: | I think this is inappropriate for sin/cos/tan et. al. and possibly even | sockets (although Win32 sockets are weird enough that it would be worthwhile) | | But for getpw* or shm/queue/msg or other may-not-be-there but we can | fake it if you REALLY want it stuff it makes sense to move the faking out | into a loadable so we can fix it independantly of perl. As I've stated before, when I first started, I decided to propose moving things as groups, not a monolithic "move everything that can/makes sense" type of thing. Unfortunately, I thought it would be a good idea to put them out one at a time (because of my schedule) and wait for discussion to quiet down a bit on each so that I could hopefully make the next one even better. I can see that maybe this wasn't the best way to do things. I'll try to write all of them and submit them all, then drop the ones that everyone agrees aren't wortthwhile. At this point, should I go ahead and abandon the Math/Trig and/or Sockets ones? -spp
Re: RFC 146 (v1) Remove socket functions from core
It's been strongly indicated that removing sockets (as well as any
other Perl functions that are little but wrappers around libc calls)
will not meaningfully reduce the size of Perl nor increase its
speed. Various VM issues have been discussed, including risks of
deadly embrace and egregious performance problems resulting from
the running of numerous instantiations on some architectures. A
simple run-once test on a single target platform, or even several,
will not bring these matters to light. but this will all have to
be addressed in exploring what can or cannot be done.
That leaves the deceptively appealing argument that "it will be
easier to port Perl without them". This is trotted out as a strong
argument, but in fact, it is the weakest amongst them. That's
because it is not at *all* true!
Why? Because HAS_SOCKET already takes care of that for sockets.
If the system has them, then they're compiled in. If it doesn't,
then trying to call that function raises an exception at run-time.
You do not make the perl binary more portable by getting rid of
sockets. The build process already considers their availability.
And you do not make Perl scripts more portable, either, because if
sockets aren't available, that socket-diddling script is doomed anyway.
At last check, the following built-in functions in theory can, on
various unfriendly systems, raise "unimplemented" exceptions:
alarm bind chown chroot closedir connect crypt dbmclose dbmopen
fcntl flock fork getgrent getgrgid getgrnam gethostbyaddr
gethostbyname gethostent getlogin getnetbyaddr getnetbyname
getnetent getpeername getpgrp getppid getpriority getprotobyname
getprotobynumber getprotoent getpwent getpwnam getpwuid
getservbyname getservbyport getservent getsockname getsockopt
ioctl kill link listen lstat msgctl msgget msgrcv msgsnd open
opendir pipe readdir readlink readpipe recv rewinddir seekdir
select semctl semget semop send setpgrp setpriority setsockopt
shmctl shmget shmread shmwrite shutdown socket socketpair symlink
syscall telldir times truncate umask utime wait waitpid
There may be other justifications for doing so, but contrary to
popular belief, migrating these functions into modules will *not*
affect the portability of either perl the program or of one's Perl
scripts. So this portability talk should not be used to justify
the act--it's a red herring. The /usr/bin/perl binary itself already
detects and/or emulates the underlying functions at build time, so
it is neither more nor less portable, and the scripts themselves
have little recourse if something critical isn't there. If they
care, they can always test for this either via %Config::Config or,
perhaps, through the old Ceval { syscall } strategy.
Perhaps something clearer could be devised there, like perhaps
Cexists CORE::chroot (or would that be defined?). Seems to me
Nick said something about making all these builtins work just like
real functions, and that should follow. This requires a bit of
-internals work though, more than it does -language work. Well,
unless we wanted
use CORE qw/socket bind connect listen/;
to do the exists() test on all those. I know that I've long wished
for POSIX to, at import time, verify that the things asked for were
actually there, as at this time, it doesn't tell you up front at
compile-time, even with the import, but not till way later upon
calling the function. This, too, will require -internals changes
if it is to be addressed.
--tom
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
RE: RFC 146 (v1) Remove socket functions from core
BTW, I have access to Rational Software's Quantify (and PureCoverage and Purify) on WinNT and HP-UX 10.20 which I'd be glad to use for such tests. If you want to get "in the mood" it would be good to fire it up on (say) perl5.6.0 and see where the hot-spots are. Planning on it as part of my upcoming perlhack doc patch on tools for debugging/testing perl. === Mark Leighton Fisher[EMAIL PROTECTED] Thomson Consumer ElectronicsIndianapolis IN "Display some adaptability." -- Doug Shaftoe, _Cryptonomicon_
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
At 10:48 AM 8/28/00 -0400, Karl Glazebrook wrote:
Using semicolons is an interesting idea. But consider:
@a[10:20; 30:40];
The ":"s and ";" are awfully hard to visually distinguish.
True, but @a[10..20; 30..40]; isn't hard to distinguish.
Even so, you might get such things as:
@a[10..20:2; 30..40:2]; which could cause the confusion you mention.
But for me, on the platforms I work on, I have a harder time distinguishing
between () and {} that ; and :. Visually, it's hard for me to see that
{foo (bar} baz) is unbalanced, yet @a[10:20;30:40]; is clear.
c.f.
@a[10:20, 30:40];
This has other problems I'm discussing in the RFC that Nathan Wiger
requested of me (being written in another window right now).
What do people feel about the whole replacing ".." by ":"
issue?
I think the RFC which suggests using both .. and : in ranges for different
meanings is probably a useful distinction. ".." is more intuitive a range
indicator than ":". I see "1, 2, 3, ... , 50" all the time, so "1..50"
works, but I never see a ":" used in an analogous situation.
Karl
Re: New variable type: matrix
Karl, all: I have just been auditing this list so far ;)
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.
Cheers,
Doug Hunt
Baris wrote:
Hi Karl,
Thanks for your comments.
I still think it would be a good idea to have a new type for both functional and
promotional purposes. I know that Nathan Torkington answered that perl6 will support
the requirements of PDL but I am hoping that having a new type for multidimentional
arrays lets PDL developpers freely create whichever syntax they want without worrying
that if a syntax has any other meaning in another context. Also this will increase
readibility of code. (Why do we have a new type for hashes?). And wouldn't it be
faster since clases/objects/etc. are slower than regular perl. The whole issue looks
like the regex support of perl. It needed a dedicated built in engine to have the
flexibility and speed. People say that perl character manipulation is faster than
C... And speed is much more crucial in linear algebra problems.
I think the question at this point will be that "Does perl want to target a new
audience?". Having a new type will force new books from Oreilly ("Learning Perl6") to
teach the new type in the second chapter (might be good or bad). Suppose I am a
newcomer to perl and my aim is to multiply two matrices and I don't really care about
regex's or references in perl. Currently I have to learn a lot about perl language to
begin working with matrix multiplication. This seems to me aginst the perl culture. I
know pdl is very easy to use, but how about somebody who doesn't know anything about
perl? He will have to first buy an introductory book for perl.
Even if you can solve all problems with syntax, performance, flexibility (I am not
saying these are problems, just guessing), in terms of promotion of perl in this
area, having a new type will make a difference. I know this because saying that
hashes are built in types for perl made a difference.
Thanks,
Baris.
*** REPLY SEPARATOR ***
On 25.08.2000 at 12:28 Karl Glazebrook wrote:
Hi Baris,
I agree with your sentiments. Most people in PDL DO come from the
number crunching/scientific background.
I would say that a matrix is just a special case of a general
N-dimensional compact array which obeys various rules. PDL
supplies a matrix-mult operator ("x") and other matrix ops.
Note it is useful to have BOTH "x" and "*".
Our goal is to get true multi-dim arrays like PDL, as you say,
into the core. Then one would have matrices too.
What the prefix should be is of course as interesting question,
currently PDL uses $, @ could be used if overloading became possible.
Is there a real case for a special prefix?
Karl
Baris Sumengen wrote:
I am little bit confused and probably very ignorant but one thing seems to
me very useful. Why doesn't perl support a new data type matrix. If perl
wants to become a real "programming language" not just a scripting language
it should support number crunching internally in a more intuitive way. I
don't know if this is suggested before but until now the messages I read
mentioned only making perl arrays consistant with pdl arrays.
etc.
1stUp.com - Free the Web
Get your free Internet access at http://www.1stUp.com
--
[EMAIL PROTECTED]
Software Engineer III
UCAR - COSMIC
Tel. (303) 497-2611
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) I seem to remember that ^ was in the process of being highjacked by some other RFC already. Was it higher-order functions? Christian
Re: New variable type: matrix
^foo -- compact array (or whatever notation) I seem to remember that ^ was in the process of being highjacked by some other RFC already. Was it higher-order functions? Yes: RFC 23 (v4): Higher order functions Damian
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 110 (v3) counting matches
Drawing on some of the proposals for extended 'for' syntax:
for my($mo, $dy, $yr) ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
...
}
This still requires that you know how many () matching groups are in
the RE, of course. I don't think I would consider that onerous.
If ther regex is fixed at compile time, you can simple count. But if
the regex varies at run time, it's not only onerous, it's pretty near
to impossible.
Re: RFC 110 (v3) counting matches
1. Return the number of matches 2. Iterate over each match in sequence 3. Return list of all matches 4. Return a list of backreferences Please see RFC 164. It can handle all of 1-3. You seem to have missed my point. I'm not asking for a notation that can do all these four things. We have such a notation already. I'm asking for a notation that does these things *orthogonally* and *consistently*. As nearly as I can tell RFC164 doesn't address this at all. It's basically syntactic sugar for the same mess we have now. If I am mistaken, please correct me.
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 Well, use strict refuses soft-links, and -w refuses use of undefined values. It may be that these are easy to check for at the low level, and therefore are candidates for flag-based operations. But for style, I don't see why the interpreter can't also check for various non-obscure syntaxes / styles. I doubt that requireing m/.../ really would help parsing performance any though. 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. -Michael
Re: RFC 110 (v3) counting matches
$count = () = $string =~ /pattern/g;
Which I find cute as a demonstration of the Perl's context concept,
but ugly as hell from usability viewpoint.
I'd really like to see an RFC that looks into making the following
features more orthogonal:
1. Return the number of matches
2. Iterate over each match in sequence
3. Return list of all matches
4. Return a list of backreferences
Perl presently uses various combinations of /g and scalar/list context
to get these. But some useful variants are missed. For example,
suppose you have a string like this:
"04-23-64 02-13-62 02-01-99 05-13-18 08-10-99"
You can run a loop once for each date:
while ($string =~ /\d\d-\d\d-\d\d/g) {
...
}
You can also extract the month-day-year parts of the first date:
($mo, $dy, $yr) = ($string =~ /(\d\d)-(\d\d)-(\d\d)/);
But there is no convenient way to run the loop once for each date and
split the dates into pieces:
# WRONG
while (($mo, $dy, $yr) = ($string =~ /\d\d-\d\d-\d\d/g)) {
...
}
This is an infinite loop. It sets $mo $dy $yr to 04 23 64, repeatedly.
One solution here is:
while ($string =~ /\d\d-\d\d-\d\d/g) {
($mo, $dy, $yr) = ($ =~ /(\d\d)-(\d\d)-(\d\d)/)
...
}
Not only do you have to use $, but you also have to write the pattern
twice.
Another solution:
@matches = ($string =~ /(\d\d)-(\d\d)-(\d\d)/g);
while (@matches) {
($mo, $dy, $yr) = splice @matches, 0, 3;
...
}
This is clumsy, and it doesn't work unless you know in advance how
many backreference groups the pattern will contain. (Perl knows, and
this number is part of the struct regexp, but there is no way to get
Perl to tell you.)
My wish list for better orthogonality is actually a little longer than
the four items above, but the other items are more abstruse.
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
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. This becomes not merely "It is not expected that perl6 will run perl5 programs unchanged." but also "It is not expected that perl6 will run perl4 programs unchanged." "It is not expected that perl6 will run perl3 programs unchanged." "It is not expected that perl6 will run perl2 programs unchanged." "It is not expected that perl6 will run perl1 programs unchanged." This has never been the case before, at least, not so dramatically. Sure, the edges have been dodgy, like what happened with "[EMAIL PROTECTED]". But if *MOST* perl1 .. perl5 programs aren't going to work unchanged, that means that most people's existing perl knowledge-base will no longer be valid. That probably means that they aren't going to be able to just type in the Perl that they already know, either, since that Perl will no longer be valid. And in my ever so humble opinion, that's when one should consider dropping the name "perl". This is *not* a bad thing; think of it as much the same as occurred when people stopped calling their improved version of Lisp "Lisp" and started calling it Scheme, or how "C with Classes" eventually took on a different name as well. Names--or, I suppose, "branding", if you truly must--are important things. If the perl6:perl5 relationship is similar in breadth to what we saw in the perl5:perl4 one, then perhaps, maybe even probably, one will get away with it. However, if the stretch is appreciably further, I don't think one will. And I do fear the negative public image ramifications to Perl. This will have to be handled gently and sensitively lest the public lose faith. (No, I didn't really *say* "spin control" there--you just read it.) A new dialect name might save some public confusion. --tom
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
Tom Christiansen writes: if you truly must--are important things. If the perl6:perl5 relationship is similar in breadth to what we saw in the perl5:perl4 one, then perhaps, maybe even probably, one will get away with it. However, if the stretch is appreciably further, I don't think one will. What you say makes sense, and I agree that radical changes to the language will pose us problems. However, I'm stubbornly not thinking about that until after Larry shows us what perl6 will look like. It may be that Larry will boil down everyone's suggestions into something that looks like perl5, walks like perl5, but quacks like Python and Java's love-child amped up on a batch of cheap Eiffel crank. Nat
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
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... 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. next if /\s+/ || /\w+/; next if match /\s+/ or match /\w+/; Gosh this is annoying. I *really* don't want to have to type "match" all the time. And now I have to use Cor rather than C||, which is already ingrained in my head (I rarely use "or" or "and") v2 will clarify this some more and let you type: next if m/\s+/ or m/\w+/; Which is essentially the same as now. 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. -Nate
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 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
next if /\s+/ || /\w+/; next if match /\s+/ or match /\w+/; Gosh this is annoying. I *really* don't want to have to type "match" all the time. And now I have to use Cor rather than C||, which is already ingrained in my head (I rarely use "or" or "and") There are thirteen years of precedent, not to mention the millions of users, who are completely accustomed to writing expressions like next if /\s+/ || /\w+/; It's nearly part of Perl's language signature. I wouldn't count on this going away if you still think to call this "Perl". It is of course much more likely in the renamed "Frob" language, however. --tom
Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst()
Tom Christiansen wrote: There are thirteen years of precedent, not to mention the millions of users, who are completely accustomed to writing expressions like next if /\s+/ || /\w+/; It's nearly part of Perl's language signature. I wouldn't count on this going away if you still think to call this "Perl". It is of course much more likely in the renamed "Frob" language, however. First off, this argument is just a little too grandiose, because if we can't change anything because of precedent, then we're stuck and Perl 6 should just be Perl 5.9 instead. That being said, I don't see why this wouldn't work still. As I noted in an email to Scott, at the very least this will work: next if m/\s+/ || m/\w+/; And if we want to special case // still that's fine with me. -Nate
Creating Perl 6, not Perl++ (was Re: RFC 164 (v1) Replace =~, !~, m//, and s/// with match() and subst())
Tom Christiansen wrote: But if *MOST* perl1 .. perl5 programs aren't going to work unchanged, that means that most people's existing perl knowledge-base will no longer be valid. That probably means that they aren't going to be able to just type in the Perl that they already know, either, since that Perl will no longer be valid. And in my ever so humble opinion, that's when one should consider dropping the name "perl". I agree with this statement wholeheartedly. You have some excellent points, Tom, as always. I do, however, disagree we should view renaming Perl 6 to "Perl++" or something else as even a remote possibility. At all. Instead, I'd like to see a Perl 6 that has a ridiculous amount of power "just under the hood", but which superficially looks like "the same old Perl", with perhaps a few exceptions here and there. I absolutely *love* Perl. *LOVE*. It's the *only* language I enjoy using. It's fun! I'd hate to see it destroyed, and I want to emphasize this strongly lest people misread some of my RFC's. I don't think having Perl 6 be the bastard child of terrible OO, quasi-PDL, Python, C structs and types, missing prefixes, and moving everything out of core is a good goal. And I think accepting the idea of a "Perl++" is the easiest way to let this happen. I just reread Simon Cozen's excellent RFC 28, just to remind myself of what we should be aiming for here. And if any of my RFC's ever run against this goal, please point them out. I'll be the first to retract them. But I don't want Perl++, I want a better Perl. climbing down from grandstand and preparing for tomatoes -Nate
Re: RFC 110 (v3) counting matches
On Mon, Aug 28, 2000 at 01:30:41PM -0500, Jarkko Hietaniemi wrote: $count = () = $string =~ /pattern/g; Which I find cute as a demonstration of the Perl's context concept, but ugly as hell from usability viewpoint. I how to assign to an empty list to get a number of something? Hello? This harks back to the dirty (similarly cute, but still dirty) (c(a(s(t games of C. It may be an idiom but it still doesn't sing to me. It's pretty far from perfect, but I do find the above much easier to understand than $count = $string =~ /pattern/t; There are far too many regexp option modifiers as it stands. I don't think adding new ones for functionality which can be derived from the existing ones is going to help anyone. I'm quite certain that a t modifier sings less for me than the existing idiom. - Damien
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
"DC" == Damian Conway [EMAIL PROTECTED] writes:
DC However, I have given thought to allowing conditions to be grouped,
DC and de-activated by group. This would probably meet your need.
DC pre mymethod : group("safe-coding practice") { @_ 0 }
DC pre mymethod : group("debugging") { print @_, "\n"; }
Makes it difficult to specify on the command line. Unless you have
another way of matching them to higherarchy or perhaps a cost level?
DC There would be a 'contract' pragma:
DC use contract qw("safe-coding practice");
DC no contract qw("debugging");
DC no contract;# turn everything off (production code)
One issue that bothers me with this. Even though it is a _minor_ edit,
I never like to twiddle a working piece of code. No contract should
be the default, and during testing it should be overridden from the
command line.
chaim
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
What you want is a pre-condition on the overridden assignment operator.
What you want to do may involve having the suggested transactional
variables.
chaim
"NT" == Nathan Torkington [EMAIL PROTECTED] writes:
NT Damian Conway writes:
pre mymethod : group("safe-coding practice") { @_ 0 }
pre mymethod : group("debugging") { print @_, "\n"; }
NT Using these for lvalue subs doesn't give you the behaviour you want:
NT sub foo :lvalue { $foo }
NT post foo { die if $foo == 5 }
NT eval {
NT foo() = 5;
NT };
NT Should not set the lvalue of foo to 5. But you can't test for
NT bad values until after you've made the assignment.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 118 (v1) lvalue subs: parameters, explicit assignment, andwantarray() changes
Hildo Biersma writes: Hold on - post conditions are not intended to veto a change, they're intended to terminate the program if an assertion is invalid. Hence it should not matter if they run before or after assignment. Given that the assertion should be "now this and that should be true", and you may want to call validation methods as part of that assetion, the implementation of the checks becomes vastly easier if they are applied to the new state of the object, instead of the old state and a set of proposed changes. So it sounds like Damian's lvalue subs + postconditions won't give me what I want. How do I do what I want? Have an lvalue sub but prevent the value from being changed to something invalid? Do I need a combination of lvalue subs and tied variables? Augh. Nat
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: 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: On the case for exception-based error handling.
At 12:16 PM 8/27/00 -0400, Bennett Todd wrote: The ramifications of some of these things are sufficiently important that drawing attention to them might be a good thing. In this case, note that Perl 6 will need to spell out which core exceptions are by default fatal (eg, :arithmetic) and which aren't. Although RFC 70 doesn't have to do that. It feels to me like this should maybe be divided into some change to RFC 70, along with a companion RFC --- unless you want to fold all discussion of Fatal.pm development into 70. But if you like I'll be happy to include in RFC 70 the request that any builtins that _by_default_ "throw exceptions" (die) on errors, _also_ be wrappable so that Fatal.pm can be written to allow e.g. "no Fatal qw(:arithmetic)". Of course that specific one may require additional intimacy between Fatal and the core, since unless we make all arithmetic scalars into objects, I don't think we're set up to allow overriding basic arithmetic builtins like e.g. "/" for divide-by-zero. I don't think you need to get into the -internals part of it. Although if you were, I'd say that where pp.c does DIE(aTHX_ "Illegal division by zero"); the DIE will be turned into something that checks fatalism first. -- Peter Scott Pacific Systems Design Technologies
Re: RFC 159 (v1) True Polymorphic Objects
Removed perl6-announce x-post
Tom Christiansen wrote:
Hm I don't recall C++ ever thinking to overload the control-flow
operators ("", "||", "," (that is, comma), and "?:"). Why not?
Even if their "a b" should produce a more mundane 1 or 0, one
still might wish control.
'', '||', et al are just operators that happen to evaluate their second
argument lazily. There's no reason to assume that the prototype to _any_
operator couldn't specify one or more lazily evaluated arguments in Perl 6.
I don't see why we should assume that these four operators should be the
only operators to provide this control-flow side-effect.
...
I do not see how it is a
feature to create a new universe in which
!a !b
and
a || b
can no longer equated.
It's always dangerous to make assumptions about what rules an operator
obeys. As well as the various logical operator equalities, there's
a + b == b + a
and
a + (b + c) == (a + b) + c
and so forth.
Which of these equalities holds for which operators for which types should
not necessarily be assumed. It's nice to be able to implement non-standard
logic by overloading standard operators, and to work with tensors, complex
numbers, non-cartesian coordinate systems and so forth where not all
'standard' rules (rational numbers; cartesian coordinates; classical logic;
...) necessarily apply.
Is the key issue here about what optimisations Perl can make? If so, we
should look to enumerate the properties of an operator under which specific
optimisations can be made. Then we can check the prototype of an overloaded
operator to see if it fits these properties, and maybe add attributes (e.g.
':associative') where the prototype does not provide sufficient information.
Re: RFC 161 (v2) OO Integration/Migration Path
Matt Youell wrote:
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-
I just want to hit this point a little more, to make sure we're actually
in agreement.
Under my RFC (which I have postponed assuming you and I see eye-to-eye),
'int' would be a special package (a subclass) and *NOT* a function:
package int;
# inherit all methods from CORE except:
sub STORE {
if ( is_not_an_int($_[0]) ) {
return ERROR_BAD_DATA_TYPE;
} else {
internally_store($_[0]);
}
}
Pardon the extreme pseudocode, but you get the idea. Then you'd write:
my int $x = 5; # $x-CREATE, $x-STORE(5) from class int
This integrates OO at the bottom level, but hides it where nobody can
see it. Inheritance is ridiculously simple - everything is some class or
other, and that class's methods are simply used to store and access
data. Everything is an object, only unlike Python (been reading a lot),
nobody has to know.
My idea would be to seamlessly integrate this idea with RFC 159. We'd
use the existing OO structure of Perl 5, only we wouldn't put it on top
of everything, but put everything on top of IT.
Sound good? If we don't agree 100%, that's fine, I'll just RFC mine
separately. Even if the idea is the same, if the procedure is markedly
different it probably deserves a separate RFC. But if we agree and
you're willing to change the language of your RFC to reflect the above
class structure, then fewer RFC's for Larry to have to read is probably
good. :-)
-Nate
Re: RFC 161 (v2) OO Integration/Migration Path
Steve Fink wrote:
But then what does my $x = BlueFoo-new(); print
"$x" do, assuming there is a BlueFoo::STRINGIFY? Print
"BlueFoo=HASH(0x0b38134)"?
The current thinking it to preserve the default behavior, which would be
to print out the ref info, UNLESS there is a STRING function. That
STRING function would then print out whatever you set it up to print
out. See RFC 49 for more info.
So, if you defined BlueFoo::STRING as follows:
package BlueFoo;
sub STRING {
return "Wazzap!!";
}
Then your code would do this:
my $x = BlueFoo-new;
print "$x";# prints "Wazzap!!"
Also, please note the sub is STRING. 10,000 emails went back and forth,
and STRINGIFY is too cute for non-English natives. It also requires we
do NUMMIFY or BOOLIFY instead of NUMBER or BOOLEAN. Too cute.
See RFC 159 for more details on this.
As for non-vtable methods, were you planning on making
my Foo $foo; $foo-method_not_in_Foo_package();
The identical Perl 5 behavior and error of:
Can't locate method method_not_in_Foo_package via package $foo
Should apply here.
-Nate
Re: New variable type: matrix
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. Thanks for the vote of confidence... The RFC was sent to the RFC editor this afternoon (about 7 hours ago as I type), but it doesn't look processed yet. If it doesn't turn up by the time I get to work tomorrow (09:00 -0400 (EDT)), I'll send an unnumbered copy to perl6-language-data. -Nate -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacophony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Re: RFC 148 (v1) Add reshape() for multi-dimensional array reshaping
Karl Glazebrook wrote: 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. I see a number of problems with the current (scalar) PDL objects being turned (essentially) into perl arrays in perl6. 1) How do you pass lists of PDLs into functions without having to explicitly reference them: my @result = fitit @x, @y, @derivs; would turn (in current thinking) @x, @y, @derivs into one big array. So is it my @result = fitit \@x, \@y, \@derivs; which is much worse than what we do in PDL now. An automatic pass by reference mechanism seems necessary (is that already in some RFC)? 2) any function returning such arrays would do so in list context. Currently, PDLs being scalars you can distinguish with wantarray if the user just wants one piddle or a whole collection of result piddles which is very useful: return wantarray() ? ($fit,$fwhm,$correlation) : $fit; I am not sure how you do this with the @notation?? 3) Although PDL objects share some ideas with arrays it is much more useful to think of each instance as singular. That's anyway the programming style that an array-oriented numerical language should favour. 4) The history of perl lists seems to unnecessarily restrict the vital flexible slicing syntax. As I stressed a million times it must be flexible and very concise to be useful. The solution: don't use the @array syntax but stay with either blessed objects or some new prefix (hard to find any that aren't taken). Then go for the $pdl(args) syntax for slicing. Yes, it's new but not outrageous (DEFAULT method for '()' overloading). 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? As currently suggested 10:20 (or 10..20) would return a list (that could be lazy evaluated). The problem arises when you try to use that in arglists. With current perl5 logic $pdl(10:20,:2,(5)) would call the default method (or whatever is decided) with just one big list that is the concatenation of the three lists. Definitely not what is desired. Two possible solutions: (1) let 1:3:4 create a range object (rather than a list) $rg = 1:3:4; $pdl($rg,$n:-1) *= 2; or (2) introduce some way of specifying a prototype that allows positional arrays in argument lists (that are not concatenated). In summary, I doubt that having PDLs being represented by arrays helps *unless* quite a number of things are changed with regard to array passing, list context, etc. Christian
Role of perl6-language-data
First of all, apologies for my lack of input over the last week--unfortunately I went on holidays pretty much as this list went online, so I've been pretty quiet. Anyhow, for those who don't know me, I'm the chair of perl6-language-data. For the remainder of its existance I'll be more active. This message is designed to provide an overview of this list's role, potential inspirations, and key RFCs. If you reply with a comment on a particular issue, please change the subject line accordingly. The role of this list is to try and create the features necessary to make Perl the best language for data crunching around, while keeping it Perlish. These two goals should be complimentary, not conflicting. 'Data crunching' involves the input, manipulation, and output of large enough amounts of data that memory usage and speed of the operation is a very important factor. This includes numeric data crunching such as image processing or scientific data processing, data-intensive modelling such as neural network training or stochastic modelling, and text processing such as dictionary analysis or large transaction log processing. PDL provides a source of many important lessons for us. It shows the kinds of features that are required for numeric data crunching, and it also shows the kinds of obstacles we need to remove from Perl 6. Other sources of inspiration for syntax, paradigms, and implementation ideas include: - Mathematica (combines functional, declarative, and procedural styles; implements memoization, lazy lists, and array notation) - Matlab (fast and simple array language) - C++ expression templates such as POOMA and Blitz++ (implicit looping and generalised slicing; loops unrolled and parse trees walked completely at compile time resulting in zero run-time overhead) - FORTRAN (still the most widely used numeric programming language) - Haskell (effective data crunching in a purely functional paradigm) RFCs that are important for data crunching are (available from http://dev.perl.org/rfc/): - 23 (v4): Higher order functions--frequently used in reduce() and list generation/slicing - 24 (v1): Semi-finite (lazy) lists--not active, but maybe still required in a revised form - 45 (v2): C|| and C should propagate result context to both sides--need to fix incompatibility with RFC 82 - 76 (v1): Builtin: reduce--provides the generalised mechanism to reduce lists/arrays - 81 (v2): Lazily evaluated list generation functions--key platform for generalised slicing - 82 (v2): Apply operators component-wise in a list context--makes @a=@b+@c DWIM - 90 (v1): Builtins: zip() and unzip() 91 (v1): Builtin: partition--allows 1d arrays to be split and combined flexibly; can be used to generalise 1d arrays to act as n-dim tensors - 107 (v1): lvalue subs should receive the rvalue as an argument 118 (v1): lvalue subs: parameters, explicit assignment, and wantarray() changes--lvalue subs are already useful for PDL - 115 (v1): Default methods for objects--provides overloading for brackets - 116 (v1): Efficient numerics with perl--overview of PDL - 117 (v1): Perl syntax support for ranges--should be merged with RFC 81 shortly - 123 (v1): Builtin: lazy--lets the programmer decide when lazy evaluation is safe - 128 (v2): Subroutines: Extend subroutine contexts to include name parameters and lazy arguments - 142 (v1): Enhanced Pack/Unpack--important data crunching features - 148 (v1): Add reshape() for multi-dimensional array reshaping--Different notation for RFCs 90 and 91 I've cc'd the authors of these RFCs--you may want to change your RFC so that it has this list as its home (if appropriate), or at least please subscribe to this list since we might discuss things of relevance to you.
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: New variable type: matrix
Christian Soeller wrote: 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? This should be overrideable by prototypes. And the internals guys are probably going to fix the "list-flattening problem" anyways. So I wouldn't worry about this part. -Nate
Fwd: Re: Automated no status messages
The way people seem to be showing the status of RFCs is by putting "Status: foo" up near the maintainer info etc. This makes good sense. Can this be reflected in the sample RFC and the instructions and so on? K. - Forwarded message from Peter Scott [EMAIL PROTECTED] - From: Peter Scott [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Automated "no status" messages Date: Mon, 28 Aug 2000 09:20:01 -0700 At 05:31 PM 8/28/00 +1000, you wrote: 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. Whee can I find out what 'frozen' means? I'm looking at links under http://dev.perl.org/rfc/meta/, but none of them mention a status field, only an optional STATUS section that's something else. -- Peter Scott Pacific Systems Design Technologies - End forwarded message - -- 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
