uc import
Brent "Dax" Royal-Gordon
subject a few days ago, but apparently it didn't get through.)
A few weeks ago, my father and I were discussing Perl. (He is a
professional programmer of about twenty-five years; the last seven or so
have been spent building Visual FoxPro apps for a major financial
institution.) I ended up explaining Perl's module loading mechanism to
him; he agreed that the concept was elegant, but thought that calling
the subroutine "import" was a bad idea, because it kept users from
creating a sub with that name for other purposes.
It occurred to me that Perl has a "syntax" in place for dealing with
this problem--subroutines with special purposes have names in all-caps.
(Besides all the blocks like BEGIN and END, consider DESTROY. I also
seem to remember that there's an all-caps object initializing method in
Perl 6.) I suggest that this mechanism be extended to import, making it
IMPORT instead. This would return to the module writer's domain a
common English word that is often used in computer contexts, which is
probably a Good Thing.
Of course, this entire post assumes that import isn't going away entirely.
--Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Larry Wall
: (Apologies if this is a repeat--I tried to send something on the same
:
: A few weeks ago, my father and I were discussing Perl. (He is a
: professional programmer of about twenty-five years; the last seven or so
: have been spent building Visual FoxPro apps for a major financial
: institution.) I ended up explaining Perl's module loading mechanism to
: him; he agreed that the concept was elegant, but thought that calling
: the subroutine "import" was a bad idea, because it kept users from
: creating a sub with that name for other purposes.
:
: It occurred to me that Perl has a "syntax" in place for dealing with
: this problem--subroutines with special purposes have names in all-caps.
: (Besides all the blocks like BEGIN and END, consider DESTROY. I also
: seem to remember that there's an all-caps object initializing method in
: Perl 6.) I suggest that this mechanism be extended to import, making it
: IMPORT instead. This would return to the module writer's domain a
: common English word that is often used in computer contexts, which is
: probably a Good Thing.
Yes, it's a pretty good idea. In fact, RFC 74 proposes the same thing.
But I classified it under Apocalypse 11, Modules, which we skipped over
to get to Objects first. So it hasn't actually been discussed much.
: Of course, this entire post assumes that import isn't going away entirely.
Well, there has to be a general hook for it, and IMPORT is about as
good a name as any, if we need a name. Though most modules won't in
fact define an IMPORT--most exportation will be done simply by marking
the routines and variables in question "is exportable" or some such.
The default importer (whatever its name) will know how to find those
names and alias them.
Interestingly, the module name itself might be aliased, since the
module's full name might include author and version information.
When you use a module without specifying those things, you get
wildcarded to the most recent available version. But if you specify
them, you get the one you want. In either event, the short name for
the module is really an alias to the complete name, so if module A
uses module C, and module B also uses module C, they might in fact be
using two different versions. There will probably need to be some
additional discipline to let these different versions share those
resources that can be shared. Doubtless this involves factoring out
the shared resource in some kind of OO-ish. And in fact, the same
version aliasing can happen with classes and roles, since they're
all just fancy packages. Though we have to think through how inner
packages work--they probably just track the version number of the
file they're in, whether the file defines a class or a module.
But that's for A11.
Larry
Aaron Sherman
> [...] RFC 74 proposes the same thing. But I classified it under
> Apocalypse 11, Modules, which we skipped over to get to Objects
> first. So it hasn't actually been discussed much.
> most exportation will be done simply by marking the routines and
> variables in question "is exportable" or some such.
I cringe at what I'm about to ask because I know it's pushy, but thus is
the burden of my impatience and hubris...
There was a document:
TITLE
Apocalypse 1: The Ugly, the Bad, and the Good
AUTHOR
Larry Wall <la...@wall.org>
VERSION
Maintainer: Allison Randal <a...@shadowed.net>
Date: 2 Apr 2001
And in it Apocalypse #26 was mentioned. Above, Larry mentions #11. At
first the rate of 1 apolcalypse per month seemed to support the idea
that Perl 6 would be defined within the next couple of years. However,
trending shows that this function was actually logarithmic, and spacing
has increased from month to quarter to half-year to year....
At the current rate, the aforementioned apoc #11 will be out sometime
after I die, a frustrated old man who remembers the glory days of Perl
3.
There are many ways that we could deal with this, and I think all of
them are up to Larry:
1. Larry gets help in writing these (various degrees of delegation).
2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done.
3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set.
4. Don't worry, be happy (aka back in your hole, Hobbit! ;-)
So Larry, it's up to you. Is there some way to accelerate Perl 6? Can we
help?
Before people say that #3 already exists, I'm not talking about adding
sugar to Perl 5, I'm talking about a major overhaul that really gives us
a stop-gap while we wait for Perl 6.
I hope that everyone understands that I'm saying this because I want to
help. I backed off of Perl 6 a while back, but as Perl 5 begins to feel
more and more like a holding pattern for Perl 6, I find myself needing
the next step to be taken for work reasons and wanting it for personal
reasons.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Chromatic
> And in it Apocalypse #26 was mentioned. Above, Larry mentions #11. At
> first the rate of 1 apolcalypse per month seemed to support the idea
> that Perl 6 would be defined within the next couple of years. However,
> trending shows that this function was actually logarithmic, and spacing
> has increased from month to quarter to half-year to year....
No plan survives first contact with the enemy.
With Apocalypse 12 (soon!), much of the plan is finished. There are
still rough edges to smooth down with regard to modules and packages, or
at least how they differ from objects, but there's more than enough for
implementation.
> 1. Larry gets help in writing these (various degrees of delegation).
Already in place. See the end of Apocalypse 6 for the very short
Apocalypse 7.
> 2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done.
No.
> 3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set.
Perl 5.10.
> 4. Don't worry, be happy (aka back in your hole, Hobbit! ;-)
Yeah, that'd be my recommendation.
> I hope that everyone understands that I'm saying this because I want to
> help. I backed off of Perl 6 a while back, but as Perl 5 begins to feel
> more and more like a holding pattern for Perl 6, I find myself needing
> the next step to be taken for work reasons and wanting it for personal
> reasons.
There's a compiler in progress in Parrot's languages/perl6 directory, as
well as Parrot itself, documentation to write, test suites to write,
synopses to read and to correct....
Honestly -- and I don't aim this at anyone in specific -- I really
wonder where the idea comes from that people must wait until Larry makes
his final pronouncement to all of mankind before doing anything. If
everyone believed that, we wouldn't have much of Parrot or Perl 6 or
Ponie right now.
Of course, if fewer people believed that, we'd have more of each right
now. I'd consider that a good thing.
-- c
Simon Cozens
> At the current rate, the aforementioned apoc #11 will be out sometime
> after I die, a frustrated old man who remembers the glory days of Perl
> 3.
The current rate is not going to be sustained; the Perl 6 class sytem
is a massive thing, and once that's done, most of the rest of Perl 6
should fall into place pretty quickly.
> 1. Larry gets help in writing these (various degrees of delegation).
I think we've been through this idea, no?
> 2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done.
Ouch, no.
> 3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set.
Shouldn't we all be helping Artur with Ponie?
> 4. Don't worry, be happy (aka back in your hole, Hobbit! ;-)
Why do we need Perl 6 tomorrow?
--
"The best index to a person's character is a) how he treats people who can't
do him any good and b) how he treats people who can't fight back."
-- Abigail Van Buren
Robin Berjon
> With Apocalypse 12 (soon!)
I'm sorry but this just begs for the question: (vaguely) how soon? :)
I get all excited whenever I hear "Perl" and "six" in the same sentence,
and it's building up to be unbearable ;)
--
Robin Berjon
Aaron Sherman
> > 1. Larry gets help in writing these (various degrees of delegation).
>
> I think we've been through this idea, no?
I dropped off the face of the earth for a bit... sorry if I am
re-hashing something old I did not see anything in the archives, but
have not read everything in depth either.
> > 2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done.
>
> Ouch, no.
I would tend to agree.
> > 3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set.
>
> Shouldn't we all be helping Artur with Ponie?
Well, p5 on parrot isn't really any closer to Perl 6 is it? I agree that
it's needed, but not sure that it resolves the problem that p5 can't
really grow substantially while the spectre of p6 hangs over it. Thus,
we're in a kind of stasis for now.
> > 4. Don't worry, be happy (aka back in your hole, Hobbit! ;-)
>
> Why do we need Perl 6 tomorrow?
Tomorrow? I don't. Keep in mind that I've held off this comment for a
year now.
But everything that I see as an external observer tells me that p6 won't
even be defined in my lifetime. You say that's not true, and believe me
I CHEER to hear that. But if it is true, I want to know how I can help
make it NOT true.
There are certain structural problems with Perl as it stands that I
really need to get fixed or I'm going to have to stop using it in
production in favor of other languages that I like far less. It was my
understanding that those things were also some of the primary goals of
Perl 6, so I got excited in 2001 about how much better my life would be
... soon ....
Those include:
* way to package environment-neutral programs reliably
* parameterized argument passing with basic type constraints
* much improved and more reliable thread-safety
* A far lighter weight exception system
If Perl 6 contained only the above and nothing else, I would be a happy
camper, and my production code would be far less prone to errors and
structural shortcomings.
Larry Wall
: I cringe at what I'm about to ask because I know it's pushy, but thus is
: the burden of my impatience and hubris...
:
: There was a document:
:
: TITLE
: Apocalypse 1: The Ugly, the Bad, and the Good
: AUTHOR
: Larry Wall <la...@wall.org>
: VERSION
: Maintainer: Allison Randal <a...@shadowed.net>
: Date: 2 Apr 2001
:
: And in it Apocalypse #26 was mentioned. Above, Larry mentions #11. At
: first the rate of 1 apolcalypse per month seemed to support the idea
: that Perl 6 would be defined within the next couple of years. However,
: trending shows that this function was actually logarithmic, and spacing
: has increased from month to quarter to half-year to year....
Well, some of that relates to the fact that last year I basically
had to take half a year off to participate in various non-optional
gastric revisions.
Which of course may only prove your point. I wonder if I'll have to
take the whole year off this year... Next year I might have to take
two years off...
: At the current rate, the aforementioned apoc #11 will be out sometime
: after I die, a frustrated old man who remembers the glory days of Perl
: 3.
Well now, I remember Perl 0, sonny. They don't make 'em like they used to...
: There are many ways that we could deal with this, and I think all of
: them are up to Larry:
:
: 1. Larry gets help in writing these (various degrees of delegation).
Er, I've been getting lots of help. That's part of what slows things
down, but it also makes them righter...eventually...after I filter all
the input down to something coherent. It's the coherence that I can't
delegate, and if I tried to, we would certainly end up with Second
System Syndrome Done Wrong, instead of Done Right.
As they say, you can't have all of Good, Fast, Cheap. I'm concentrating
on the Good part. So it's not going to be Fast. As for Cheap, well...
I have to take time off today to apply for college scholarships next
year, or we can't afford to send Aron to college. If someone wants to
donate college tuition I can be faster by a day or so. But that ain't
Cheap...
: 2. Perl 6 now (apoc 1-6), Perl 7 when the apocs are done.
Perl 6 now is pretty much A1-6 plus 12. That's actually most of the
earth-shaking stuff. The later apocalypses have bike-shed tendencies.
Plus we've actually decided a lot of what's in those chapters already.
: 3. Perl 5.aleph-1: Perl 5 code-base, Perl 6ish feature-set.
How "ish" is "ish"? The main problem with that approach (other than
that it takes talent away from the Parrot effort) is that migration
becomes a bitch when you break things every subrelease. I'm all in
favor of the evolutionary approach when it works, but I think if
we're breaking things on purpose, we have to do it all at once.
: 4. Don't worry, be happy (aka back in your hole, Hobbit! ;-)
That too. :-)
: So Larry, it's up to you. Is there some way to accelerate Perl 6? Can we
: help?
Actually, for the moment I think Parrot is on the critical path more
than I am.
: Before people say that #3 already exists, I'm not talking about adding
: sugar to Perl 5, I'm talking about a major overhaul that really gives us
: a stop-gap while we wait for Perl 6.
It would take as long as Parrot to do P6ish completely. Longer, in fact,
because you'd be fighting the general creakiness of the P5 codebase.
: I hope that everyone understands that I'm saying this because I want to
: help. I backed off of Perl 6 a while back, but as Perl 5 begins to feel
: more and more like a holding pattern for Perl 6, I find myself needing
: the next step to be taken for work reasons and wanting it for personal
: reasons.
I'd love to be done with it too. Here's the chapter-by-chapter list
of RFCs so you can see the kind of stuff in the later chapters. I'll
comment briefly on the undone chapters.
ch01/016.bdb Keep default Perl free of constraints such as warnings and strict.
ch01/026.ccb Named operators versus functions
ch01/028.acb Perl should stay Perl.
ch01/073.adb All Perl core functions should return objects
ch01/141.abc This Is The Last Major Revision
ch02/005.cdr Multiline Comments for Perl.
ch02/009.bf Highlander Variable Types
ch02/010.rr Filehandles should use C<*> as a type prefix if typeglobs are eliminated.
ch02/034.aaa Angle brackets should not be used for file globbing
ch02/038.bdb Standardise Handling Of Abnormal Numbers Like Infinities And NaNs
ch02/043.bcb Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars
ch02/051.ccr Angle brackets should accept filenames and lists
ch02/071.aaa Legacy Perl $pkg'var should die
ch02/102.dcr Inline Comments for Perl.
ch02/103.rr Fix C<$pkg::$var> precedence issues with parsing of C<::>
ch02/105.aaa Remove "In string @ must be \@" fatal error
ch02/109.rr Less line noise - let's get rid of @%
ch02/111.aaa Here Docs Terminators (Was Whitespace and Here Docs)
ch02/133.bcr Alternate Syntax for variable names
ch02/134.bcc Alternative array and hash slicing
ch02/139.cfr Allow Calling Any Function With A Syntax Like s///
ch02/161.adb Everything in Perl becomes an object.
ch02/162.abb Heredoc contents
ch02/175.rr Add C<list> keyword to force list context (like C<scalar>)
ch02/192.ddr Undef values ne value
ch02/196.bcb More direct syntax for hashes
ch02/201.bcr hash slicing
ch02/212.rr Make length(@array) work
ch02/218.bcc C<my Dog $spot> is just an assertion
ch02/222.abb Interpolation of object method calls
ch02/226.acc Selective interpolation in single quotish context.
ch02/237.adc hashes should interpolate in double-quoted strings
ch02/245.rr Add new C<empty> keyword to DWIM for clearing values
ch02/251.acr Interpolation of class method calls
ch02/252.abb Interpolation of subroutines
ch02/263.rr Add null() keyword and fundamental data type
ch02/327.dbr C<\v> for Vertical Tab
ch02/328.bcr Single quotes don't interpolate \' and \\
ch03/024.rr Data types: Semi-finite (lazy) lists
ch03/025.dba Operators: Multiway comparisons
ch03/039.rr Perl should have a print operator
ch03/045.bbb C<||> and C<&&> should propagate result context to both sides
ch03/054.cdr Operators: Polymorphic comparisons
ch03/081.abb Lazily evaluated list generation functions
ch03/082.abb Arrays: Apply operators element-wise in a list context
ch03/084.abb Replace => (stringifying comma) with => (pair constructor)
ch03/104.ccr Backtracking
ch03/138.rr Eliminate =~ operator.
ch03/143.dcr Case ignoring eq and cmp operators
ch03/170.ccr Generalize =~ to a special "apply-to" assignment operator
ch03/283.ccc C<tr///> in array context should return a histogram
ch03/285.acb Lazy Input / Context-sensitive Input
ch03/290.bbc Better english names for -X
ch03/320.ccc Allow grouping of -X file tests and add C<filetest> builtin
ch04/006.acc Lexical variables made default
ch04/019.baa Rename the C<local> operator
ch04/022.abc Control flow: Builtin switch statement
ch04/063.rr Exception handling syntax
ch04/064.bdc New pragma 'scope' to change Perl's default scoping
ch04/083.aab Make constants look like variables
ch04/088.bbc Omnibus Structured Exception/Error Handling Mechanism
ch04/089.cdr Controllable Data Typing
ch04/106.dbr Yet another lexical variable proposal: lexical variables made default
ch04/113.rr Better constants and constant folding
ch04/119.bcr Object neutral error handling via exceptions
ch04/120.bcr Implicit counter in for statements, possibly $#.
ch04/167.bcr Simplify C<do BLOCK> Syntax
ch04/173.bcc Allow multiple loop variables in foreach statements
ch04/199.abb Short-circuiting built-in functions and user-defined subroutines
ch04/209.cdr Fuller integer support in Perl.
ch04/262.cdr Index Attribute
ch04/279.cdr my() syntax extensions and attribute declarations
ch04/297.dcr Attributes for compiler hints
ch04/309.adr Allow keywords in sub prototypes
ch04/330.acc Global dynamic variables should remain the default
ch04/337.bcc Common attribute system to allow user-defined, extensible attributes
ch04/340.dcr with takes a context
ch04/342.bcr Pascal-like "with"
ch05/072.aaa Variable-length lookbehind.
ch05/093.abb Regex: Support for incremental pattern matching
ch05/110.bbb counting matches
ch05/112.acc Assignment within a regex
ch05/135.acr Require explicit m on matches, even with ?? and // as delimiters.
ch05/144.aaa Behavior of empty regex should be simple
ch05/145.acr Brace-matching for Perl Regular Expressions
ch05/150.acc Extend regex syntax to provide for return of a hash of matched subpatterns
ch05/156.aaa Replace first match function (C<?...?>) with a flag to the match command.
ch05/164.ccr Replace =~, !~, m//, s///, and tr// with match(), subst(), and trade()
ch05/165.acc Allow Varibles in tr///
ch05/166.abc Alternative lists and quoting of things
ch05/191.bdr smart container slicing
ch05/197.cdr Numeric Value Ranges In Regular Expressions
ch05/198.adr Boolean Regexes
ch05/261.dbr Pattern matching on perl values
ch05/274.acc Generalised Additions to Regexs
ch05/276.aaa Localising Paren Counts in qr()s.
ch05/308.dar Ban Perl hooks into regexes
ch05/316.bcr Regex modifier for support of chunk processing and prefix matching
ch05/317.aaa Access to optimisation information for regular expressions
ch05/331.acc Consolidate the $1 and C<\1> notations
ch05/332.abc Regex: Make /$/ equivalent to /\z/ under the '/s' modifier
ch05/348.bcc Regex assertions in plain Perl code
ch05/360.acb Allow multiply matched groups in regexes to return a listref of all matches
ch05/361.abb Simplifying split()
ch06/021.abc Subroutines: Replace C<wantarray> with a generic C<want> function
ch06/023.bcc Higher order functions
ch06/057.abb Subroutine prototypes and parameters
ch06/059.bcr Proposal to utilize C<*> as the prefix to magic subroutines
ch06/075.dcr structures and interface definitions
ch06/107.adr lvalue subs should receive the rvalue as an argument
ch06/118.rr lvalue subs: parameters, explicit assignment, and wantarray() changes
ch06/128.acc Subroutines: Extend subroutine contexts to include name parameters and lazy arguments
ch06/132.acr Subroutines should be able to return an lvalue
ch06/149.adr Lvalue subroutines: implicit and explicit assignment
ch06/154.bdr Simple assignment lvalue subs should be on by default
ch06/160.acc Function-call named parameters (with compiler optimizations)
ch06/168.abb Built-in functions should be functions
ch06/176.bbb subroutine / generic entity documentation
ch06/194.acc Standardise Function Pre- and Post-Handling
ch06/271.abc Subroutines : Pre- and post- handlers for subroutines
ch06/298.cbc Make subroutines' prototypes accessible from Perl
ch06/334.abb Perl should allow specially attributed subs to be called as C functions
ch06/344.acr Elements of @_ should be read-only by default
ch07/181.rr Formats out of core / New format syntax
ch07/230 Replace C<format> built-in with C<format> function
E7 is coming out within a week or so.
ch08/177 A Natural Syntax Extension For Chained References
ch08/241 Pseudo-hashes must die!
ch08/242.aaa No overloading of f($arg) basing on ref($arg)
Not much here. And we already decided pseudohashes must die.
ch09/116 Efficient numerics with perl
ch09/117.rr Perl syntax support for ranges
ch09/122 types and structures
ch09/123 Builtin: lazy
ch09/124 Sort order for any hash
ch09/136 Implementation of hash iterators
ch09/142 Enhanced Pack/Unpack
ch09/169.rr Proposed syntax for matrix element access and slicing.
ch09/202 Arrays: Overview of multidimensional array RFCs (RFC 203 through RFC 207)
ch09/203 Arrays: Notation for declaring and creating arrays
ch09/204 Arrays: Use list reference for multidimensional array access
ch09/205 Arrays: New operator ';' for creating array slices
ch09/206 Arrays: @#arr for getting the dimensions of an array
ch09/207 Arrays: Efficient Array Loops
ch09/225 Data: Superpositions
ch09/231 Data: Multi-dimensional arrays/hashes and slices
ch09/247 pack/unpack C-like enhancements
ch09/266 Any scalar can be a hash key
ch09/268.rr Keyed arrays
ch09/273 Internal representation of Pseudo-hashes using attributes.
ch09/282 Open-ended slices
ch09/341 unified container theory
Nearly all this stuff is already in there.
ch10/008.cd The AUTOLOAD subroutine should be able to decline a request
ch10/232 Replace AUTOLOAD by a more flexible mechanism
ch10/324 Extend AUTOLOAD functionality to AUTOGLOB
We know AUTOLOAD needs some work to be able to return a ref without
actually calling a routine. And a "next method" mechanism is
already in the works for A12 so that AUTOLOAD can decline to work.
ch11/062 Wildcards for multiple module imports
ch11/074 Proposal to rename C<import> and C<unimport>
ch11/078 Improved Module Versioning And Searching
ch11/233 Replace Exporter by a better scaling mechanism
ch11/253 UNIVERSAL::require()
ch11/257 UNIVERSAL::import()
ch11/289 Generate module dependencies easily
ch11/291 Detecting Perl Core Modules Should Be Easy
Mostly decided already. Some of it comes out in A12, such improved
versioning and searching.
ch12/032.abb A method of allowing foreign objects in perl
ch12/067.abb Deep Copying, aka, cloning around.
ch12/092.abb Extensible Meta-Object Protocol
ch12/095.acc Object Classes
ch12/101.bcc Apache-like Event and Dispatch Handlers
ch12/126.aaa Ensuring Perl's object-oriented future
ch12/137.bdd Overview: Perl OO should I<not> be fundamentally changed.
ch12/147.rr Split Scalars and Objects/References into Two Types
ch12/152.bdd Replace invocant in @_ with self() builtin
ch12/163.bdd Objects: Autoaccessors for object data structures
ch12/171.rr my Dog $spot should call a constructor implicitly
ch12/174.bdd Improved parsing and flexibility of indirect object syntax
ch12/187.abb Objects : Mandatory and enhanced second argument to C<bless>
ch12/188.acc Objects : Private keys and methods
ch12/189.abb Objects : Hierarchical calls to initializers and destructors
ch12/190.acc Objects : NEXT pseudoclass for method redispatch
ch12/193.acc Objects : Core support for method delegation
ch12/223.bdd Objects: C<use invocant> pragma
ch12/224.bdd Objects : Rationalizing C<ref>, C<attribute::reftype>, and C<builtin:blessed>
ch12/244.cdr Method calls should not suffer from the action on a distance
ch12/254.abb Class Collections: Provide the ability to overload classes
ch12/256.abb Objects : Native support for multimethods
ch12/265.abc Interface polymorphism considered lovely
ch12/277.bbb Method calls SHOULD suffer from ambiguity by default
ch12/307.rr PRAYER - what gets said when you C<bless> something
ch12/335.acc Class Methods Introspection: what methods does this object support?
ch12/336.bbb use strict 'objects': a new pragma for using Java-like objects in Perl
A12 is mostly written.
ch13/020.cd Overloadable && and ||
ch13/049 Objects should have builtin stringifying STRING method
ch13/097 prototype-based method overloading
ch13/098 context-based method overloading
ch13/108 Scope of Polymorphic References and Objects
ch13/115 Overloadable parentheses for objects
ch13/159 True Polymorphic Objects
ch13/180 Object Class hooks into C<printf>
ch13/234 Data: overloading via the SECOND operand if needed
ch13/235 Data: sprintf() with overloaded objects
ch13/258 Distinguish packed data from printable strings
Mostly covered already, or in A12.
ch14/015.cf Stronger typing through tie.
ch14/200 Objects: Revamp tie to support extensibility (Massive tie changes)
ch14/243 No special UPPERCASE_NAME subroutines
ch14/319 Transparently integrate C<tie>
The main decision about tie is that you can't tie a variable
unless it's been declared as tie-able. Otherwise the optimizer
is hamstrung. Perhaps more importantly, tie has been generalized
to container typing, which we already have decided most of.
ch15/050 BiDirectional Support in PERL
ch15/069 Standardize input record separator (for portability)
ch15/131 Internal String Storage to be Opaque
ch15/294 Internally, data is stored as UTF8
ch15/295 Normalisation and C<unicode::exact>
ch15/296 Getting Data Into Unicode Is Not Our Problem
ch15/300 C<use unicode::representation> and C<no unicode>
ch15/311 Line Disciplines
ch15/312 Unicode Combinatorix
ch15/322 Abstract Internals String Interaction
Most of this is already done right in recent Perl 5, except the
parts that are done wrong...
ch16/060 Safe Signals
ch16/086 IPC Mailboxes for Threads and Signals
Parrot issues.
ch17/001.ac Implementation of Threads in Perl
ch17/027 Coroutines for Perl
ch17/031 Subroutines: Co-routines
ch17/047 Universal Asynchronous I/O
ch17/087 Timers and Timeouts
ch17/178 Lightweight Threads
ch17/185 Thread Programming Model
ch17/293 MT-Safe Autovariables in perl 5.005 Threading
ch17/321 Common Callback API for all AIO calls.
ch17/345 Putting an Event Loop in the Core
Parrot issues, mostly. If the underlying mechanism is there,
it's trivial to expose the API at the language level. If it's not,
well, that makes it a little harder...
ch18/004.bd type inference
ch18/012.af variable usage warnings
ch18/018.ad Immediate subroutines
ch18/040 Module Scope Control
ch18/068 Eliminate the optional C<sub> for C<BEGIN> etc block declarations
ch18/070 Allow exception-based error-reporting.
ch18/172 Precompiled Perl scripts.
ch18/214 Emit warnings and errors based on unoptimized code
ch18/264 Provide a standard module to simplify the creation of source filters
ch18/314 A parser is a many-layered thing
Much already decided, either on Perl level or Parrot level.
ch19/114 Perl resource configuration
I don't mind if Perl has a -r switch, as long as it's not default.
ch20/184 Perl should support an interactive mode.
ch20/292 Extensions to the perl debugger
Not a language issue. I don't mind if other people work on this.
(I almost never use the debugger.)
ch21/035 A proposed internal base format for perl variables
ch21/046.rr Use features of portable, free compilers and libraries
ch21/061 Interfaces for linking C objects into perlsubs
ch21/121 linkable output mode
ch21/125 Components in the Perl Core Should Have Well-Defined APIs and Behavior
ch21/210 Data/Binary Dumping and Freezing
ch21/270 Replace XS with the C<Inline> module as the standard way to extend Perl.
ch21/281 The Perl 6 Development Log
ch21/301 Cache byte-compiled programs and modules
ch21/310 Ordered bytecode
ch21/315 Kick out all ops - libprt
ch21/318 Handling environment setting in extension modules
ch21/323 Perl's embedding API should be simple
ch21/326 Symbols, symbols everywhere
ch21/338 shareable bytecode
ch21/349 Perl modules should be built with a Perl make program
ch21/352 Merge Perl and C#, but have default Main class for scripting.
Mostly Parrot issues.
ch23/130 Transaction-enabled variables for Perl6
ch23/227 Extend the window to turn on taint mode
ch23/353 A Sandboxing mechanism for Perl 6
We have "let" for transaction-enabled variables. Sandboxing is a rathole.
ch24/183 "=for testing" - Embedded tests
Up to the qa folks.
ch25/036 Structured Internal Representation of Filenames
ch25/099 Standardize ALL Perl platforms on UNIX epoch
ch25/100 Embed full URI support into Perl
Library issues, not language design issues.
ch26/011.cf Examples encoded with =also for|begin|end POD commands
ch26/044 Bring Documentation Closer To Whatever It Documents
ch26/065 Add change bar functionality to pod
ch26/079 The Predefined POD Streams are C<perl>, C<data>, and C<doc>
ch26/216 POD should tolerate white space.
ch26/217 POD needs a reorder command.
ch26/280 Tweak POD's CE<lt>E<gt>
ch26/286 Add a "emit pod" runtime option to Perl
ch26/306 User-definable POD handling
ch26/325 POD and comments handling in perl
ch26/357 Perl should use XML for documentation instead of POD
POD definitely needs some tweaks, some of which we've already
published. What it doesn't need is to be turned into TeX or XML.
ch27/013.aa The Copyright and Licensing Working Group
ch27/182 JART - Just Another Regression Test
ch27/211 The Artistic License Must Be Changed
ch27/219.rr Perl6's License Should Be a Minor Bugfix of Perl5's License
ch27/240 Form a documentation working group to edit, clean, and produce
ch27/343 New Perl Mascot
ch27/346 Perl6's License Should be (GPL|Artistic-2.0)
ch27/354 A Trademark on Perl Should be Acquired in Larry Wall's Name
Licensing has to be decided soon--probably we'll go with
(GPL|Artistic-2.0), more or less. We're not changing the Perl
Mascot-I own too many stuffed camels for that. Trademarks are a
royal pain. Do you really always want to say "the Perl programming
language" everywhere you now say "Perl"? Otherwise we lose
trademark status.
Oh, sorry, make that "the Perl® programming language".
ch28/017.bd Organization and Rationalization of Perl State Variables
ch28/030 STDIN, STDOUT, STDERR, ARGV, and DATA should become scalars
ch28/033 Eliminate bareword filehandles.
ch28/094.rr Rename @ARGV to @ARGS
ch28/129 Replace default filehandle/select with $DEFOUT, $DEFERR, $DEFIN
ch28/151 Merge C<$!>, C<$^E>, C<$@> and C<$?>
ch28/158 Regular Expression Special Variables
ch28/236 Change the way $SIG{__WARN__} and $SIG{__DIE__} are used
ch28/284 Change C<$SIG{__WARN__}> and C<$SIG{__DIE__}> to magic subs
ch28/299 C<@STACK> - a modifyable C<caller()>
ch28/305 C<$^C> should be true when compiling
ch28/347 Remove long-deprecated $* (aka $MULTILINE_MATCHING)
ch28/355 Leave $[ alone.
Most all of these have been accepted already.
ch29/007.ab Higher resolution time values
ch29/014.ab Modify open() to support FileObjects and Extensibility
ch29/029 unlink() should be left alone
ch29/037 Positional Return Lists Considered Harmful
ch29/048 Replace localtime() and gmtime() with date() and utcdate()
ch29/052.rr List context return from filesystem functions
ch29/053 Built-ins: Merge and generalize C<index> and C<rindex>
ch29/055 Compilation: Remove requirement for final true value in require-d and do-ed files
ch29/056 Optional 2nd argument to C<pop()> and C<shift()>
ch29/058 C<chomp()> changes.
ch29/076 Builtin: reduce
ch29/077 Suggested isa() operator.
ch29/090 Arrays: merge() and unmerge()
ch29/091 Arrays: part and flatten
ch29/127 Sane resolution to large function returns
ch29/146 Remove socket functions from core
ch29/148 Arrays: Add reshape() for multi-dimensional array reshaping
ch29/155 Remove mathematic and trigonomic functions from core binary
ch29/157 Delete C<dbmopen> and C<dbmclose> commands.
ch29/179 More functions from set theory to manipulate arrays
ch29/195 Retire chop().
ch29/208 crypt() default salt
ch29/213 rindex and index should return true/false values
ch29/215 More defaulting to $_
ch29/220 wait() and waitpid() should return false on failure
ch29/221 system() should return useful values
ch29/229 Variable interpolation on demand.
ch29/239 IO: Standardization of Perl IO Functions to use Indirect Objects
ch29/246 pack/unpack uncontrovercial enhancements
ch29/248 enhanced groups in pack/unpack
ch29/249 Use pack/unpack for marshalling
ch29/250 hooks in pack/unpack
ch29/255.rr Fix iteration of nested hashes
ch29/259 Builtins : Make use of hashref context for garrulous builtins
ch29/267 Eliminate dump() function
ch29/269.rr Perl should not abort when a required file yields a false value
ch29/272 Arrays: transpose()
ch29/339 caller->eval BLOCK
ch29/351 Beyond the amnesic eval
ch29/358 Keep dump capability.
Doubtless a great deal of the remaining design work is here.
But it's reasonable to assume that most of these functions work
as in Perl 5 unless we decide otherwise. Which, in many cases,
we already have. Or there's already a newer, more obvious way
to write the function in question.
ch30/186 Standard support for opening i/o handles on scalars and arrays-of-scalars
ch30/228 Add memoize into the standard library
ch30/260 More modules
ch30/287 Improve Perl Persistance
ch30/288 First-Class CGI Support
ch30/333 Add C<header> and C<unheader> funtions to core distribution
ch30/350 Advanced I/O (AIO)
Mostly oddities.
ch31/002.cf Request For New Pragma: Implicit
ch31/041.rr Request For New Pragma: Implicit
ch31/042 Request For New Pragma: Shell
ch31/066 Shell Style Redirection
ch31/140 One Should Not Get Away With Ignoring System Call Errors
ch31/153 New pragma 'autoload' to load functions and modules on-demand
ch31/275 New 'tristate' pragma to allow undef to take on NULL semantics
ch31/278 Additions to 'use strict' to fix syntactic ambiguities
ch31/302 Unrolling loops and tail recursion
ch31/303 Keep C<use less>, but make it work.
ch31/304 C<sort> algorithm to be selectable at compile time
ch31/329 C<use syntax>
ch31/356 Dominant Value Expressions
Many pragma requests are bandaids on a deficient language design.
It's usually better to fix the language in those cases, except
where we want a certain default behavior, and use a pragma to
select a different default behavior. In particular, now that we
have named arguments, a lot of these options can just be applied
adverbially, such as forcing C<sort> to use a particular algorithm.
ch33/003.bf messages.rfc - An RFC to discussing the wisdom of allowing run time error
ch33/080 Exception objects and classes for builtins
ch33/085 All perl generated errors should have a unique identifier
ch33/096.rr A Base Class for Exception Objects
ch33/238 length(@ary) deserves a warning
ch33/313 Perl 6 should support I18N and L10N
ch33/359 Improvement needed in error messages (both internal errors and die function).
I could reasonably delegate the design of exception classes.
And I18N will certainly be an I11l effort. I think Parrot has
pretty much ignored the issue till now because all the Parrot
Mongers speak English, and since everyone else retrofits I18N,
why not us too? :-)
I hope this all paints a rosier bike-shed, er, picture for you.
Larry
Larry Wall
: chromatic wrote:
: >With Apocalypse 12 (soon!)
:
: I'm sorry but this just begs for the question: (vaguely) how soon? :)
Well, here's the rough outline. I still have to do some writing on
multiple dispatch, overloading, and delegation, But it's shaping up
pretty well. Should be to alpha state within a week or so, depending
on how much Real Life™ intrudes. Then the sixperl cabal has to
hammer on it for a while to remove various intrinsic idiocies.
Overview
Some of the problems with Perl 5 OO
A little too orthogonal
Not quite orthogonal enough
Forced non-encapsulation
A little too minimal
Too much keyword reuse
Too difficult to capture metadata
Inside-out interfaces
Not enough convention
Wrong conventions
Everything possible, but difficult
Perl 5 non-problems
Generating class by running code at compile time
There are many roads to polymorphism
People using a class shouldn't have to think hard
Trust in convention, but keep your powder dry
Classes
Philosophy
Declaration
Traits
Use
Class name semantics
Private classes
Methods
Philosophy
Declaration
Use
Class methods
Class invocant
Class|object invocant
Submethods
Attributes
Philosophy
Declaration
Use
Default values
Object construction
The default constructor
CREATE
BUILDALL
BUILD
Eliminating redundancy in constructor calls
Object deconstruction
DESTROYALL
DESTROY
Dispatch mechanisms
Single dispatch
Multiple dispatch
next Class, next Role, next Multi
last Class, last Role, last Multi
DISPATCHALL/DISPATCH
CLASSWALK
The "multi" modifier
Philosophy
Declaration
Use
Overloading
method prefix:+
method prefix:?
method prefix:~
etc.
Delegation
Compile-time method $:obj.foo()
Run-time method $:obj.*()
Relationship to has
Relationship to does
Naming delegated methods
Delegation of handlers through an array @:handlers.*()
Anonymous delegation for isa emulation?
Class composition with Roles
Philosophy
declaration
Use of Roles at compile time
Use of Roles at run time (mixins)
Open vs closed classes
Collections of classes
In classes
In modules
Versioning
Version declarations
Use of version and author wildcards
Introspection
Other non-OO decisions
: I get all excited whenever I hear "Perl" and "six" in the same sentence,
: and it's building up to be unbearable ;)
Yeah, well...it hurts at least as bad on this end.
Larry
Mark J. Reed
RobinBerjon> how soon? :)
LarryWall> here's the rough outline
[indicating that it's pretty soon indeed]
Cool! But now I'm a little confused - what happened to Apocalypses 8
through 11? :)
-Mark
Aaron Sherman
> ch26/011.cf Examples encoded with =also for|begin|end POD commands
> ch26/044 Bring Documentation Closer To Whatever It Documents
> ch26/065 Add change bar functionality to pod
> ch26/079 The Predefined POD Streams are C<perl>, C<data>, and C<doc>
> ch26/216 POD should tolerate white space.
> ch26/217 POD needs a reorder command.
> ch26/280 Tweak POD's CE<lt>E<gt>
> ch26/286 Add a "emit pod" runtime option to Perl
> ch26/306 User-definable POD handling
> ch26/325 POD and comments handling in perl
> ch26/357 Perl should use XML for documentation instead of POD
>
> POD definitely needs some tweaks, some of which we've already
> published. What it doesn't need is to be turned into TeX or XML.
Well, I failed to avoid scanning through this until tonight (bad Aaron,
do work!), and I noticed this.
I just want to emphatically agree! POD has really taken root anywhere
that I've planted it BECAUSE it is so simple and so easy to use. People
fire up vi or notepad and edit a POD document where any other form of
editing would have posed a mental hurdle. I'd love to see POD become
more compact vertically (e.g. not as much reliance on blank lines), and
also a better implementation of X and L, but other than that I think POD
is a wonderful format and one of the strenghts of the Perl distribution.
Larry Wall
: chromatic> With Apocalypse 12 (soon!)
They were left as exercises for the reader.
Seriously, because of the Camel Book, Apocalypses are numbered in order
of Perl 5 importance, but they come out in order of Perl 6 importance.
More or less. Once we get Objects straight it'll be a lot easier to
talk about References, Data Structures, Packages, and Modules. And
everything else.
Larry
Chromatic
> Cool! But now I'm a little confused - what happened to Apocalypses 8
> through 11? :)
They were:
- 8, References
- 9, Data Structures
- 10, Packages
- 11, Modules
Since 12, Objects is more important (and covers most of those anyway),
it had a little push forward.
There will likely be an apocalypse or exegesis or two that covers those
specifically, but things change.
-- c
Bennett Todd
> Well now, I remember Perl 0, sonny.
Does that still exist anywhere? I don't have anything older than
perl 1.
> They don't make 'em like they used to...
That they don't. On Bent Linux (my own distro, based on uClibc
instead of glibc) I get
; ls -l perl1 perl5.8.1
-rwxr-xr-x 1 root root 137184 Feb 26 15:24 perl1
-rwxr-xr-x 2 root root 878772 Feb 15 00:44 perl5.8.1
;
and that perl1 is statically linked, -vs- perl5 dynamically linked
(I couldn't figure out how to make a working statically linked
perl5).
I do adore perl, but my how she has grown!
-Bennett
Simon Cozens
> It's the coherence that I can't delegate, and if I tried to, we would
> certainly end up with Second System Syndrome Done Wrong, instead of Done
> Right.
You know, it's statements like this that make it hard for even me to
be curmudgeonly.
> E7 is coming out within a week or so.
s/week/day/
> Nearly all this stuff is already in there.
Let's also remember that Perl 6 allows us to write a lot more of Perl 6 in
Perl, and we don't need to specify the whole of CP6AN quite yet. If people
want crazy data types, that's cool, but they don't need to be ready the
day perl-6.0.0.tar.gz ships.
> (ch 29)
> Doubtless a great deal of the remaining design work is here.
I still think most of this is library stuff too.
> And I18N will certainly be an I11l effort. I think Parrot has
> pretty much ignored the issue till now because all the Parrot
> Mongers speak English, and since everyone else retrofits I18N,
> why not us too? :-)
Aieee.
--
"Though spring is here, to me it's still September,
That September, in the rain"
- Dinah Washington, The USENET Anthem.
Simon Cozens
> 2004-02-26T14:26:47 Larry Wall:
> > Well now, I remember Perl 0, sonny.
>
> Does that still exist anywhere?
If nowhere else, Larry's got a copy IN HIS HEAD. :)
--
I have heard that the universe does not support atomic operations
(although I've not seen the code.) If this is true, perhaps we should
report the bug to the manufacturer.
- Mark-Jason Dominus
Chromatic
> la...@wall.org (Larry Wall) writes:
> > It's the coherence that I can't delegate, and if I tried to, we would
> > certainly end up with Second System Syndrome Done Wrong, instead of Done
> > Right.
> You know, it's statements like this that make it hard for even me to
> be curmudgeonly.
Nah, you only have to convince yourself that someone besides Larry could
provide a greater coherence.
I'm not saying that's likely or even true. I'm just saying that you
*could* practice an extraordinary amount of self-delusion. It may help
to meditate while chanting the meaningless syllables the mantra "ehn
tuhr priy zuh pruh groh mah ing lahn guh juh" for a while.
-- c
Uri Guttman
SC> b...@rahul.net (Bennett Todd) writes:
>> 2004-02-26T14:26:47 Larry Wall:
>> > Well now, I remember Perl 0, sonny.
>>
>> Does that still exist anywhere?
SC> If nowhere else, Larry's got a copy IN HIS HEAD. :)
better than a copy in his stomach where it could cause more digestive
troubles for him. :)
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Eric TF Bat
WE WANTS PERL SIX, MY PRECIOUSSSS! WE DON'T WANT TO WAIT! IT'S TOO
YUMMY! IT SINGS! IT DANCES! IT MAKES THE COFFEE! THERE'S MORE THAN
ONE WAY TO DO *EVERYTHING*!!! WE WANTS IT! WE WANTS IT! WE
WAAAAAAANTS IT!
<pant> <pant> Sorry about that. Better now. Just had to get that
out of my system.
Larry, we love you. Perl 6 is SOOOO gonna be worth the wait. No
pressure tho, ok?
: Bat :