Re: perl 6 requirements

If an individual had a Perl requirement they wanted to see in the SRD, to 
whom would they address/send it?

Also, on http://infotrope.net/opensource/software/perl6/ it would be useful 
to have a table of contents for the HTML link, hyperlinked to each section: 
Introduction, Internals, Language, and so on. The NEXT link isn't obvious, 
particlarly since users must scroll down to see it.

Thank-You,
M


>From: Hildo Biersma <[email protected]>
>To: [email protected]
>CC: [email protected]
>Subject: Re: perl 6 requirements
>Date: Mon, 31 Jul 2000 12:17:58 +0100
>
>[email protected] wrote:
> >
> > OK.  I've got a draft requirements document together.  I was going to
> > post it, but it's 700 lines long, so instead I've put it up at
> > http://infotrope.net/opensource/software/perl6/ in a variety of formats
> > (txt, HTML, ps, pdf, docbook source).
>
>Good work!  Here are my comments on this revision...
>
>In item 2.3 (pseudo-hashes), it might be useful to include Chip's Topaz
>experience, which is (summarized) pseudo-hashes are especially nasty
>as any array can suddenly become a pseudo-hash at run-time.
>Stricter data-typing may alleviate this problem.
>
>In item 2.4 (garbage collection), we need to make sure there is an
>alternative for people that need guaranteed cleanup time of their
>objects (such as SelectSaver).  To a large extent, this could be solved
>by having a special kind of 'Guard' object in the language that either
>is reference-counted or cleaned up when the scope it lives in is exited;
>the 'Guard' object can then run a 'finalize'-like cleanup method for the
>object it is guarding.
>
>In item 3.1.3 (exceptions), we need to start a discussion on at least
>the following related issues:
>- do system functions also throw exceptions (e.g. open()),
>   maybe optionally if an option is set?
>- Do we include a Java-like finally() clause?
>- Do we support re-throw of exceptions?
>- Must exceptions be objects (as in Java), or can they be any
>   data type (as in C++, IMHO far more useful)
>
>In issue 3.1.6, note that Damian Conway's Text::Balanced module comes
>quite close to parsing most of the perl constructs - but not the
>statements.
>
>In issue 3.1.8 (safe 'each'):
>- Using explicit iterators could help
>- It would also be useful if a 'last' out of an 'each' loop could
>destroy
>   the iterator (possibly on demand)
>
>In issue 3.2.1 (localtime), note that the month starting at 0 is very
>useful for arrays - which is of the course the reason it is done this
>way.  I am not convinced going to an index of 1 is the right approach.
>It might be more useful if the core came with a useful, minimalistic but
>inheritable, Date object.
>
>In issue 3.5.1 (data types), I would strongly propose that any strong
>data typing of perl is done sanely: using the C/C++ approach of
>'natural' data sizes.
>This means 'int' means 'whatever your architecture usefully supports as
>an int'.
>The Java approach (and 'int' is 32 bits, a 'long' is 64 bits, and if you
>have a 128-bit CPU, well, we're not going to use it) emphasizes
>portability a bit too much over usefulness.  The Microsoft approach
>(Int32, Int64, etc) is abhorrant to me and doesn't solve any of the real
>issues - though of course having these available for extension module
>writers would come in handy.
>
>In issues 3.6.1 (OO), I don't see where the Exporter comes in with
>objects.  I propose this issue be split into 'lets make writing
>procedural modules easier' and 'lets make writing classes easier'.
>
>In issue 3.6.2 (speed of method calls), this would probably tie in to
>stricter checking at compile-time - which allows the use of vtables
>etc.  Doing this properly when also supporting multiple inheritance is
>very hard (see any book on C++ implementation), so way may not want to
>be as fast and complex as C++.
>
>In issue 3.6.3, let's make sure week keep the current approach working.
>For simulations, I also need to be able to re-bless objects - we need to
>keep that.
>
>In issue 3.6.4, note that C++ has both arrow and dot - and they have a
>distinct meaning (follow-pointer vs read-structure).  Of course, Java
>doesn't have the read-structure operation, so it uses the dot for
>follow-pointer (how nice). Let's make sure we will never need both
>meanings for the same data-type before we get rid of the arrow.
>
>In issue 4.4 (undef warnings), note it is by no means always possible to
>attribute an undef to a variable - for instance, in a larger expression
>involving functiion calls.  Also, the better we get at compiling and
>optimizing code, the harder this requirement is going to be.
>
>In issue 6.1 (object frameworks), note that Microsoft is moving away
>from COM/DCOM to their .NET architecture, which seems to be quite sane
>for something coming out of Redmond.  We'd do better to support *that*
>than to work on COM/DCOM.
>
>For issue 7.3 (module dependency hell), we should add an requirement
>that you can ask for the following:
>- use default version of a module
>- use a specific version of a module (or die)
>- use a specific version of a module, or the default if it is newer
>- use a specific, or later, version of a module
>- use the latest version of a module
>Using namespace/pathname/version tricks, all of these are reasonably
>feasible and very useful.
>
>For issue 10.1 (persistence), note there is also no real persistence
>standard for C++ - and that has a reason.  (Yes, I know ther's an OODBMS
>binding.  That doens't cover RDBMSes.)  The reason there is no One True
>Persistence Model is that requirements differ.  Using serialization (as
>in Java) is bot sufficient when it comes to large collections of objects
>and dealing with transactions.  So I would guess that most
>standardization here is doomed.
>
>Finally, some missing requirements:
>- Named subroutine parameters (no more @_, or at least an optional @_)
>- (pipedream) making closures proper first-level objects that
>   can be serialized/dumped and later restored.
>
>Hildo

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com