[Raku/old-design-docs]
Branch: refs/heads/design-into-raku Home: https://github.com/Raku/old-design-docs
[perl6/specs] 6390a5: Move the design documents into the Raku era
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 6390a500201b5c26512940b0920cd6e9e5111abf https://github.com/perl6/specs/commit/6390a500201b5c26512940b0920cd6e9e5111abf Author: Elizabeth Mattijsen Date: 2019-11-16 (Sat, 16 Nov 2019) Changed paths: M S01-overview.pod M S02-bits.pod M S03-operators.pod M S04-control.pod M S05-regex.pod M S06-routines.pod M S07-lists.pod M S08-capture.pod M S09-data.pod M S10-packages.pod M S11-modules.pod M S12-objects.pod M S13-overloading.pod M S14-roles-and-parametric-types.pod M S15-unicode.pod M S16-io.pod M S17-concurrency.pod M S19-commandline.pod M S21-calling-foreign-code.pod M S22-package-format.pod M S24-testing.pod M S26-documentation.pod M S28-special-names.pod M S29-functions.pod M S31-pragmatic-modules.pod M S32-setting-library/Basics.pod M S32-setting-library/Containers.pod M S32-setting-library/Exception.pod M S32-setting-library/IO.pod M S32-setting-library/Numeric.pod M S32-setting-library/Rules.pod M S32-setting-library/Str.pod M S32-setting-library/Temporal.pod M S99-glossary.pod M html/index.html M html/perl-with-historical-message.css M html/style.css Log Message: --- Move the design documents into the Raku era This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl". Clearly, many of the oldes documents still assumed that Raku was going to be another version of "Perl", hence the word "Perl" was often used without any digit following it. I have tried to deduce the meaning from the context and either changed these to "Raku" (looking towards the future), or left them to be "Perl" (when looking to the past). I've also done this as Raku hopefully will get some more eyeballs looking at it, and how it got designed / conceived. Having a mix of "Perl", "Perl 5" and "Perl 6" in there, will only cause more confusion. Which we do *NOT* want to have. Errors may have been made in this editorial process. So please do not assume this is canon in any way! If you think something is wrong, let us know or even better, provide a Pull Request! Thank you for reading this!
[perl6/specs] 3d62b9: Move the design documents into the Raku era
Branch: refs/heads/design-into-raku Home: https://github.com/perl6/specs Commit: 3d62b9ea86f586612d5df9ea9460a12239b6ccf2 https://github.com/perl6/specs/commit/3d62b9ea86f586612d5df9ea9460a12239b6ccf2 Author: Elizabeth Mattijsen Date: 2019-11-16 (Sat, 16 Nov 2019) Changed paths: M S01-overview.pod M S02-bits.pod M S03-operators.pod M S04-control.pod M S05-regex.pod M S06-routines.pod M S07-lists.pod M S08-capture.pod M S09-data.pod M S10-packages.pod M S11-modules.pod M S12-objects.pod M S13-overloading.pod M S14-roles-and-parametric-types.pod M S15-unicode.pod M S16-io.pod M S17-concurrency.pod M S19-commandline.pod M S21-calling-foreign-code.pod M S22-package-format.pod M S24-testing.pod M S26-documentation.pod M S28-special-names.pod M S29-functions.pod M S31-pragmatic-modules.pod M S32-setting-library/Basics.pod M S32-setting-library/Containers.pod M S32-setting-library/Exception.pod M S32-setting-library/IO.pod M S32-setting-library/Numeric.pod M S32-setting-library/Rules.pod M S32-setting-library/Str.pod M S32-setting-library/Temporal.pod M S99-glossary.pod M html/index.html M html/perl-with-historical-message.css M html/style.css Log Message: --- Move the design documents into the Raku era This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl". Clearly, many of the oldes documents still assumed that Raku was going to be another version of "Perl", hence the word "Perl" was often used without any digit following it. I have tried to deduce the meaning from the context and either changed these to "Raku" (looking towards the future), or left them to be "Perl" (when looking to the past). I've also done this as Raku hopefully will get some more eyeballs looking at it, and how it got designed / conceived. Having a mix of "Perl", "Perl 5" and "Perl 6" in there, will only cause more confusion. Which we do *NOT* want to have. Errors may have been made in this editorial process. So please do not assume this is canon in any way! If you think something is wrong, let us know or even better, provide a Pull Request! Thank you for reading this!
[perl6/specs] 180b53: Revert "Move the design documents into the Raku era"
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 180b534bd6f012e7576384326f2e915162c496be https://github.com/perl6/specs/commit/180b534bd6f012e7576384326f2e915162c496be Author: Elizabeth Mattijsen Date: 2019-11-16 (Sat, 16 Nov 2019) Changed paths: M S01-overview.pod M S02-bits.pod M S03-operators.pod M S04-control.pod M S05-regex.pod M S06-routines.pod M S07-lists.pod M S08-capture.pod M S09-data.pod M S10-packages.pod M S11-modules.pod M S12-objects.pod M S13-overloading.pod M S14-roles-and-parametric-types.pod M S15-unicode.pod M S16-io.pod M S17-concurrency.pod M S19-commandline.pod M S21-calling-foreign-code.pod M S22-package-format.pod M S24-testing.pod M S26-documentation.pod M S28-special-names.pod M S29-functions.pod M S31-pragmatic-modules.pod M S32-setting-library/Basics.pod M S32-setting-library/Containers.pod M S32-setting-library/Exception.pod M S32-setting-library/IO.pod M S32-setting-library/Numeric.pod M S32-setting-library/Rules.pod M S32-setting-library/Str.pod M S32-setting-library/Temporal.pod M S99-glossary.pod M html/index.html M html/perl-with-historical-message.css M html/style.css Log Message: --- Revert "Move the design documents into the Raku era" This reverts commit 6390a500201b5c26512940b0920cd6e9e5111abf. Will re-commit as a PR
[perl6/specs] c5aa24: Remove obsolete file
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: c5aa24071599a46240ba09cd9c91a37749799d7e https://github.com/perl6/specs/commit/c5aa24071599a46240ba09cd9c91a37749799d7e Author: Elizabeth Mattijsen Date: 2019-11-16 (Sat, 16 Nov 2019) Changed paths: R S22-package-format-OLD.pod Log Message: --- Remove obsolete file
Re: Is this a bug?
It is the .perl representation of a Block. > On 18 Sep 2016, at 22:49, Parrot Raiser <1parr...@gmail.com> wrote: > > say { $_ } was the correct thing to use there. (I'm trying to avoid > any mention of O-O for the moment.) > say {} was a "what happens if I do this" exercise. > > What is this -> ;; $_? is raw { #`(Block|170303864) … } output? > > On 9/18/16, Brent Laabs <bsla...@gmail.com> wrote: >> Remember you can call a block with parentheses: >> >>> say { 11 + 31 }; >> -> ;; $_? is raw { #`(Block|140268472711224) ... } >>> say { 11 + 31 }(); >> 42 >> >> >> On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen <l...@dijkmat.nl> >> wrote: >> >>> I think you want: >>> >>> .say for reverse lines; >>> >>> not sure what you are trying to achieve otherwise, but: >>> >>> say { } >>> >>> producing something like >>> >>> -> ;; $_? is raw { #`(Block|170303864) … } >>> >>> feels entirely correct to me. :-) >>> >>> >>> Liz >>> >>>> On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote: >>>> >>>> This code: >>>> 1 #! /home/guru/bin/perl6 >>>> 2 >>>> 3 # Ask for some lines and output them in reverse >>>> 4 # Work out the appropriate EOF symbol for the OS >>>> 5 >>>> 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D"); >>>> 7 >>>> 8 say "Please enter some lines and end them with $EOF"; >>>> 9 >>>> 10 say { for reverse lines() {} }; >>>> 11 >>>> 12 # End >>>> produces this: >>>> Please enter some lines and end them with CTRL-D# obviously from >>> line 8 >>>> -> ;; $_? is raw { #`(Block|170303864) ... }# but >>> this? >>> >>> >>
Re: Is this a bug?
I think you want: .say for reverse lines; not sure what you are trying to achieve otherwise, but: say { } producing something like -> ;; $_? is raw { #`(Block|170303864) … } feels entirely correct to me. :-) Liz > On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote: > > This code: > 1 #! /home/guru/bin/perl6 > 2 > 3 # Ask for some lines and output them in reverse > 4 # Work out the appropriate EOF symbol for the OS > 5 > 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D"); > 7 > 8 say "Please enter some lines and end them with $EOF"; > 9 > 10 say { for reverse lines() {} }; > 11 > 12 # End > produces this: > Please enter some lines and end them with CTRL-D# obviously from line 8 > -> ;; $_? is raw { #`(Block|170303864) ... }# but this?
Re: Help mechanism in REPL?
FWIW, the .WHY is a method just like any other. What would need to be changed, is the behaviour of Mu.WHY (around line 60 in Mu.pm). > On 10 Sep 2016, at 16:41, Brad Gilbertwrote: > > There was some talk in the past about having `.WHY` look up the > descriptions in the POD6 doc ( so that we don't have to bloat Rakudo > with that information ) > > On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed wrote: >> On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote: >>> This isn't a request for a feature, merely a thought experiment. We're >>> still in the phase where it's more important to ensure that existing >>> features work properly than add new ones. >>> >>> How difficult would it be to include a mechanism within the REPL to >>> select either documentation or an example, (possibly from the test >>> suite), for a particular command? Selection might be by some control >>> key combination, cursor positioning, or an alternative to "enter" at >>> the end of the line. The purpose would be to speed development, by >>> enabling an inexperienced developer to look up details while testing. >>> >>> Syntax errors generate messages which attempt to provide help; could >>> this provide the basis for a "help" mechanism? Would this be useful? >>> >>> Opinions? >> >> Well, this sounds like a job for the meta-object protocol (specifically, >> `.WHY`): >> >> https://docs.perl6.org/language/mop#WHY >> >> The simplest option for handling this in the REPL is probably to have some >> sort of automatic handling of Pod sent to sink context, rendering it and >> sending it to a pager. Then, the user could simply do >> Hash.WHY >> (LET THERE BE DOCS!) >> >> And there would be docs.
Re: A practical benchmark shows speed challenges for Perl 6
> On 30 Mar 2016, at 16:06, yary <not@gmail.com> wrote: > > Cross-posting to the compiler group- > > On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen <l...@dijkmat.nl> wrote: >> If you know the line endings of the file, using >> IO::Handle.split($line-ending) (note the actual character, rather than a >> regular expression) might help. That will read in the file in chunks of 64K >> and then lazily serve lines from that chunk. > > This reminds me of a pet peeve I had with p5: Inability to easily > change the default buffer size for reading & writing. > > I'm the lone Perl expert at $work and at one point was trying to keep > a file processing step in perl. These files were about 100x the size > of the server's RAM, consisted of variable-length newline-terminated > text, the processing was very light, there would be a few running in > parallel. The candidate language, C#, has a text-file-reading object > that lets you set its read-ahead buffer on creation/opening the file- > can't remember the details. That size had a large impact on the > performance of this task. With perl... I could not use the > not-so-well-documented IO::Handle->setvbuf because my OS didn't > support it. I did hack together something with sysread, but C# won in > the end due partly to that. > > It seems this "hiding-of-buffer" sub-optimal situation is being > repeated in Perl6: neither https://doc.perl6.org/routine/open nor > http://doc.perl6.org/type/IO::Handle mention a buffer, yet IO::Handle > reads ahead and buffers. Experience shows that being able to adjust > this buffer can help in certain situations. Also consider that perl5 > has defaulted to 4k and 8k, whereas perl6 is apparently using 64k, as > evidence that this buffer needs to change as system builds evolve. > > Please make this easily readable & settable, anywhere it's implemented! Thanks for your thoughts! I’ve implemented $*DEFAULT-READ-ELEMS in https://github.com/rakudo/rakudo/commit/5bd1e . Of course, all of this is provisional, and open for debate and bikeshedding. Liz
Re: Backwards compatibility and release 1.0
> On 15 Oct 2015, at 12:57, Mark Overmeer <m...@overmeer.net> wrote: > > * Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]: >> FWIW, I’m with FROGGS on this. >> use variables :D; > > In the first response to this message, Moritz spoke about > use invocant :D; > and use parameters :D; > > Three different things? There are actually 4 different default setters: use variables :D;# works, e.g. ‘my Int $a = 42’ use attributes :D; # works, e.g. ‘has Int $.a = 42’ use invocant :D; # parses, does not work yet, e.g. method a(Int:) {} # Int:D: use parameters :D; # parses, does not work yet, e.g. sub a(Int $a) {} # Int:D >> at the top of the scope of your code, and then you’re set. I admit >> it feels a *little* like the “use strict” boilerplate of Perl 5. > > It is. > >> On the other hand, I think by just specifying a type *without* smiley, >> is already so much better than the situation in Perl 5 that the lacking >> strictness of :D will not be needed much to catch programming / garbage >> in type of errors anyway. > > Much better, of course. Programming languages are used by people > of different taste. Some may find "much better" enough, other people > want more. And sometimes less is more :-) Liz
Re: Backwards compatibility and release 1.0
> On 15 Oct 2015, at 11:06, Tobias Leichwrote: > Am 15.10.2015 um 10:47 schrieb Smylers: >> Moritz Lenz writes: >> >>> On 10/13/2015 10:52 AM, Richard Hainsworth wrote: >>> Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: > We have 390+ modules, and hand-waving away all trouble of > maintaining them seems a bit lofty. Surely, the idea of keeping the release number below 1.0 is to warn early adopter developers that code is subject to change and thus in need of maintenance? >>> ... a large percentage of the module updates are done by group of >>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390 >>> modules. Modules they are usually not all that familiar with, and >>> usually don't have direct access. So they need to go through the pull >>> request dance, waiting for reaction from the maintainer. In short, it >>> sucks. >> Thanks for the explanation, Moritz. That does make sense. >> >> I'm still a _little_ uneasy because that sounds a bit like the >> explanation of why Makefiles have to use tab characters: >> >> I just did something simple with the pattern newline-tab. It worked, >> it stayed. And then a few weeks later I had a user population of about >> a dozen, most of them friends, and I didn't want to screw up my >> embedded base. The rest, sadly, is history. >> >>— Stuart Feldman http://stackoverflow.com/a/1765566/1366011 >> >> Though the important difference is that invisible whitespace characters >> that some editors don't even let you type are particularly >> beginner-hostile, whereas allowing undef arguments where they don't make >> sense (and hence where callers don't generally try supplying undef) is >> something that many Perl 5 programs have been doing for years with no >> widespread harm. >> >> Cheers >> >> Smylers > Btw, In my opinion the current model about :D etc is very correct. I > don't see any need to change the > defaults as how type objects or their definedness is implementet. > Changing for example the params > to mean Int:D by default when one writes Int is something you have to > explain a lot. And in fact it is a lie. > There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but > there is also a rule about "All is > fair if you predeclare". But if I don't predeclare that I mean Int:D by > writing Int, then the compiler is > not allowed to change the meaning of what I wrote. FWIW, I’m with FROGGS on this. Because Perl 6 has gradual typing. Going automatically from Int to Int:D, doesn’t feel gradual for me. If you want this behaviour in your code, it is as easy as adding a: use variables :D; at the top of the scope of your code, and then you’re set. I admit it feels a *little* like the “use strict” boilerplate of Perl 5. On the other hand, I think by just specifying a type *without* smiley, is already so much better than the situation in Perl 5 that the lacking strictness of :D will not be needed much to catch programming / garbage in type of errors anyway. Liz
Re: [perl6/specs] 614b6f: doc with/without
If this is about: These may be cascaded: with $s.index(a) { Found a at $_ } orwith $s.index(b) { Found b at $_ } orwith $s.index(c) { Found c at $_ } else { Didn't find a, b or c” } then the code is correct. What would be the point of searching for “a” again and again if it wasn’t found the first time? Liz On 11 Aug 2015, at 06:08, Richard Hainsworth rnhainswo...@gmail.com wrote: Is there an error in the cascade? Shouldn't the indices be 'a', 'b', 'c'; not 'a','a','a' ? On 08/10/2015 11:26 PM, yary wrote: with, without look awesome. -y On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0 https://github.com/perl6/specs/commit/614b6f36e1cae4c787e378bc6ab2afa1f86de1f0 Author: TimToady la...@wall.org Date: 2015-08-08 (Sat, 08 Aug 2015) Changed paths: M S04-control.pod Log Message: --- doc with/without
Re: Synopses size and revision state
On 15 May 2015, at 16:05, Parrot Raiser 1parr...@gmail.com wrote: Without doing too much work, can anyone offer an estimate of the volume of the Perl 6 Synopses? I'm assuming that by now, they are unlikely to undergo serious modification. I'm trying to estimate the cost of rendering them to dead-tree versions for study. (Personal limitation; I can look up a command definition online, but for study and mental integration, it's got to be something like a real book.) at 4+ lines and 100 lines / page, that would be about 400 pages ? Liz
Re: S02 mistake re Blob?
On 21 Feb 2015, at 21:56, Darren Duncan dar...@darrenduncan.net wrote: On 2015-02-21 2:45 AM, Moritz Lenz wrote: On 21.02.2015 08:51, Darren Duncan wrote: I notice from looking at http://design.perl6.org/S02.html that Blob is listed both as being a role and as a type. See http://design.perl6.org/S02.html#Roles for an example of the former, and http://design.perl6.org/S02.html#Immutable_types for an example of the latter. -- Darren Duncan so, you think roles aren't types? (Also, roles auto-pun into classes upon usage). When I said type I meant class. As I recall from the rest of the spec, things were either roles or classes. You can't instantiate a role directly, so if a Blob is declared as a role you can't just instantiate one directly, isn't that how it works? Either way it seemed to be getting treated differently. -- Darren Duncan $ 6 'role A {}; my $a = A.new; say $a' A.new() You *can* instantiate a Role directly. See above. Liz
Re: state and = vs :=
On 01 Oct 2014, at 07:48, Father Chrysostomos spr...@cpan.org wrote: Does ‘state’ govern ‘:=’ the way it governs ‘=’? In other words, just as this: state $x = 1; only assigns to $x once (per closure), does the same apply to this? state $x := $y; I can’t find anything in the specs that implies that it does. The reason I ask is that I am currently implementing binding for Perl 5, but the syntax is different— \$x = \$y; (The reason for the different syntax is that, when we tried to use :=, we could not find a coherent way to handle edge cases [e.g., flattening vs not flattening]. Reusing existing Perl 5 syntax seemed the most straightforward and intuitive approach.) —and I am debating whether \state $x = \$y should bind only once or every time the surrounding code is executed. I could argue it either way (though I am leaning toward the latter), so I thought to find out what Perl 6 does. It would seem that binding state variables will be something that will be prohibited in Perl 6, until such time we find a good use case for it. [15:55:36] lizmat well, all of this was because of a question of Father Chrysostomos (a very productive p5p contributor) on p6l [15:57:01] jnthn OK. Well, I'll leave it at, I'm happy enough with the current semantics, so unless TimToady++ feels they have to chnage, then I'm not inclined to do much about the status quo. [15:57:44] jnthn (Where by the current semantics I mean, what Moar does, and I'm about certain what we do on JVM. I don't actually know how things are on Parrot.) [15:57:59] lizmat eh, but the current semantics silently do the wrong thing, no ? [15:59:11] jnthn lizmat: Depends how you define the semantics of state. [15:59:44] jnthn lizmat: Note that if you go binding a temp or let var you are in equal trouble. [16:00:03] moritzwouldn't mind compile-time disallowing rebinding temp/let/state vars [16:00:05] jnthn 'cus those are certainly about value, not container [16:00:14] lizmat moritz +1 [16:00:18] jnthn I took state to be wanting the same semantics [16:00:31] jnthn Yeah, I could go with a conservative approach of just disallow it [16:00:53] lizmat I'll answer FC Hope this answer your question, Liz
Re: Class attribute introspection
Maybe http://en.wikipedia.org/wiki/Metaobject is a good start for reading up on what a MOP (Meta-Object Protocol) is. Liz === On 28 Oct 2013, at 14:17, Richard Hainsworth rich...@rusrating.ru wrote: Moritz, You are the everflowing font of knowledge. Thanks. However, I read the synopsis on objects and did not find the .get_value method. Pardon the ignorance, but what is the MOP. I sometimes get floored by the jargon. I read about the indirection for methods, but how does that relate to attributes? Richard On 10/28/2013 01:45 PM, Moritz Lenz wrote: Hi Richard, On 10/28/2013 08:07 AM, Richard Hainsworth wrote: Perhaps I am using class incorrectly, but I set up a class, then change some of the parameters in an instance of the class. Next I would like to discover what the current state of the instance is. There is a way to introspect through the MOP: class A { has $!x = 42; }; my $obj = A.new; say A.^attributes[0].get_value($obj); It's not straight forwards, and that's actually a feature :-) The usual way to go is through the accessors, and indirect method calls with $obj.$name(); Cheers, Moritz
Re: Perl 6 in non-English languages
On Jun 23, 2010, at 12:34 AM, SundaraRaman R wrote: This is an idea that originated in #perl6 during a discussion with slavik ( http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow Perl 6 source code to be written in natural languages other than English. The motivation would be to make programming accessible to a lot of people who don't know English well (or at all), to make it easier to teach programming to kids in non-English speaking countries, and just plain fun. Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place a modification is required would be in the keywords. However, it is not a simple matter of substituting s/keyword/local_language_keyword/ since the resultant phrasing might be awkward or meaningless and unreadable (examples in the linked discussion). It requires reordering the syntax of each construct. Is it possible to do this at a module level? If so, how much English usage would that require before someone could start programming in their own language - say, two, for a shebang line and a use Lang::Language line? or zero, by using perl6 -MLang::Language in the command line? Are there any ongoing works in this vein? Having been that road down at least once in my life already (using the TUTOR language), I would be very much against adding this as a standard feature. Unless you have people that can provide support (aka a user base) for that language, you are going to introduce a babylonian knot of misunderstanding in mailinglist, chats and what not. If this would be added as a feature, then there should be an easy way to take any source file in a different natural language, and have it rendered into English (or any other of the languages supported that way). My old 2cents worth... Going back to lurking mode again. Liz
Re: Default program
At 00:05 -0800 4/1/04, Brent 'Dax' Royal-Gordon wrote: On the other hand, the current behavior may be somewhat entrenched, and might break our promise to assume that code is Perl 5 until we see a different indication. As an alternative, perhaps the -H command-line switch could be used to use a hello world program. I think we need to consider all of the implications here: Hello World is very english centric, so I would assume that Perl 6 would need investigate the locale and change the text to Monde, Allo! if you're using a French locale, Hallo, Welt! for German locale, and 1 april! for Dutch. ;-) Liz
Resource Management ?
After lurking on the Perl6-lists and finally catching up on this long discussion about garbage collection, I'm coming out ;-). The reason I'm coming out is that I realised that we should maybe have a radically different view on garbage collection than we have now. Think about it: 1: in an ideal world with unlimited resources, who would need garbage collection anyway? Or: simple oneliners and small scripts don't need GC. 2: limited resources may appear still available when in fact, they are not. E.g. a limit on the total number of simultaneous database connections as seen from the database server, not the Perl process. The Perl process still thinks it can open connections, when in fact the database server is already saturated. 3: some resources may not be needed temporarily, but should become available magically when needed. E.g. virtual memory, database connections that re-connect automatically after a disconnect (for whatever reason). 4: As a Perl programmer, I don't care whether a file-handle has been closed because of resource management, as long as it is available to me when I need it. I don't care whether a connection to a database server has been re-used by other database server users, as long as I have a connection (transparently) when I need it. 5: As a server administrator, I would like to be able to limit the available memory to a Perl program or maximum number of database connections, so that it behaves nicely towards other users of that server. I think this calls for a resource management system, rather than a garbage collection system. A resource management system with an API with which resources (their creation, cleanup and destruction routines) can be registered. No garbage collection (which implies a not well thought out "way of life" to me) but planned ahead resource management (know in advance what you need when) for situations that need it. (I guess my Dutch background is showing here, wanting to have everything neatly organised ;-). This resource management system would ideally include a (pluggable) virtual memory system for Perl itself (Perl may be able to know better what to temporarily store on disk than any OS would). It would include the file IO subsystem. It would include the handling of any external connections (such as connections to databases). Or any other resource that is in limited availability. And of course, such a resource management system should degrade to a "everything is free" approach for simple one-liners and small scripts, like the current situation. Elizabeth Mattijsen P.S. Dan: I hope you don't mind not waiting for your PDD, but this seemed too important to me for the train of thought about garbage collection at this point in time.