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

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: The Future - grim.

Adam Turoff wrote: > From this, I can extract these action items: > > 1) Set up p6 development like other open source projects, where there >is a "core team" responsible for the progress of Perl6 or a component >of Perl6. These people have write access to the source repository >(wha

Re: perl 5.6.0 stdlib stats

This is very much what I had started to do, although you have already taken it further that what I had done. However I was also lookiing at documentation style. Here are just a selection of different ways to document a function or method =item timeit(COUNT, CODE) =item timethis ( COUNT, CODE

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 write @t[|i;|

Re: perl 5.6.0 stdlib stats

> Alongside giving consistent APIs I think perl6 should also give consistent > documentation format. Are there any proposals to add per-argument markup to POD so that these could be generated automatically? (Even in the 'locally preferred style' if necessary). jb

Re: perl 5.6.0 stdlib stats

>> Alongside giving consistent APIs I think perl6 should also give consistent >> documentation format. >Are there any proposals to add per-argument markup to POD so that these >could be generated automatically? (Even in the 'locally preferred style' >if necessary). If people are already not foll

Re: perl 5.6.0 stdlib stats

On Mon, Sep 11, 2000 at 06:37:26AM -0600, Tom Christiansen wrote: > >> Alongside giving consistent APIs I think perl6 should also give consistent > >> documentation format. > > >Are there any proposals to add per-argument markup to POD so that these > >could be generated automatically? (Even in t

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

[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 is exact 2-dim, i.e. it would > not just swap the first two dims of any n-dim array? I suppose if

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

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 is exact 2-dim, i.e. it would > > no

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

Sorry, the mailer did something unexpected... 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 requ

Re: An attempt to be constructive

Russ Allbery wrote: > Surely there must be someone in the Perl community with either > intellectual property law experience or a willingness to chip in to a fund > to hire an intellectual property lawyer? I have been talking with Eben Moglen, a prominent law professor at Columbia University, and

Re: An attempt to be constructive

"Bradley M. Kuhn" wrote: >Russ Allbery wrote: > > > Surely there must be someone in the Perl community with either > > intellectual property law experience or a willingness to chip in to a >fund > > to hire an intellectual property lawyer? Define "Perl Community". I am currently trying to get K

Re: An attempt to be constructive

>> Here's what I like: *LARRY AND LARRY ALONE* gets to say what happens to >> that thing we call "perl". >The plan of this working group is to propose RFCs for Larry's later perusal >about what should happen with copyright and licensing of perl6. You misunderstand. I was talking something else

Re: Licensing of perl5 (was Re: Storable integration in core)

I presume everyone who cares about this is already on the perl6-licenses list, so I am taking it there, since many people do not want this on p5p. At 1:16 -0700 2000.09.11, Russ Allbery wrote: >Only those portions of a license that can be unambiguously relied upon are >usable, in my opinion. I'd

I think the AL needs a rewrite

I don't think it needs it for Perl. I think it needs it because it expresses something that many people want to say, and so it is worth having it said well so that people can say what they want to say and know it works. The artistic license says, "You can do anything you want with this so long a

Re: Can we ignore licensing?

Chris Nandor wrote: > >At 9:29 -0400 2000.09.11, Ben Tilly wrote: > >If I were to launch a challenge of the AL, the obvious target > >is that it is a copyright statement that violates all sorts of > >rules around fair use and so on. > >Such as? I won't respond to vague assertions anymore. > Suppo

Re: An attempt to be constructive

Tom Christiansen wrote: > >In more of an attempt to be constructive, what if we identify the key > >aspects to the AL that people like and then, for Perl 6, find legal > >counsel to review and help draft a precise legal license with those key > >features? > Here's what I like: *LARRY AND LARRY A

Re: I think the AL needs a rewrite

Chris Nandor wrote: > >I have also included my reply to "Can we ignore licensing?" below. > >At 10:38 -0400 2000.09.11, Ben Tilly wrote: > >1. Rephrase it so that it is clearly a copyright notice with > > an offered contract available for anyone who wishes to do > > things normally restricted

Re: I think the AL needs a rewrite

I suggest that one explore the answer to this question: What does one wish to prohibit people from doing? --tom

Re: An attempt to be constructive

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 opinions: > > > >3. The current AL probably does not convey

Re: I think the AL needs a rewrite

Tom Christiansen wrote: > >I suggest that one explore the answer to this question: > > What does one wish to prohibit people from doing? My answer matches my understanding of what you have said in the past. I wish to prohibit people from distributing something that they call Perl which diffe

Re: I think the AL needs a rewrite

>Does that suffice and match your opinion? Yes, it does. But I wasn't looking for confirmation of my own opinion, but the development of others'. --tom

Re: An attempt to be constructive

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 >proposed new versions of the Artistic License. That sounds really bad. The last thing we need in here is a

Re: I think the AL needs a rewrite

I have also included my reply to "Can we ignore licensing?" below. At 10:38 -0400 2000.09.11, Ben Tilly wrote: >1. Rephrase it so that it is clearly a copyright notice with > an offered contract available for anyone who wishes to do > things normally restricted by copyright. Like the GPL. W

Re: An attempt to be constructive

Tom Christiansen wrote: > > >> Here's what I like: *LARRY AND LARRY ALONE* gets to say what happens to > >> that thing we call "perl". > > >The plan of this working group is to propose RFCs for Larry's later >perusal > >about what should happen with copyright and licensing of perl6. > >You misund

Re: An attempt to be constructive

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 opinions: > >3. The current AL probably does not convey the above in terms > acceptable to la

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 argume

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

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

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 follow

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

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

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

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

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

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 toget

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 n

-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

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

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

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 twiddli

Perl Implementation Language

I think it's about time we decided what compiler we want to hand perl's source to, and what language we want to implement perl in. Currently I'm thinking C for the target compiler just because of its ubiquity. I am *not* particularly advocating for C as a spiffy language. Nor against, for that

Re: New Perl rewrite - embedded Perl

Tom Christiansen writes: > We've been down this route. It doesn't help the way you think it does. > These are merely wafer-thin wrappers about syscalls. It's Perl's > complete infrastructure support system you're seeing, and that you > will not reduce. Actually, if we can split compiler from r

Re: New Perl rewrite - embedded Perl

At 11:40 AM 9/11/00 -0600, Nathan Torkington wrote: >Tom Christiansen writes: > > We've been down this route. It doesn't help the way you think it does. > > These are merely wafer-thin wrappers about syscalls. It's Perl's > > complete infrastructure support system you're seeing, and that you > >

Re: New Perl rewrite - embedded Perl

Matthew Gillman wrote: > Dear All > > I wrote a large C++ program which used embedded Perl. Later, this was changed to >embedded Python. The reasons for this included: > > 1) Python allows you to pass a pointer to an object from C/C++ to the embedded >Python interpreter, wheras Perl makes you p

Re: New Perl rewrite - embedded Perl

>Perlsonally, I don't think mod_perl is a success story, the main problem >is perl interpreter is too big and need so much memory, so build apache >interpreter makes apache couldn't run fast as it should be. Size doesn't matter. CF a "browser". And a VM system. >I suggest Perl6 can give us a

Re: New Perl rewrite - embedded Perl

Tom Christiansen wrote: > >Perlsonally, I don't think mod_perl is a success story, the main problem > >is perl interpreter is too big and need so much memory, so build apache > >interpreter makes apache couldn't run fast as it should be. > > Size doesn't matter. CF a "browser". And a VM system

Re: New Perl rewrite - embedded Perl

>are put in "main" directory. I woud like Perl6 do the same thing, leave >etc stuff >outside of core. We've been down this route. It doesn't help the way you think it does. These are merely wafer-thin wrappers about syscalls. It's Perl's complete infrastructure support system you're seeing, a

Re: The Future - grim.

Well, THAT was certainly specific, insightful, politely phrased, and filled with pertinent advice on how to remedy the problem! Alan, you're right about certain things...it's important that talented, experienced people have the final say over the final product. However, most of the problems in e

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

On Mon, Sep 11, 2000 at 02:29:47PM -0400, John Porter wrote: > No. You can not oblige the RFC maintainer to write the prototype or > cat-herd someone else into it. The vast majority of RFC authors > (myself included) would simply not be up to such an order. > > Instead, it should be the WG lead

Re: The Future - grim.

Alan Burlison wrote: > > I'm sorry but I really can't stomach watching this slow motion train > wreck any longer, so good luck and goodbye. Plonk. -- John Porter

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

Michael G Schwern wrote: > On Mon, Sep 11, 2000 at 02:29:47PM -0400, John Porter wrote: > > No. You can not oblige the RFC maintainer to write the prototype or > > cat-herd someone else into it. The vast majority of RFC authors > > (myself included) would simply not be up to such an order. > >

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

Michael G Schwern wrote: > Chaim Frenkel wrote: > > > > At this point, I think this is too strong. My understanding of Larry's > > intention is that we are now brainstorming. Brainstorming can not work > > if folks will pre-filter their ideas. Part of the effect is a half-baked > > idea on anothe

RFC 116 (v2) Efficient numerics with perl

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Efficient numerics with perl =head1 VERSION Maintainer: pdl-porters team <[EMAIL PROTECTED]> Date: 16 August 2000 Last Modified: 11 September 2000 Mailing List: [EMAIL PROTECTED] Number: 116 Ver

RFC 117 (v2) Perl syntax support for ranges

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Perl syntax support for ranges =head1 VERSION Maintainer: pdl-porters team <[EMAIL PROTECTED]> Date: 16 August 2000 Last Modified: 11 Spetember 2000 Mailing List: [EMAIL PROTECTED] Number: 117 V

RFC 178 (v4) Lightweight Threads

This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Lightweight Threads =head1 VERSION Maintainer: Steven McDougall <[EMAIL PROTECTED]> Date: 30 Aug 2000 Last Modified: 11 Sep 2000 Mailing List: [EMAIL PROTECTED] Number: 178 Version: 4 Status:

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 =

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

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

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: 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: $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: $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: $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: 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 () ;

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

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

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: RFC 72 (v1) The regexp engine should go backward as well as forward.

> Simply put, I want variable-length lookbehind. Why didn't you simply propose that the (?<...) operator be fixed to support variable-length expressions? Why so much additional machinery?

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

> As to your contention that "at best" (?r) will defeat many present > optimizations, can you tell me why this will necessarily be so in the > new engine? Let me explain my thinking along these lines. I've made a number of assumptions, which may not be correct, and certainly aren't obvious. I

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 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: Perl Implementation Language

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; I'm talking about a language designed for manipulati

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: 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: 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: 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: Perl Implementation Language

At 08:19 PM 9/11/00 +0100, Simon Cozens wrote: >On Mon, Sep 11, 2000 at 02:39:14PM -0400, Dan Sugalski wrote: > > At 01:23 PM 9/11/00 -0500, David L. Nicol wrote: > > >Dan Sugalski wrote: > > > > > > > If anyone's got any arguments in a particular direction, now would > be the > > > > time. Once

Re: New Perl rewrite - embedded Perl

ye, wei <[EMAIL PROTECTED]> writes: > Yes, I agree with you that Perl kernel is too big to embed into other > program. You do? I don't. INN has been embedding Perl for years, quite successfully. -- Russ Allbery ([EMAIL PROTECTED])

Re: New Perl rewrite - embedded Perl

On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote: > ye, wei <[EMAIL PROTECTED]> writes: > > > Yes, I agree with you that Perl kernel is too big to embed into other > > program. > > You do? I don't. INN has been embedding Perl for years, quite > successfully. There's embedding and

Re: New Perl rewrite - embedded Perl

At 03:16 PM 9/11/00 -0500, Jarkko Hietaniemi wrote: >On Mon, Sep 11, 2000 at 01:12:44PM -0700, Russ Allbery wrote: > > ye, wei <[EMAIL PROTECTED]> writes: > > > > > Yes, I agree with you that Perl kernel is too big to embed into other > > > program. > > > > You do? I don't. INN has been embeddin

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

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: $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 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 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: $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: $& 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

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

  1   2   3   >