Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

On Tue, Sep 12, 2000 at 05:44:38PM +1100, [EMAIL PROTECTED] wrote: > Schwern wrote: > > Seperating the men from the boys. > > I'll just go get my detachable penis :) That's easily solved with the Tie::Penis module. -- Michael G Schwern http:/

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

Schwern wrote: > Seperating the men from the boys. I'll just go get my detachable penis :) K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne V

Re: The Future - grim.

On Mon, Sep 11, 2000 at 11:49:52PM -0500, J. David Blackstone wrote: > > Presumably the discarding will be heralded with an announcement on the > > mailing list, as well as a note to the maintainer. The interested > > parties should see this and yell. > > Just wanted to get that stated explici

Re: Project management page

J David Blackstone <[EMAIL PROTECTED]> writes: > I think the success criteria on http://dev.perl.org/pm/pos.html > should be more measurable. >> SUCCESS CRITERIA >> 1. Benchmarks of text processing programs show improved performance on > perl6 over perl5. > Yes, but how much improved? Is

Re: XML/HTML-specific ?< and ?> operators?

> :Anyway, Snobol has a nice heuristic to prevent infinite recursion in > :cases like this, but I'm not sure it's applicable to the way the Perl > :regex engine works. I will think about it. > > It is probably worth adding the heuristic above: anytime you recurse > into the same re at the same

Project management page

I think the success criteria on http://dev.perl.org/pm/pos.html should be more measurable. > SUCCESS CRITERIA > 1.Benchmarks of text processing programs show improved performance on perl6 over perl5. Yes, but how much improved? Is 50% in everyone's minds, or is 10% enough? How much i

Re: XML/HTML-specific ?< and ?> operators?

In <[EMAIL PROTECTED]>, Mark-Jason Dominus writes: : :> : it looks worse and dumps core. :> :> That's because the first non-paren forces it to recurse into the :> second branch until you hit REG_INFTY or overflow the stack. Swap :> second and third branches and you have a better chance: : :I thin

Re: The Future - grim.

> I believe in having small control teams (2-3 people) assigned to > each issue; these teams act as moderators for whatever they are > implementing. These teams consist entirely of proven people. Give > the control teams whatever they need to function: read-only + public > mailing lists, etc.

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 -

Re: The Future - grim.

On Mon, Sep 11, 2000 at 11:49:52PM -0500, J. David Blackstone wrote: > > On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote: > > > > Presumably the discarding will be heralded with an announcement on the > > mailing list, as well as a note to the maintainer. The interested > > pa

Re: The Future - grim.

Nat "Is pm for Project Management or Perl Module" Torkington wrote: > You're right that it's very unclear how RFCs will be accepted or > rejected. It's become obvious from the variety of RFCs proposed that > Perl cannot be designed by committee. That's why there's one person > designated as the

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

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-

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

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

> RFC - Prototype RFC Implementations - Seperating the men from the boys. Feh. Scuse me while I find my detachable penis. K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone:

Re: The Future - grim.

> On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote: >> Wait. Does a good idea have to go away simply because the person >> who originally proposed it no longer has interest? What if several >> people are interested, but the original author has totally skipped out >> on Perl6

Re: The Future - grim.

On Mon, Sep 11, 2000 at 11:34:55PM -0500, J. David Blackstone wrote: > Wait. Does a good idea have to go away simply because the person > who originally proposed it no longer has interest? What if several > people are interested, but the original author has totally skipped out > on Perl6 devel

Re: The Future - grim.

Adam Turoff wrote: > All of the RFCs have mailing lists associated with them, and all of > the mailing lists have chairpeople leading discussion. > > Why not ask these chairpeople to start a Last Call process, whereby > any unmaintained RFCs can be marked as "unmaintained and withdrawn" > by the r

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

