Re: RFC 206 (v1) Array: @#arr for getting the dimensions of an array

2000-09-08 Thread Jeremy Howard
[EMAIL PROTECTED] wrote: > Perl6 RFC Librarian wrote: > > > This RFC proposes using @#array, analogous to $#array, to get the list of > > upper bounds for a multidimensional array @array. The length of @#array > > would indicate the dimensionality of @array. > > That's fine. This RFC does not seem

Re: RFC 203 (v1) Arrays: Notation for declaring and creating arrays

2000-09-08 Thread Jeremy Howard
[EMAIL PROTECTED] wrote: > Perl6 RFC Librarian wrote: > > > The bounds of an array or list can be specified at run time, of course: > > > > my int @t1 :bounds(@dimList) = getFromSomeplace(); > > Hm, I think some clarification would be good. I'd imagine three cases: > (1) getFromSomeplace retur

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Dan Sugalski
At 04:21 PM 9/8/00 -0400, Chaim Frenkel wrote: > > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: > >DS> The problem with using database locking and transactions as your >DS> model is that they're *expensive*. Amazingly so. The expense is >DS> certainly worth it for what you get, and in many

Re: RFC 203 (v1) Arrays: Notation for declaring and creating arrays

2000-09-08 Thread c . soeller
Perl6 RFC Librarian wrote: > The bounds of an array or list can be specified at run time, of course: > > my int @t1 :bounds(@dimList) = getFromSomeplace(); Hm, I think some clarification would be good. I'd imagine three cases: (1) getFromSomeplace returns an untyped and unbounded LOL. In that

Re: RFC 206 (v1) Array: @#arr for getting the dimensions of an array

2000-09-08 Thread c . soeller
Perl6 RFC Librarian wrote: > This RFC proposes using @#array, analogous to $#array, to get the list of > upper bounds for a multidimensional array @array. The length of @#array > would indicate the dimensionality of @array. That's fine. This RFC does not seem to touch on the question what $#arra

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-08 Thread Jeremy Howard
[EMAIL PROTECTED] > Nathan Wiger wrote: > > > > > This RFC proposes that operators in a list context should be applied > > > element-wise to the elements of their arguments: > > > > > > @d = @b * @c; # Returns (2,8,18) > > > > > > If the lists are not of equal length, an error is raised. > > >

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-08 Thread c . soeller
Nathan Wiger wrote: > > > This RFC proposes that operators in a list context should be applied > > element-wise to the elements of their arguments: > > > > @d = @b * @c; # Returns (2,8,18) > > > > If the lists are not of equal length, an error is raised. > > I've been watching this RFC for a

Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-08 Thread Dan Sugalski
At 05:27 PM 9/8/00 -0400, Chaim Frenkel wrote: > > "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: > >AT> that is lost is who actually made any specific update; all changes >AT> are made by 'cvs-bot' or somesuch. > >Is this a programming issue? or something more fundemental. > >(is it time and

Re: RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-08 Thread Nathan Wiger
> This RFC proposes that operators in a list context should be applied > element-wise to the elements of their arguments: > > @d = @b * @c; # Returns (2,8,18) > > If the lists are not of equal length, an error is raised. I've been watching this RFC for a while. I would hesitate to change th

all regexp RFCs

2000-09-08 Thread Hugo
Hi guys, I'm sorry that time has not permitted me to join and take an active part in the perl6-language-regex list; however, I have grabbed an opportunity to look through the RFCs generated to date, and thought I should throw some comments at you. Apologies in advance for so rudely dumping this l

Re: Pre-RFC: undef =~ s/def/initialize/

2000-09-08 Thread Randal L. Schwartz
> "Peter" == Peter Scott <[EMAIL PROTECTED]> writes: Peter> Make that uninit() for typing ease (only one char longer than undef) and I'd Peter> vote for it. Makes a heck of a lot of sense. uninit looks like a typo for "unit". Maybe we need "denit" for "de-nitialize" :)... -- Randal L. Sc

NOTE: RFC 202..207

