Re: sort syntax
On Thu, 07 Sep 2000 13:44:10 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> Having no time to write and/or maintain RFC's, I'll toss this up in the air
> and see what happens.
[ snip ]
> my $Ycmp = sub { $a cmp $b };
> @a = sort $Ycmp @x;
>
> but this is an unsupported syntax for sort.
No it is :-) (I was lost in focus after fork, D'uh)
> Is it feasable/useful to extend sort's syntax in supporting sub ref's?
Consider previous mail never sent
--
H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl5.005.03, 5.6.0 & 516 on HP-UX 10.20, HP-UX 11.00, AIX 4.2, AIX 4.3,
DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: $a in @b
> "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes: RLS> We really need a clean way to distinguish those four cases: RLS> "yes" and keep going RLS> "no" and keep going RLS> "yes" and abort after this one RLS> "no" and abort after this one RLS> What would you have "last" do? And how would you distinguish "the RLS> other one"? Either last has to be extended with a return value or a new keyword is needed. I'm quite partial to yield. Which might be overloaded to work with lazy lists, continuations, and short-circuiting. yield EXPR - stop what I am doing now and give something else a a chance to do its things. And while you are doing that please take this EXPR from me. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
Chaim Frenkel <[EMAIL PROTECTED]> writes: > > "RLS" == Randal L Schwartz <[EMAIL PROTECTED]> writes: > > RLS> We really need a clean way to distinguish those four cases: > > RLS> "yes" and keep going > RLS> "no" and keep going > RLS> "yes" and abort after this one > RLS> "no" and abort after this one > > RLS> What would you have "last" do? And how would you distinguish "the > RLS> other one"? > > Either last has to be extended with a return value or a new keyword > is needed. I'm quite partial to yield. Which might be overloaded > to work with lazy lists, continuations, and short-circuiting. > > yield EXPR - stop what I am doing now and give something else a > a chance to do its things. And while you are doing > that please take this EXPR from me. When you put it this way, isn't C spelled C in Perl5? (Except, of course, that C inside a C does a whole lot more nowadays). -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: $a in @b
Randal Schwartz wrote:
>We really need a clean way to distinguish those four cases:
>
>"yes" and keep going
>"no" and keep going
>"yes" and abort after this one
>"no" and abort after this one
>
>What would you have "last" do? And how would you distinguish "the
>other one"?
Sounds like people are trying to fit two booleans into one expression.
Probably what is needed is for grep to have two control expressions:
one to determine whether each element is selected to be put into the
output list (grep's current boolean expression), and one to determine
whether grep should continue execution.
Perhaps a new "pass" keyword should be added, which passes the
current list element through the filter.
@L = (1, 2, 3, 10, 3, 2, 1);
@l = grep {pass if $_>1; last if $_>9} @L;#--> (2, 3, 10)
@l = grep {last if $_>9; pass if $_>1} @L;#--> (2, 3)
@l = grep {pass if $_>1; next if $_>9} @L;#--> (2, 3, 10, 3, 2)
@l = grep {next if $_>9; pass if $_>1} @L;#--> (2, 3, 3, 2)
A grep block with no explicit 'pass' would pass if the last expression
in the block evaluates to true, just as grep does now:
@l = grep {$_>9} @L; # same as:
@l = grep {pass if $_>9}; #--> (10)
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: $a in @b
> "Ariel" == Ariel Scolnicov <[EMAIL PROTECTED]> writes:
>> yield EXPR - stop what I am doing now and give something else a
>> a chance to do its things. And while you are doing
>> that please take this EXPR from me.
Ariel> When you put it this way, isn't C spelled C in Perl5?
Ariel> (Except, of course, that C inside a C does a whole lot
Ariel> more nowadays).
Yes, I'd be in favor of making return() in a valued block (as opposed
to a looping block) abort the block early and return the value. I
don't think I'd want to change last() to do that, since last() already
has an optional parameter (the loop label). That makes the valued
block of a do {} or a grep or map be able to abort with a particular
value. Although it would break any use of return in those blocks to
abort the enclosing subroutine, and there wouldn't be any clean
translation available. Ugh. Maybe we do need a new keyword. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence
Glenn Linderman wrote:
>
> >/Class->blah/# ditto
>
> for the middle of the above example, what happens when
>
> package Class;
> package lass;
> package ass;
> package ss;
>
> /Class->blah/ then becomes pretty ambiguous.
Actually, I don't think so. The -> should simply act on \b\w+ before it,
like anywhere else in Perl:
$stuff = Class->blah;
So regardless of the packages imported "Class" would always be called.
One potential way to override this:
/{Class}->blah/
/C{lass}->blah/
/Cl{ass}->blah/
/Cla{ss}->blah/
This is consistent with the way ref variables work currently:
${r}->blah; # class method
${h}->{key}; # hash ref key
${a}->[0];# array ref key
I'll add this to the RFC unless there are objections.
-Nate
Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence
>Actually, I don't think so. The -> should simply act on \b\w+ before it,
>like anywhere else in Perl:
> $stuff = Class->blah;
>So regardless of the packages imported "Class" would always be called.
Foo::Bar->stickysnort()
>One potential way to override this:
> /{Class}->blah/
> /C{lass}->blah/
> /Cl{ass}->blah/
> /Cla{ss}->blah/
>This is consistent with the way ref variables work currently:
> ${r}->blah; # class method
> ${h}->{key}; # hash ref key
> ${a}->[0];# array ref key
>I'll add this to the RFC unless there are objections.
I don't see that it's all that consistent, since braces only delimit
variables' symbols when they follow a $ etc.
Anyway, one can always write:
${\"ClassName"}->frob(stuff)
Although this gets icky in dq strings, since this:
"This ${\"ClassName"}->frob(stuff) here"
isn't good enough currently.
I wonder whether the "I want to expand arbitrary expressions within
strings even when there aren't any $ or @ symbols about" people
just need better familiarity with the alternatives.
--tom
Re: $a in @b
Ariel Scolnicov wrote: > > Chaim Frenkel <[EMAIL PROTECTED]> writes: > > > yield EXPR - stop what I am doing now and give something else a > > a chance to do its things. And while you are doing > > that please take this EXPR from me. > > When you put it this way, isn't C spelled C in Perl5? > (Except, of course, that C inside a C does a whole lot > more nowadays). And except that C allows you to pick up where you left off later, at least per Damian's RFC 31: "Co-routines". For a grep/map this could potentially be really useful, especially if you have code that modifies values in your block but want to do it conditionally/iteratively. -Nate
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> At what point do you feel a new operator is not justified? Why do > we need grep/map, just use for? Why have <=>, cmp, just use ?: > > So what if the man wants > > @foo = @bar union @baz; > @foo = @bar intersetcion @baz; > > This is a lot more of a direct map than the twiddling with hashes. > > How are you drawing the line. Where does giving the user more power > than a turing machine stop. > > Yes Baby ! This sound good for me ! I'm completly ok with this new syntax, it is much better than a function ! Gael,
Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence
> Foo::Bar->stickysnort() Right, knew I forgot something... > I wonder whether the "I want to expand arbitrary expressions within > strings even when there aren't any $ or @ symbols about" people > just need better familiarity with the alternatives. This was all spawned by a consistency argument brought up by Bart on "where to draw the line" with having -> interpolate: http://www.mail-archive.com/perl6-language@perl.org/msg03658.html http://www.mail-archive.com/perl6-language@perl.org/msg03659.html If instead we chose to draw the line at needing a $, I'm fine with that, as long as the line is well-defined and allows for class methods to interpolate in qq// strings. -Nate
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Gael Pegliasco wrote: > >> So what if the man wants >> >> @foo = @bar union @baz; >> @foo = @bar intersetcion @baz; >> >> This is a lot more of a direct map than the twiddling with hashes. >> >> How are you drawing the line. Where does giving the user more power >> than a turing machine stop. >> >> > > >Yes Baby ! > >This sound good for me ! > >I'm completly ok with this new syntax, it is much better than a function >! The underlying problem is that arrays don't make SENSE as an implementation for sets. What is the value of: (1, 2, 3, 1, 2, 3) union (2, 3, 4, 5) ? is it (1, 2, 3, 4, 5)? is it (1, 2, 3, 1, 2, 3, 4, 5)? (1, 2, 3, 1, 2, 3) is NOT a valid set. The problem GOES AWAY if you make a small mental shift and deal with HASHES instead of ARRAYS. (1, 2, 3, 1, 2, 3) CANNOT be the keys of a hash -- the language ALREADY enforces this! Why reinvent the wheel when there's already half a wheel there? IF new keywords "union" and "intersection" (and perhaps others) are to be added to the language, they should be functions that operate on the KEYS of HASHES, not on arrays! And, imho, these are special-purpose functions that are going to be extremely useful to a fairly small set of users (math folks), and are going to be somewhat useful to another small set of people, and fairly useless to the majority of Perl programmers. That screams "module" to me, not "new core features". -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>> At what point do you feel a new operator is not justified? Why do >> we need grep/map, just use for? Why have <=>, cmp, just use ?: >> >> So what if the man wants >> >> @foo = @bar union @baz; >> @foo = @bar intersetcion @baz; >> >> This is a lot more of a direct map than the twiddling with hashes. >> >> How are you drawing the line. Where does giving the user more power >> than a turing machine stop. >> >> >Yes Baby ! >This sound good for me ! >I'm completly ok with this new syntax, it is much better than a function General cases should be preferred over special ones. We've never had named aggregate functions in Perl before that work like infix operators. What is the general proposal out of which this would intuitively decend? --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>The underlying problem is that arrays don't make SENSE as an >implementation for sets. And even in those rare places where they do, to use them as such is gratuitously counter-efficient. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Eric Roode <[EMAIL PROTECTED]> writes: [...] > The underlying problem is that arrays don't make SENSE as an > implementation for sets. What is the value of: > > (1, 2, 3, 1, 2, 3) union (2, 3, 4, 5) ? > > is it (1, 2, 3, 4, 5)? is it (1, 2, 3, 1, 2, 3, 4, 5)? But all of the following DO make sense as implementations for sets, depending on your application: * Sorted lists * Lists with guaranteed unique elements * Lists (as implementations for multisets, with you favourite definitions of the operations) * Hashes * Bit vectors * Integers * Trees * Balanced trees [...] > IF new keywords "union" and "intersection" (and perhaps others) > are to be added to the language, they should be functions that > operate on the KEYS of HASHES, not on arrays! Now s/HASHES/SORTED LISTS/ on the above, followed by the other 6. I assure you that readers of the list have used all 8 (and likely others). > And, imho, these are special-purpose functions that are going to be > extremely useful to a fairly small set of users (math folks), and > are going to be somewhat useful to another small set of people, > and fairly useless to the majority of Perl programmers. That screams > "module" to me, not "new core features". They're going to be useful to a tiny minority of users: math folks whose application matches the use of a hash-based implementation. (Actually, all uses I've seen of set datatypes were strictly outside mathematics, but that doesn't alter your argument or mine). The problem is that the desired semantics (in the sense, e.g., of worst-case, average-case, and "my-case" complexity) of the "set" datatype vary greatly with application. When I started reading this thread, I was *sure* it would be immediately clear that sets are bit vectors, drawn on some pre-specified world! -- Ariel Scolnicov|"GCAAGAATTGAACTGTAG"| [EMAIL PROTECTED] Compugen Ltd. |Tel: +972-2-5713025 (Jerusalem) \ We recycle all our Hz 72 Pinhas Rosen St.|Tel: +972-3-7658514 (Main office)`- Tel-Aviv 69512, ISRAEL |Fax: +972-3-7658555http://3w.compugen.co.il/~ariels
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Ariel Scolnicov wrote: >Eric Roode <[EMAIL PROTECTED]> writes: > >[...] > >> The underlying problem is that arrays don't make SENSE as an >> implementation for sets. What is the value of: > >But all of the following DO make sense as implementations for sets, >depending on your application: > >* Sorted lists (1, 1, 2, 2, 3, 3, 4, 5) is as invalid a set as (1, 2, 3, 1, 2, 3, 4, 5). >* Lists with guaranteed unique elements Yes -- we call these "hash keys" ;-) Anything else is reinventing the wheel. >* Lists (as implementations for multisets, with you favourite > definitions of the operations) Not sure I follow you here. >* Hashes Yes. >* Bit vectors Yes, I forgot about these. Thanks for bringing this up. _Mastering Algorithms_ goes into much detail about how to represent and manipulate sets as bit vectors. >* Integers Only inasmuch as the integers are used to store bit vectors, which see above. >* Trees >* Balanced trees No built-in language support for these structures, unless you're proposing adding such...? [...] >When I started reading this thread, I was *sure* it would be >immediately clear that sets are bit vectors, drawn on some >pre-specified world! Bit vectors do have their problems, vis a vis mapping the set universe onto the bit positions, adding and deleting elements from the set universe, etc. But they can be a useful way of representing sets, so thanks for bringing them up. -- Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort Senior Software Engineer'tona ', 'reh', 'ekca', 'lre', Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 199 (v2) Another question...
Garrett Goebel wrote: > Would it be possible to expand the function prototypes so that a function > could be defined to take a loop block instead of a code block? Might be easier to do what I suggested, and unify the two types of blocks. -- John Porter We're building the house of the future together.
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> General cases should be preferred over special ones. TC> We've never had named aggregate functions in Perl before that work TC> like infix operators. What is the general proposal out of which this TC> would intuitively decend? Sorry, I'm not understanding your question. 1+2 = 3 2*2 = 4 (1,2,3) U (2,3,5) = (1,2,3,5) (1,2,3) ^ (2,3,5) = (2,3) (1,2,3) x (2,3,5) = ((1,2),(1,3), (1,5), (2,2), (2,3), (2,5) ...) # yes, no nested lists. But what about # n-dim arrays/matrices/tensors/whatevers Seems just as useful as sin, cos, tan, **, and the other mathematical operations. And the proposals to make matrix operations ala Basic's MAT. Unless you want to go with my Set (@a, @b, @c);# Is the type distributive? @c = @a - @b; @c = @a + @b; @c = @a * @b; # cross product ? I'm not understaning your position. I could have used such an operation rather than rolling my own. And a module would be too heavy handed for such a simple concept. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
Randal L. Schwartz wrote:
>
> We really need a clean way to distinguish those four cases:
>
> "yes" and keep going
> "no" and keep going
> "yes" and abort after this one
> "no" and abort after this one
>
> What would you have "last" do? And how would you distinguish "the
> other one"?
This is my suggestion: the only effect of "last" should be to signal
to the grep not to iterate further; and, as with the current sitch,
whatever the last evaluated value in the block would be the "returned"
value. So to effect the above, you would do the following:
Just as with the current implementation:
"yes" and keep going: grep { ... 1 } @a;
"no" and keep going: grep { ... 0 } @a;
Exercising the new feature:
"yes" and abort after this one: grep { ... 1, last } @a;
"no" and abort after this one: grep { ... 0, last } @a;
Of course, "last" would have to be ignored in the algorithm which
determines the "last evaluated value"...
--
John Porter
We're building the house of the future together.
Re: $a in @b
Ariel Scolnicov wrote: > > When you put it this way, isn't C spelled C in Perl5? > (Except, of course, that C inside a C does a whole lot > more nowadays). Hopefully, what C does in grep in perl6 will be different from perl5. -- John Porter We're building the house of the future together.
Re: RFC 195 (v1) Retire chop().
> "RP" == Richard Proctor <[EMAIL PROTECTED]> writes: >> Perhaps $/ and $\ should become per-filehandle variables, and >> there should be some way to set autochomp-on-read per filehandle, >> and auto-newline-on-output per filehandle. RP> I can see a small benefit for autochomp-on-read but none whatsoever RP> for auto-newline-on-output (even if you could decide when to send it). Use this all the time. perl -wl (or #!/usr/local/bin/perl -wl) It autochomps and then adds back the newline on the way out. Great for one liners, and in general when doing line at a time filter processing. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
-a and @F autospliting
Is there a fundemental reason (other than performance) that when using -a that the $1,...$n fields should not be populated in parallel? Yes, after a match they would be destroyed, but I find typing $1,$2 a lot easier than $F[0]. (And for one-liners, if a reference to @F is not seen or $1 before a regex operation, one or the other wouldn't have to be populated.) Thoughts? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
Randal L. Schwartz wrote: > > Yes, I'd be in favor of making return() in a valued block (as opposed > to a looping block) abort the block early and return the value. Imho, it should return the value, but not abort the block. That's not very dwimmy. Loop blocks look like sub blocks to me. After all, grep is (ostensibly) prototyped as grep(&@), so I expect to pass it a sub block. And that block gets called once per iteration over the input list; "return" is what I expect it to do once per iteration, implicitly; so using C explicitly to mean "no further iterations" is highly counterintuitive, or at least inconsistent. -- John Porter We're building the house of the future together.
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>I'm not understaning your position. We don't have very long names for function names. Our functions scan left to right, although our postfix modifiers alter that picture. And something like "union" or "intersection", long and alphabetic, certainly looks like a function name. My position is that we don't currently have a way to create user-defined function that works as an infix. Are we really wanting to create something as a built-in that a user can't create for his own types? Perhaps. >I could have used such an operation >rather than rolling my own. And a module would be too heavy handed for >such a simple concept. It's not a simple concept: arrays are not sets, and seldom are a good representation for the same due to efficiency and to countability. And it does merit a module. And we already have some. For that matter, we don't have non-prefix operators that operate on pairs of operands that are lists, arrays, or hashes. Well, unless you want to call comma an infix in @a = (@b, @c). But commas and parens are special. What I'd like to see is a real general-purpose proposal out of which this set crud might be merely an instance of. Here are some example steps down that route. These are not concrete suggestions: Given that: We no longer believe that scalar operators should operate on scalars alone. We no longer believe that scalar operators applied to aggregates should autocoerce those aggregates. We no longer believe that implicit distribuive application of scalar operators is a bad idea. We no longer believe that if it looks like a function, that it should act like a function. We no longer believe that the set of operators in Perl should be restricted to those same names, precedences, associativities, and arities as correspond to the built-in operators. (etc) We therefore propose to create: A general-purpose mechanism to denote a function as occupying a particular slot, whether prefix or postfix or infix, along with their prototypes (context coercion templates), precedences, arities, and associativities. These functions' profiles need not correspond to anything that exists in Perl today. This would be useful, for example, in creating pre-defined set-related op codes. I think you still have some big hurdles here, however. Lists are crappy set reps. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>We don't have very long names for function names. s/function/operator/
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Tom Christiansen wrote: > > General cases should be preferred over special ones. Perl is diagonal. No preferences should be prejudicially deemed exclusive. > We've never had named aggregate functions in Perl before that work > like infix operators. What is the general proposal out of which this > would intuitively decend? Infix operators for other types of operations; indirect object syntax. Under certain proposals, any function can be defined in such a way as to be used infix. union() and intersection() et al. could be prime examples of that style. -- John Porter We're building the house of the future together.
Re: Beefier prototypes (was Re: Multiple for loop variables)
> "BL" == Bart Lateur <[EMAIL PROTECTED]> writes: BL> On 10 Sep 2000 00:33:43 -0400, Chaim Frenkel wrote: >> I view it as a mis-feature. BL> I'm sorry to disagree. But flattening of argument lists is one of those BL> things that make Perl, Perl. Change it, and it's not Perl anymore. Sorry, I don't see list flattening as _fundemental_ to perl. It is just the way it is currently done. Could you tell me how it could be _fundemental_? How would perlishness suddenly break if (@foo, @bar) = (@bar, @foo) would not be valid. >> One is unable to return multiple arrays, >> or to pass through multiple arrays without resorting to messy extra >> punctuation characters. BL> You can pass and return references. The thing gets quite a bit faster in BL> the process, too. If only Perl had a neater way to make aliases to the BL> arguments passed ( *ary = shift; looks very messy)... As I said, using references adds lots of line noise. If I understand it correctly, this is the logical result of Larry's decision not to allow automatic dereferencing. (No nested lists, etc.) Being able to pass aggregates without flattening, and without having to use reference syntax (@$foo), would fall out of Damian's "parameters once known as prototypes" RFC. I wonder why not going full LISP with nested lists would be that bad. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Beefier prototypes (was Re: Multiple for loop variables)
> "DC" == Damian Conway <[EMAIL PROTECTED]> writes: >> How would the parser handle this? Some '}' would need ';' some don't. DC> The trailing C<&> parameter specification tells the parser that there DC> the last argument will be a raw block and that it need not be a followed DC> by a semicolon. It's no harder than parsing an C, C, or C, DC> except that parser has to update itself when it sees the parameter DC> specification. An excersize left for the student, eh? Sounds messy. That next brace could be one of many things. Does the prototype help guide the decision that it is a block and not an anon-hash? -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
auto-initializing values
This is something fairly basic, but I haven't seen it in discussion or in
the RFCs. If I've missed it, my apologies.
In Perl 5, when a variable is created, it is given the "undefined" value.
This can lead to lots of spurious "Use of uninit'd variable" warnings.
Suppose you could specify the value with which all variables in the
enclosing scope should be initialized; for example:
{
# handle pensioners here
init_vars = 0;
my ($num_pensioners, $base_pension, $years_service); # all get '0'
}
{
init_vars = 'ERROR::NAME_NOT_FOUND';
my ($name_1, $spouse_name_1); # all get 'ERROR...' message
}
{
init_vars = (1,7,9);
my (@blarg);
}
{
init_vars = \{};
my ($rh_data_record);
}
...etc
An example of when you might use this is when working with a
DB...frequently, I do the following:
1) Set up a large number of variables
2) Put sentinel values in them
3) Fill them with info from the DB
4) Check to see if the sentinel value are still there
5) If so, do error handling
Dave
Re: auto-initializing values
I like this idea, although not necessarily for the "spurious warnings" reason. --tom
RE: Beefier prototypes (was Re: Multiple for loop variables)
From: Damian Conway [mailto:[EMAIL PROTECTED]]
>> >> my_while { pred() } { # don't gimme no Tcl flac.
>> >> ...
>> >> } # no semicolon needed here!
>>
>> DC> Just added to the RFC :-)
>>
>> How would the parser handle this? Some '}' would need
> ';' some don't.
>
> The trailing C<&> parameter specification tells the parser that there
> the last argument will be a raw block and that it need not be
> a followed by a semicolon.
Do you mean Code block instead of raw block?
I am only aware of 3 kinds of blocks in Perl: Loop, Code, and Bare
I'm under the impression that "&" used in a function prototype signifies
that the function takes a code block.
I could be wrong. I often am. Am I?
Garrett
labels within expressions?
John Porter wrote:
>
> Randal L. Schwartz wrote:
> >
> > Yes, I'd be in favor of making return() in a valued block (as opposed
> > to a looping block) abort the block early and return the value.
>
> Imho, it should return the value, but not abort the block. That's
> not very dwimmy. Loop blocks look like sub blocks to me. After all,
> grep is (ostensibly) prototyped as grep(&@), so I expect to pass it
> a sub block. And that block gets called once per iteration over the
> input list; "return" is what I expect it to do once per iteration,
> implicitly; so using C explicitly to mean "no further iterations"
> is highly counterintuitive, or at least inconsistent.
What if we could use C to exit valued iterators? Currently we cannot
because labels can not appear within statements, only on their own.
Allowing labels to appear anywhere -- that might initially be confusing, but
would it be impossible?
$ perl -le'goto two; one: print "one"; exit; two: print "two"; print grep { ($_ == 25
and goto one) or !($_ % 3) }
(1..30)'
two
one
$ perl -le'goto two; one: print "one"; exit; two: print "two"; print three: grep {
($_ == 25 and goto three) or !($_ %
3) } (1..30)'
syntax error at -e line 1, near "three:"
Execution of -e aborted due to compilation errors.
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
perl -e'map{sleep print$w[rand@w]}@w=<>' ~/nsmail/Inbox
Re: Beefier prototypes (was Re: Multiple for loop variables)
On 11 Sep 2000 13:47:22 -0400, Chaim Frenkel wrote:
>Sorry, I don't see list flattening as _fundemental_ to perl. It is
>just the way it is currently done. Could you tell me how it could be
>_fundemental_?
I'll give one example.
sub min {
my $min = shift;
foreach (@_) {
$min = $_ if $_ < $min;
}
return $min;
}
$a = min(12, 45, 7);
@b = (12, 45, 7);
$b = min(@b);
Now, the possibility to either pass individual scalars to a sub, or an
array, (or several arrays, or a mixture of arrays and scalars) and Perl
treating them as equivalent, that is pretty much the most important
feature of Perl. IMO. Perl would not be Perl without it.
--
Bart.
RE: RFC 199 (v2) Another question...
From: John Porter [mailto:[EMAIL PROTECTED]] > > Garrett Goebel wrote: > > Would it be possible to expand the function prototypes so > > that a function could be defined to take a loop block > > instead of a code block? > > Might be easier to do what I suggested, and unify the two > types of blocks. Sounds like an RFC waiting to happen. Unify "code", "loop", and "bare" blocks, so that they can all be short-circuited with C, C, C. However it still doesn't answer how you are able to: return $true and next; return $false and next; return $true and last; return $false and last; return $true and redo; return $false and redo; How about adding an optional expression to C, C, and C? Something that would allow for the following combinations: next REAL_LABEL $true; next REAL_LABEL $false; next REAL_LABEL; next $true; next $false; next; Garrett
Re: auto-initializing values
Dave Storrs wrote:
>
> {
> # handle pensioners here
my ($num_pensioners, $base_pension, $years_service) = (0,0,0);
> }
>
> {
my $init_vars = 'ERROR::NAME_NOT_FOUND';
my ($name_1, $spouse_name_1) = ($init_vars)x2;
> }
>
> {
my @init_vars = (1,7,9);
my (@blarg) = @init_vars;
> }
>
> {
my $rh_data_record = {};
> }
Four (slightly) different scenarios, all easily handled with existing
perl syntax. Choose the one which fits best.
--
John Porter
RFC 115 (v2) Overloadable parentheses for objects
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Overloadable parentheses for objects
=head1 VERSION
Maintainer: pdl-porters team <[EMAIL PROTECTED]>
Date: 16 August 2000
Last Modified: 10 September 2000
Mailing List: [EMAIL PROTECTED]
Number: 115
Version: 2
Status: Developing
=head1 ABSTRACT
This RFC proposes syntactic support for a polymorphic method
that can be defined for blessed references. It would
allow the parentheses C<()> to be used for a variety of convenient
syntaxes for objects. This is principally motivated by a need
of PDL for a simple syntax of PDL object slicing.
=head1 DESCRIPTION
=head2 Motivation
Currently, PDL objects have to use quite an unwieldy syntax
for the all important slicing and indexing. In perl5 the syntax is
$n1 = $n-1; # since we need to stringify
$y = $x->slice("0:$n1:4");
$y = $x->slice("0:${\($n-1)}:4"); # even more horrible
This should be contrasted with the less cluttered syntax offered
by numerical Python and commercial systems such as Matlab and IDL:
y = x[0:n-1:4];
In perl we desire to say:
$y = $x(0:$n-1,4); # or, depending on the choice of separator
$y = $x(0:$n-1;4); # see also RFC 169
Note that we need to keep l-value subs in perl6 to avoid related
types of syntactical clumsiness if C<$x()> can invoke a subroutine
(see below).
$x(0:$n-1:4) *= 2;
should be allowed, as well as the long form
$x->slice(0:$n-1:4) *= 2;
L and related RFCs propose introducing ranges as part of the
syntax cleanup, this RFC proposes C<()> overloading for
objects.
=head2 Overloading C<()>'s
If classes allowed the definition of a method that is invoked with a
syntax akin to one used with sub refs (but without the need for the
C<&> dereferencing) we could have the cake and eat it. The parentheses
method notion seems general enough to be useful for other classes.
=head2 Examples:
A possible scenario could be as follows. The class PDL
defines a default method that is invoked when a syntax
like
$(args)
is used, where C<$Evariable_nameE> is supposed to be an
instance of the class in question (here PDL).
The PDL package would contain the definition of the
method C (a polymorphic method along the lines of RFC 159):
package PDL;
sub PARENTHESES {
my $this = shift;
$this->slice(@_);
}
This would allow for the creation of a variety of powerful syntaxes
for different kinds of objects. For example in PDL we might
wish to use C<()> to slice by index value and in a derived class
PDL::World C<()> would slice by physical real-value coordinate.
One could think of this as saying that C<()> is an
operators which can be overloaded.
Note that we still would like to have such a feature even if
Perl 6 provided its own multi-dim array type. It would
give us the freedom to provide an object oriented interface
to these arrays and/or derive classes from it I have
convenient slicing syntax.
=head1 IMPLEMENTATION
Changes to the parser to allow the new syntax.
We are not aware of any other conflicts with existing
or proposed language features.
=head1 SEE ALSO
RFC 159: True Polymorphic Objects
RFC 117: Perl syntax support for ranges
RFC 81: Lazily evaluated list generation functions
RFC 169: Proposed syntax for matrix element access and slicing
L (http://pdl.sourceforge.net/PDLdocs)
http://pdl.perl.org
Numerical Python: http://starship.python.net/~da/numtut/
Re: RFC 199 (v2) Another question...
Garrett Goebel wrote: > However it still doesn't answer how you are able to: > > return $true and next; > return $false and next; > return $true and last; > return $false and last; > return $true and redo; > return $false and redo; What if the semantics of C are changed so that the actual sub exit does occur until the end of the currently executing statement? I.e. C would place X on the return stack and set a special flag meaning "exit the sub at your earliest convenience" which would be defined as not sooner than the end of the current expression. -- John Porter We're building the house of the future together.
Re: $a in @b
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes: AS> Chaim Frenkel <[EMAIL PROTECTED]> writes: >> yield EXPR - stop what I am doing now and give something else a >> a chance to do its things. And while you are doing >> that please take this EXPR from me. AS> When you put it this way, isn't C spelled C in Perl5? AS> (Except, of course, that C inside a C does a whole lot AS> more nowadays). Err, no. return is much stronger. It goes to the caller of the sub. Yield would be relative to a much tighter scope. I think Randal would reject this, but if we make it an error to have a last/next/redo reach outside of a visible lexical scope, then last,next,redo would be 'weakest', followed by yield, return, die (and whatever is used for exceptions.) -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RFC 94 (v2) Rename @ARGV to @ARGS
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Rename @ARGV to @ARGS =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 11 Aug 2000 Last-Modified: 11 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 94 Version: 2 Status: Retracted =head1 ABSTRACT Perl isn't C. Time to get over it. :-) =head1 NOTE ABOUT RETRACTION Beginner-friendly, at the expense of all the experts. Bad Idea. =head1 DESCRIPTION @ARGV is Perl's version of something like C's argv/argc. However, I would argue its naming is bad, because: 1. It isn't used like and doesn't behave like C's argv/argc in many circumstances 2. There's no $ARGC to go with it 3. It's not a word or anything close to a word 4. Perl isn't C (thank heavens!) 5. @ARGV makes little sense to people (like me) from a sh/ksh background @ARGS is a better choice for several reasons: 1. It's closer to a word and so is faster to read [1] 2. It's easier to explain and remember "Your command-line args are contained in @ARGS" 3. When you say "$var = $ARGS[2]" it's easier to glance at and tell what you're getting quickly 4. It makes it more consistent with other word-like Perl vars like $VERSION. 5. There's no expectation that it works like or should be used like C's argv/argc I don't feel this is changing something just for the sake of changing something. I think it actually helps clarify a key difference between Perl and C. However, feel free to disagree with me. Be nice. ;-) =head1 IMPLEMENTATION Change @ARGV to @ARGS. Make sure that the translator changes any code references in a person's script too. Make sure shift works on @ARGS, etc, etc. =head1 NOTES [1] This is true. I did a lot of work in cognition and artifical intelligence in college. Your brain reads words and legal word-like constructs about 3 times faster than non-words, even if there's only a one or two character difference. For example, you'd read "fleggies" much faster than "fleggitg". Kind of neat, eh? =head1 REFERENCES
RFC 175 (v2) Add C keyword to force list context (like C)
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Add C keyword to force list context (like C) =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 29 Aug 2000 Last-Modified: 11 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 175 Version: 2 Status: Retracted =head1 ABSTRACT Currently, we have a C keyword to force scalar context. However, we have no corresponding C keyword, leading to constructs like this: foo( () = bar() ); # force list context Which are clumsy, at best. Do they work? Yes. Is it easily readable and maintainable code? Not really. This RFC proposes a new keyword, C, which forces list context. This means the above can simply be written as: foo(list bar()); # force list context Which is consistent with similar uses of C, and also makes the code much more readable. This RFC does NOT propose any other keywords because they are unnecessary. All data types in Perl are built on lists and scalars. =head1 NOTES ON RETRACTION On the surface makes sense. But in reality...Bad Idea. http://www.mail-archive.com/perl6-language%40perl.org/msg03404.html http://www.mail-archive.com/perl6-language%40perl.org/msg03489.html =head1 DESCRIPTION =head2 The Proposal The purpose of this RFC is to increase clarity, make easy things easier, and make Perl contexts more accessible. It is not to supplant the current implicit typing methods, which are a beautiful thing. The new C context keyword makes things clearer and easier to understand in some situations, just like C: foo(list bar()); # easy foo( () = bar() ); # not as easy foo(bar()); # easy foo(scalar bar()); # not as easy $count = list split /!/; # easy $count = () = split /!/; # not as easy my($arg1) = func;# easy my $arg1 = list func;# not as easy my $num = @a;# easy my($num) = scalar @a;# not as easy my($nextvar) = scalar ; # Camel-3 p. 778, for clarity my $nextvar = ; # implicit Here, C can be used to force list context, just like C can be used to force scalar context. And, as the Camel-3 example shows, it can be used for greater clarity if you so desire just like C. There are several arguments against C, so I'll spend the remainder of the RFC addressing them. There has already been a huge discussion on this as well; please see the REFERENCES for links to the thread. =head2 Arguments Against =head3 We don't need C, it's unnecessary So is C. There are ways around using C, just as there are ways around using C. While they are not exactly analogous workarounds, there is still no real reason C is needed and C is not. Consider: $num = scalar @a; # scalar explicit $num = @a;# scalar implicit $num = list @a; # list explicit ($num) = @a; # list implicit We don't need 6 trigonometric functions, either - everything can be derived from C. However, we support them to make easy things easier. The same philosophy should apply here. =head3 What next, C, C, and other keywords? No. Every Perl data type is built on either a C (arrays and hashes) or a C (scalars) context. Other contexts are not analogous or even closely related. =head3 Forcing C context is not a common problem If it weren't, then it wouldn't have spawned a huge discussion already. Also, Perl books would not have to make special notes of how to artificially enforce C context with special constructs: () = funkshun(); $x = ( () = funk() ); Which could be easily rewritten as: list funkshun; $x = (list funk);# with one keyword, or... $x = scalar list funk; # can chain to make explicit Thanks to the new C keyword. =head3 The keyword C adds nothing new Except clarity, simplicity, and consistency, without having to sacrifice any part of the existing language. If you don't like it, don't use it. =head1 IMPLEMENTATION Hold on. =head1 MIGRATION None. This adds new functionality. =head1 REFERENCES Camel-3, p. 778 (The section on C) Thanks to Bart Lateur for his input There was an extensive, heated discussion between Tom C and myself on this topic. I will post a link to the email archive as a follow-up after this posts (it is not currently available on mail-archive.com).
RE: RFC 199 (v2) Another question...
From: 'John Porter' [mailto:[EMAIL PROTECTED]]
>
> Garrett Goebel wrote:
> > However it still doesn't answer how you are able to:
> >
> > return $true and next;
> > return $false and next;
> > return $true and last;
> > return $false and last;
> > return $true and redo;
> > return $false and redo;
>
> What if the semantics of C are changed so that the actual
> sub exit does occur until the end of the currently executing
> statement?
Well, that would break most all code that has multiple conditional returns
in a function. I'm not sure how a Perl 5 -> 6 translator would handle:
sub AUTOLOAD {
return if $AUTOLOAD =~ /DESTROY$/;
...
}
Re: RFC 199 (v2) Another question...
>However it still doesn't answer how you are able to: >return $true and next; >return $false and next; >return $true and last; >return $false and last; >return $true and redo; >return $false and redo; BZZZT You *aren't* able to do that, silly! However, if you would please please just stop using those gratuitous and annoying tricksy-trickie alphabetic ops, and then you can. return $true && next; return $false && next; return $true && last; return $false && last; return $true && redo; return $false && redo; #!/usr/bin/tchrist -w use less precedence; no tricks; use parens; --tom
RFC 208 (v1) crypt() default salt
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
crypt() default salt
=head1 VERSION
Maintainer: Mark Dominus <[EMAIL PROTECTED]>
Date: 11 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 208
Version: 1
Status: Developing
=head1 ABSTRACT
A frequently-asked question is how to generate an appropaite random
salt for password encryption. I propose that Perl generate the salt
automatically if the salt argument is omitted in the call to crypt().
=head1 DESCRIPTION
At present, crypt() requires two arguments:
crypt PLAINTEXT,SALT
It then passes these arguments directly to the C library crypt()
function.
When encrypting a new password, the programmer is required to generate
a salt at random:
@letters = ('A' .. 'Z', 'a' .. 'z', '0' .. '9', '/', '.');
$salt = $letters[rand@letters] . $letters[rand@letters];
$passwd = crypt($passwd, $salt);
This is inconvenient and nonportable. It's also nonobvious: people
frequently ask in the newsgroups how to do it. I propose that if the
SALT argument is omitted, Perl should generate an appropriate salt
internally and use that.
$passwd = crypt($passwd);# Same as above
On systems where the password format is different, Perl can do the
appropriate thing.
=head1 IMPLEMENTATION
For the standard DES-based crypt, the implementation is
straightforward trivial. Perl already has many functions that take an
optional argument, and the C internals of the random-salt generator
are well-known.
Details will vary for systems using alternative password hashing
schemes. On some systems, no salt need be generated. These can be
taken care of with a suitably ifdef'ed section of code if necessary.
If the random number generator has not yet been seeded, Perl should
seed it.
=head1 MIGRATION
C with only one argument is presently a compile-time error,
so there are probably few translation issues. The meaning of this
program will change:
$" = ', ';
$code = "crypt(@ARGV)";
eval $code;
die $@ if $@;
But I don't think this is anything to worry about---it should fall
into the "other 5%" category.
=head1 REFERENCES
perlfunc manpage for discussion of crypt()
crypt(3)
RFC 209 (v1) Fuller integer support in Perl.
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Fuller integer support in Perl. =head1 VERSION Maintainer: Shane Kerr <[EMAIL PROTECTED]> Date: 11 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 209 Version: 1 Status: Developing =head1 ABSTRACT Perl currently allows blocks of code to use integer math for both increased performance and integer semantics. This should be extended to allow programs to specify both the size and signedness of integers. =head1 DESCRIPTION Programs sometimes need to operate on values that map in a natural fashion to integers of specific size. For example, IPv4 addresses may most naturally be represented as unsigned 32-bit integers. By default, Perl uses floating point numbers, but precision is lost in the 32-bit integer range. Currently the only safe alternative is to use strings for this range, e.g. 0-padded hexidecimal numbers. In order to both save memory and allow more rapid processing, Perl should support the ability to specify both the size and signedness of numbers for a given block. =head1 IMPLEMENTATION Programs will specify arithmetic processing in typical Perl fashion: use integer qw(32bit unsigned); use integer qw(64bit); Perl semantics will reflect this value until the end of current block. =head1 REFERENCES perldoc integer for discussion of current integer support
Re: RFC 103 (v1) Fix print "$r->func" and $pkg::$var precedence
Nathan Wiger wrote:
>
> > Foo::Bar->stickysnort()
>
> Right, knew I forgot something...
>
> > I wonder whether the "I want to expand arbitrary expressions within
> > strings even when there aren't any $ or @ symbols about" people
> > just need better familiarity with the alternatives.
>
> This was all spawned by a consistency argument brought up by Bart on
> "where to draw the line" with having -> interpolate:
>
> http://www.mail-archive.com/perl6-language@perl.org/msg03658.html
> http://www.mail-archive.com/perl6-language@perl.org/msg03659.html
>
> If instead we chose to draw the line at needing a $, I'm fine with that,
> as long as the line is well-defined and allows for class methods to
> interpolate in qq// strings.
Not entirely unrelated:
Last weekend I got tired of writing
print "Reduced symbol ".$parser->dump_sym($sym)." via rule
".$parser->dump_rule($r).", went to state
".$parser->dump_kernel($k)."\n";
and wrote a very simple module, let's call it Magic:
use Magic;
my (%DSym, %DRule, %DKernel);
register_magic(\%DSym, 'dump_sym', $parser);
register_magic(\%DRule, 'dump_rule', $parser);
register_magic(\%DKernel, 'dump_kernel', $parser);
.
.
.
print "Reduced symbol $DSym{$sym} via rule $DRule{$r}, went to state
$DKernel{$k}\n";
Much nicer. You can even use this to replace map:
register_magic(\%Size, sub { -s $_[0] });
@sizes = @Size{@filenames};
Define the map function once, use it all over the place. (Slowly. This
is using tie()).
More relevant to the current discussion,
register_magic(\%ID, sub { $_[0] });
print "f(1,2,3) = $ID{f(1,2,3)}\n";
Does anyone remember who I stole this idea from? mjd, I think. Ah, yes,
here it is: Interpolate.pm.
Re: auto-initializing values
At 11:55 AM 9/11/00 -0600, Tom Christiansen wrote: >I like this idea Can you explain why? I don't like it, too much action-at-a-distance for me. Does it propagate to enclosed scopes? If I do it at the outer level does it go through the whole file? I would assume so. It's not something I've ever wanted. Have you? -- Peter Scott Pacific Systems Design Technologies
RE: auto-initializing values
On Mon, 11 Sep 2000, Myers, Dirk wrote:
> >Suppose you could specify the value with which all variables
> >in the enclosing scope should be initialized; for example:
>
> I haven't seen this either, but I suggest that it should be a set of
> pragmas:
> use init_scalar 0 ;
> use init_array () ;
>
> ... especially because I'm not sure what effect :
>
> init_vars = \{} ;
>
> my @foo ;
>
> should have. (Probably none, but how do you specify default values if you
> want to init multiple kinds of data in the same scope?)
My suggestion would be that it simply have no effect. On the
other hand, if a "initial size" attribute were added to arrays, then this
could be very useful...say that you have 50 employees, each of whose data
is stored in a hash. Here's an easy way to get a list of references to
all the hashes, with error handling built in:
init_vars \{name => 'NONE'};
my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
@employees = get_from_db('*');
for (@employees) {
if ( $_{name} eq 'NONE' ) {
die "Oops! DB error\n";
}
}
Dave
Re: auto-initializing values
Dave Storrs wrote:
>
> if a "initial size" attribute were added to arrays, then this
> could be very useful...say that you have 50 employees, each of whose data
> is stored in a hash. Here's an easy way to get a list of references to
> all the hashes, with error handling built in:
>
> init_vars \{name => 'NONE'};
> my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
> @employees = get_from_db('*');
> for (@employees) {
> if ( $_{name} eq 'NONE' ) {
> die "Oops! DB error\n";
> }
> }
I still don't see any compelling benefit for new syntax here.
Old syntax works great.
my @employees = map { { name => 'NONE' } } 1..50;
By the way, regardless of how @employees gets initialized above,
that initialization gets blown away by the next thing you do:
> @employees = get_from_db('*'); # only got 2 records???
Unfortunately, your approach in this particular case is flawed.
You could do something like this, which is ripe for optimizations:
for ( @employees ) {
get_from_db( \$_, '*' );
# may or may not have assigned some fields...
--
John Porter
We're building the house of the future together.
Re: $a in @b
I don't want 'return' to have any meaning other than returning from a
subroutine, nor do I want the word 'goto' to appear in my code except for
goto &sub.
How about we just allow last, redo, next to take another argument, which
provides the final or intermediate value of a block whose value is being
used? First argument can be undef for nearest enclosing block. Yes, it
looks a little weird, but this is a relatively uncommon thing to want to do
and not worth IMHO creating a new keyword for, so why shouldn't it look
weird. Hence:
$foo = do { last undef, $bar if baz($bar) } while $bar++;
@list = grep { last undef, '' if /sentinel/; baz($_) } @thingies;
@list = grep { next undef, 'okay' if /sentinel/; baz($_) } @thingies;
etc. I'm assuming that one would want to retain the capability to last,
next etc out of an outer enclosing labelled loop, otherwise I'd just
propose overloading the one argument and say that if it's a reference, take
the thing it refers to as the value and exit/continue the nearest enclosing
loop.
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> The underlying problem is that arrays don't make SENSE as an
>> implementation for sets.
TC> And even in those rare places where they do, to use them as such
TC> is gratuitously counter-efficient.
Why? How is
@main_list = ;
@more_stuf = ;
@just_to_do_a_job{@main_list} = ();
@just_to_do_a_job{@more_stuff} = ();
@main_list = keys %just_to_do_a_job;
more or less efficient than
@main_list union= @more_stuff;
Both have to go through the same amount of work ("work is conserved")
but one is more efficient in terms of the user's brainpower.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "AS" == Ariel Scolnicov <[EMAIL PROTECTED]> writes: AS> They're going to be useful to a tiny minority of users: math folks AS> whose application matches the use of a hash-based implementation. AS> (Actually, all uses I've seen of set datatypes were strictly outside AS> mathematics, but that doesn't alter your argument or mine). The AS> problem is that the desired semantics (in the sense, e.g., of AS> worst-case, average-case, and "my-case" complexity) of the "set" AS> datatype vary greatly with application. Tiny minority? I'm no mathematician, but I've used set operations to avoid redoing known work. And I've used hashes simply because I have no other 'lazy' choice. But the code becomes harder to read. >From a conceptual level, when looking at the code (not the surrounding application) I'm no longer working with the data, but rather with a side effect. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC 208 (v1) crypt() default salt
On Mon, Sep 11, 2000 at 07:10:36PM -, Perl6 RFC Librarian wrote: > =head1 TITLE > > crypt() default salt I've whipped out a quick prototype for this RFC. http://www.pobox.com/~schwern/src/RFC-Prototype-0.01.tar.gz Nothing fancy. The major thing missing is how to deal with multiple crypt() impelementations (ie. DES vs MD5 vs whatever). -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
RE: $a in @b
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> I don't want 'return' to have any meaning other than returning from a
> subroutine
Which it wouldn't since the {} block in grep is a code block ;)
Garrett
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
Chaim Frenkel wrote:
>
>TC> And even in those rare places where they do, to use them as such
>TC> is gratuitously counter-efficient.
>
>Why? How is
>
> @main_list = ;
> @more_stuf = ;
>
> @just_to_do_a_job{@main_list} = ();
> @just_to_do_a_job{@more_stuff} = ();
>
> @main_list = keys %just_to_do_a_job;
>
>more or less efficient than
>
> @main_list union= @more_stuff;
>
>Both have to go through the same amount of work ("work is conserved")
>but one is more efficient in terms of the user's brainpower.
Why not simply do
@main_list = (@main_list, @more_stuf); ?
What? You say you don't want duplicates in the resulting list?
Why didn't you say so?
So how is the hypothetical union operator going to check for dupes?
Loop over each element of the first array, checking whether it is
contained somewhere in the second array (by looping over it)?
Dude, O(m*n) ain't good.
Or perhaps you think that Perl should do for you what you're not
willing to do for yourself: it should create two temporary hashes
to do the collision detection. A lookup table is a great way to
find collisions, right? And a hash is a great way to implement a
lookup table, right? Yes! So Perl should internally create hashes
to do your union operator. And intersection operator. And whatever.
But don't you think creating and destroying all those temporary
hashes is going to be a waste of your computer's time? I mean, I
know hardware is cheap and all, but
Why not create a permanent lookup table of all the elements of each
of your sets. Wouldn't that be a good optimization? Sure! So instead
of:
@first_list = qw/one two three/;
@second_list = qw/two four six/;
create hashes:
%first_set = map {$_=>()} qw/one two three/;
%second_set = map {$_=>()} qw/two four six/;
Don't like that ugly syntax? Can't remember it? Here's a free sub for
you:
sub create_set { map {$_=>()} @_ }
"But," I hear you wail, "I like using arrays for sets! It makes sense
to me!". Tell me, Chaim, how DO you test for membership in your array
world? grep?
if (grep {$_ eq 'three'} @first_list)
Talk about ugly. And slow: O(n/2). What's wrong with:
if (exists $first_set{three})
Simple, elegant, fast. O(1), more or less.
You think hash functions are ugly? Then wrap them in functions so
you don't have to look at them.
How *do* you propose to implement union and intersection with arrays,
internally in Perl? Any idea? Double-looping over the arrays is
horribly slow. Forcing Perl to create and destroy lookup tables each
time is wasteful. Did you have a better idea?
If you want Perl to have core support for widgets like union and
intersection, that's one thing. Make a case for it. But you have
repeatedly tried to make a case for arrays as set representations
and you have not made a good case yet. Your least-bad argument has
been that arrays "make more sense to you" than hashes. Does execution
time mean nothing to you?
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: Thanks for the summary. (I wish you would be able or have the time to exand more often on your positions.) TC> I think you still have some big hurdles here, however. Lists are TC> crappy set reps. I don't want a set representation. I want set operations. And somehow for this having to add a use statment and who knows what overhead for what seems to be a simple operation is a pain. >From an efficiency standpoint, all of the hash overhead (allocating buckets, assigning values, etc.) can be chucked all I would need is the key management part. Which could probably be boiled down to converting the hash key into a bit. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: auto-initializing values
On Mon, 11 Sep 2000, John Porter wrote:
> Dave Storrs wrote:
> >
> > init_vars \{name => 'NONE'};
> > my @employees : size 50; # 50 entries, each a ref to 1 elem. hash
> > @employees = get_from_db('*');
> > for (@employees) {
> > if ( $_{name} eq 'NONE' ) {
> > die "Oops! DB error\n";
> > }
> > }
>
> I still don't see any compelling benefit for new syntax here.
> Old syntax works great.
>
> my @employees = map { { name => 'NONE' } } 1..50;
Ok, this is a fine complaint. Which is why I started this thread
with the question "Would it be useful if"
> By the way, regardless of how @employees gets initialized above,
> that initialization gets blown away by the next thing you do:
>
> > @employees = get_from_db('*'); # only got 2 records???
>
> Unfortunately, your approach in this particular case is flawed.
*Sigh* This, unfortunately, shows that you completely missed my
point. The point of the exercise was to set up some variables (the entries
in the array), initialize them with sentienl values (i.e., values that are
known to be invalid), fill them with information from a DB, and then check
to make sure that you actually got valid info into each variable. As
regards the imaginary function "get_from_db('*')"...I expected it to be
understood that that meant "get all records from the DB."
Dave
RE: $a in @b (RFC 199)
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> Randal L. Schwartz wrote:
> >
> > Yes, I'd be in favor of making return() in a valued block
> > (as opposed to a looping block) abort the block early and
> > return the value.
> Imho, it should return the value, but not abort the block.
I.e. stick with the current behaviour. -Yes, I'd be surprised if
sub mygrep (&@) {
my ($coderef, @list, @stack) = @_;
&$coderef and push(@stack, $_) foreach (@list);
return @stack;
}
@a = mygrep { return ($_ <= 2) ? 1 : 0 } (1, 2, 3, 2, 1);
print "\@a = @a\n";
Resulted in: @a =
Instead of the current Perl 5: @a = 1 2 2 1
> After all, grep is (ostensibly) prototyped as grep(&@), so I
> expect to pass it a sub block. And that block gets called
> once per iteration over the input list; "return" is what I
> expect it to do once per iteration, implicitly; so using
> C explicitly to mean "no further iterations" is highly
> counterintuitive, or at least inconsistent.
RE: $a in @b (RFC 199)
From: Nathan Wiger [mailto:[EMAIL PROTECTED]]
>
> Ariel Scolnicov wrote:
> >
> > Chaim Frenkel <[EMAIL PROTECTED]> writes:
> >
> > > yield EXPR - stop what I am doing now and give something else a
> > > a chance to do its things. And while you are doing
> > > that please take this EXPR from me.
> >
> > When you put it this way, isn't C spelled C in Perl5?
> > (Except, of course, that C inside a C does a whole lot
> > more nowadays).
>
> And except that C allows you to pick up where you left
> off later, at least per Damian's RFC 31: "Co-routines". For a
> grep/map this could potentially be really useful, especially
> if you have code that modifies values in your block but want
> to do it conditionally/iteratively.
I wouldn't argue that C would be a useful in the context of C
and C. But it doesn't solve the problem (RFC 199) of short-circuiting
C and C if you have no intention of preserving state.
grep { 1 } 1..1_000_000;
Garrett
Re: $a in @b (RFC 199)
Garrett Goebel wrote:
>
> I'd be surprised if
>
> sub mygrep (&@) {
> my ($coderef, @list, @stack) = @_;
> &$coderef and push(@stack, $_) foreach (@list);
> return @stack;
> }
>
> @a = mygrep { return ($_ <= 2) ? 1 : 0 } (1, 2, 3, 2, 1);
> print "\@a = @a\n";
>
> Resulted in: @a =
> Instead of the current Perl 5: @a = 1 2 2 1
Yes! *Exactly* my point! Blocks should quack the same whether
I pass them to the built-in grep or to my own sub; i.e. they're
anonymous subs, not some magico-special "looping" blocks.
--
John Porter
We're building the house of the future together.
Re: $a in @b (RFC 199)
On Mon, Sep 11, 2000 at 05:31:33PM -0400, 'John Porter' wrote:
> Garrett Goebel wrote:
> >
> > I'd be surprised if
> >
> > sub mygrep (&@) {
> > my ($coderef, @list, @stack) = @_;
> > &$coderef and push(@stack, $_) foreach (@list);
> > return @stack;
> > }
> >
> > @a = mygrep { return ($_ <= 2) ? 1 : 0 } (1, 2, 3, 2, 1);
> > print "\@a = @a\n";
> >
> > Resulted in: @a =
> > Instead of the current Perl 5: @a = 1 2 2 1
>
> Yes! *Exactly* my point! Blocks should quack the same whether
> I pass them to the built-in grep or to my own sub; i.e. they're
> anonymous subs, not some magico-special "looping" blocks.
Allow me to repeat: instead of trying to shoehorn (or piledrive) new
semantics onto existing keywords/syntax, let's create something new.
The blocks of grep/map/... are special. They are not quite looping
blocks, they are not quite sub blocks, they are different. Well, to
be frank they are just very plain, ordinary, blocks that return their
last value, but if we want to introduce both flow control
(short-circuiting) and as a derived requirement, a return value
(was the last test a success or a failure), they definitely begin to
become not your ordinary blocks. I do not think the existing arsenal
of keywords/syntax is enough to cover all the behaviour we are after.
The 'pass' keyword someone suggested has potential (when combined with
allowing last -- and next -- to work on these mongrel blocks).
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>>> The underlying problem is that arrays don't make SENSE as an
>>> implementation for sets.
>TC> And even in those rare places where they do, to use them as such
>TC> is gratuitously counter-efficient.
>Why? How is
> @main_list = ;
> @more_stuf = ;
> @just_to_do_a_job{@main_list} = ();
> @just_to_do_a_job{@more_stuff} = ();
> @main_list = keys %just_to_do_a_job;
>more or less efficient than
> @main_list union= @more_stuff;
>Both have to go through the same amount of work ("work is conserved")
>but one is more efficient in terms of the user's brainpower.
Only if you made the mistake of using the wrong data structure all
along -- that is, an array.
--tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>I don't want a set representation. I want set operations. And somehow >for this having to add a use statment and who knows what overhead for >what seems to be a simple operation is a pain. The overhead is not that it should be a module, but rather, the sillily/evilly inefficient thing that *you* are doing. Or trying to do. We have modules to do this. We have hashes to do this. We have the technology. It is ignored. Ignorance of technology is no excuse for adding strange basic types and operations on them into the very heart of a programming language. --tom
Re: $a in @b
> DC> I would propose that the C operation should short-circuit if the > DC> block throws an exception, with the value of the expection determining > DC> whether the final invocation of the block should accept the element it > DC> was filtering: > > Why not spell it 'yield'? > > It seems to have all the right connotations. > > A sort of soft return. Gives of itself. Very polite. :-) I did consider that too, but the problem is that according to RFC 31 a C leaves the future entry point of a block at the next statement after the C, whereas the block needs to start from the beginning on each iteration. Damian
RE: Beefier prototypes (was Re: Multiple for loop variables)
> I'm under the impression that "&" used in a function prototype signifies > that the function takes a code block. That's right. As I said in another post, I'm functioning rather poorly just at the moment. :-( Damian
Re: Beefier prototypes (was Re: Multiple for loop variables)
> Does the prototype help guide the decision that it is a block and not
> an anon-hash?
Yes, as it does now in the existing prototype mechanism. For example:
use Data::Dumper 'Dumper';
sub takes_block (&) { print "takes_block: ", Dumper $_[0] }
sub takes_any { print "takes_any: ", Dumper $_[0] }
takes_block { a => print("then\n"), b => 2 };
takes_any { a => print("then\n"), b => 2 };
Damian
Re: $a in @b
> Either last has to be extended with a return value or a new keyword > is needed. I'm quite partial to yield. Which might be overloaded > to work with lazy lists, continuations, and short-circuiting. > > yield EXPR - stop what I am doing now and give something else a >a chance to do its things. And while you are doing >that please take this EXPR from me. The problem is, C also means "..and when this code is next executed start at the line after this C". Which is *not* the desired semantics. Damian
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes:
>> Both have to go through the same amount of work ("work is conserved")
>> but one is more efficient in terms of the user's brainpower.
TC> Only if you made the mistake of using the wrong data structure all
TC> along -- that is, an array.
But a Hash isn't the correct data structure either. It just has some,
of the correct properties.
Perhaps we should add a Set to the toolkit. Basically a hash with
only the keys, no other baggage.
But you still would argue against the operators/functions? Ignoring
spelling.
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>But a Hash isn't the correct data structure either. It just has some, >of the correct properties. Whatever. >Perhaps we should add a Set to the toolkit. Basically a hash with >only the keys, no other baggage. Define "toolkit". >But you still would argue against the operators/functions? Ignoring >spelling. In Perl? Of course. In a module? Of course not. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>Basically a hash with >only the keys, no other baggage. If you don't want but the keys, don't use but the keys. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
> "TC" == Tom Christiansen <[EMAIL PROTECTED]> writes: TC> The overhead is not that it should be a module, but rather, TC> the sillily/evilly inefficient thing that *you* are doing. TC> Or trying to do. Why, For example, I need it as a sorted array 90% of the time. Some of the time I need/want to add a unique element. So, what do I do, keep it as an array and sort every time I access it? Keep two copies one as the hash the other as an array? TC> We have modules to do this. We have hashes to do this. TC> We have the technology. It is ignored. Ignorance of TC> technology is no excuse for adding strange basic types TC> and operations on them into the very heart of a programming TC> language. I'm not ignorant of the technology. But having a method that directly represents my thought process, and does something that I need would be a win for me. Time for another missive in language design of why pop and push, shift and unshift are in, but union and intersection are not. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: $a in @b
> > Either last has to be extended with a return value or a new keyword
> > is needed. I'm quite partial to yield. Which might be overloaded
> > to work with lazy lists, continuations, and short-circuiting.
> >
> > yield EXPR - stop what I am doing now and give something else a
> >a chance to do its things. And while you are doing
> >that please take this EXPR from me.
>The problem is, C also means "..and when this code is next
>executed start at the line after this C".
>Which is *not* the desired semantics.
I don't quite see yeild as being that. I think more in terms of driving a car.
Give precedence to someone else but keep running, either way not quite the
best word... not bad but not optimium (if you're into making the word mean
what it does)
What about feign?
feign \'fa-n\ vb [ME feignen, fr. OF feign-, stem of feindre, fr. L
fingere] to shape, feign - more at DOUGH 1a: to represent by a false
appearance of : SHAM 1b: to assert as if true : PRETEND archaic 2a:
INVENT, IMAGINE 2b: to give fictional representation to obs 3: DISGUISE,
CONCEAL : PRETEND, DISSEMBLE - feign.er n
This is a nice general word, and this keyword could be used elsewhere as
well... How about "a general means of short-circuting a block"?
skip is another word, but it seems to connote a loop. and we already have
words for those.
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Prickle-Prickle, the 35th of Bureaucracy, in the YOLD 3166:
Were that I say, pancakes? --JP
Re: $a in @b
Pardon my repetitiousness, but I'm puzzled at the total lack of response AFAICS to my proposal for a second argument to next/last/redo. Was it so stupendously moronic as to be beneath anyone's dignity to rebut, or what? Either I'm out of it, or it looks a whole lot more appealing than a new keyword. $0.02. -- Peter Scott Pacific Systems Design Technologies
Re: $a in @b
>Pardon my repetitiousness, but I'm puzzled at the total lack of response
>AFAICS to my proposal for a second argument to next/last/redo. Was it so
>stupendously moronic as to be beneath anyone's dignity to rebut, or
>what? Either I'm out of it, or it looks a whole lot more appealing than a
>new keyword.
IMHO THAT (two args) would be overkill. These are operators, simple flow
control words that also make the source very easy to read.
i really can;t see adding a second arg because ythen you're going to have
to do stuff like
next undef, 1
etc. which is wholly unappetizing. The only way I myself see extending
current words is to use some special label name. not that that is very nice...
Only if this special name perhaps contained a character which is not valid in
a label... (are there any? [:*] ?)
I personally like the idea of somehting like feign (or whatever it's called),
nice and generic. But if not that and not 2 arg next etc. And I may have
missed this thread if someone hit upon it, but what's wrong with
allowing something like
grep ITEM: { /^[1-9]/ || next ITEM } @list;
--
#!/usr/bin/perl -nl
BEGIN{($,,$0)=("\040",21);@F=(sub{tr[a-zA-Z][n-za-mN-ZA-M];print;});
$_="Gnxr 1-3 ng n gvzr, gur ynfg bar vf cbvfba.";&{$F[0]};sub t{*t=sub{};
return if rand()<.5;$_="Vg'f abg lbhe ghea lrg, abj tb.";&{$F[0]};$_=0;}
sub v{print map sprintf('%c', 2**7-2**2),(1 .. $0);}&v;}{$_++;$_--;$_||=4;
if($_>>2||($_<<2>12)){$_="Vainyvq ragel";&{$F[0]};last;}&t;$0-=$_;$_="Lbh jva";
die(&{$F[0]}) if !($0-1);$0-=$0%2?$0>2?2:1:$0<=5?$0>2?3:1:rand>.5?1:3;
$_="V jva";die(&{$F[0]}) if !($0-1>1);}&v __END__ http://pthbb.org/
MOTD on Prickle-Prickle, the 35th of Bureaucracy, in the YOLD 3166:
Were that I say, pancakes? --JP
Re: RFC 115 (v2) Overloadable parentheses for objects
> The PDL package would contain the definition of the
> method C (a polymorphic method along the lines of RFC 159):
>
> package PDL;
>
>
>
> sub PARENTHESES {
> my $this = shift;
> $this->slice(@_);
> }
I'd suggest PARENS to save typing and spelling mistakes, but the idea
seems to jive well with RFC 159 otherwise.
-Nate
Re: RFC 209 (v1) Fuller integer support in Perl.
> Programs will specify arithmetic processing in typical Perl fashion: > > use integer qw(32bit unsigned); > use integer qw(64bit); > > Perl semantics will reflect this value until the end of current block. I wonder if this wouldn't be better handled on an item-by-item basis like other languages that use types? my int $x : 64bit = some_big_val(); my int $y : 32bit, unsigned = 5; my float $z; -Nate
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>I'm not ignorant of the technology. But having a method that directly >represents my thought process, and does something that I need would be >a win for me. Adding to the core infinitely more new functions in an environment with people screaming to yank stuff out, and still worse, adding new inherent *types* (or else incurring stupid costs) that are of use to only a few, is something that just will not make sense to me. If this were so important, then the existing modules that already do this would be being used all over the place. They aren't. You must account for this lack. I believe this is nearly a non-existence proof. I believe it's because hashes suffice. I have never seen a posted program actually use the set modules, let alone such prevalence of the same that a million people are crying to add some brand new set type to the very core of the language. You're going to have to work incredibly harder than you have to justify adding a new fundamental type when what we already have works perfectly fine. Yes, I do set operations. Yes, I do them in Perl. No, I do not use fufi new types to do it. I simply use the Perl we have, and it works excellently for this purpose. --tom
Re: RFC 179 (v1) More functions from set theory to manipulate arrays
>I need it as a sorted array 90% of the time. Some of >the time I need/want to add a unique element. So, what do I do, keep >it as an array and sort every time I access it? Keep two copies one as >the hash the other as an array? Yep. This is *not* a glaringly common data structure. I can think of a dozen of comparable utility. Some of them I'm really quite fond of. They also do not deserve to be crammed into each and everyone's /usr/bin/perl or brains. --tom
Re: RFC 209 (v1) Fuller integer support in Perl.
Nathan Wiger wrote:
>
> > Programs will specify arithmetic processing in typical Perl fashion:
> >
> > use integer qw(32bit unsigned);
> > use integer qw(64bit);
> >
> > Perl semantics will reflect this value until the end of current block.
>
> I wonder if this wouldn't be better handled on an item-by-item basis
> like other languages that use types?
>
>my int $x : 64bit = some_big_val();
>my int $y : 32bit, unsigned = 5;
>my float $z;
>
> -Nate
Types just seem so very un-perl. There is much to be said for the
universal scalar vairable. I'm not sure I fully understand just why we
NEED types in the language. We have functions such as:
my $integervalue = int($value);
and...
my $float = sprintf("%2.2f", $integervalue);
So what are the benifits of types?
Greg
-
Re: $a in @b
At 09:45 PM 9/11/00 -0400, Jerrad Pierce wrote:
> >Pardon my repetitiousness, but I'm puzzled at the total lack of response
> >AFAICS to my proposal for a second argument to next/last/redo. Was it so
> >stupendously moronic as to be beneath anyone's dignity to rebut, or
> >what? Either I'm out of it, or it looks a whole lot more appealing than a
> >new keyword.
>
>IMHO THAT (two args) would be overkill. These are operators, simple flow
>control words that also make the source very easy to read.
>i really can;t see adding a second arg because ythen you're going to have
>to do stuff like
> next undef, 1
>etc. which is wholly unappetizing.
Well, it's hard to argue matters of taste. All I'll say is that the
capability we're discussing will be so rarely used IMHO that expending a
new keyword for its sake isn't worth it. Keywords exact a high price in
namespace pollution and user brain cells. I know it's debatable whether it
uses any more brain cells than an extra argument to next, but I happen to
find it a bit more intuitive. There again, I would :-)
> The only way I myself see extending
>current words is to use some special label name. not that that is very nice...
>Only if this special name perhaps contained a character which is not valid in
>a label... (are there any? [:*] ?)
>
>I personally like the idea of somehting like feign (or whatever it's called),
>nice and generic. But if not that and not 2 arg next etc. And I may have
>missed this thread if someone hit upon it, but what's wrong with
>allowing something like
>
> grep ITEM: { /^[1-9]/ || next ITEM } @list;
Not much that I can see, but your next does not include any return value,
so what should it be? Of course, if it's false, you didn't need a next in
the first place and if it's true you didn't need a grep in the first place :-)
--
Peter Scott
Pacific Systems Design Technologies
Re: RFC 209 (v1) Fuller integer support in Perl.
Gregory S Hayes wrote:
> Types just seem so very un-perl. There is much to be said for the
> universal scalar vairable. I'm not sure I fully understand just why we
> NEED types in the language. We have functions such as:
>
> my $integervalue = int($value);
>
> and...
>
> my $float = sprintf("%2.2f", $integervalue);
>
> So what are the benifits of types?
>
Efficiency: For instance, an array of identical simple types can be stored
contiguously and accessed directly.
Robustness: Operations which do not make sense for a particular type can be
caught at compile time or at run time. This can make it easier to create
robust programs.
*Allowing* typing is not the same as *demanding* typing. Adding types will
not make the 'universal scalar variable' any less accessible or convenient.
Re: RFC 209 (v1) Fuller integer support in Perl.
Gregory S Hayes wrote: > > Types just seem so very un-perl. There is much to be said for the > universal scalar vairable. I'm not sure I fully understand just why we > NEED types in the language. > So what are the benifits of types? Note: I am *not* claiming to be pro-types. However, in cases such as this they might make more sense. Otherwise, I could potentially see tons of pragmas cascading throughout code to try and satisfy what are really variable-specific concerns. Types do have certain advantages that should not be overlooked regardless of one's religious views on the matter: 1. Storage optimizations 2. Tighter code-checking for crucial applications 3. Mathematical operation optimizations I know there are others, but those are always the ones I remember off the top of my head. Anyways, I'm not for or against this RFC per se, but when we start getting into complex optimizations, variable promotion, storage concerns, and so on, there might be other approaches that are more suitable. You won't be able to get all the "benefits" of true types through a pragma, which is sort of like a hand grenade in that it's block-specific, and not variable-specific. A more fluid approach is to tag a variable that can then be followed throughout the code by Perl. Less for you to worry about with pragmas, and better optimizations potentially as well. This typing wouldn't be mandatory (I haven't heard anyone suggest that), but rather available if you wanted it: my $x = 5.3; my int $y = 10; # ooo! can optimize The thinking I've heard is that you could still do anything you wanted with $y (even assigning strings and floats to it) unless you have Nat's proposed "strict types" on: use strict 'types'; my int $z = 5.3; # nope! later... Basically, default "types" in Perl would really be more like "hints" that could save some valuable time and storage, without causing Perl to be un-fun. -Nate
Please take RFC 179 discussion to -data
Could we please take discussion of 179 to -data? I think that's where it should be. K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Seeking new regex sublist chair
Mark-Jason Dominus has indicated that he would like to be replaced as chair of the regex sublist. Would anyone else like to take on this role for the next few weeks? The responsibilities include: - weekly report to me - guide discussion on regex related issues - encourage RFC authors to redraft towards Frozen or Withdrawn status K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC 209 (v1) Fuller integer support in Perl.
> *Allowing* typing is not the same as *demanding* typing. Adding types will > not make the 'universal scalar variable' any less accessible or convenient. My mistake, I believed that the aforementioned types would become a requirement ala C/C++ and many other languages. Greg -
Language WG quasi-report
There's been a lot of discussion lately on -meta which implies that the RFC/brainstorming process has gotten out of control. I personally think that it's going exactly as it should, and I've seen little to worry about, which is why I've been fairly hands-off apart from trying to get some process-related things sorted out. With regard to the "what's going on on -language" (supposedly) weekly report, I find this very difficult to do, because there really is an awful lot going on. So, I guess my report is: Discussion proceedeth apace. Many RFCs. Most RFCs are redrafting towards being either frozen or withdrawn. The sublists seem to be chugging along adequately. No particularly vitriolic flamewars have erupted. Traffic is more or less manageable, at about 50 posts a day on the main -language list and less on each sublist. However, the September 30 deadline is approaching, and I'm going to start trying to move towards wrap-up. This means chasing down RFCs which haven't been resubmitted lately, and helping others move towards "Frozen" or "Withdrawn". Nathan Wiger has raised some issues regarding conflicting RFCs on similar topics (eg subroutine prototypes) which, ideally, should be redrafted so that one is "Frozen" in a state which represents the WG (or the sub-group) consensus, and the others are "Withdrawn". It will be interesting to see if this can be achieved. K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