Peter Heslin writes: :On Wed, Aug 30, 2000 at 11:54:29PM -0400, Mark-Jason Dominus wrote: :> Perhaps Hugo van der Sanden :> would be willing to discuss this with you in more detail? : :I am not acquainted with the gentleman you name. Please do solicit :the input of others you know who might be in

Re: what (?x) are in use? (was RFC 145 (alternate approach))

> In theory, all letters should be reserved to map to future flags for > the same reason. My recollection is that Larry specifically mandated this, and that's why (?p...) was changed to (??...) in 5.6.0.

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

Re: XML/HTML-specific ?< and ?> operators?

> : it looks worse and dumps core. > > That's because the first non-paren forces it to recurse into the > second branch until you hit REG_INFTY or overflow the stack. Swap > second and third branches and you have a better chance: I think something else goes wrong there too. > $re = qr{...

Re: RFC 72 (v3) Variable-length lookbehind: the regexp engine should also go backward.

mike mulligan replied to Peter Heslin: :> Simply put, I want variable-length lookbehind. : :The RFC seems to say you want this so that you can optimize the operation of :the regex execution. I've been looking at the existing fixed-length :look-behind and see that it does not seem to operate the w

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

Re: An attempt to be constructive

At 20:04 -0700 2000.09.11, Russ Allbery wrote: >Chris Nandor <[EMAIL PROTECTED]> writes: > >> But my point is that I don't want a laywer actually writing the license. >> I would rather he give his input and opinions, and then others do the >> writing. I am far more interested in his opinion of th

Re: RFC 72 (v2) The regexp engine should go backward as well as forward.

mike mulligan writes: :If it important to be able to do both: : : $large = join '|', @possible' : $data =~ / (?<= $large) GAAC /x; # Don't care which @possible? : :and : : $data =~ m/ ($large) GAAC /x; # Need $1 to say which @possible : :Then perhaps a back-reference-setting look-behind cou

Re: I think the AL needs a rewrite

