Not really, except insofar as we've talked about compact classes of
native types working like C structs. There are lots of nitty things
we can fix with pack/unpack, but the basic underlying problem is
that pack/unpack are defined operationally rather than declaratively.
I think it's worth takin
On 6/14/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Heh, that classification was a fast guess about RFCs made more than
> 4 years ago. I'm amazed it's stood up as well as it has, even where
> it hasn't.
I agree, and lacking anything I could find more recent, initially
thought it was the right way
On Tue, Jun 14, 2005 at 09:38:43AM -0400, Joshua Gatcomb wrote:
: On 6/13/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
:
: > Since it might not have been clear from my earlier post -- I've
: > now committed the S17 framework draft into the repository. Thanks.
:
: I am now questioning using
On 6/13/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> Since it might not have been clear from my earlier post -- I've
> now committed the S17 framework draft into the repository. Thanks.
I am now questioning using "Perl6 Timeline By Apocolypse" as reference
material. I am rather intereste
On Mon, Jun 13, 2005 at 02:22:59PM -0500, Patrick R. Michaud wrote:
> On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
>
> > I have included a sample framework for chapter 17. Theoretically,
> > someone could then go search the archives for decision points in any
> > of those headi
On Mon, Jun 13, 2005 at 02:22:59PM -0500, Patrick R. Michaud wrote:
> On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
> > Ok, are there any guidelines for what should and should not be put
> > forward as a patch.
> [...]
> For anything that doesn't come from @Larry or $Larry, I th
On Fri, Jun 10, 2005 at 02:36:52PM -0400, Joshua Gatcomb wrote:
> Ok, are there any guidelines for what should and should not be put
> forward as a patch. I can see 3 key areas of concern:
>
> 1. Framework for unwritten Synopses (so we know what goes where)
> 2. Heading placeholders for written
On 6/10/05, Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> Hmmm. Thanks. I guess I will have to go back over the questions I
> have asked and see if any decisions were rendered not relfected in
> docs and be a pioneer.
Ok, are there any guidelines for what should and should not be put
forward as a
On 6/10/05, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> This already exists -- the design documents are all available from
> http://svn.perl.org/perl6/doc/trunk . And I've already volunteered
> to review/apply patches to the design documents or forward them to
> the appropriate people for rev
On Fri, Jun 10, 2005 at 12:51:15PM -0400, Joshua Gatcomb wrote:
> I know that decisions are subject to change but having the current
> state of decisions in a single location (Synopses) would be a great
> benefit to all. I am a firm believer in not complaining unless you
> have an idea about how t
All:
Designing a language isn't easy - I get that. Opening up the design
process to the entire community and filtering everyone's "good" ideas
certainly doesn't make this any easier. My concern is that these
difficulties are being aggravated because the design documents
(Synopses) are not kept up
11 matches
Mail list logo
