Re: perl 6 requirements

[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