At 12:22 -0400 2000.09.11, Ben Tilly wrote: >> >2. Freely Available is too vague. Is it freely available if >> > I release my changes in a form with a copyright notice >> > saying (like Sun does) that you need to submit all of your >> > changes to my changes back to me? (Under the definiti

Re: I think the AL needs a rewrite

At 10:41 -0600 2000.09.11, Tom Christiansen wrote: >I suggest that one explore the answer to this question: > >What does one wish to prohibit people from doing? That is an excellent question. Bradley Kuhn asked we hold off on more discussion until he can release some RFCs tomorrow. I will p

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 o

Re: An attempt to be constructive

At 12:45 -0400 2000.09.11, Ben Tilly wrote: >Chris Nandor wrote: >> >>At 11:40 -0400 2000.09.11, Ben Tilly wrote: >> >1. Larry is in charge of Perl. >> > >> >2. Perl should be available under terms agreeable with the >> > above statement. >> > >> >Two additional points come to mind as my opinion

Re: An attempt to be constructive

Chris Nandor <[EMAIL PROTECTED]> writes: > But my point is that I don't want a laywer actually writing the license. > I would rather he give his input and opinions, and then others do the > writing. I am far more interested in his opinion of the existing > license than his version of it. This m

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

Re: An attempt to be constructive

At 13:02 -0700 2000.09.11, Russ Allbery wrote: >Chris Nandor <[EMAIL PROTECTED]> writes: >> At 10:58 -0400 2000.09.11, Bradley M. Kuhn wrote: > >>> I have been talking with Eben Moglen, a prominent law professor at >>> Columbia University, and he is willing to help us in developing some >>> propos

Re: The Future - grim.

On Mon, 11 Sep 2000, Alan Burlison wrote: > I hope many more people take > note of your gutsy lead and follow it. > I'm sure that your mail will have put you high up on the list of > 'promising fresh blood' :-) Please don't take my original commnents as > being directed at you personally - your

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

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 inh

System epochs

All- I'm writing a prototype for RFC 99, Standardize ALL Perl platforms on UNIX epoch, which does some simplistic manipulation of CORE::time to return the UNIX epoch on all platforms. My question is: Are there any system-specific epochs that Perl uses other than MacPerl's? If so, what are they?

Re: RFC 158 (v1) Regular Expression Special Variables

Mark-Jason Dominus writes: :> There's also long been talk/thought about making $& and $1 :> and friends magic aliases into the original string, which would :> save that cost. : :Please correct me if I'm mistaken, but I believe that that's the way :they are implemented now. A regex match populate

Re: What good are WG chairs?

Russ Allbery wrote: > > I've been feeling guilty about not doing much in the way of chair-like > things with date-time, but I'm also not sure what exactly I'm supposed to > be doing. Discussion has essentially died out completely, which means > that I probably should be trying to kick-start it.

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 lang

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

Re: XML/HTML-specific ?< and ?> operators?

Mark-Jason Dominus wrote: :This is not exactly the same, but I tried a direct translation: : : $re = qr{ \( (??{$re}) \) : | (??{$re}) (??{$re}) : | (?> [^()]+) : }x; : :and it looks worse and dumps core. That's because the first non-paren forces it to recu

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

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

what (?x) are in use? (was RFC 145 (alternate approach))

[resent, 'cos I can't spell "perl6"] Richard Proctor wrote: :The whole (?x set of thingies is getting complicated... The list of what is :used at present (and in current suggestions is: : :Current Use in perl5 : :(?# comment :(?imsx flags :(?-imsx flags That's actually (?iogcmsx and (?-iog

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 > >

Re: RFC 150 (v1) Extend regex syntax to provide for return of a hash of matched subpatterns

Richard Proctor writes: :On Fri 08 Sep, Kevin Walker wrote: [...] :> Tom's comment points out a shortcoming in the original RFC: There's :> no way to make, by name, a backref to a named group. I propose to :> fix that in a revised version of RFC 150. I don't have strong :> feelings about wha

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

Re: perl6-language-regex summary for 20000911

Nathan Wiger wrote: > > > RFC 145: Brace-matching for Perl Regular Expressions (Eric Roode) > > > > Nathan Wiger suggested a special syntax for matching XML-style > > open and close tags. > > This died in favor of a more general brace-matching construct, ?[ and > ?], which could be used in this

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

>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? Ignori

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 arra

Re: all regexp RFCs

In <[EMAIL PROTECTED]>, Hugo writes: :Apologies in advance for so rudely dumping this lot and _still_ not :joining the list [...] Ah, I've now discovered the archives, and seen that this list is not so frighteningly busy as I had anticipated. Now joined. Hugo

Where are we at?

So where are we at with the various date-time RFCs and the discussion of better ways of handling time inside Perl? There was a proposal to use TAI and Dan Bernstein's libtai as the basis of time handling inside Perl. I think this is a good idea, and the next obvious step would seem to be to writ

Re: RFC 207 (v1) Array: Efficient Array Loops

Buddha Buck wrote: > > Reading through the examples left me wondering about some > > technicalities: > > > > > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a > > > > Written like this it would require that @a is exact 2-dim, i.e. it would > > not just swap the first two dims of any n-dim array? I su

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 >

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

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: $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'?

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

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_l

Re: RFC 207 (v1) Array: Efficient Array Loops

> Reading through the examples left me wondering about some > technicalities: > > > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a > > Written like this it would require that @a is exact 2-dim, i.e. it would > not just swap the first two dims of any n-dim array? I suppose if I'd > want that I'd wr

Re: I think the AL needs a rewrite

Ask Bjoern Hansen wrote: > >On Mon, 11 Sep 2000, Ben Tilly wrote: > >[...] > > Sorry, I thought most would be familiar with this story. > >Sorry, I misinterpreted what you said as the usual "BSD-like >licenses are evil, just see what Microsoft did with Kerberos". > Ah, sorry. No, I am not religio

Re: perl6-language-regex summary for 20000911

> RFC 145: Brace-matching for Perl Regular Expressions (Eric Roode) > > Nathan Wiger suggested a special syntax for matching XML-style > open and close tags. This died in favor of a more general brace-matching construct, ?[ and ?], which could be used in this capacity: /(?['' => '')Stuff(?]

Re: What good are WG chairs?

Mark-Jason Dominus <[EMAIL PROTECTED]> writes: > I also think it would be a step in the right direction if the WG chairs > wrote up summaries like they said they would. They obviously don't. > Frankly, I don't really see what the WG chairs are for, unless maybe > it's to play list mom. Good qu

What good are WG chairs?

> I think it would be a step in the right direction if the WG chairs > actually required RFC authors to maintain their RFCs. I also think it would be a step in the right direction if the WG chairs wrote up summaries like they said they would. They obviously don't. Frankly, I don't really see w

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

> Bad reasons > I do not have time. > I do not have the tuits. I think it would be a step in the right direction if the WG chairs actually required RFC authors to maintain their RFCs.

Re: RFC 110 counting matches (post Hugo)

> I propose adding this note. His preference for the working of > /t and /g seems the most appropriate. Unless I here any further > discussion I propose moving this RFC to frozen this week. Please post a complete, revised version of the RFC *before* you freeze it.

Re: $& and copying: rfc 158 (was Re: RFC 110 (v3) counting matches)

> > in any case, i think we have a fair agreement on rfc 158 and i will > > freeze it if there is no further comments on it. > > I think you should remove the parts of your propsal about making $& be > autolocalized. If you're not planning to revise your RFC, let me know so that I can

perl6-language-regex summary for 20000911

perl6-language-regex Summary report 2911 RFC 72: The regexp engine should go backward as well as forward. (Peter Heslin) The author sent revised version of the RFC. There seem to be two ideas here: 1. The lookbehind assertions should work for variable-length patterns. (At

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

On Mon, Sep 11, 2000 at 05:38:59PM -0400, John Porter wrote: > Maybe ALL of p6 should be prototyped using one giant filter? That would be basically what the p52p6 translator will be. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

On Mon, Sep 11, 2000 at 05:30:01PM -0400, Chaim Frenkel wrote: > We are not at that stage yet. We're so far into that stage that its starting to rot. We have 209 seperate feature ideas. That's plenty to start getting serious. Just because we start thinking seriously about implementation detai

Re: RFC 207 (v1) Array: Efficient Array Loops

Buddha Buck wrote: > At 12:00 AM 9/12/00 +1100, Jeremy Howard wrote: > >[EMAIL PROTECTED] wrote: > >> Reading through the examples left me wondering about some > >> technicalities: > >> > >> > @t[|i;|j] = @a[|j;|i]; # transpose 2-d @a > >> > >> Written like this it would require that @a

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

At 05:30 PM 9/11/00 -0400, Chaim Frenkel wrote: >Up until that point, it is wasted energy. At this point, without code >there is nothing locked down, no cost in changing. (Yes, even though >they are bits, changing software, changing architecture has major >costs.) Don't forget that changing archi

Re: New Perl rewrite - embedded Perl

On Mon, Sep 11, 2000 at 09:36:19PM -, John van V wrote: > > I just subscribed this minute... > > > >There's embedding and there's embedding. Embedding in an UNIX server > > >is different than from embedding in a RTOS microcontroller. > > > We're getting very close to blurring the line bet

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 (

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

Michael G Schwern wrote: > > -*> SOURCE FILTERS <<< Oh, yes. Damn. I forgot about filters. :-( Sorry, one and all. Maybe ALL of p6 should be prototyped using one giant filter? -- John Porter

Re: RFC 197 (v1) Numberic Value Ranges In Regular Expressions

I have some trouble understanding just what the proposal is, since the RFC doesn't contain any examples. But I gather that you want to usurp *both* the (...) and the [...] notation for numeric ranges. This would change the meaning of any code that happened to contain a regex like this:

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 = > I

Re: New Perl rewrite - embedded Perl

I just subscribed this minute... > >There's embedding and there's embedding. Embedding in an UNIX server > >is different than from embedding in a RTOS microcontroller. We're getting very close to blurring the line between microcontrollers and servers. In the next few years the palm tops will h

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: MGS> If the idea behind the RFC is good enough, not having time or tuits MGS> should not be a problem, as its inherent err... "goodness" should MGS> attract those who have time and tuits. Even if the RFC is marginal MGS> but provocativ

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 pl

Re: RFC 166 (v1) Additions to regexs

> (?@foo) is sort of equivalent to (??{join('|',@foo)}), ie it expands into a > list of alternatives. One could possible use just @foo, for this. It just occurs to me that this is already possible. I've written a module, 'atq', such that if you write use atq; then your regexes may co

Re: I think the AL needs a rewrite

On Mon, 11 Sep 2000, Ben Tilly wrote: [...] > Sorry, I thought most would be familiar with this story. Sorry, I misinterpreted what you said as the usual "BSD-like licenses are evil, just see what Microsoft did with Kerberos". - ask -- ask bjoern hansen - mo

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.

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' ) { > >

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 w

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} = (); > >

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

On Mon, Sep 11, 2000 at 04:38:01PM -0400, John Porter wrote: > You have not addressed my (and I suspect many others') greatest concern: > I am not a p5 hacker; nor am I a p6 hacker by dint of the fact that p6 does > not yet exist. Can I write the prototype in pseudocode? Or should I be > buildin

Re: Perl Implementation Language

At 09:26 PM 9/11/00 +0100, Simon Cozens wrote: >On Mon, Sep 11, 2000 at 04:01:53PM -0400, Dan Sugalski wrote: > > Are you thinking of something along the lines of FORTH or PostScript? Or > > something else? > >Something else. Forth and PostScript are languages which are implemented >through stacks

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: I think the AL needs a rewrite

Ask Bjoern Hansen <[EMAIL PROTECTED]> writes: > On Mon, 11 Sep 2000, Ben Tilly wrote: >> Take a look at how Microsoft "released" the changes that they made to >> Kerebos. > FUD, afaik. Microsoft reimplemented Kerberos, they didn't change any > software. Correct. Furthermore, since Kerberos is

Re: I think the AL needs a rewrite

Ask Bjoern Hansen wrote: > >On Mon, 11 Sep 2000, Ben Tilly wrote: > >[...] > > Because vagueness has led to being overly permissive. > > > > Take a look at how Microsoft "released" the changes that they > > made to Kerebos. > >FUD, afaik. Microsoft reimplemented Kerberos, they didn't change any >s

Re: RFC 165: Allow Variables in tr/// (post hugo)

> I propose adding the first para as a note and moving RFC to frozen soon. You did not address my points about tr///o and related issues. I suggest that you submit a revised RFC and then freeze it a week afterwards if there is still no discussion.

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()

Re: Perl Implementation Language

On Mon, Sep 11, 2000 at 01:09:41PM -0400, [EMAIL PROTECTED] wrote: > Currently I'm thinking C for the target compiler just because of its > ubiquity. I don't think it matters much. Any language similar to C (or C itself) is fine. The ticklish part is garbage collection, exceptions, and the for

Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.

Michael G Schwern wrote: > > The main thing I wish to accomplish here is to change the prevailing > attitude from "write an RFC and maybe something will come of it" to > "write an RFC and make sure something comes of it." Move the ball > down the field. Eminently reasonable. > I wish to make

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

Re: I think the AL needs a rewrite

On Mon, 11 Sep 2000, Ben Tilly wrote: [...] > Because vagueness has led to being overly permissive. > > Take a look at how Microsoft "released" the changes that they > made to Kerebos. FUD, afaik. Microsoft reimplemented Kerberos, they didn't change any software. If they had it would probabl

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 =

  1   2   3   >