Nicholas Clark wrote:
> On Mon, Oct 02, 2000 at 02:44:56PM -0600, John Barnette wrote:
> > But why extend the syntax for such a niche application?
> >
> > * POD can be easily converted to XML.
> > * POD can contain XML.
> > * Advanced concepts that POD cannot contain that the XML junk
On Mon, Oct 02, 2000 at 01:22:47PM -0600, Tom Christiansen wrote:
> > Eliott P. Squibb
> > Joe Blogg
>
> That is an excellent description of why THIS IS COMPLETE
> MADNESS.
It also shows how easy it is to get wrong
Graham.
On Mon, Oct 02, 2000 at 12:58:37PM -0700, Damien Neil wrote:
> What? I don't think people should be writing either XML or HTML
> as the source documentation format. I said that, quite clearly.
Then what are they going to write it in ? And don't tell me to get
some fangle dangled editor. Which w
Bradley M. Kuhn writes:
> It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups
> should be able to produce additional RFCs after this. Of course, the
> Language will be frozen, but these three groups may need to remain fluid
> after the 14 October 2000 annoucement.
I thin
John Siracusa wrote:
>
> POD is supposed
> to be the common format that can be transformed into other representations.
> Instead, you have to add the different representations yourself if you do
> anything remotely complex.
No, POD is supposed to be simple. It addresses a very small, common sub
Nathan Torkington <[EMAIL PROTECTED]> writes:
> I have no objection to -internals remaining. I think their discussion
> will probably take off more after Larry's announcement.
Personally I'm betting that the volume we've seen on -language will
pale into tiny insignificance compared to the volume
At 10:59 03/10/2000 -0400, John Porter wrote:
>Complex things should not be done in POD.
Indeed. This debate has been done to death. Have any of the would-be
pod-killers read the thread at
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-08/thrd11.html#0
1078 ? The thread eventually di
On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote:
> Personally I'm betting that the volume we've seen on -language will
> pale into tiny insignificance compared to the volume on -internals
> once Larry has made his announcement.
I doubt it; I think we've a lot of people who want to ta
On 10/3/00 10:59 AM, John Porter wrote:
> John Siracusa wrote:
>> POD is supposed to be the common format that can be transformed into other
>> representations. Instead, you have to add the different representations
>> yourself if you do anything remotely complex.
>
> No, POD is supposed to be si
On Tue, Oct 03, 2000 at 03:42:49PM +0100, Graham Barr wrote:
> On Mon, Oct 02, 2000 at 12:58:37PM -0700, Damien Neil wrote:
> > What? I don't think people should be writing either XML or HTML
> > as the source documentation format. I said that, quite clearly.
>
> Then what are they going to wri
John Siracusa wrote:
>
> Tables are my personal peeve, but I'm sure you can think of many more common
> documentation features that POD should support natively. Hypertext is
> another example, off the top of my head.
I agree that pod could support these thing better. I believe it will,
and it
Dan Sugalski wrote:
>
> At 04:39 PM 10/1/00 -0700, Peter Scott wrote:
> > What are the chances of the internals supporting user-defined
> >attributes? What would the API look like?
>
> Well, yeah, it'll sort of have to if we allow user-defined types. If you do:
>
>my Dog $spot : male;
>
>
On Tue, Oct 03, 2000 at 08:50:24AM -0600, Nathan Torkington wrote:
> Bradley M. Kuhn writes:
> > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups
> > should be able to produce additional RFCs after this. Of course, the
> > Language will be frozen, but these three group
At 04:26 PM 10/3/00 -0400, Adam Turoff wrote:
>On Tue, Oct 03, 2000 at 08:50:24AM -0600, Nathan Torkington wrote:
> > Bradley M. Kuhn writes:
> > > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses
> groups
> > > should be able to produce additional RFCs after this. Of course
From: Peter Scott [mailto:[EMAIL PROTECTED]]
>
> As I said earlier, why don't we just define a syntax for
> *anything* to be used as an extension language, and let
> the, er, market decide?
Here, here!
Peaceful coexistance... what a concept.
On Sat, 30 Sep 2000, David Grove wrote:
[...]
> I don't know, it just doesn't feel like the holes are closed. How do we let
> people "nab it and do good things with it", but prohibit people from "nabbing
> it and doing bad things with it"?
Personally I don't care. For all I care anyone can do
On Tue, 03 Oct 2000, Simon Cozens wrote:
> On Tue, Oct 03, 2000 at 04:06:00PM +0100, Piers Cawley wrote:
> > Personally I'm betting that the volume we've seen on -language will
> > pale into tiny insignificance compared to the volume on -internals
> > once Larry has made his announcement.
>
> I d
> > Some arguments for XML:
> >
> > - Done right, it could be easier to write and maintain
> Pod is already "done right", and it's already spectacularly
> easy to write and maintain. XML is a hammer in search of nail.
Actually, a better analogy would be a its a sledge hammer
in search of a fin
Bart Lateur wrote:
> On 2 Oct 2000 00:48:45 -, Perl6 RFC Librarian wrote:
>
> > Status: Frozen
>
> and
>
> >A copyright lawyer has I looked at this license yet. I sent it to Eben
> >Moglen, but he is very busy and hasn't been able to reply due to lack of
> >time. I hope we find some copy
Nathan Torkington wrote:
> Bradley M. Kuhn writes:
> > It seems to me that the perl6-internals, perl6-qa, and perl6-licenses groups
> > should be able to produce additional RFCs after this. Of course, the
> > Language will be frozen, but these three groups may need to remain fluid
> > after the 1
Dan Sugalski wrote:
> I'd personally like a license chosen before any code gets written in
> earnest, so that might well argue for -license to wrap up before then.
> (Whether this is an issue or not is up in the air--it depends on who's
> submitting code)
I see the point, and I actually agree th
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Exception objects and classes for builtins
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 9 Aug 2000
Last Modified: 3 Oct 2000
Mailing List: [EMAIL PROTECTED]
Number: 80
Versio
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Merge C<$!>, C<$^E>, C<$@> and C<$?>
=head1 VERSION
Maintainer: Peter Scott <[EMAIL PROTECTED]>
Date: 25 Aug 2000
Last Modified: 3 Oct 2000
Mailing List: [EMAIL PROTECTED]
Number: 151
Version:
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Short-circuiting built-in functions and user-defined subroutines
=head1 VERSION
Maintainer: Garrett Goebel <[EMAIL PROTECTED]>
Date: 6 Sep 2000
Last Modified: 15 Sep 2000
Mailing List: [EMAIL PROTEC
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Perl should use XML for documentation instead of POD
=head1 VERSION
Maintainer: Frank Tobin <[EMAIL PROTECTED]>
Date: 30 Sep 2000
Last Modified: 3 Oct 2000
Mailing List: [EMAIL PROTECTED]
Number:
At 12:01 PM 10/3/00 -0400, John Porter wrote:
>How would you down-convert a complex math formula to ascii from, say, xhtml?
>
>You know, I'm thinking TeX would make a great extension language for pod.
>Simple, powerful, text-based, with translators to lots of other formats,
>and good tool support
[EMAIL PROTECTED] (Johan Vromans) writes:
> [Quoting Piers Cawley, on October 2 2000, 09:44, in "Re: RFC 335 (v1) Cla"]
> > > $class->can(qr/./);
> >
> > That wasn't the similar thing I meant. I was talking about walking the
> > @ISA tree. But having C work like that too would be neat.
>
> Ex
Greg Williams <[EMAIL PROTECTED]> writes:
> At 11:01 +0100 2000/10/02, Piers Cawley wrote:
> >Hmm... I'm really not keen on this idea. Not keen at all. And I can't
> >for the life of me see what's wrong with just making a factory method
> >(or factory class):
> ...
> >Or even simply:
> >
> >
> Michael G Schwern wrote:
>
> > Also, just being able to tack flags onto a variable means each
> > variable (that has a flag) would have to carry around a hash!
No; it has to carry around a vtbl (or vtbl-like thing).
User-level attributes are (or should be :-) accessor methods
to some underlyin
29 matches
Mail list logo