2000-09-08 Thread ziggy
Due to a processing hiccup, a some of the last few RFCs were announced twice, with different numbering. For the record, this is the correct numbering of RFC 202 through 207: 202 Arrays: Overview of multidimensional array RFCs 203 Arrays: Notation for declaring and creati

Re: RFC 39 (v3) Perl should have a print operator

2000-09-08 Thread Ask Bjoern Hansen
On 8 Sep 2000, Chaim Frenkel wrote: > >> Oh, why not? Does anybody actually *ever* check the return value of > >> print? I think it's not as if we'd break a lot of code. > > ABH> uh, what? you don't do much socket programming now, do you? sockets > ABH> breaks all the time. Disks runs out of spa

RFC 207 (v1) Array: Efficient Array Loops

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Array: Efficient Array Loops =head1 VERSION Maintainer: Buddha Buck <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 207 Version: 1 Status: Developing =head1 A

RFC 206 (v1) Array: @#arr for getting the dimensions of an array

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Array: @#arr for getting the dimensions of an array =head1 VERSION Maintainer: Buddha Buck <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 206 Version: 1 Statu

RFC 205 (v1) Arrays: New operator ';' for creating array slices

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: New operator ';' for creating array slices =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 205 Version: 1 Stat

RFC 204 (v1) Array: Use list reference for multidimensional array access

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Array: Use list reference for multidimensional array access =head1 VERSION Maintainer: Buddha Buck <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 204 Version: 1

RFC 203 (v1) Arrays: Notation for declaring and creating arrays

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Notation for declaring and creating arrays =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 203 Version: 1 Stat

RFC 202 (v1) Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207)

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207) =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number:

RFC 204 (v1) Arrays: Notation for declaring and creating arrays

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Notation for declaring and creating arrays =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 204 Version: 1 Stat

RFC 203 (v1) Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207)

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207) =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number:

RFC 202 (v1) Arrays: Notation for declaring and creating arrays

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Notation for declaring and creating arrays =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 202 Version: 1 Stat

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-08 Thread Jeremy Howard
Matthew Wickline wrote: > (not on list, just tossing this in for discussion) > OK--we'll keep you cc'd in on this discussion. > > RFC 90 (v3) wrote: > -> Both C and do not make > -> a copy of the elements of their arguments; > -> they simply create an alias to them: > -> > 1> @a = (1,3,5); > 2

Re: we already have barewords as variables if we want them Re: the C JIT

