Re: New variable type: matrix
Baris wrote: Hi, ^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. Why do you think that individual elements are perl scalars? To avoid anyone getting yelled at by TomC or someone else: Yes. Anything individual in Perl is a scalar. By definition. Please don't try to change this. For more details on this, please read this email: http://www.mail-archive.com/perl6-language@perl.org/msg00329.html Under these definitions - which are at the core of Perl - piddles are just @arrays (maybe special arrays, though, see Buddha's RFC) and do not warrant their own data type. Yes, I do view this as a good thing. -Nate
Re: New variable type: matrix
Dan Sugalski wrote:
At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
But scalars are not compact.
Since scalars are singular things, how would you compact them anyway?
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floating point number.
This is not a perl scalar.
If I then say $b = $a-slice("(5),(5)") then $b is a zero-dim
piddle - not a scalar.
Karl
Re: New variable type: matrix
At 12:42 PM 8/29/00 -0400, Karl Glazebrook wrote:
Dan Sugalski wrote:
At 12:28 PM 8/29/00 -0400, Karl Glazebrook wrote:
But scalars are not compact.
Since scalars are singular things, how would you compact them anyway?
If I say $a = ones(float,10,10) in PDL then each element of $a
is a 4 byte floating point number.
I presume in PDL that gets you a 10x10 matrix of floats? In that case
you're not getting a scalar back, you're getting a matrix. That it needs to
be represented as an object is an indication of one of perl 5's
limitations. (And then the compactness would be something the object
applies to whatever data structure it builds
This is not a perl scalar.
Right, so the question still stands--since scalars are singular things, how
(and why?) would you compact them?
If I then say $b = $a-slice("(5),(5)") then $b is a zero-dim
piddle - not a scalar.
So then it's not relevant to the question. :)
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Proposed RFC for matrix indexing and slicing
At 12:33 PM 8/29/00 -0400, Karl Glazebrook wrote:
You should have a look at the PDL RFC 117 before submitting this.
It would be bad to have multiple RFCs suggesting the same thing.
I just read PDL RFC 117, and your current argument with Dan aside...
I don't see a problem.
Here is the core of what I see in my RFC:
1. Use ';' as an index separator for matrices.
2. Use lists as methods of getting slices of matrices
3. Use ^var (or some other syntax) as a way of expressing
relationships/constraints among different indices when writing
matrix slices.
Here is what I see as the core of RFC 117:
1. Use start:stop:step as syntax for complex ranges.
I see them as orthogonal. You could just as easily use RFC 117 syntax to
specify the lists I use to get slices as you could standard perl lists.
Much better to come to some agreement HERE on what the syntax
should be first, then submit consensus RFCs.
My view: I am pretty flexible I like most suggestions as long as
they are concise.
Don't forget we also need to support the equivalent of
$pdl-slice('10:20:2')
@matrix[10:20:2];
that is, assuming my RFC and RFC117 are both accepted. What's the problem?
i.e. use a non-unit stride
Karl
Access to the perl6 parser
IMHO if the perl6 core only allow access to the parser, than a module can do just about anything including all of those things proposed in RFC 115 - 117. Maybe this is an over simplification, but it seems that if the statement: use Python; caused the subsequent source to go through my Python::parser subroutine, my module could do just about anything (including parse Python!?) So the question is - does such an RFC exist for perl6 and is it's scope as broad as my imagination makes it out to be? If so need we ask for anything else?If not, why not? Jim
Re: Access to the perl6 parser
At 06:05 PM 8/29/00 +, Jim Edwards wrote: IMHO if the perl6 core only allow access to the parser, than a module can do just about anything including all of those things proposed in RFC 115 - 117. That's sort of on the list of things to allow (I think Damian RFC'd it) but whether it happens depends on the resulting parse speed. Hardcoded parsers seem to run faster than more dynamic, extendable ones, so it might cost too much. OTOH, parse speeds might end up being a trivial part of the total program load/compile time, so it might not matter. Regardless, you can already do this in perl 5, and will undoubtedly be able to do it in perl 6, with source filters. (If Damian can write perl that looks like Latin or Klingon, then python ought to be simple... :) Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
drop type indicators for typed variables
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? if strongly typed barewords are allowed to represent variables (like they do in most other languages) we could have my piddle x,y,bounds; @result = integrate x,y,bounds we would know x,y, and bounds are piddles without needing the marker indicating scalar (they aren't scalars, they're piddles) or container (@ or %) type. And then the line noise haters can say my SCALAR x; and they're happy. -- David Nicol 816.235.1187 [EMAIL PROTECTED] Yum, sidewalk eggs!
Re: Proposed RFC for matrix indexing and slicing
Dan Sugalski wrote: Meanwhile we all go rambling around on cross-threads and come up with no coherent set of proposals. So? If the idea has merit, it'll make it into one or more RFCs, and Larry's rather good at making things coherent. If it just putters around for a while on the list, then maybe it's really not worth all that much. What Karl was trying to get at is a suggestion to have one RFC on indexing instead of three competing ones, for example. The current approach seems to be make a new RFC always (regardless what is there already). The other approach would be to take existing ones and rewrite them heavily. Christian
Re: New variable type: matrix
Baris wrote: My motivation was to give more freedom to the developers of pdl so that they can freely create the syntax without worrying about the workarounds. Matlab, in my opinion, is much more natural to code than current pdl. It'd be interesting to hear what you dislike in particular. By the way I am pretty much happy with $pdl notation and I really hate @pdl notation and I find it confusing. I agree (but not many others seem to). You forgot that there is a dimentionality associated with a piddle elements. $p = pdl [1]; is not equavalent to $p = pdl [[1]]; and neither of them are equivalent to $p =1; # I think there should be a 0 dimentional pdl also so that we can have compact scalars. There is: $p = pdl 1; However, it is not really compact due to the overhead a piddle has to carry around. A perl scalar is probably still as compact as it gets (maybe explicit typing can cut down a bit more). http://www.mail-archive.com/perl6-language@perl.org/msg00329.html It is great that perl is similar to speaking english and it is more closer to how we behave in our daily lives, but there is something missing here. When was the last time you needed to multiply two matrices in your daily life? Yes people learn a language such as English and I realy like that writing perl programs is like speaking English, (in a natural way). But we also did learn another language, which is called mathematics. IMHO I don't think pdl should follow the natural language path, but the mathematics path. How do we explain things in mathematical terms? Pdl should be natural in a sense that I should be able to code my program in a similar way that I answer a math question in a linear algebra exam. Syntax examples? Sounds like functional programming. Christian
Re: RFC 90 (v2) Builtins: merge() and demerge()
Still think Cmerge and Cemerge are cuter. :-) Except that that pair looks like "munge" and "emunge" (and probably sounds like them too in certain accents :-), which are actually synonyms of each other. :-( --tom
RFC 169 (v1) Proposed syntax for matrix element access and slicing.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Proposed syntax for matrix element access and slicing.
=head1 VERSION
Maintainer: Buddha Buck [EMAIL PROTECTED]
Date: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 169
Status: Developing
=head1 ABSTRACT
I propose the use of ';' as a separator for index terms when accessing
multi-dimensional arrays (matrices). The syntax
"$matrix[$w;$x;$y;$z];" is clearer and more flexible than other
proposed alternatives. The flexibility is mainly in the possibility
of a robust slicing syntax.
Although I know of no RFC's that recommend the implementation of
matrices, I expect such a proposal to be made, and this RFC does not
make such a suggestion.
=head1 DESCRIPTION
Several suggestions have been made for matrix element accessors,
including:
$matrix[$x][$y][$z] # aka "(Lo)*L" notation ( (lists of)* lists)
$matrix[$x,$y,$z] # aka "[,,]" notation
$matrix{"$x,$y,$z"} # aka hash notation
All three of these have problems. The (Lo)*L notation either requires
matrices be (lists of)* lists, or uses the same syntax for both
matrices and (lists of)* lists. The hash notation has the same
confusion, but with hashes. The [,,] notation is too similar to
the existing syntax for array slices.
None of them allow for convenient matrix slicing.
Using $matrix[$i;$j;$k;$l] has the advantage that it is dissimilar
from exising syntax, thus minimizing confusion with pre-existing data
structures, and it provides a clean separation of indices, allowing
for a flexible slice notation.
=head2 Matrix Element Access.
Matrix elements should be accessed as normal arrays, but using ";" to
separate the indices:
my @matrix;
$matrix[1;2;3;4] = 5;
sub tensor2mul {
my @tensor1 = @{shift @_};
my @tensor2 = @{shift @_};
my @tensor3;
for $i (0..3) {
for $j (0..3) {
for $k (0..3) {
for $l (0..3) {
$tensor3[$i;$j;$k;$l] = $tensor1[$i;$j] * $tensor2[$k;$l];
} } } }
return @tensor3;
}
Currently, ';' is only used for statement separators and as term
separators in for(;;) loops. This new proposed use should not be a
problem for the parser or programmers to understand in this context.
=head2 Matrix Slices
Because the indices are separate, array slice notation can easily be
used for the individual indices.
#exlude row $j and column $k, as if taking a determinant.
@submatrix = @matrix[0..$j-1,$j+1..$n;0..$k-1,$k+1..$n];
While that should work obviously enough, a more flexible syntax would
be nice:
# leave index blank for "all" # or use unterminated ".."
@row = @matrix[1;];# @row = @matrix[1;..];
@col = @matrix[;1];# @col = @matrix[..;1];
@swaprow = @matrix[1,0,2..$n;]
# Use ^var to get more complicated slices
@diagonal= @matrix[^i;^i];
@rdiagonal = @matrix[^i;$n-$i];
@uptriangle = @matrix[^i;0..$i];
@lowtriangle = @matrix[^i;$i..$#];
# These would be nice, but probably not feasable
@trans[^i;^j] = @matrix[^j;^i];
@tensor3[^i;^j;^k;^l] = @tensor1[^i;^j] * @tensor2[^k;^l];
$dotproduct = reduce ^1+^2 , 0, a[^_] * b[^_];
Those above would work if the ^vars would scope across all indices in
the statement, not just one.
# use $# to get maximum val for index
sub lowtriangle {
@matrix = @{ shift @_ };
return @matrix[^i;^i..$#]; # works for all 2-d matrices.
}
Matrices of more than two dimensions should be handled similarly:
# Slice through middle of cube perpendicular to main diagonal
@slice = @matrix[^i;^j;^i-^j];
The use of the ^var syntax is analogous to the use of ^placeholder
syntax in Damian Conway's HOF RFC.
=head2 Computing the size of matrices
I'd propose that, analogous to the $#array notation for revealing the
upper index of @array, @#matrix return the analogous list:
my @matrix
$matrix[2;2;2] = 1;
@sizes = @#matrix; # @sizes == (2,2,2)
$numdim = @#matrix; # array in scaler context.
=head2 Unresolved issue -- variable dimensionality
Right now, the syntax above hardcodes the dimension of a matrix in the
index list. This does not allow you to write programs which
manipulate $n-dimensional matrices, where $n is computed at run-time.
This is unfortunate, and I'd like to hear suggestions on how to deal
with that issue.
One possible mechanism would be to allow @k = @matrix[$n;]; to always
assign to @k a matrix of one less dimension that @matrix, regardless
of the original dimensionality, with the exception that @array[$n;]
will return a singleton list rather than a 0-dimension matrix (which
should by rights be a scalar). How that should generalize is not
clear.
=head2 Unresolved issue -- ^var slices and HOF
Damian Conway suggested a HOF syntax which used ^var as a
placeholder. The "reduce" example above shows how confusing using
both HOF and ^var slices in the same expression can
RFC 90 (v2) Builtins: merge() and demerge()
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Builtins: merge() and demerge()
=head1 VERSION
Maintainer: Jeremy Howard [EMAIL PROTECTED]
Date: 10 August 2000
Last modified: 29 August 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 90
Status: Developing
=head1 ABSTRACT
It is proposed that two new functions, Cmerge, and Cdemerge, be added
to Perl. Cmerge(@list1, @list2, ...) would return a list that
interleaved its arguments. Cdemerge($num_lists, @list) would reverse
this operation.
=head1 CHANGES
=head2 Since v1
=over 4
=item *
Moved list to [EMAIL PROTECTED]
=item *
Changed name from zip/unzip
=item *
Pass lists directly in examples, not references
=item *
Change 2nd argument from $list_size to $num_lists
=back
=head1 DESCRIPTION
It is proposed that Perl implement a function called Cmerge that
interleaves the arguments of arrays together, and is evaluated lazily.
For instance:
@a = (1,3,5);
@b = (2,4,6);
@merged_list = merge(@a,@b); # (1,2,3,4,5,6)
This makes it easy to operate on multiple lists using flexible reduction
functions:
$sum_xy = sub {reduce ^last+^x*^y, merge($_[0], $_[1])};
print $sum_xy-(@a, @b); # Prints '44', i.e. 1*2+3*4+5*6
In order to reverse this operation we need an Cdemerge function:
@merged_list = merge(@a,@b); # (1,2,3,4,5,6)
@demerged_list = demerge(2, @merged_list); # ([1,3,5], [2,4,6])
The second argument to Cdemerge is the number of lists that are to be
created (i.e. the number of lists that would have been Cmerged for this
to reverse the operation).
If the list to be demerged is not an exact multiple of the partition size,
the final list references are not padded--their length is one less than
the list size. For example:
@list = (1..7);
@demerged_list2 = demerge(3, @list); # ([1,4,7], [2,5], [3,6])
=head1 IMPLEMENTATION
The Cmerge and Cdemerge functions should be evaluated lazily.
Effectively, Cmerge creates an iterator over multiple lists. If used as
part of a reduction, the actual interleaved list need never be created.
For instance:
$sum_xy = sub {reduce ^last+^x*^y, merge($_[0], $_[1])};
$answer = $sum_xy-(@a, @b);
should be evaluated as if it read:
$answer = 0;
$answer += $a[$_] * $b[$_] for (0..$#a-1));
which does not need to create an intermediate list.
=head1 REFERENCES
RFC 23: Higher order functions
RFC 76: Builtin: reduce
RFC 91: Builtin: partition
Re: RFC 120 (v2) Implicit counter in for statements, possibly $#.
On Tue, Aug 29, 2000 at 09:15:35AM +0100, John McNamara wrote:
At 13:11 28/08/00 -0400, Steve Simmons wrote:
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.
What I really want to do is write a summary, get some consensus and redraft
the RFC. I'll do this in the next few days.
As far as I can see the current consensus is as follows:
1. Implicit variable: nice but not really worth the trouble.
2. Explicit variable between foreach and the array: might conflict
with other proposals.
This doesn't conflict with the idea of assigning multiple variables
per loop execution as long as explict grouping of the vars assigned
to is required. As examples:
foreach ( $var, $var2 ) $i ( @arr ) { } # OK
foreach $var, $var2, $i ( @arr ) { } # Not OK
foreach $var, $var2 $i ( @arr ) { } # Not OK
foreach ( @list ) $i ( @arr ) { }# OK
foreach ( @list, $var ) $i ( @arr ) { } # OK
foreach @list, $var $i ( @arr ) { } # Not OK
Some underlying logic for this
o it allow one to use the original $_ in the body while still
permitting use of an index var, ie
foreach () $i { something( $_, $i ) }
o any use of the index var which is inadvertantly given to
pre-perl6 code will bomb with a syntax error
If I get up and write that RFC, that's how I'll propose it be done.
Re: RFC 161 (v2) OO Integration/Migration Path
"Randal L. Schwartz" wrote: That's my first gut reaction to this proposal. "If you like Python, you know where to find it, but let us have some primitive data types in Perl that act primitive so we can optimize things." Well, we're on a border here. What this RFC is really referring to is embedded objects, which are wholly different from objects stacked on top of simple variables. If everything uses these methods, then these methods *are* the internal representation of data, meaning there's no slow down with builtin data types. If you add your own class that grabs these methods, you pay when you override one, but you don't when you don't. These messages talk about this concept thoroughly: http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00097.html http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00106.html http://www.mail-archive.com/perl6-language-objects%40perl.org/msg00112.html Perl != Python. Perl != Python. Perl != Python... ;-) -Nate
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
mainstream OO languages go). It looks like Dog could be a type of String
subclass.
That was my first thought as well. Besides, I'd rather type:
my Dog $spot("Spot");
Which says everything that needs to be said without any repetition, and it's
fairly intuitive.
As with the above, the problem you are trying to solve is long type-names
(which is a bazzar thing to find in perl anyway). I just think that there
are better ways of skinning that cat.
I think the main idea here is this: being allowed to say what you mean
without repeating yourself.
Matt
Re: RFC 171 (v1) my Dog $spot should call a constructor implicitly
On Tue, Aug 29, 2000 at 11:04:26PM -0400, Michael Maraist wrote: First greatly stylistic compatibilty. An inexperienced programmer would see: my Dog $spot = "Spot"; And become confused. It's totally unintuitive (at least so far as other mainstream OO languages go). It looks like Dog could be a type of String subclass. Granted, the my Dog $spot = "Spot" example is a little confusing. In this specific example it doesn't make much sense to assign a value in this way. Consider, however, types: my int $i = 4; my float $f = 8.5e10; possibly even (and I'm making syntax up here): my int ($x, $y, $z) = (4, 5, 6); This general syntax is not entirely unseen, consider C: int x = 4; int x = 4, y = 5, z = 6; or C++: string foo = "bar"; The latter being an overload of the assignment operator; any arbitrary value could be there, provided you have an overload that matches it. It's up to the author of the library (or module) to make it make sense. The next most important point is that, up until this point, there has been no enforcement of the constructor name (nor for the $self name). This obviously requires it. Now there have been numerous discussions about RFCs that required such standardization. Some stronger than others. I don't think that this alone is a strong enough case to break backward compatibility (with things like DBI-connect). The constructor name is only forced (if it's not author-controlled) when using the my Dog $spot syntax. my $spot = Dog-new() isn't going anywhere. As with the above, the problem you are trying to solve is long type-names (which is a bazzar thing to find in perl anyway). I just think that there are better ways of skinning that cat. Well, if it were only long type names I'm trying to solve, Doug MacEachern submitted a patch that provides for: my __PACKAGE__ $spot = Animal::Mammal::Canine-new(); to be the equivalent long version. (At least, that's what I think it's supposed to do.) I was going for more elegance and simplicity, especially in the case of specifying types. Perhaps you can suggest some alternatives? :) Michael -- Administrator www.shoebox.net Programmer, System Administrator www.gallanttech.com --
RFC 166 (disambiguator)
Richard Proctor suggests that (?) will match the empty string.
Then it can be inserted into regexes to separate elements that need to
be separated. For example, /$foo(?)bar/ interpolates the value of
$foo and then looks for that pattern followed by 'bar'. You cannot
simply write /$foobar/ because then Perl tries to interpolate $foobar,
which is not what you wanted.
1. You can already write /${foo}bar/ to get what you wanted. This
solution already works inside of double-quoted strings. (?) would
not work inside of double-quoted strings.
2. You can already write /$foo(?:)bar/ to get what you wanted. This
is almost identical to what Richard proposed anyway.
It is really not clear to me that this problem needs to be solved any
better than it is already.
I suggest that this section be removed from the RFC.
Mark-Jason Dominus [EMAIL PROTECTED]
I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: RFC 110 (v3) counting matches
On Mon, 28 Aug 2000, Mark-Jason Dominus wrote:
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)) {
...
}
What I use in a script of mine is:
while ($string =~ /(\d\d)-(\d\d)-(\d\d)/g) {
($mo, $dy, $yr) = ($1, $2, $3);
}
Although this, of course, also requires that you know the number of
backreferences.
The real problem I was trying to discuss was not this particular
application. I was trying to point out a larger problem, which is
that there are several regex features that are enabled or disabled
depending on what context the match is in, so that if you want one
scalar-context feature and one list-context feature at the same time,
there is no direct way to do it.
Nicer would be to be able to assign from @matchdata or something
like that :)
I agree. There are many operations that would be simpler if there was
a magic array that contained ($1, $2, $3, ...). If anyone wants to
write an RFC on this, I will help.
Re: RFC 110 (v2) counting matches
On Tue, 29 Aug 2000 08:47:25 -0400, Mark-Jason Dominus wrote: m/.../Count,Insensitive (instead of m/.../ti) That would escape the problem that we are running out of letters and also the problem that the current letters are hard to remember. Yes, but wouldn't this give us backward compatibility problems? For example, code like $result = m/(.)/Insensitive, ord $1; No, because that is presently a syntax error. The one you have to watch out for is: $result = m/(.)/s,Insensitive, ord $1; And, I don't really see the need for the comma. m/.../CountInsensitive (instead of m/.../ti) I guess, but to me CountInsensitive looks like one option, not two.
Re: RFC 110 (v3) counting matches
On Tue, 29 Aug 2000 08:51:29 -0400, Mark-Jason Dominus wrote:
There are many operations that would be simpler if there was
a magic array that contained ($1, $2, $3, ...). If anyone wants to
write an RFC on this, I will help.
Heh. I once complained about the lack of such an array, in
comp.lang.perl.misc, *years* ago.
My practical problem was something like this, in a translation program.
$phrase is one of many patterns in a table, to look for English phrases,
%translate contains the French translations. interpolate() is a sub that
fills in the parameters -- the numbers in the string):
$_ = "It is 5 past 10."
$phrase = 'it is (\d+) past (\d+)';
s/^$phrase/interpolate($translate{$phrase}, $1, $2)/ie;
The problem is that with variable patterns, you *don't know* how many
paren groups there are.
The solution they came upo with, was @+ and @-. I still can't work with
those. An array of matches, (e.g. @) would be a lot easier. It could
also be a lot slower; see the discussion on $ for this. (mystery: how
can filling in $ be a lot slower than filling in $1?)
--
Bart.
Re: RFC 110 (v2) counting matches
On Tue, 29 Aug 2000 09:00:43 -0400, Mark-Jason Dominus wrote: And, I don't really see the need for the comma. m/.../CountInsensitive (instead of m/.../ti) I guess, but to me CountInsensitive looks like one option, not two. That goes fot this too. : m/.../iCount (instead of m/.../it) -- Bart.
Re: RFC 110 (v3) counting matches
That empty list to force the proper context irks me. How about a
modifier to the RE that forces it (this would solve the "counting matches"
problem too).
$string =~ m{
(\d\d) - (\d\d) - (\d\d)
(?{ push @dates, makedate($1,$2,$3) })
}gxl;
$count = $string =~ m/foo/gl; # always list context
The reason why not is because you're adding a special case hack to
one particular place, rather than promoting a general mechanism
that can be everywhere.
Tell me: which is better and why.
1) A regex switch to specify scalar context, as in a mythical /r:
push(@got, /bar/r)
2) A general mechanism, say for example, "scalar":
push(@got, scalar /bar/)
Obviously the "scalar" is better, because it does not require that
a new switch be learnt, nor is its use restricted to pattern matching.
Furthermore, it's inarguably more mnemonic for the sense of "match this
scalarishly".
Likewise, to force list context (a far less common operation, mind
you), it is a bad idea to have what amounts to a special argument
to just one function to this. What happens to the next function you
want to do this to? How about if I want to force getpwnam() into list
context and get back a scalar result?
$count = getpwnam("tchrist")/l;
$count = getpwnam("tchrist", LIST);
$count = getpwnam("tchrist")-as_list;
All of those, frankly, suck. This is much better:
$count = () = getpwnam("tchrist");
It's better because
* You don't have to invent anything new, whether syntactically
or mnemonically. The sucky solution all require modification
of Perl's very syntax. With the list assignment, you just need
to learn how to use what you *already have*. I could say as
much for (?{...}). Think how many of the suggestions on these
lists can be dealt with simply through using existing features
that the suggesting party was unaware of.
* It's a general mechanism that isn't tailored for this particular
function call. Special-purpose solutions are often inferior
to general-purpose ones, because the latter are more likely to
be creatively usable in a fashion unforeseen by the author.
* What could possibly be more intuitive for the action of acting
as though one were assigning to a list than doing that very
thing itself? Since () is the canonical list (it's empty, after
all), this follows directly and requires on special knowledge
whatsoever.
--tom
Re: RFC 110 (v2) counting matches
If we want to use uppercase, make these unique as well. That gives us many more combinations, and is not necessarily confusing: m//f - fast match m//F - first match m//i - case-insentitive m//I - ignore whitespace And so on. This seems like a much more productive use, otherwise we're just wasting characters. Larry's on record as preferring not to have us going down the road of using distinct upper and lower case regex switches. The distance between //c and //C, say, is far too narrow. --tom
Overlapping RFCs 135 138 164
RFC135: Require explicit m on matches, even with ?? and // as delimiters. C?...? and C/.../ are what makes Perl hard to tokenize. Requiring them to be written Cm?...? and Cm/.../ would solve this. (Nathan Torkington) RFC138: Eliminate =~ operator. Replace EXPR =~ m/.../ with m/.../ EXPR, and similarly for s/// and tr///. Force an explicit dereference when using qr/.../. Disallow the implicit treatment of a string as a regular expression to match against. (Steve Fink) RFC164: Replace =~, !~, m//, and s/// with match() and subst() Several people (including Larry) have expressed a desire to get rid of C=~ and C!~. This RFC proposes a way to replace Cm// and Cs/// with two new builtins, Cmatch() and Csubst(). (Nathan Widger) I would like to see these three RFCs merged into one if this is appropriate. I am calling on the three authors to discuss in private email how this may be done. I hope that the discussion will result in the withdrawal at least two of the three RFCs, and that this private discussion produces a new RFC. The new RFC should discuss the points raised by all three existing RFCs, should investigate several solutions in parallel, and should compare them with one another and contrast the benefits and drawbacks of each one. Mark-Jason Dominus [EMAIL PROTECTED] I am boycotting Amazon. See http://www.plover.com/~mjd/amazon.html for details.
Re: Overlapping RFCs 135 138 164
Mark-Jason Dominus wrote: RFC135: Require explicit m on matches, even with ?? and // as delimiters. This one is along a different line from these two: RFC138: Eliminate =~ operator. RFC164: Replace =~, !~, m//, and s/// with match() and subst() Which I could see unifying. I'd ask people to wait until v2 of RFC 164 comes up. It may well include everything from RFC 138 already. -Nate
Re: RFC 165 (v1) Allow Varibles in tr///
Mark-Jason Dominus wrote: I think the reason this hasn't been done before it because it's *not* quite straightforward. Before everyone gets tunnel vision, let me point out one thing: Accepting variables in tr// makes no sense. It defeats the purpose of tr/// - extremely fast, known transliterations. tr///e is the same as s///g: tr/$foo/$bar/e == s/$foo/$bar/g I don't think this RFC accomplishes anything, personally. -Nate
Re: RFC 110 (v2) counting matches
Mark-Jason Dominus wrote: It occurs to me that since none of the capital letters are taken, we could adopt the convention that a capital letter as a regex modifier will introduce a *word* which continues up to the next comma. Excelsior! -- David Nicol 816.235.1187 [EMAIL PROTECTED] Yum, sidewalk eggs!
Re: RFC 165 (v1) Allow Varibles in tr///
tr///e is the same as s///g: tr/$foo/$bar/e == s/$foo/$bar/g I suggest you read up on tr///, sir. You are completely wrong. --tom
Re: RFC 165 (v1) Allow Varibles in tr///
Tom Christiansen wrote: tr///e is the same as s///g: tr/$foo/$bar/e == s/$foo/$bar/g I suggest you read up on tr///, sir. You are completely wrong. Yep, sorry. I tried to hit cancel and hit send instead. I'll shut up now. -Nate
Re: RFC 110 (v3) counting matches
p.s. Has anybody already suggested that we ought to have a nicer
solution to execute perl code inside a string, replacing "${\(...)}" and
"@{[...]}", which also won't ever win a beauty contest? Oops, wrong
mailing list.
The first one doesn't work, and never did. You want
@{[]} and @{[scalar ]} instead.
"Doesn't work"?
print "The sum of 1 + 2 is ${\(1+2)}.\n";
--
The sum of 1 + 2 is 3.
I'm surprised your wouldn't have known this. The principle is the same:
"${...}" expects a scalar reference inside the block, and '\' provides
one. Of course, there shouldn't be a real multi-element list inside the
parens, but just one scalar. And often, the parens aren't needed.
I'm surprised that you still don't understand. Notice what I showed
you for the replacement above: @{[scalar ]}.
Using ${\(...)} doesn't work in the sense that contrary to popular
belief, it fails to provide a scalar context to the contents of
those parens. Thus ${ \( fn() ) } is still calling fn() in list
context, not scalar context. Witness:
sub fn { sprintf "called in %s context", wantarray ? "list" : "scalar" }
print "Test 1: ";
print "@{ [fn()] }\n";
print "Test 2: ";
print "${ \(fn()) }\n";
print "Test 3: ";
print "@{ [scalar fn()] }\n";
That, when executed, yields:
Test 1: called in list context
Test 2: called in list context
Test 3: called in scalar context
*That's* why test 2 "doesn't work".
--tom
Re: Overlapping RFCs 135 138 164
($foo = $bar) =~ s/x/y/; will never make much sense to me. What about these, which are much the same thing in that they all use the lvaluability of assignment: chomp($line = STDIN); ($foo = $bar) += 10; ($foo += 3) *= 2; func($diddle_me = $protect_me); $n = select($rout=$rin, $wout=$win, $eout=$ein, 2.5); --tom
Re: Overlapping RFCs 135 138 164
What about these, which are much the same thing in that they all
use the lvaluability of assignment:
And don't forget:
for (@new = @old) { s/foo/bar/ }
--tom
RFC 170 (v1) Generalize =~ to a special-purpose assignment operator
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Generalize =~ to a special-purpose assignment operator
=head1 VERSION
Maintainer: Nathan Wiger [EMAIL PROTECTED]
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 170
Status: Developing
Requires: RFC 164
=head1 ABSTRACT
Currently, C=~ is only available for use in specific builtin pattern
matches. This is too bad, because it's really a neat operator.
This RFC proposes a simple way to make it more general-purpose.
=head1 DESCRIPTION
First off, this assumes RFC 164. Second, it requires you drop any
knowledge of how C=~ currently works. Finally, it runs directly
counter to RFC 139, which proposes another application for C=~.
This RFC proposes a simple use for C=~: as a last-argument rvalue
duplicator. What this means is that an expression such as this:
$value = dostuff($arg1, $arg2, $value);
Could now be rewritten as:
$value =~ dostuff($arg1, $arg2);
And C$value would be implicitly transferred over to the right side as
the last argument. It's simple, but it makes what is being operated on
very obvious.
This enables us to rewrite the following constructs:
($name) = split /\s+/, $name;
$string = quotemeta($string);
@array = reverse @array;
@vals = sort { $a = $b } @vals;
$string = s/\s+/SPACE/, $string;# RFC 164
$matches = m/\w+/, $string; # RFC 164
@strs = s/foo/bar/gi, @strs;# RFC 164
As the shorter and more readable:
($name) =~ split /\s+/;
$string =~ quotemeta;
@array =~ reverse;
@vals =~ sort { $a = $b };
$string =~ s/\s+/SPACE/;# looks familiar
$string =~ m/\w+/; # this too [1]
@strs =~ s/foo/bar/gi; # cool extension
It's a simple solution, true, but it has a good amount of flexibility
and brevity. It could also be the case that multiple values could be
called and returned, so that:
($name, $email) = special_parsing($name, $email);
Becomes:
($name, $email) =~ special_parsing;
Again, it's simple, but seems to have useful applications.
=head1 IMPLEMENTATION
Simplistic (hopefully).
=head1 MIGRATION
This introduces new functionality, which allows backwards compatibility
for regular expressions. As such, it should require no special
translation of code. This RFC assumes RFC 164 will be adopted (which it
may not be) for changes to regular expressions.
True void contexts may also render some parts of this moot, in which
case coming up with a more advanced use for C=~ may be desirable.
=head1 NOTES
[1] That m// one doesn't quite work right, but that's a special case
that I would suggest should be caught by some other part of the grammar
to maintain backwards compatability (like bare //).
=head1 REFERENCES
RFC 164: Replace =~, !~, m//, and s/// with match() and subst()
RFC 139: Allow Calling Any Function With A Syntax Like s///
Re: RFC 64 (v2) New pragma 'scope' to change Perl's default scoping
$x and $y are in the same scope. This is good, but also bad. For one
thing, you can hang yourself real easily if you come from a C background
and expect this to keep stuff private:
$x = 10;
sub square {
($x) = @_;
$x *= $x;
}
$ans = square($x);
print "$x squared is $ans\n"; # "100 squared is 100" ?
Ooops. What happened? Turns out the sub square()'s $x is the same $x as
the one outside. Bad news, you reset the (global) value of $x. Ooops.
Perhaps you simply know inept C programmers. In C, something that
isn't declared auto or static is going to be global. Seeing no
scoping declarations, the C programmer who knows C will come to the
same conclusion as the Perl programmer, correctly understanding the
scope.
--tom
Re: RFC 64 (v2) New pragma 'scope' to change Perl's default scoping
Tom Christiansen wrote: Perhaps you simply know inept C programmers. Is there any other kind? ;-) *Kidding*! In C, something that isn't declared auto or static is going to be global. Seeing no scoping declarations, the C programmer who knows C will come to the same conclusion as the Perl programmer, correctly understanding the scope. You're right. That's why I froze the RFC, said "this may be cool", and left it at that. It has limited applications for the extremely Lazy (me). If it never makes it into Perl, I'll hardly be heartbroken... -Nate
Re: New match and subst replacements for =~ and !~ (was Re: RFC 135 (v2) Require explicit m on matches, even with ?? and // as delimiters.)
On Mon, 28 Aug 2000 20:26:41 -0700, Nathan Wiger wrote:
foreach (@str) { print "Got it" if match /\w+/, @str;
if (/\w+/) { $gotit = 1 };
}
print "Got it" if $gotit;
Now if DWIM just worked for email as well... ;-)
You mean, like grep?
print "Got it" if grep /\w+/, @str;
This one *currently works*. No need for a new feature.
--
Bart.
Re: RFC 147 (v2) Split Scalars and Objects/References into Two Types
Nathan Wigner, disguised as Perl6 RFC Librarian [EMAIL PROTECTED] writes:
[...]
Gut feeling, I don't like this proposal. Examples coming up.
Increases in namespace are basically always beneficial.
=head2 Potential Problems
This approach is not without its problems. These need to be carefully
addressed before this can be implemented.
=head3 Iterating through a mixed array
[ Examples given, with the suggestion that
for (@mixed_array) { ... }
sets $_ or *_ as appropriate and three different suggestions about
what to do when you have a named variable ]
None of the examples given addresses polymorphism.
for (@stringlike_things) # Strings or objects that stringify
{
print;
}
Under the proposal this becomes
for (@stringlike_things)
{
print defined $_ ? $_ : *_
}
Which is ugly. And which gets more ugly the more one thinks about it.
Consider:
sub mess_with_string ($) {
...
}
for (@stringlike_things) {
mess_with_string($_ || *_);
}
Given that you are also the author of the polymorphism RFC I'd hope to
see this addressed in the next version of this RFC.
Differentiating scalars and references gives us many key advantages:
1. Ability to differentiate types in all contexts
But sometimes I don't *want* to differentiate types.
2. More compact, readable, and flexible syntax
For flexible values of compact and readable.
3. Leftmost $ tells true context
4. Implicit type checking
But not necessarily *useful* type checking.
5. Better cognitive properties
Depends on your definition of 'better'.
6. Increased namespace
Hmm... I'm not sure that the Highlander Variable folks would agree
with you. And the thought of this RFC combined with Highlander
variables is just too scary to contemplate.
[1] The "single" part isn't true, either, since $arrayrefs and $hashrefs
in fact point to multiple values. Some will counter with the idea that
$arrayrefs and $hashrefs actually point to "single" arrays and hashes.
However, this is a stretch in the author's opinion.
Not even vaguely a stretch. One has *a* collection of *some* things.
Such arcane languages as English support this distinction trivially.
=head1 MIGRATION
The p52p6 translator would have to convert all Perl 5 reference and
object notations into the new Perl 6 syntax. This is not actually as
hard as it sounds since a few regexp's would do the trick for
references. Objects are trickier and would require some backtracking
through the code.
Hmm... that's one enormous handwave.
--
Piers
no autovivify?
dear all,
today this just came up to my mind, we could have a pragma that disable
`autovivification' of hash and array keys. Consider the follow code snippet:
@arr = ( 0..9 );
%hash = ( a=1, b=2 );
{
no autovivify;
$arr{10}++; # both are
$hash{c}--; # fatal
}
this way we can eliminate the need to tie any variables to special classes
and catch invalid accesses.
if this already been discussed before, feel free to blame me and (kindly)
point me to the relevant threads.
please criticize if there's anything wrong with this.
regards,
kenneth
Re: RFC 162 (v1) Filtering Here Docs
On 27 Aug 2000, Perl6 RFC Librarian wrote: With a here doc print ZZZ; the here doc, is processed verbatum. ITYM "verbatim". Cheers, Philip -- Philip Newton [EMAIL PROTECTED]
Re: Multiple for loop variables
On Tue, Aug 29, 2000 at 09:21:32AM -0400, Eric Roode wrote: I'm not seeing an earth-shattering advantage of: for my($k,$v) (%hash) over while(my($k,$v) = each %hash) AFAICT, they act the same, just look a little different. Eight characters difference, counting whitespace. What's the "earth-shattering advantage" of "=" over ","? Answer: there isn't one. A common task was just made easier through a simple addition to syntax. Why not the same for loops? People keep proposing bells, whistles, antennae, and tentacles for the "for" statement, and I haven't seen one yet that had seemed justified to me. What's "justified"? It sounds like you're arguing "we already have a way to do it, let's not make another" even if the other way makes it *easier* to do the thing. Remember, Perl's motto is TMTOWTDI and that's not by accident. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Do we really need eq?
At 12:57 PM 8/29/00 -0500, David L. Nicol wrote: I'd like to see every number bundled with a "precision" attribute. It's a holdover from when I was heavily into chemistry. Some of the other RFCs on the list also appear to have been triggered the same way. Oh, wait... :-) -- Peter Scott Pacific Systems Design Technologies
Re: Multiple for loop variables
Exactly. We need a nondestructive slice. Some short piece of
syntax which expands
for [my](list of vars) (big list){ ... }
to
my @uniquelynamedcopy = (big list);
while ( [my](list of vars) = splice(@u15y,0,(length of list of vars))){ ... }
I think the absence of a comma btn the two lists would
be enough to tip Cfor off that it is this kind of situation,
since currently
for ($a) (split //) {
is a syntax error
Eric Roode wrote:
Peter Scott wrote:
Graham Barr once allowed as how he thought it would be neat if you could say
for my($x, $y, $z) (@list) { ... }
ObLanguageMinimalist:
Um. Is this so frequently-used that the above syntax is preferable to:
while ( ($x, $y, $z) = splice (@list, 0, 3) ) {...}
? (notwithstanding the destructive nature of splice)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Yum, sidewalk eggs!
RE: Do we really need eq?
I'd like to see every number bundled with a "precision" attribute.
That's not what I call a high-level language feature. People don't
want to think about that, nor about machine-level precision issues.
See REXX.
In fact, I'd rather to see a painless and transparent int-float-bignum
autoconversion happen, the way currently we (theoretically) see the
int-float one occur.
In some of the OO stuff people (me included) wanted to see simple scalars be
able to act "like" objects. Others have talked about allowing for strong
typing. I was wondering about maybe being able to store these attributes as
optional parts of the scalar. Something like this (please don't get hung up
on the details, I am not much of a designer):
my($amt,$hours,$total);
$amt-{TYPE} = "DOLLARS";
$total-{TYPE} = "DOLLARS";
$hours-{TYPE} = "INTEGER";
$total-{PICTURE} = "$zzz,zz0.00"; # seen any COBOL in Perl, can't
remember the Perl equiv?
#
$total = $amt * $hours;
# for strict type checking
$total-{ASREAL} = $amt-{ASREAL} * $hours-{ASREAL};
does the concept make any sense (God help the example)? The idea being that
when strong type checking is turned on the first multiplication example
would flag a warning.
Re: Do we really need eq?
On Tue, 29 Aug 2000, David L. Nicol wrote: I'd like to see every number bundled with a "precision" attribute. While that might be useful for simple calculations, I expect it would simply get in the way and slow things down for larger, more complex calculations. Alas I don't think there's any shortcut for actual analysis of the underlying data and algorithms. Andy Dougherty [EMAIL PROTECTED]
Re: Beefier prototypes (was Re: Multiple for loop variables)
Jonathan Scott Duff wrote:
I'm wondering how we get both
for ($x,$y,$z) (@array) { ... }
and
for ($x,$y,$z) (@array1,@array2,@array3) { ... }
That's an -internals issue. Suffice it (here) to say that
the parser could be made to handle it. In fact, to the parser,
it's all the same. At least if Cfor has the proper prototype.
But as for the semantics... how does perl handle this:
for ($x,$y,$z) (@a1,@a2) { ... }
and
for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
Making the case where the number of iterators == the number of arrays
special may not be so good. Not to mention
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
The square bracket syntax is alluring since it implies referenceness,
but it goes the wrong way; squares enreference rather than dereference.
No; you can dereference on the inside, as you propose, or enreference
on the outside, as I propose.
for [ $a, $b, $c ] ( @things ) {
print "They are: $a, $b, $c\n";
}
The idea is to get pass them en bloc to Cfor(), which will then
set them up as iterators appropriately.
--
John Porter
We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
At 02:57 PM 8/29/00 -0400, John Porter wrote:
But as for the semantics... how does perl handle this:
for ($x,$y,$z) (@a1,@a2) { ... }
and
for ($x,$y,$z) (@a1,@a2,@a3,@a4) { ... }
Making the case where the number of iterators == the number of arrays
special may not be so good. Not to mention
for ($x,$y,$z) (@a1,@a2,4..12,@a4) { ... }
Probably we'll have to say that the user must explicitly zip if that
is what is desired.
Yes, please. I view the flattening of lists as a feature, not a bug, and
it has made Perl a lot easier to understand IMHO.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 122 (v1) types and structures
Chaim Frenkel wrote:
We should be able to represent
any packed structure. We should be able to handle anything that an
pack/unpack format can currently handle.
...
The raw structures could be passed between perl and the XS unchanged.
the COBOL redefines capabilities.
...a method of saying
that there are two descriptive overlays of the same memory area
would be nice.
I agree 100%. Besides stealing at least some of COBOL's data
representation power, we should also support recursive data structures,
as in some functional languages. E.g. (pseudocode):
define foo as {
short a;
foo b; # exists at first only "in potential".
long c;
};
--
John Porter
We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
Peter Scott wrote: Yes, please. I view the flattening of lists as a feature, not a bug, and it has made Perl a lot easier to understand IMHO. So... is an RFC forthcoming? Or shall I? -- John Porter We're building the house of the future together.
Re: Do we really need eq?
At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote: On Tue, 29 Aug 2000, David L. Nicol wrote: I'd like to see every number bundled with a "precision" attribute. While that might be useful for simple calculations, I expect it would simply get in the way and slow things down for larger, more complex calculations. It'd also tend to freak people out when this: my $foo : sig_figs(1) = 2; print 3.1415926 * $foo; printed out 6. You think we have bug reports from floating point issues now... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! Ah, the old "If you want Tcl, you know where to find it" non-argument. "Closures?""No! This is Perl, not Lisp!" "Objects?" "No! This is Perl, not Smalltalk!" "Patterns?""No! This is Perl, not Snobol!" "Subroutines?" "No! This is Perl, not Basic!" "Upvars?" "No, and for the following well-understood technical reasons..." -- John Porter
Re: Multiple for loop variables
Graham Barr wrote:
Also it hash been
suggested that it could potentially replace each
for my($k,$v) (%hash) { ... }
Continuing my crusade for beefier prototypes, I can easily envision this:
for(\$\$\%);
callable as
for ($k,$v) %h { }
--
John Porter
We're building the house of the future together.
Python proposals
It's probably worth reading through the Python Enhancement Proposals (PEPs) to see if there's anything that makes sense to steal: http://python.sourceforge.net/peps/ Nat
Re: Tainted precision
Dan Sugalski wrote: At 02:49 PM 8/29/00 -0400, Andy Dougherty wrote: On Tue, 29 Aug 2000, David L. Nicol wrote: I'd like to see every number bundled with a "precision" attribute. While that might be useful for simple calculations, I expect it would simply get in the way and slow things down for larger, more complex calculations. It'd also tend to freak people out when this: [...] printed out 6. You think we have bug reports from floating point issues now... Okay, brainstorming here ... bear with me. What if limit-of-error precision were tracked, as Perl tracks tainted variables when you tell it to? It'd have to be more than a single bit, which I believe is all that's stored for taintedness. Instead of Perl horning in on your calculations, as in Dan's example above, you'd have the ability to query the precision of results. $one = 25; # Integer. Infinite precision. Or at least, 32 bits. $two = $one/7; # Float. Precision is reduced to your mantissa. $thr = $two * $two; # Still less precision. I don't know the math. print $thr; # Prints 12.7551020408163 print precision ($thr); # Tells you how much to trust $thr Perhaps it would be a read/write value, so you could tell it that a raw number had only so many bits of precision. $four = 74.5; precision($four) = 7; # Only 7 mantissa bits of accuracy here. This would be a feature, like taint, that would only be turned on when the programmer explicitly asked for it, as I expect it would slow things down somewhat, and would not be used by many people. Mostly scientific and maybe financial people, I'd think. use precision; # maybe? Disclaimer: I failed limit-of-error analysis in college :-) -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: Tainted precision
At 03:46 PM 8/29/00 -0400, Eric Roode wrote: Okay, brainstorming here ... bear with me. What if limit-of-error precision were tracked, as Perl tracks tainted variables when you tell it to? Can't be done that way, unfortunately. You need to enforce significant digits at every step of the calculation you make, or you can end up with insignificant digits altering the results. This would be a feature, like taint, that would only be turned on when the programmer explicitly asked for it, as I expect it would slow things down somewhat, and would not be used by many people. Mostly scientific and maybe financial people, I'd think. Significant digits are really only used when there's some slop in the numbers, usually when they're derived from measurements. Financial calcs, for example, don't suffer from that problem. They, instead, need good fixed-point math, which has its own problems. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC 157 (v1) Delete Cdbmopen and Cdbmclose commands.
Lightning flashed, thunder crashed and Michael G Schwern [EMAIL PROTECTED] wh ispered: | On Thu, Aug 24, 2000 at 08:29:21PM -, Perl6 RFC Librarian wrote: | The Cdbmopen and Cdbmclose commands are legacy commands which have been | deprecated for at least 5 years. They should be removed from the language. | | Two nit picks. | | First, dbmopen() isn't deprecated. | | [This function has been largely superseded by the tie() function.] | --perlfunc | | Deprecated, no. Redundant, yes. And Perl has *never* had two ways to | do things. ;) Deprecated, superseded, obsolete, whatever... it all comes down to the same thing. There is a better way to do it. This function is actually just a call to tue with the proper arguments, but is provided for backwards compatibility with older versions of Perl. -Camel II Functions obsoleted in perl5 dbmclose, dbmopen -perlfunc | Secondly, I still use dbmopen(). I find it a much simpler interface | than AnyDBM_File when I just need any ol' disk hash. | | Compare: | | dbmopen(%foo, 'somefile', 0644); | | with: | | use AnyDBM_File; | use Fcntl; | | tie %hash, 'AnyDBM_File', 'somefile', O_RDWR|O_CREAT, 0644; | | dbmopen()'s interface is much shorter and its much, much easier to | understand. Try explaining O_RDWR|O_CREAT to a newbie. People have | enough trouble with 0644. Don't try to explain that to a newbie. Let them learn it on their own. There are plenty of examples that just use tie %hash, 'AnyDBM_File', 'somefile', 1, 0 that never explain what 1, 0 are for. I also seem to remember an RFC to make "tie %blah 'DB'" automatically do a "use DB". | Now, this doesn't mean dbmopen() has to remain as a builtin. It could | be written as a pure Perl wrapper around tie() and AnyDBM_File. But | keep it somewhere. Its useful and its not bothering anyone. Keep it in a DB.pm module, if you want. There's no need to keep it in the core binary. I'd much rather teach people use DB; dbmopen ...; -spp
Re: implied pascal-like with or express
"David L. Nicol" wrote: Ken Fox wrote: IMHO, curries have nothing to do with this. All "with" really does is create a dynamic scope from the contents of the hash and evaluate its block in that scope. ... But that doesn't give us the speed win we want from compiling offset lookups into a static record structure, at the cost of some funny "in -the-record" syntax, as in other languages that support this (pascal, VB, C) The hash keys (symbol lookups) could be pre-computed. Unless you are proposing something really radical, like replacing blessed hashes with fixed-size structs, that's the best you can do. IMHO, the "with" proposal should not assume other RFC proposals. It will be obvious to optimize "with" if, for example, strong types are available. - Ken
Re: Multiple for loop variables
Eric Roode wrote:
Also the ability to traverse multiple lists at once
for ($a,$b,$c) (zip(@a,@b,@c)) { ... }
I don't get it. This is a great advantage over:
@looparray = zip(@a,@b,@c);
while ( ($a,$b,$c) = splice (@looparray, 0, 3))
?
Because splice() is destructive, the 1st of your 2 lines would have to do a
full copy (otherwise based on the zip() RFC it would be lazily evaluated
without a copy). Doing a full copy would destroy the efficiency of such an
algorithm.
I'm thinking that if I were implementing such a loop, I'd probably
have set up my data structures so that instead of three arrays, I'd
have one array of three hash elements, and iterate over it:
for $iter (@data)
{
foo ($iter-{a}, $iter-{b}, $iter-{c});
}
I wouldn't have thought this would be a good idea. The for (...) zip(...)
construct may be used to transpose a matrix stored as an array, or maybe the
lists are slices of other lists. It's the kind of construct one would see in
numeric programming all the time. Using a hash would both destroy the
efficiency of the program, and would also make other transposes, slices,
diagonals, etc very unwieldy.
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: Well, as I mentioned in another recent parallel thread, if Cfor is to be properly functionalized, Whoa -- why? Syntax keywords (eg if, unless) certainly need not be expressible as functions.This isn't tcl! Ah, the old "If you want Tcl, you know where to find it" non-argument. "Closures?""No! This is Perl, not Lisp!" "Objects?" "No! This is Perl, not Smalltalk!" "Patterns?""No! This is Perl, not Snobol!" "Subroutines?" "No! This is Perl, not Basic!" Fine. Explain why it is that a syntactic keyword governing normal flow of control, such as for, foreach, if, while, return, next, etc., should have the properties of a function. For example, Why should it be referenceable, as in \CORE::if? What does dereferencing it mean? How can the compiler do what the compiler has to do if you hide it? Why should it have a prototype? What are you going to do with that prototype? Why should it be overridable? What are you planning to to with it? What are you going to do about things like if/elsif/elsif/.../else? I see nothing broken. Yet. --tom
switch s/statement/operator/
went through the archives about RFC22 "builtin switch statement".
didn't see any mention of this, thought I'd throw it in there to see
how it was recieved.
I was thinking that the switch statement could possibly be expanded
to also behave as an operator and not just a control statement.
i.e. the way the trinary conditional operator works:
my $final = $boolean ? $this_value_if_true : $else_this_value;
except you could do a case operator:
my $final = switch ( $val ) {
case 0 { $zero_val;}
case 1 { $one_val;}
case 2 { $two_val;}
case 3 { $three_val;}
};
why?
because the Verilog language has the same limitation
(a conditional operator but only a case statement)
and suggestions to the next version of Verilog
include adding a case operator.
thought maybe perl could learn from that mistake
before it actually ships.
also, while I'm at it, just how difficult would it be
to add the conditional operator to the operators
that can be overloaded by "use overload;" ???
(and the case operator if that were to exist)
Greg London
Re: switch s/statement/operator/
I was thinking that the switch statement could possibly be expanded to also behave as an operator and not just a control statement. I had considered this, but didn't put this in because no other Perl control statements return a value. Personally, I like the notion a great deal. What the heck, I'll add it to the next iteration of the RFC. :-) Damian
Re: RFC 122 (v1) types and structures
John Porter wrote:
we should also support recursive data structures,
as in some functional languages. E.g. (pseudocode):
define foo as {
short a;
foo b; # exists at first only "in potential".
long c;
};
how deep would it go? C allows you to have
struct foo {
short a;
foo *b;
long c;
};
because all pointers are the same size. I suppose these functional
languages hide the implementation, allowing vivication and automatic
dereferencing of the enclosed type as needed, transparently to the
programmer.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
Yum, sidewalk eggs!
Re: Pre-RFC: Require a warning on spaces after here-document terminator
"LW" == Larry Wall [EMAIL PROTECTED] writes: LW : This can be very hard to discover. I find it hard to see myself doing LW : this on purpose. I would like to see a compiler warning for this: LW : "Spaces detected after apparent here document terminator", but LW : preferably phrased better. LW : LW : Are there any objections? LW I object, vaguely. I think it should just Do The Right Thing. LW (I suspect it should ignore spaces on the left to.) This was suggested a while back in p5p. But it was shot down. I can't remember the reason offered. (Speed?) I can see a possible issue print EOF;# or 'EOF' The following is not the end EOF But this one is EOF Though I don't really see a very good use for having trailing invisible characters. chaim -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Extended Regexs
* Using an array of "words" as an alternate list as part of a regex
/match any of (${\join'|',@list}) here/
NT $" = "|"; /@list/ # snicker
Certainly I've written
if (do { local $" = "|"; $var =~ /@any/}) { blah() }
before.
--tom
Re: RFC 33 (v2) Eliminate bareword filehandles.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore? Heck, some people
still use stdin and stdout! :-)
=head1 ABSTRACT
Now that scalars (objects) can be used for filehandles, the bareword form
should be eliminated.
If true, doesn't that argument hold true for functions, too? If
all non-method functions were stored in only in variables, I guarantee
you that it would be rather harder to call a non-method function
as though it were a method.
=head1 DESCRIPTION
The venerable bareword form of the filehandle leads to code that is
unnecessarily abstruse given that they can now be stored in
scalars. Bareword filehandles are not lexical, and require the use of
typeglobs and Clocal to pass them to subroutines, concepts unnecessarily
advanced for such a beginner-type operation.
It does?
sub p {
my $fh = shift;
print $fh "got it\n";
}
p(STDOUT);
Of course, that's a bit dicey because STDOUT is omniglobal. You
could pass it as
p(*FH);
instead, and the function's definition doesn't change. What I tell
people is that if they want, they can just pretend, even though
it's not quite true, that * is the type symbol for a filehandle
at least when it comes to passing it or storing in somewhere.
This works out quite well.
Of course, with prototypes, even this is unneeded:
sub p(*) {
my $fh = shift;
print $fh "got it\n";
}
p(FH);
Filehandles really aren't that spooky anymore.
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
A simple unsubscripted scalar can virtually always be used to hold
a potentially package-qualified subroutine name, filehandle name,
a directory handle name, or a format handle name, and that scalar
used in lieu of those names (if unqualified, they're usually
package-relative, of course). These are called "indirect function calls"
or "indirect filehandles", etc. You can even do it with a method name, to
invoke an indirected method call (well, if you use the arrow syntax).
Indirections seem kind of nice.
--tom
Re: RFC 33 (v2) Eliminate bareword filehandles.
At 06:17 PM 8/29/00 -0600, Tom Christiansen wrote:
Eliminate bareword filehandles.
"Eliminate" is such a strong word. You're saying that we can't
use STDIN, STDOUT, STDERR, ARGV, or DATA anymore?
There are some people I would like to stop using output filehandles, yes :-)
Heck, some people
still use stdin and stdout! :-)
The RFC is absent a necessary discussion of what to do with the global
filehandles. Some people have already suggested renaming them; RFC 30
takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
issue of $ARGV which already has a meaning :-( If we can solve that one
then I'd just make all those filehandles scalars. Backwards compatability
hit but worth it in simplification IMHO. I recall an earlier discussion
about the $ prefix meaning a singular whatzit... as a filehandle clearly is...
Any ideas on what to do with the existing $ARGV if it became the
filehandle? Can it be one of those magical things that knows when it's
being used as a filehandle and Do The Right Thing?
=head1 ABSTRACT
Now that scalars (objects) can be used for filehandles, the bareword form
should be eliminated.
If true, doesn't that argument hold true for functions, too?
That wasn't the entirety of my argument :-) It's not a sufficient reason
per se.
If
all non-method functions were stored in only in variables, I guarantee
you that it would be rather harder to call a non-method function
as though it were a method.
=head1 DESCRIPTION
The venerable bareword form of the filehandle leads to code that is
unnecessarily abstruse given that they can now be stored in
scalars. Bareword filehandles are not lexical, and require the use of
typeglobs and Clocal to pass them to subroutines, concepts unnecessarily
advanced for such a beginner-type operation.
It does?
sub p {
my $fh = shift;
print $fh "got it\n";
}
p(STDOUT);
Of course, that's a bit dicey because STDOUT is omniglobal. You
could pass it as
p(*FH);
instead, and the function's definition doesn't change. What I tell
people is that if they want, they can just pretend, even though
it's not quite true, that * is the type symbol for a filehandle
at least when it comes to passing it or storing in somewhere.
This works out quite well.
This is true; but won't it make even more sense, and less pretense, just to
pass filehandles around in scalars?
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 33 (v2) Eliminate bareword filehandles.
sub getfh {
return open(my $fh, "+ /dev/null") $fh;
}
Aha! You fell for one of my pet pieves. You tried to return a lexical in
the same expression were it was declared. That doesn't work. It's not
the same variable. Running it with warnings enabled says:
Grr..
Name "main::fh" used only once: possible typo at test.pl line 3.
I feel that this ought to have worked, i.e. that the scope of the
lexical kicked in in the middle of the expression, at the transition
over the shortcut operator "".
Except that then you can't say
local $x = $x;
or
my $x = $x;
--tom
Re: RFC 168 (v1) Built-in functions should be functions
One function that takes an optional leading commaless arg: sub print(handle? $FH, @) or Two functions differentiated by their prototypes sub print(@); sub print(handle,@); I'm always forgetting the comma after the handlename in Copen statements because I learned "no comma after file handle names" for Cprint We could rectify this situation by giving Copen the same header.
Re: RFC 168 (v1) Built-in functions should be functions
I intend to extend the parameter lists RFC to cover optional (non-tailing) arguments. Will this include having typed variadic functions, allowing you, for example, to say something like This function takes any number of arrays, all passed by reference. I keep thinking of a * or a ... to say "repeat the previous thing", but that's stepping on other toes. Personally, I would like to see the indirect object syntax removed in all contexts, inclusing this one, and filehandles simply passed as a first argument. I don't know what's happening with indirect objects, but the nastiness whereby you can only use unsubscripted scalars is quite the crock. You know, where you can say print $fh "stuff\n"; and $fh But are not (well, in the second you can, but it's wrong) able to say print $fh[$i] "stuff\n"; and $fh[$i] Definitely worth a clean-up--at the least. --tom
Re: RFC 168 (v1) Built-in functions should be functions
Basically, it "fixes" the indirect notation by making all of these Do The Right Thing: $r = new CGI (@args); # CGI-new(@args) $r = new(CGI, @args); # CGI-new(@args) $r = new(CGI @args); # CGI-new(@args) It's all in the details (I'm sure you see the edge cases already, but they're addressed), so I invite people to read it. I posted it to -subs. That's hardly the problem with indirect object syntax. Besides what I just mentioned, there is the fact that it's acting in a fashion that you could call stronger than a unary operator in terms of precedence. --tom
Re: RFC 168 (v1) Built-in functions should be functions
I intend to extend the parameter lists RFC to cover optional (non-trailing) arguments. Will this include having typed variadic functions, allowing you, for example, to say something like This function takes any number of arrays, all passed by reference. I keep thinking of a * or a ... to say "repeat the previous thing", but that's stepping on other toes. Yes, I'll definitely be including that facility. Personally, I would like to see the indirect object syntax removed in all contexts, including this one, and filehandles simply passed as a first argument. I don't know what's happening with indirect objects, but the nastiness whereby you can only use unsubscripted scalars is quite the crock. Definitely worth a clean-up--at the least. At least. Damian
Re: RFC 168 (v1) Built-in functions should be functions
Tom Christiansen wrote: That's hardly the problem with indirect object syntax. Besides what I just mentioned, there is the fact that it's acting in a fashion that you could call stronger than a unary operator in terms of precedence. This is also mentioned in the RFC, although probably not clearly enough. I also wasn't claiming to fix *the* problem, just *a* problem. If you read the RFC, I think you'll see this opens doors to a lot of benefits. It probably has to be fleshed out considerably, but I'm sure the people on -subs will definitely be able to help there. -Nate
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
$r-{{qw(a b c d e f g h)}}
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
$r-{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
Except in the case where you don't have the list until run-time. I made a
class once that emulated the hierarchical structure of a filesystem using a
deep hash of hashes. It had an accessor something like:
$obj-file(qw(usr local bin gpg));
or
$obj-file("/usr/local/bin/gpg"); # which would get split
(I'm paraphrasing and changing syntax, because I don't actually recall the
actual syntax I came up with.)
The accessor would traverse down the internal hash of hashes to retrieve the
information about /usr/local/bin/gpg. With current syntax this is rather
awkward, resulting in code something along the lines of:
my $cur = $hoh;
foreach my $file (@_) {
if (exists $$cur{$file}) {
$cur = $$cur{$file};
} else {
# error
}
}
So the syntax would be useful; I'm not sure how useful, such deeply nested
hashes requiring run-time key lookup like that are a rarity. The array
syntax would also be useful in multi-dimensional arrays.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
Re: RFC 177 (v1) A Natural Syntax Extension For Chained References
On Tue, Aug 29, 2000 at 07:27:15PM -0700, Peter Scott wrote:
$r-{{qw(a b c d e f g h)}}
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
$r-{a}{b}{c}{d}{e}{f}{g}{h}
which is only one character longer than the proposal...
Except in the case where you don't have the list until run-time.
snip
So the syntax would be useful; I'm not sure how useful, such deeply nested
hashes requiring run-time key lookup like that are a rarity. The array
syntax would also be useful in multi-dimensional arrays.
That is if multi-dimensional arrays are implemented as lists-of-lists,
which they might not be.
On language-data a counter-proposal to my RFC169 has been made,
suggesting the use of array/list references for multidimensional
indices. In the simplest case, assuming list-of-list implementation,
$a[[1,2,3]] would be the same under both proposals (unless this
proposal would require $a[[(1,2,3)]], which is too much syntax for my
taste). But the list-ref idea would also allow @a[$point1,$point2] as
a slice of two elements of the matrix @a, each point being a reference
to a 4-element list of integers.
Michael
--
Administrator www.shoebox.net
Programmer, System Administrator www.gallanttech.com
--
--
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
ARGV vs $ARGV (was Re: RFC 33 (v2) Eliminate bareword filehandles.)
Peter Scott wrote:
Some people have already suggested renaming them; RFC 30
takes the obvious step of making $STDIN, $STDOUT, $STDERR but sidesteps the
issue of $ARGV which already has a meaning :-( If we can solve that one
then I'd just make all those filehandles scalars.
I've been thinking about this all night, and then it dawned on me that
this isn't actually a problem at all. According to RFC 14, all
fileobjects will have a -filename attribute, and moreover this
-filename attribute will also be -STRING, meaning that a fileobject
will morph into the filename it was opened on when in a string context.
This means that $ARGV will be both the filehandle *and* the name of the
file, depending on context:
while ($ARGV) {# used as fileobject
next if ($ARGV eq $lastfile) # -STRING, both are filenames
print "Now reading $ARGV";# $ARGV-STRING, filename
dostuff($_);
$lastfile = $ARGV;# copies object, but that's ok
#$lastfile = "$ARGV"; # speed-concerned folks could do
this
}
A glimpse of how polymorphic objects can be used practically,
methinks...
I don't think this needs an RFC of its own (just counted, I'm up to 23
RFCs and 2 sublists, so a little overworked :), but if everyone is in
agreement, I'll add it to the bottom of RFC 30 as a "By the way...".
-Nate
P.S. Further discussion should really be on -io, so if you reply please
change the sublist. Thanks.
RFC 33 (v2) Eliminate bareword filehandles.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Eliminate bareword filehandles. =head1 VERSION Maintainer: Peter Scott [EMAIL PROTECTED] Date: 4 Aug 2000 Last Modified: 29 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Status: Frozen Number: 33 =head1 ABSTRACT Now that scalars (objects) can be used for filehandles, the bareword form should be eliminated. =head1 DESCRIPTION The venerable bareword form of the filehandle leads to code that is unnecessarily abstruse given that they can now be stored in scalars. Bareword filehandles are not lexical, and require the use of typeglobs and Clocal to pass them to subroutines, concepts unnecessarily advanced for such a beginner-type operation. =head1 IMPLEMENTATION Easy, hopefully. =head1 REFERENCES Lperlvar/"Typeglobs and Filehandles"
RFC 45 (v3) C|| and C should propagate result context to both sides
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE C|| and C should propagate result context to both sides =head1 VERSION Maintainer: Peter Scott [EMAIL PROTECTED] Date: 5 Aug 2000 Last-Modified: 29 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 3 Number: 45 Status: Frozen =head1 ABSTRACT Currently the expressions lvalue = expr_A || expr_B lvalue = expr_A expr_B evaluate Cexpr_A in scalar context, regardless of the type of Clvalue, only propagating list or scalar context to Cexpr_B. This proposal is that the context of Clvalue should be propagated to Cexpr_A as well. =head1 DESCRIPTION It would be nice to be able to say @a = @b || @c instead of having to resort to @a = @b ? @b : @c The reason that it is not currently possible is that C@b (or the list expression in its place) has to be evaluated in scalar context to determine whether to evaluate C@c, and that propagating context to C@b would require reevaluating it, which might have undesirable side effects (instead of C@b, it might be Cdecrement_balance()). Tom Christiansen pointed out that for consistency, both C|| and C need to be changed, since in the latter case, if C@b is empty, then C@a will currently get the single element 0. We want it to get an empty list. =head1 IMPLEMENTATION It seems that it ought to be possible to evaluate something in a list context and test whether there are any entries in the resulting list without having to reevaluate the expression in a scalar context. The work-around with the trinary operator also evaluates C@b twice (which H.Merijn Brand pointed out could even be tied and hence evaluation not idempotent). It's true that we are evaluating something in list context and then applying a boolean interpretation to the result (empty list is false, otherwise true); in this case we are trading a lesser consistency (likely only to be appreciated by someone who's been thinking for a long time about contexts) for a greater one. =head1 IMPACTS LRFC 82 would require a different interpretation, namely that the result would be the list formed by applying C or C|| to each successive pair of elements in C@b and C@c. This author likes the idea of certain component-wise operators, and appreciates the importance of consistency, but just can't see a component-wise interpretation of the logical operators being either useful or intuitive. =head1 REFERENCES Lperlop/"C-style Logical Or" RFC 21: "Replace Cwantarray with a generic Cwant function" RFC 82: "Apply operators component-wise in a list context"
RFC 52 (v2) List context return from filesystem functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
List context return from filesystem functions
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 6 Aug 2000
Last Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 52
Status: Frozen
=head1 ABSTRACT
Cchmod, Cchown, and Cunlink return the Inumber of successfully
affected files. I suggest that in a list context, they return the Inames
of the Iunsuccessfully affected files. Add Crmdir to that list as
well, since although it currently only takes one directory name as input,
there is no reason it shouldn't take a list.
=head1 DESCRIPTION
In a scalar context, the result should remain the same as it is now. It is
very tempting to make the list context return be the Isuccessfully
altered files, which is far more intuitive given the scalar context
behavior; but that is almost certainly not the list the user will be
interested in and they'd just end up doing the Cgrep suggested in the
docs (Camel III) anyway, which calls the filesystem function once for each
file.
=head2 Hash Context
When the result is assigned to a hash, the list returned could be the names
of the unsuccessfully modified files and their corresponding C$! errors.
=head1 IMPLEMENTATION
Examples of use:
# Current behavior: scalar context
chmod 755, grep -d, glob '*' or die "Couldn't chmod dirs"
# List context behavior
warn "Unable to modify $_" for chown $uid, $gid, @files;
# Hash context behavior
%error = rmdir grep -d, glob '*';
warn "Couldn't remove $_: $error{$_}" for keys %error;
It would be nice to include Cmkdir in this list as well, but there
appears to be no way of doing that without radically changing its
interface, or forcing the IMASK argument to be included, or interpreting
an initial argument that looks like a IMASK to be one. None of those appeal.
=head1 REFERENCES
Lperlfunc
Camel III function list (the entry for Cchmod is different from the one
in perl-current at the moment).
RFC 67 (v3) Deep Copying, aka, cloning around.
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Deep Copying, aka, cloning around.
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 8 Aug 2000
Last-Modified: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 3
Number: 67
Status: Frozen
=head1 ABSTRACT
Perl should have a Cclone method for deep copying of hierarchical data
structures.
Damian Conway mooted a Cclone function for deep copying of objects as
part of an earlier discussion. This RFC expands upon that and gives it
special attention. I expect several iterations of this RFC from feedback.
=head1 DESCRIPTION
The language interface is the Cclone method which takes an object as
argument and returns a copy of it as result:
=over 4
=item clone SCALAR
=item clone SCALAR, CALLBACK
$copy = clone($obj)
$copy = clone($obj, sub { die 'Filehandle copying not allowed' })
The CCALLBACK is an optional function to be called if Cclone encounters
a filehandle, dirhandle, or object with magic or an XS implementation. It
will either throw an exception or return a value to be used as the cloned
filehandle.
=back
=head1 IMPLEMENTATION
=head2 Default
The default functionality will switch on Cref SCALAR and recursively
create new data structures in the way many people have written
themselves. Here, for instance, is Garrett Goebel
(C[EMAIL PROTECTED])'s version implementing circular reference checking:
our %SEEN = ();
our $DEPTH = 0;
sub clone { # Dereference and return a deep copy of whatever's passed
our %SEEN;
local $_ = ref($_[0]) or return $_[0];
exists $SEEN{$_} and return $SEEN{$_};
$DEPTH++;
my $rval =
/^HASH$/ ? {map {clone($_)} (%{$_[0]})}
: /^ARRAY$/ ? [map {clone($_)} @{$_[0]} ]
: /^SCALAR$/ ? \${$_[0]}
: /^FORMAT$/ ? $_[0] # Shallow copy until we figure out
: /^Regexp$/ ? $_[0] # B.pm and Class::Tom show the way
: /^REF$/? $_[0] # how to deep copy these. Note:
: /^IO$/ ? $_[0] # "
: /^GLOB$/ ? $_[0] # "
: /^CODE$/ ? $_[0] # " (B::Deparse)
: $_[0]-CLONE;
--$DEPTH
and $SEEN{$_} = $rval
or %SEEN = ();
$rval;
}
=head2 Blessed objects
If Cclone encounters a blessed object C$obj say, it will call
C$obj-CLONE(CALLBACK). If the CCLONE method is not defined in
C$obj's class or any of its superclasses, CUNIVERSAL::CLONE will carry
out the default functionality on the internal representation of
C$obj. Probably this will mean little more than calling Cclone.
Classes (e.g., DBI) may well choose to throw an exception in their CCLONE
methods.
=head2 Filehandles
If Cclone encounters an CIO::Handle, its default behavior will be to
make a copy of the filehandle (debatable: perhaps the default should be to
throw an exception) unless a CCALLBACK function was specified, in which
case it will use the return value of CCALLBACK.
=head2 Tied variables
If Cclone encounters a tied variable, it will call the CCLONE method in
the class of the underlying implementation object or fall back to
CUNIVERSAL::CLONE. (Note: perhaps all missing functions from tied
classes should punt to CUNIVERSAL. But that is outside the scope of this
RFC.)
=head2 Cyclic references
The Cclone function should detect circular references and replicate the
same structure in the copy. One implementation that suggests itself is to
keep a hash of input references with output references as values. It has
been suggested that the code to do this will already be available in the
garbage collector.
=head2 Exceptions
If an exception is thrown anywhere during the copying, it needs to be
trapped so that Cclone can clean up any cyclic references it has created,
then rethrown.
=head1 REFERENCES
The LStorable module
(http://search.cpan.org/doc/RAM/Storable-0.7.0/Storable.pm).
The LData::Dumper module
(http://search.cpan.org/doc/GSAR/perl-5.6.0/ext/Data/Dumper/Dumper.pm).
RFC 68 (v2) Eliminate the optional Csub for CBEGIN etc block declarations
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Eliminate the optional Csub for CBEGIN etc block declarations =head1 VERSION Maintainer: Peter Scott [EMAIL PROTECTED] Date: 8 Aug 2000 Last Modified: 29 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 2 Number: 68 Status: Frozen =head1 ABSTRACT The Csub keyword is currently optional on CBEGIN, CEND, CCHECK, CINIT. Almost certainly no-one ever uses it. It should be eliminated as an option. =head1 DESCRIPTION CBEGIN etc have special semantics making them different from ordinary subroutines; telling the user that they can use the Csub keyword gives a false impression. =head1 IMPLEMENTATION Obvious. =head1 REFERENCES Lperlmod/"Package Constructors and Destructors"
RFC 26 (v2) Named operators versus functions
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Named operators versus functions =head1 VERSION Maintainer: Johan Vromans [EMAIL PROTECTED] Date: 04 Aug 2000 Last Modified: 28 Aug 2000 Version: 2 Mailing List: [EMAIL PROTECTED] Number: 26 Status: Frozen =head1 ABSTRACT Perl distinguishes named operators and functions. For Perl6, this disctinction can be dropped. =head1 DESCRIPTION Named operators, like Cabs, can be called like functions in which case they behave like functions. This has always been so in Perl. Recent versions of Perl allow user-defined functions to be called as operators, using context coercion templates to resolve argument passing. Larry said: "Theoretically, we'd like to make subs run as fast as ops." Since there is no real difference between named operators and functions anymore, they can be treated identically. The difference in terminology can be applied to how it is called instead of how it is defined. So, a Ifunction is a user-defined or built-in function called with a parenthesized list of arguments, and a Inamed operator is a user-defined or built-in function called with its arguments "bare". The latter form is subject to the usual restrictions. Note that this applies to the language aspects. The actual implementation may be different for user-defined and built-in functions. =head1 REFERENCES [i] perldoc perlop
RFC 2 (v3) Request For New Pragma: Implicit
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Request For New Pragma: Implicit =head1 VERSION Maintainer: Bryan C. Warnock [EMAIL PROTECTED] Date: 5 Aug 2000 Last Modified: 28 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 3 Number: 2 Status: Frozen =head1 ABSTRACT Perl 6 should add a new pragma called Cimplicit. =head1 DESCRIPTION I am lazy. I am spoiled by the implicit $_. I like the implicit $_. Implicit $_ good. Ugh. (Conversely, some people abhor the implicit $_ while in a strict programming environment, as it tends to add confusion.) I came to the sysadm / programming world in a long, circuitous route. I never programmed with toggle switches. I've never seen a punch card. My first programming was in Commodore 64 Basic. C64 Basic. No safe-signals there, either. ;) It did have one good thing, though. One very useful thing, for lazy people like me. Cprint could be written like C?. It just rolled off the fingers. C10 ?"Port Perl for the 64!". Of course, those days have gone. I've seen the light. I'm a *nix head and JAPH. But how I still hate typing out print. Particularly because I do it so much. Oh, sure, I could play games with HERE docs and the ilk, but I'm too lazy. (Like I posted in a response, I wrangled an input filter to allow me to write C? "Print me.!". But I digress. There should be an Cimplicit pragma that gives new life and meaning to void context constructs. In my case, I want it to print to the default filehandle, (which is also implicit, I might add.) Scoping needs to be tightly controlled, of course. Don't want someone else's void context to show up on your display, now do you? And, of course, it would be defaulted to off. It could continue to ignore constant 0s and 1s. (But those pre-pod embedded comment strings just Bhave to go.) Ideally, I'd like to use it for printing, but I suppose some other lazy person may want to use it for something else. Or, from reading the traffic, to prevent laziness. One of the suggestions was to disallow implicit $_ for functions. That could fit right in with this pragma. It would be on be default, but you could turn it off. =head1 MOTIVATORS Laziness, pure and simple. =head1 IMPLEMENTATION The front-end would have to detect void usage and either arrange to have the results passed to a callback, (in which case, would you know what wantarray() wants to know?) or inject the appropriate term in the optree. In the case of Cno implicit arg, the front-end would have to not assume the implicit $_ as an argument. =head2 SUMMARY OF IMPLEMENTATION I've no real concrete ideas on this, sorry. =head2 IMPACT =over 4 =item * Impact on Perl 5. Mutual compatibility between Perl 5 and Perl 6, with the exception of Cuse implicit and the sematics it would add. (Obviously, other changes to the language notwithstanding.) =back =head2 UNKNOWNS =over 4 =item * What about subs? Backticks? Things that return meaningless printable information, like system()? Cno implicit would put it on the user. After all, he doesn't have to use it. =item * Would C; print the contents of $_ to the default filehandle? ;-) =back =head1 REFERENCES RFC 40: Module Scope Control. =head1 STATUS Frozen as is. Most people don't like it. II don't like it. Not really. I hate to think that Perl will have more pragmas than functions at the current pace. But I like the idea behind it. I think a smarter solution would be found in something akin to L"RFC 40"|RFC40. In which case, I would gladly withdraw it.
RFC 168 (v2) Built-in functions should be functions
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Built-in functions should be functions
=head1 VERSION
Maintainer: Johan Vromans [EMAIL PROTECTED]
Date: 27 Aug 2000
Last Modified: 28 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 2
Number: 168
Status: Developing
=head1 ABSTRACT
RFC 26 proposes to eliminate the distinction between functions and
operators from a language perspective.
This RFC proposes that all Perl built-in functions should be usable in
all ways normal functions can be used. It is part of a big consipracy
to remove the number of cases with exceptional behaviour in Perl.
=head1 DESCRIPTION
Named operators, like Cabs, can be called like functions in which
case they behave like functions. However, that's where the similarity
ends. You cannot override most builtins, and cannot tack a reference
to them.
There is no reason why the built-ins should be treated differently. A
famous Perl saying reads "if it looks like a function, it Bis a
function." So be it.
In particular, it is desired that every built-in
=over 4
=item *
can be overridden by a user defined subroutine;
=item *
can have a reference taken;
=item *
has a useful prototype.
=back
=head2 Overriding
The principle of least surprise dictates that
sub Ifoo { return 10 }
print Ifoo();
should call Ifoo() and print "10" for all Ifoo.
Currently, most built-ins are excluded from this. For example:
sub system { return 10 }
print system();
Instead of calling the user defined system(), the built-in is used.
The second line may give a warning, but only if warnings are enabled:
Ambiguous call resolved as CORE::system(), qualify as such or use
=head2 References
You can call a built-in, but not take a reference.
$a = \system;
print $a-(-1)
This gives an error:
Undefined subroutine main::system called
This should return a reference to the built-in instead.
Since CIfoo implicitly refers to the current package, it would be
acceptible to require
$a = \CORE::system;
Note that this currently (5.7.0 DEVEL6806) results in the error:
Undefined subroutine CORE::system called
which is surprising, if not misleading.
=head2 Prototypes
Currently, several built-ins do not provide prototype information.
prototype("CORE::abs") == ;$
prototype("CORE::shift") == undef
This must be fixed. One might even call this a bug, although the
current prototype mechanism is not powerful enough to cope with all
built-ins.
=head1 REFERENCES
RFC 26: Named operators versus functions
Tom Christiansen in 12231.967154045@chthon (perl6-internals, Aug 24, 2000).
RFC 70 (v3) Allow exception-based error-reporting.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Allow exception-based error-reporting. =head1 VERSION Maintainer: Bennett Todd [EMAIL PROTECTED] Date: 8 Aug 2000 Last Modified: 29 Aug 2000 Mailing List: [EMAIL PROTECTED] Version: 3 Number: 70 Status: Developing =head1 ABSTRACT Allow full implementation of Fatal.pm, for programmers who prefer exceptions for error reporting. To enable this, ensure that all builtins (like e.g. print()) that return errors can be wrapped. In addition, ensure that builtins like e.g. integer division, which currently throw exceptions on errors, can have that behavior switched off. At least glob, print, and printf should be wrappable. =head1 DESCRIPTION Perl has traditionally reflected the Unix syscall and library tradition for error reporting: errors are indicated by otherwise-impossible return values, which must be checked for explicitly, lest system error events be ignored. Some programmers prefer to have errors print a message and exit with non-zero status, by default, rather than having to always code " || die ...". In perl5 this has proven elusive of implementation. Fatal.pm has been the attempt made to date, and it suffers from two problems. One can be fixed with further development: it should have various lists of builtins available, e.g. :io, :system, :all for including all calls affecting I/O, all system calls of any sort, and all calls that can have error returns. If these were a success, then the requested category could also be posted into a testable variable, allowing module authors who wished to to automatically support this functionality as well. In addition, for classes of errors that currently throw exceptions, Fatal could be taught to disable them, allowing e.g. no Fatal qw(:arithmetic); my $result = 1 / 0; # $result now contains undef, w/ # error posted in $! or maybe $@ But Fatal.pm development stalls out early, because some builtins, which report testable error conditions, cannot be wrapped. A conspicuous example is print(). =head1 IMPLEMENTATION Ensure that every perl builtin that can return an error, can be wrapped. Perhaps in addition ensure that routines that currently die on error, can have their behavior changed as well. For the first part, tchrist posted a nice list of non-overridable builtins; running my eye down it, it looks like the gross offenders here are: glob, print, printf I don't know whether this is purely an implementation issue (and so lies solely in the domain of perl6-internals) or whether any programmer-visible changes may be necessary to allow this (justifying posting to perl6-language). =head1 REFERENCES Fatal.pm, as included with recent perls. Error.pm, available from CPAN, and cited by RFC 63: if this proposal should carry, then Fatal.pm will see some very active development, and if RFC 63 should also prevail, then Fatal's development should be guided by RFC 63/Error.pm. RFC 80 Proposes a taxonomy for exception objects; should it prevail, it should guide the structure of exceptions thrown when Fatal.pm gets worked on.
RFC 173 (v1) Allow multiple loop variables in foreach statements
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Allow multiple loop variables in foreach statements
=head1 VERSION
Maintainer: Peter Scott [EMAIL PROTECTED]
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 173
Status: Developing
=head1 ABSTRACT
Allow for a list of loop variables in for(each) statements, i.e. e.g.,
foreach my ($x, $y, $z) (@list) { ... }
=head1 DESCRIPTION
This has been raised by several people in the past, most recently on the
perl6-* lists by Graham Barr, who does not have time to RFC it
currently. The semantics are (hopefully) obvious: where
foreach $var (@list)
iterates through C@list, assigning C$var to each element in turn,
foreach ($var_1, ... $var_n) (@list)
iterates through C@list n elements at a time, assigning C$var_1 through
C$var_n to them respectively. If the number of elements in C@list is
not evenly divisible by n, the remaining loop variables on the last
iteration become Cundef.
The most obvious usefulness is traversing a hash which has been passed in
an argument list:
sub foo {
foreach my($key, $value) (@_) { ... }
}
foo(%hash);
instead of having to make a temporary copy:
sub foo {
my %h = @_;
while (my ($key, $value) = each %h) { ... }
}
This extension does not apply to the Cforeach statement Imodifier,
since that doesn't accept a loop variable anyway.
=head2 Alternatives
While Csplice is frequently adduced as an alternative, this requires an
array instead of just a list, and is destructive to boot.
=head1 IMPLEMENTATION
The potential parsing difficulty I came up with was how to tell that
foreach ($a,$b,$c) (@list) ...
was not
foreach $_ ($a, $b, $c) (@list) ...
Graham tells me that the required parentheses and block braces make it
possible for the parser to be able to tell the difference.
=head1 REFERENCES
Lperlsyn/"Foreach Loops"
RFC 176 (v1) subroutine / generic entity documentation
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
subroutine / generic entity documentation
=head1 VERSION
Maintainer: Michael Maraist [EMAIL PROTECTED]
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 176
Status: Developing
=head1 ABSTRACT
Extend perl's self documentation to allow dynamic documentation with at
least as much power as "perldoc -f ". Ideally, documentation would be
an attribute and therefore retrievable at run time.
#File: Foo.pm
sub foo : doc( EOS )
Function: Foo
In:scalar - int - foo identifier
Out:array - decomposed foo
Effects: Queries Foo DB
Exceptions: DBI, "bad foo id"
EOS
{
# Do good foo
...
} # end foo
#File: main.pl
use Foo;
print "Foo Info: ", attributes::doc::get( \Foo::foo ), "\n";
# Command prompt
% perldoc -f Foo::foo
=head1 DESCRIPTION
=head2 Motivation
Many interpreted languages allow run-time querying of information about a
function. Lisp, python, matlab, etc. Recently, even byte-compiled
languages, such as Java are even applying function-based documentation.
Perl, in comparison, has a very functional POD format, but unfortunately, it
is flat, static, and only useful at the level of a module. The only real
advantage that POD servers is in the keeping of documentation close to the
code. Though various tools exist to dynamically generate documentation on
functions (I have written a few simple ones), perl code is not easily
analyzable.
Java, for example, has many attributes associated with a function: name,
return type, parameter types, throwable exceptions, and class heirarchy.
This allows javadoc to produce a comprehensive suite of documents even from
compiled code, without a single explicit comment. Document comments ( /**
... **/ ) are also intelligently associated with the function to complete
the process.
Perl doesn't really stand a chance at this level of sophistication (being,
for the most part, a type-less language with little or no useful function pr
ototyping).
At the other extreme are the interpreted languages. Since you are at the
prompt for much of the development process in these languages, it is
obviously useful to have a "reflection", or the ability to query information
about pre-defined components. The first bare string after the function
header is usually considered the function-comment. Various languages, such
as Python, have perl-like HERE-DOCUMENTS, so this works out nicely.
Perl is somewhere in between. It was designed to work more like a compiled
language (so the reflection property isn't really necessary), but has a very
powerful interpretive debugger in which many developers, like myself, keep
open like a prompt. This begs for an ability to perform quick-and-dirty
queries about the nature of a given function. It would be a very cool and
perl-like enhancement.
=head2 Requirements
At a minimum, documentation should be able to be associated with a function.
I propose some derivative of the 'attributes' pragma for storing this
information. As it stands, attributes is keyword presence based, so it
probably would not be a good candidate for document storage out of the box.
A sub-pragma ( read sub-module ) could take as it's only argument a scalar
string as in:
sub foo {
use attributes::doc "This is my documentation";
} # end foo
sub foo {
use attributes::doc EOS;
Multi-line
Comment
EOS
} # end foo
Or even possibly using newer style:
use attributes;
sub foo : doc( EOS )
Multi-line
Comment
EOS
{
...
} # end foo
print attributes::getDoc( \foo );
Assuming the newer attributes style ( symbol: attribute-list ) is feasible
(it would require the use of function-like attribute names. This should be
an RFC), then documentation could be applied to any perl-entity. As in:
package Foo : doc( "Simple collection of Foo material" );
sub foo : doc( "analyzes a foo ID" ) {
my ( $x, $y, $z ) : doc( "temp variables to store mathematical
calculations" );
} # end foo
our %cache : doc( "Store DB accesses to foo" );
After association of text with a function, the next problem is in how to
retrieve it. There is already the attributes::get( {func-ref} ), so it
should be trivial to apply attributes::doc::get( {func-ref} ). I am not up
to speed on how perldoc -f {func-name} works, but I don't see any major
problem with extending it to perform the appropriate get and print
statements.
=head1 IMPLEMENTATION
The simplest implementation would be to create the independant module
attributes::doc, and perform a "use attributes::doc 'str'". The import
routine would get the calling function's name, and apply the documentation
to a global hash. The get function would simply query this hash. The
perldoc program would also have to add a search for this.
A more sophisticated apprach would be to slightly modify the definition of
attributes so as to allow sub-packaged attributes which can at the
RFC 177 (v1) A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
Reply-To: [EMAIL PROTECTED]
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
A Natural Syntax Extension For Chained References
(aka Multidimensional Arrays/Hashes)
=head1 VERSION
Maintainer: Jarkko Hietaniemi [EMAIL PROTECTED]
Date: 29 Aug 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 177
Status: Developing
=head1 ABSTRACT
In this RFC an extension to existing Perl syntax is proposed. The
syntax doesn't conflict with anything existing (in fact it corrects a
bug of sorts), it is natural (naturalness being naturally in the eye
of the proposer), and it gives concise way to express a complex data
structure access.
=head1 DESCRIPTION
Snatch two syntax constructs away from the jaws of illegal syntax and
an unfortunate syntax, and make them useful weapons of the Perl
arsenal. The constructs are:
$ref-[[LIST]]
$ref-{{LIST}}
The proposed respective meanings:
$ref-[$elem[0]]-[$elem[1]}-[...]-[$elem[-1]]
$ref-{$elem[0]}-{$elem[1]}-{...}-{$elem[-1]}
That is, the lists are being expanded as the indices for a chain of
references, the arrays could be called index lists. Having the
indices in one place saves a lot of characters. Compare
$r-{{qw(a b c d e f g h)}}
versus
$r-{a}-{b}-{c}-{d}-{e}-{f}-{g}-{h}
An example using an array may be even more enticing
$r-[[@a]]
versus
$r-[$a[0]]-[$a[1]]-...
or even
$r-[$a]-[$b]-...
(assuming @a = ($a, $b, ...))
As mentioned earlier, these syntaxes do not do anything useful at the moment.
The first one, -[[]], is an intermittent cause of segmentation
violations, core dumps, and bug reports because it already does have a
meaning but a rather twisted and faulty one: "access the array at the
offset of stringifying this anonymous list". This offset is usually a
rather large one, resulting in unruly memory access attempts. Reusing
the syntax for something useful cannot be an evil thing.
The second one, -{{}}, is currently a syntax error, and cannot
therefore broke existin code.
The degenerate case of the list being empty can be defined to be
equivalent to $ref.
=head1 IMPLEMENTATION
Since the exact meaning of the construct depends on the contents of
the index list, the chasing the indices (autovivifying data structures
as needed) cannot be determined in compile time and needs to be
a run-time operation.
=head1 REFERENCES
perlref
perldsc
perllol
Re: RFC 167 (v2) Simplify Cdo BLOCK Syntax
Simpify syntax of Cdo BLOCK by deleting Cdo before the
block and C; after it.
You can't do that. They do different things.
$n = do {
my $sum = 0;
for $i (@array) { $sum += $i }
$sum;
};
versus
$rec = {
FOO = 1.4,
BAR = "red",
};
--tom