2000-09-08 Thread John Porter
David L. Nicol wrote: > > I am not suggesting dropping the magic signifiers from the beginning of > Perl scalars and containers. In fact, I resent these insinuations > (first Nathan's, now yours) that I am among those who suggest dropping the > decorations from perl scalars. I am not among that

Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-08 Thread Chaim Frenkel
> "AT" == Adam Turoff <[EMAIL PROTECTED]> writes: AT> that is lost is who actually made any specific update; all changes AT> are made by 'cvs-bot' or somesuch. Is this a programming issue? or something more fundemental. (is it time and effort or a mismatch between perforce and CVS?) -- Ch

RE: RFC 199 (v2) Another question...

2000-09-08 Thread Garrett Goebel
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?

Re: RFC 200 (v1) Objects: Revamp tie to support extensibility (Massive tie changes)

2000-09-08 Thread Michael Fowler
On Fri, Sep 08, 2000 at 04:57:46AM -, Perl6 RFC Librarian wrote: > =head3 Merge C, C, and C into C > > In practice, people rarely make a class that Cs multiple data types > through the same interface. The reason is that C, C, > C, and other methods overlap. As such, it is more feasible to > c

The Future

2000-09-08 Thread Nathan Torkington
This will ultimately go in a more detailed version of the Roadmap, but here's my current thinking on what comes next. Be warned, it's written as a braindump. Larry releases his draft language design, an overview of what will be in the language and what it will look like. There'll be some clarif

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Alan Burlison
Chaim Frenkel wrote: > No scanning. I was considering that all variables on a store would > safe store the previous value in a thread specific holding area[*]. Then > upon a deadlock/rollback, the changed values would be restored. > > (This restoration should be valid, since the change could not

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes: DS> The problem with using database locking and transactions as your DS> model is that they're *expensive*. Amazingly so. The expense is DS> certainly worth it for what you get, and in many cases the expense DS> is hidden (at least to some ex

Re: RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-08 Thread Matthew Wickline
(not on list, just tossing this in for discussion) RFC 90 (v3) wrote: -> Both C and do not make -> a copy of the elements of their arguments; -> they simply create an alias to them: -> 1> @a = (1,3,5); 2> @b = (2,4,6); 3> @merged_list = merge(@a,@b); # (1,2,3,4,5,6) 4> $merged_list[1

Re: RFC 39 (v3) Perl should have a print operator

2000-09-08 Thread Chaim Frenkel
> "ABH" == Ask Bjoern Hansen <[EMAIL PROTECTED]> writes: >> Oh, why not? Does anybody actually *ever* check the return value of >> print? I think it's not as if we'd break a lot of code. ABH> uh, what? you don't do much socket programming now, do you? sockets ABH> breaks all the time. Disks

Re: RFC 178 (v3) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes: PRL> Otherwise, programmers will forever be guessing (wrong) about what PRL> exactly they can rely on the interpreter for. PRL> This RFC proposes that the boundary be placed at I. PRL> Data coherence means that primitive operations i

RFC 82 (v3) Arrays: Apply operators element-wise in a list context

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Apply operators element-wise in a list context =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 10 August 2000 Last Modified: 8 September 2000 Mailing List: [EMAIL PROTECTE

RFC 81 (v3) Lazily evaluated list generation functions

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Lazily evaluated list generation functions =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 10 August 2000 Last Modified: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number:

Re: RFC 195 (v1) Retire chop().

2000-09-08 Thread Eric Roode
Richard Proctor wrote: >>[Eric Roode wrote] >> 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. > >I can see a small benefit for autochomp-on-read but none whatsoever >f

Re: RFC 195 (v1) Retire chop().

2000-09-08 Thread Casey R. Tweten
Today around 11:17am, Nathan Wiger hammered out this masterpiece: : "Bryan C. Warnock" wrote: : > : > Someone, (and I've lost who, exactly) was interested in taking those : > off my hands for a String::Utils module. : : I believe I volunteered for this; not sure if anyone else did, but I'm : mo

RFC 91 (v3) Builtins: part and flatten

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Builtins: part and flatten =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 10 August 2000 Last Modified: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 91 Version: 3

RFC 90 (v3) Arrays: Builtins: merge() and demerge()

2000-09-08 Thread Perl6 RFC Librarian
This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Arrays: Builtins: merge() and demerge() =head1 VERSION Maintainer: Jeremy Howard <[EMAIL PROTECTED]> Date: 10 August 2000 Last Modified: 8 September 2000 Mailing List: [EMAIL PROTECTED] Number: 90

Re: extra steps required during build?

2000-09-08 Thread Andy Dougherty
On Fri, 8 Sep 2000, Qiang Tu wrote: [regarding the ext/*/*.c files automatically generated from the corresponding .xs files as part of the build process.] > Could anyone tell me why those C files are not included in the source > tarball and have to be translated from XS files during build time?

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

2000-09-08 Thread Richard Proctor
On Fri 08 Sep, Kevin Walker wrote: > (This thread has been inactive for a while. See > http://www.mail-archive.com/perl6-language-regex@perl.org/index.html#0 > 0015 for it's short history.) > > Long ago Tom Christiansen wrote: > > >This is useful in that it would stop being number dependent.

Re: RFC 195 (v1) Retire chop().

2000-09-08 Thread Richard Proctor
On Fri 08 Sep, Eric Roode wrote: > Does anyone EVER use chomp() except shortly after reading a line > of input from a stream? No? > Yes > Perhaps $/ and $\ should become per-filehandle variables, and > there should be some way to set autochomp-on-read per filehandle, > and auto-newline-on-out

Re: we already have barewords as variables if we want them Re: the C JIT

2000-09-08 Thread David L. Nicol
John Porter wrote: > undecorated variable names suffer from this showstopping weakness: > they can't be interpolated. Unless we change other aspects of perl's > syntax to support it, that is -- maybe s/${x}/5/. Now, maybe we can > live without variable interpolation; but I'd bet most perl progr

Re: RFC 195 (v1) Retire chop().

2000-09-08 Thread Nathan Wiger
"Bryan C. Warnock" wrote: > > Someone, (and I've lost who, exactly) was interested in taking those > off my hands for a String::Utils module. I believe I volunteered for this; not sure if anyone else did, but I'm more than willing to do this. -Nate

Re: Pre-RFC: undef =~ s/def/initialize/

2000-09-08 Thread Peter Scott
At 09:36 AM 9/8/00 -0600, Tom Christiansen wrote: > >So you wouldn't be in favour of: > > >my Dog $spot; > >print defined($spot) ? 'defined' : 'undefined'; # undefined > >print $spot->isa('Dog') ? 'Dog' : 'not dog';# Dog; > > >then? > > >Bang goes that RFC... > >No, I would argue t

Re: RFC 178 (v2) Lightweight Threads(multiversionning)

2000-09-08 Thread Chaim Frenkel
> "r" == raptor <[EMAIL PROTECTED]> writes: r> ]- what if we don't use "locks", but multple versions of the same variable r> !!! What I have in mind : r> If there is transaction-based variables THEN we can use multiversioning r> mechanism like some DB - Interbase for example. r> Check here

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: AB> Please consider carefully the potential consequences of your proposal. I just realized, that no one has submitted a language level proposal how deadlocks are detected, delivered to the perl program, how they are to be recovered from, Wh

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: AB> Chaim Frenkel wrote: >> What tied scalar? All you can contain in an aggregate is a reference >> to a tied scalar. The bucket in the aggregate is a regular bucket. No? AB> So you don't intend being able to roll back anything that has bee

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: AB> Chaim Frenkel wrote: >> You aren't being clear here. >> >> fetch($a) fetch($a) >> fetch($b) ... >> add ... >> store($a) store($a) >> >> Now all of the perl internals are don

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

2000-09-08 Thread Kevin Walker
(This thread has been inactive for a while. See http://www.mail-archive.com/perl6-language-regex@perl.org/index.html#0 0015 for it's short history.) Long ago Tom Christiansen wrote: >This is useful in that it would stop being number dependent. >For example, you can't now safely say > >/$v

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Dan Sugalski
At 06:18 PM 9/7/00 -0400, Chaim Frenkel wrote: > > "AB" == Alan Burlison <[EMAIL PROTECTED]> writes: > >AB> Chaim Frenkel wrote: > >> The problem I have with this plan, is reconciling the fact that a > >> database update does all of this and more. And how to do it is a known > >> problem, its

Re: Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-08 Thread Dan Sugalski
At 11:30 AM 9/8/00 -0400, Bradley M. Kuhn wrote: >Adam Turoff wrote: > > > *: Sarathy tells me that Perforce sucks at maintaining thousands of > > anonymous checkouts, while CVS doesn't mind at all. This is a perfect > > reason to use anon CVS vs. Perforce, but does not require that Perforce be >

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Chaim Frenkel
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes: NI> Chaim Frenkel <[EMAIL PROTECTED]> writes: NI> Well if you want to place that restriction on perl6 so be it but in perl5 NI> I can say NI> tie $a[4],'Something'; That I didn't realize. NI> Indeed that is exactly how tied arrays wo

extra steps required during build?

2000-09-08 Thread Qiang Tu
I built perl 5.6.0 on my Linux box yesterday. By comparing the directory content before and after the "make", I noticed there are 22 .c files are newly created at build time: ext/B/B.c, /ext/ByteLoader/ByteLoader.c, ext/DB_File/DB_File.c, ext/Data/Dumper/Dumper.c, ext/Devel/DProf/DProf.c, ext/Deve

Re: A tentative list of vtable functions

2000-09-08 Thread Ken Fox
Dan Sugalski wrote: > At 05:30 PM 8/31/00 -0400, Ken Fox wrote: > > before_get_value > > after_get_value > > before_set_value > > after_set_value > > > >There ought to be specializations of get_value and set_value > >that call these hooks if they're defined -- no sense in making the > >nor

Re: code repository

2000-09-08 Thread Dan Sugalski
At 10:24 AM 9/8/00 -0400, Bennett Todd wrote: >2000-09-07-19:50:35 Adam Turoff: > > > Given that it's only available to people who happen to run supported > > > platforms, > > > > OK. That pegged the fud-o-meter. The list of supported platforms > > listed on http://www.perforce.com/perforce/load

Pre-RFC: undef =~ s/def/initialize/

2000-09-08 Thread Tom Christiansen
>So you wouldn't be in favour of: >my Dog $spot; >print defined($spot) ? 'defined' : 'undefined'; # undefined >print $spot->isa('Dog') ? 'Dog' : 'not dog';# Dog; >then? >Bang goes that RFC... No, I would argue that undef() be changed to uninitialize(). This is infinitely better

Re: code repository

2000-09-08 Thread Dan Sugalski
At 10:48 PM 9/7/00 -0600, Nathan Torkington wrote: >But I am cool to the idea that we should lose good coders to >potentially bad ideas. Explore those ideas later, get perl6 working >first. Unfortunately we're going to lose good coders regardless of what we do. Any significant decision's going

Can perforce gateway to CVS without loss of metadata? (was Re: code repository)

2000-09-08 Thread Bradley M. Kuhn
Adam Turoff wrote: > *: Sarathy tells me that Perforce sucks at maintaining thousands of > anonymous checkouts, while CVS doesn't mind at all. This is a perfect > reason to use anon CVS vs. Perforce, but does not require that Perforce be > ditched in favor of CVS, only that an anon CVS gateway b

Re: RFC 178 (v1) Lightweight Threads

2000-09-08 Thread Ken Fox
Steven W McDougall wrote: > Question: Can the interpreter determine when a variable becomes > shared? > > Answer: No. Then neglecting to put a :shared attribute on a shared > variable will crash the interpreter. This doesn't seem very Perlish. If the variable isn't :shared then how can it be sha

Re: RFC 178 (v1) Lightweight Threads

2000-09-08 Thread Ken Fox
Steven W McDougall wrote: > How do `our' and `my' control mutex locking? I was assuming that all global (or "non-my" rather) variables would by default be shared when using a thread-enabled perl. That seems like a sensible default. If we're going to require the :shared modifier, then ignore my co

Re: code repository

2000-09-08 Thread Bennett Todd
2000-09-07-19:50:35 Adam Turoff: > > Given that it's only available to people who happen to run supported > > platforms, > > OK. That pegged the fud-o-meter. The list of supported platforms > listed on http://www.perforce.com/perforce/loadprog.html is hovering > around fifty, [...] Sure hope

Re: RFC 199 (v2) Short-circuiting C, C, and C with C

2000-09-08 Thread John Porter
Bart Lateur wrote: >... > In the same gist, a "last" inside the code block would, if you don't > know exectution order, result in a completely unpredictable result. >... > p.s. Who cares that grep() processes every item for a boolean test? If > you have a 1000 items, on average, you need 500 tests

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Steven W McDougall
> Example > > @a = (); > async { push @a, (1, 2, 3) }; > push @a, (4, 5, 6); > print @a; > > Possible output: 142536 Actually, I'm not sure I understand this. Can someone show how to program push() on a stack machine? - SWM

Re: $a in @b

2000-09-08 Thread John Porter
David L. Nicol wrote: > > I'd like to see next/last/redo in such situations pertain to the > block from which the sub was called, if that makes sense. Well, that's the behavior in perl5. Most people don't know about it, and those who do think it's bizarre. It's perl's secret action at a distan

Re: $a in @b

2000-09-08 Thread John Porter
Damian Conway wrote: >> If one were looking for the first matching item, last would work: >> >> grep { /pat/ and last } @foo >> # return()s the value of $_=~/pat/, which will be true > > Huh? I can't see how that could work unless you change the existing > semantics of C and C.

Re: RFC 199 (v2) Short-circuiting C, C, and C with C

2000-09-08 Thread Bart Lateur
On 8 Sep 2000 04:47:52 -, Perl6 RFC Librarian wrote: >Short-circuiting C, C, and C with C >(or "Allowing built-in functions to use loop blocks") >Neither Tom Christiansen nor Jarkko Hietaniemi profess to know why the >suggestion with regards to C hasn't already been implemented. I can give

Re: code repository

2000-09-08 Thread Piers Cawley
Michael G Schwern <[EMAIL PROTECTED]> writes: > On Thu, Sep 07, 2000 at 01:49:36PM -0400, Peter Allen wrote: > > They have a catchy slogan for it. They call it the > > > >test --> code --> design > > > > development cycle. > > That sounds bad. I've heard about this style. Co

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Steven W McDougall
> > You aren't being clear here. > > > > fetch($a) fetch($a) > > fetch($b) ... > > add ... > > store($a) store($a) > > > > Now all of the perl internals are done 'safely' but the result is garbage. > >

Re: RFC 195 (v1) Retire chop().

2000-09-08 Thread Eric Roode
Does anyone EVER use chomp() except shortly after reading a line of input from a stream? No? 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. Then, if anyone ever needs to

Re: RFC 178 (v2) Lightweight Threads(multiversionning)

2000-09-08 Thread raptor
> I don't even want to take things out a step to guarantee atomicity at the > statement level. There are speed issues there, since it means every > statement will need to conditionally lock everything. (Since we can't > necessarily know at compile time which variables are shared and which > aren't

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Alan Burlison
Chaim Frenkel wrote: > You aren't being clear here. > > fetch($a) fetch($a) > fetch($b) ... > add ... > store($a) store($a) > > Now all of the perl internals are done 'safely' but the result is garbage

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Alan Burlison
Chaim Frenkel wrote: > What tied scalar? All you can contain in an aggregate is a reference > to a tied scalar. The bucket in the aggregate is a regular bucket. No? So you don't intend being able to roll back anything that has been modified via a reference then? And if you do intend to allow th

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Alan Burlison
Jarkko Hietaniemi wrote: > Being multithreaded is not difficult, impossible, or bad as such. > It's the make-believe that we can make all data automagically both > shared and safe that is folly. Data sharing (also known as code > synchronization) should be explicit; explicitly controlled by the

Re: $a in @b

2000-09-08 Thread Graham Barr
On Thu, Sep 07, 2000 at 07:44:31PM -0500, Jarkko Hietaniemi wrote: > > Exactly the sort of chicanery grep/last is meant to avoid. So the question > > becomes, how do we crowbar "last" in without altering the returned value in > > C blocks. I'm for putting it after a comma. Which matches the synt

Event model for Perl...

2000-09-08 Thread Grant M.
I am reading various discussions regarding threads, shared objects, transaction rollbacks, etc., and was wondering if anyone here had any thoughts on instituting an event model for Perl6? I can see an event model allowing for some interesting solutions to some of the problems that are currently be

Re: RFC 196 (v1) More direct syntax for hashes

2000-09-08 Thread Bart Lateur
On Thu, 7 Sep 2000 20:56:47 -0400, Michael G Schwern wrote: >> C should reset the hash iterator, instead of calling >> C or C as is currently the case. > >Sounds good, except the name. reset() already does something. >Currently, reset() is for clearing large swaths of global variables (a >dubiou

Re: RFC 196 (v1) More direct syntax for hashes

2000-09-08 Thread Bart Lateur
On Wed, 6 Sep 2000 22:58:05 -0400, John Porter wrote: > keys %hash = @things; > >is defined as being equivalent to > > @hash{ @things } = (); Two more details to think about: %hash = ( b => 'beta', d => 'delta' ); keys %hash = qw(a b c); What happens to the values t

Re: RFC 39 (v3) Perl should have a print operator

2000-09-08 Thread Bart Lateur
On Fri, 8 Sep 2000 01:18:19 -0700 (PDT), Ask Bjoern Hansen wrote: >I really don't understand why you want to have what's printed. It is handy, sometimes. But I do think that the overhead of creating a longish string every time you print something, which is then simply discarded, is not really a

Re: switch s/statement/operator/

2000-09-08 Thread H . Merijn Brand
On Tue, 29 Aug 2000 16:41:41 -0600, Tom Christiansen <[EMAIL PROTECTED]> wrote: > I've actually even used this at run-time, such as: > > $value = { > azure => 0xF0, > chartreuse => 0x7FFF00, > lavender=> 0xE6E6FA, > magenta => 0xFF00FF, > turqu

Re: new list: perl6-source-control@perl.org

2000-09-08 Thread Michael G Schwern
On Fri, Sep 08, 2000 at 12:47:00AM -0700, Ask Bjoern Hansen wrote: > subscribe by sending mail to [EMAIL PROTECTED] [EMAIL PROTECTED] I believe. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee As

Re: RFC 39 (v3) Perl should have a print operator

2000-09-08 Thread Ask Bjoern Hansen
On Wed, 6 Sep 2000, Bart Lateur wrote: > >Those are not the semantics of print. It returns true (1) if successful, and > >false (undef) otherwise. You cannot change that. If I write print "0", it > >bloody well shan't be returning false. > > Oh, why not? Does anybody actually *ever* check th

Re: new list: perl6-source-control@perl.org

2000-09-08 Thread Ask Bjoern Hansen
On Fri, 8 Sep 2000, Ask Bjoern Hansen wrote: > List: [EMAIL PROTECTED] > > subscribe by sending mail to [EMAIL PROTECTED] eh, that would be [EMAIL PROTECTED] of course. Thanks to Michael G Schwern for increasing my clue'o'meter. - ask (who have a root canal ready tooth and another one tha

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

2000-09-08 Thread dLux
/--- On Fri, Sep 08, 2000 at 06:59:24AM +, Nick Ing-Simmons wrote: | | >>> eval { | >>> my($_a, $_b, $_c) = ($a, $b, $c); | >>> ... | lock $abc_guard; | >>> ($a, $b, $c) = ($_a, $_b, $_c); | >>> } | | Th

new list: perl6-source-control@perl.org

2000-09-08 Thread Ask Bjoern Hansen
List: [EMAIL PROTECTED] Chair: Dan Sugalski <[EMAIL PROTECTED]> Deadline: 18 September 2000 Mission: To decide the source control system (Perforce, CVS, etc) to be used for perl6 development. subscribe by sending mail to [EMAIL PROTECTED] More information at http://dev.perl.org/lists

Re: RFC 178 (v2) Lightweight Threads

2000-09-08 Thread Nick Ing-Simmons
Chaim Frenkel <[EMAIL PROTECTED]> writes: > >What tied scalar? All you can contain in an aggregate is a reference >to a tied scalar. The bucket in the aggregate is a regular bucket. No? I tied scalar is still a scalar and can be stored in a aggregate. Well if you want to place that restriction o

Re: code repository

2000-09-08 Thread Dave Rolsky
On Thu, 7 Sep 2000, Michael G Schwern wrote: > Refactoring is simply the automated alteration of code without > effecting its purpose. A simple example would be reversing the order > of arguments in a subroutine. A refactoring tool would be able to do > this for you automatically and in all cod

Re: RFC 130 (v4) Transaction-enabled variables for Perl6

2000-09-08 Thread Nick Ing-Simmons
Bart Lateur <[EMAIL PROTECTED]> writes: >On Wed, 06 Sep 2000 11:23:37 -0400, Dan Sugalski wrote: > >>>Here's some high-level emulation of what it should do. >>> >>> eval { >>> my($_a, $_b, $c) = ($a, $b, $c); >>> ... >>> ($a, $b, $c) = ($_a,