"David L. Nicol" wrote:
>
> Bart Lateur wrote:
>
> > Bitwise and, or and xor do distinguish strings from numbers, and return
> > entirely different kinds of results. Why can't anything else?
>
> Absolutely. There is such a thing as Too Much Convenience. I think
> BOOL as a context or an acces
On Mon, Oct 02, 2000 at 09:17:31PM -0500, David L. Nicol wrote:
> Jarkko Hietaniemi wrote:
>
> > This reminds me of a related but rather opposite desire I have had
> > more than once: a quotish context that would be otherwise like q() but
> > with some minimal extra typing I could mark a scalar o
Jarkko Hietaniemi wrote:
> This reminds me of a related but rather opposite desire I have had
> more than once: a quotish context that would be otherwise like q() but
> with some minimal extra typing I could mark a scalar or an array to be
> expanded as in qq(). For example doubling the $ and @?
Greg Williams wrote:
> Interesting! I have a few questions (meandering thoughts) though
>
> The example in the RFC gives:
>
> sub A{
> my $A = shift;
> return with;
> };
>
> $context1 = A(3);
> print "$context1"; # something like CONTEXT(0XF0GD0
At 18:43 -0500 2000/10/02, David L. Nicol wrote:
>Hmm. C could be implemented in terms of the rfc 340 C like
>so:
>
> $scope_out_here = with;
> if ($ints) {
> with $scope_out_here {use integer}
> };
>
>C is about subroutine calls.
Interesting! I have a few questions (meandering thoug
On Mon, Oct 02, 2000 at 03:36:20PM -0500, Garrett Goebel wrote:
> From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
> > >- Done right, it could be easier to write and maintain
> >
> > Strongly disagree.
>
> Ok, you disagree. There are differing opinions here. Can we agree to
> disagree?
No.
A
Bart Lateur wrote:
> Bitwise and, or and xor do distinguish strings from numbers, and return
> entirely different kinds of results. Why can't anything else?
Absolutely. There is such a thing as Too Much Convenience. I think
BOOL as a context or an accessor method should be separate from STRING
Greg Williams wrote:
> as I remember, the C pragma, when used, would simply act as if the
>enclosing scope were not in place, enabling such things as:
> if ($ints) {
> no scope;
> use integer;
> }
Hmm. C could be implemented in terms of the rfc 340 C like
so:
$scope_out_here = with;
Peter Scott wrote:
>
> Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> attributes from UNIVERSAL?
I think, rather, they should inherit from some other root class,
since UNIVERSAL is for blessed things.
> Hmm, am I saying that I should be able to
> write @array->met
Nathan Wiger wrote:
> I pushed a lot of these issues in RFC 319 and 337, which would let you
> say something like:
>
>my Pet @pets :mean; # integrated implicit tie
>@pets->attributes('mean') # "true", like 'can'
Blech.
exists @pets:mean # true
--
John Porter
> I may be raining on your RFC 337 parade here (sorry I didn't get to it
> earlier - travel), but I think it entirely reasonable to want to specify a
> type for an array different from the type of thing it contains. But what
> syntax will you use? If I make one up for the sake of illustration:
>
At 03:55 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Or are we talking apples and oranges and the above declaration is intended
> > to declare that any *member* of @a is of SomeType, never mind the array
> > itself?
>
>Yes, I think that second sentence hits the point. Currently, there's
>ambiguity a
> >However, making it a UNIVERSAL method also dictates that this:
> >
> >my SomeType @a :someattr;
> >
> >*must* be either:
> >
> >1. a builtin type
> >2. tied
> >
> >To get its attributes back out. I'm not sure this is going to always be
> >true.
>
> It must be my sinuses. I don't g
At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > Maybe I'm just being dense, but why shouldn't arrays and hashes inherit
> > attributes from UNIVERSAL? tie()ing an array is really just like being
> > able to call object methods on it distinct from its members, no? So arrays
> > and hashes coul
At 03:23 PM 10/2/00 -0700, Peter Scott wrote:
>At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote:
>>Dan Sugalski wrote:
>> >
>> > Well, yeah, it'll sort of have to if we allow user-defined types. If
>> you do:
>> >
>> >my Dog $spot : male;
>> >
>> > then the Dog package needs to be able to fetch
At 03:32 PM 10/2/00 -0700, Nathan Wiger wrote:
> > >There's two ways I've proposed in different RFC's. The first one
> > >utilizes a more general framework; the second one depends on C
> > >being used. A UNIVERSAL:: method wouldn't work because you've got to get
> > >attributes from arrays and has
> >There's two ways I've proposed in different RFC's. The first one
> >utilizes a more general framework; the second one depends on C
> >being used. A UNIVERSAL:: method wouldn't work because you've got to get
> >attributes from arrays and hashes as well.
>
> Maybe I'm just being dense, but why s
At 03:15 PM 10/2/00 -0700, Nathan Wiger wrote:
>Dan Sugalski wrote:
> >
> > Well, yeah, it'll sort of have to if we allow user-defined types. If
> you do:
> >
> >my Dog $spot : male;
> >
> > then the Dog package needs to be able to fetch the attributes. I've no idea
> > how that'd look--perha
Dan Sugalski wrote:
>
> Well, yeah, it'll sort of have to if we allow user-defined types. If you do:
>
>my Dog $spot : male;
>
> then the Dog package needs to be able to fetch the attributes. I've no idea
> how that'd look--perhaps an attributes() function, a method in UNIVERSAL,
> or someth
On Mon, Oct 02, 2000 at 10:59:46PM +0200, Bart Lateur wrote:
> On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:
>
> >> Improperly nested tags, or one character it
> >> doesn't recognize... and the parser says "nyet".
> >
> >I read that as "the machine will tell me when I messed up".
> >
>
>XML, on the other hand, uses & as the escaping mechanism, helping
>a reader sort-out deeply-nested escapings.
...
>POD has a good advantage in that it's design allows for it to
>embed well into code. If documentation is to be alongside
>code, a direction to consider is to have the Perl
>progra
From: Myers, Dirk [mailto:[EMAIL PROTECTED]]
>
> Maybe I'm reading too much into the comment, but I thought
> the big deal was that the example given was not only
> verbose, but wouldn't parse correctly:
>
> (from the section you elided:)
>
> > > > Eliott P. Squibb
> > > > Joe Blogg
>
> Who
On Mon, 2 Oct 2000 13:54:47 -0400, Tad McClellan wrote:
>> Improperly nested tags, or one character it
>> doesn't recognize... and the parser says "nyet".
>
>I read that as "the machine will tell me when I messed up".
>
>I'd rather have a machine tell me than have to figure it
>out myself. I thin
On 10/2/00 4:44 PM, John Barnette wrote:
> * Advanced concepts that POD cannot contain that the XML junkies
> might want to be used can be embedded. (=for XML)
Yeah, but then you get =for HTML, =for XML, =for 3DHOLOGRAM, whatever. No
one does that because no one wants to make 50 versions of the
> > same or greater ease than pod for build and configuration.
> >
> > >
> [...]
> > >
> >
> > That is an excellent description of why THIS IS COMPLETE
> > MADNESS.
Maybe I'm reading too much into the comment, but I thought the big deal was
that the example given was not only verbose, but w
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 junkies
> might want to
Garrett Goebel (Today):
> Horror of horrors: why not support both? Long live: TMTOWTDI. If XML
> documentation fails to thrive, cut it from Perl 6.1. If both thrive, keep
> 'em. As everyone has said XML can be converted to pod and vice versa. Pod
> tools could be made to coexist with XML.
But why
From: Tom Christiansen [mailto:[EMAIL PROTECTED]]
>
> >- Done right, it could be easier to write and maintain
>
> Strongly disagree.
Ok, you disagree. There are differing opinions here. Can we agree to
disagree? Or must all people who believe XML is easier to write and maintain
leave the room?
Jonathan Scott Duff <[EMAIL PROTECTED]> writes:
> I'll just add my voice to the others. POD is more readable than XML.
Don't forget: more _writable_ as well.
-- Johan
On Mon, Oct 02, 2000 at 01:24:37PM -0600, Tom Christiansen wrote:
> >XML is intrinsically no more or less difficult to write than HTML.
>
> Wrong.
I beg your pardon?
> >Comparing XML to HTML is pointless, however; they are not the same
> >thing.
>
> Wrong. And you only say that because you
>
> Very little discussion was generated by this RFC. Several people noted that perl -de
>42 and the Perl shell psh already provide some
> of what the RFC requests; this is noted in the RFC.
>
> The RFC is not being withdrawn, since 2 other people expressed (mild) interest in
>it.
I'd lik
>The problem with XML is that it is so unforgiving;
No, the problem is verbosity.
''tom
On Sun, Oct 01, 2000 at 10:24:58AM +0200, Bart Lateur wrote:
> difficult feature, is a lot harder than this kind of simple, er, shit.
Actually, when I was first programming Perl after coming from C I was
tripped up by this very difference, and didn't quite understand why \v
wasn't an escape.
I f
>XML is intrinsically no more or less difficult to write than HTML.
Wrong.
>Comparing XML to HTML is pointless, however; they are not the same
>thing.
Wrong. And you only say that because you will not like the answer.
Go back to the posted example and count bytes of data versus
bytes of met
>- Done right, it could be easier to write and maintain
Strongly disagree.
>- Why make people learn pod, when everyone's learning XML?
Because it is simple. It is supposed to be simple.
It is not supposed to do what you want to do.
In fact, it is suppose to NOT DO what you want to do.
>- Pod
>No-one ever did suggest adding « and » to the list of matched delimiters
>that q() etc support, did they? :-)
I did.
>Does Unicode define bracket pairings for character sets?
$ grep ^Prop /usr/local/lib/perl5/5.6.0/unicode/Props.txt
does not seem very helpful, but this may not be much of a p
At 04:39 PM 10/1/00 -0700, Peter Scott wrote:
>At 04:53 PM 10/1/00 -0400, Dan Sugalski wrote:
>>At 11:33 AM 10/1/00 -0700, Peter Scott wrote:
>>>But, setting aside my visceral reaction to changing array bases, you
>>>have precisely the same problem here that has scuppered my intent to
>>>file an
On Mon, Oct 02, 2000 at 07:56:45PM +0200, Bart Lateur wrote:
> On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote:
>
> >> XML never had human writable simplicity and never will.
> >
> >XML is intrinsically no more or less difficult to write than HTML.
>
> The problem with XML is that it is so
Garrett Goebel <[EMAIL PROTECTED]> writes:
>
> Module::Name
> 0.01
> short description
>
> =head1 long description
>
> =head2 heading
>
> foo
>
> Type in some text here...
>
>
> Eliott P. Squibb
> Joe Blogg
> none
> Distributed
On 10/2/00 1:56 PM, Bart Lateur wrote:
> The problem with XML is that it is so unforgiving; I think somebody
> already mentioned that. Improperly nested tags, or one character it
> doesn't recognize... and the parser says "nyet".
Kind of like Perl, huh... ;)
(this is a feature, not a bug! :)
-Jo
At 03:53 PM 10/2/00 +0200, Bart Lateur wrote:
>On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote:
>
> >But, why not suggest SDF instead of XML? SDF addresses most of POD's
> >deficiencies whill still retaining readability. (I don't have a URL
> >for SDF handy, but I'm sure a quick sea
On Mon, 2 Oct 2000 10:51:28 -0700, Damien Neil wrote:
>> XML never had human writable simplicity and never will.
>
>XML is intrinsically no more or less difficult to write than HTML.
The problem with XML is that it is so unforgiving; I think somebody
already mentioned that. Improperly nested tag
On Mon, Oct 02, 2000 at 09:21:51AM -0700, Glenn Linderman wrote:
> Indeed, this is the key problem with human use of XML. HTML was originally
> simple enough to be human writable, its later, more powerful incarnations
> start losing that (but you can always use a subset for simple things, and
> X
Damien Neil wrote:
> Having said that, I'm not fond of writing XML/HTML by hand. I'd far
> rather write an author-friendly language and have that translated to
> XML.
Indeed, this is the key problem with human use of XML. HTML was originally
simple enough to be human writable, its later, more
On 1 Oct 2000, Perl6 RFC Librarian wrote:
> =head1 ABSTRACT
>
> To simplify distribution of programs in binary form,
> support for dump should be kept.
>
> =head1 DESCRIPTION
>
> This would immensely aid distribution of code from one Linux, Windows,
> etc. machine to others without requiring a
From: John Porter [mailto:[EMAIL PROTECTED]]
>
> It would be very detrimental to perl's performance to have to do an
> XML parse of every input source file.
if the parser can skip between:
=pod
=cut
it can certainly be made to skip between:
From: Jonathan Scott Duff [mailto:[EMAIL PROTECTED]]
>
> On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> > =head1 TITLE
> >
> > Perl should use XML for documentation instead of POD
>
> I'll just add my voice to the others. POD is more readable than XML.
> As Nathan Wiger
On Mon, 2 Oct 2000 08:29:09 -0500, Jonathan Scott Duff wrote:
>But, why not suggest SDF instead of XML? SDF addresses most of POD's
>deficiencies whill still retaining readability. (I don't have a URL
>for SDF handy, but I'm sure a quick search on google.com would turn it
>up)
http://w
On Sun, Oct 01, 2000 at 06:34:12AM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Perl should use XML for documentation instead of POD
Wow.
I'll just add my voice to the others. POD is more readable than XML.
As Nathan Wiger said, just read the HTML vs the POD for the RFCs.
But, why
On Mon, Oct 02, 2000 at 07:32:42AM -0400, Bryan C. Warnock wrote:
> On Wed, 27 Sep 2000, Nathan Wiger wrote:
> > Yeah, I've never liked the _ syntax, I've always thought it was weird
> > (to say the least). I think grouping file tests would be much cleaner.
>
> As long as you are okay with havin
On Wed, 27 Sep 2000, Nathan Wiger wrote:
> Yeah, I've never liked the _ syntax, I've always thought it was weird
> (to say the least). I think grouping file tests would be much cleaner.
As long as you are okay with having to restat for 'or' clauses.
(There are work arounds, and supposedly 'this
On Mon, Oct 02, 2000 at 10:40:28AM +0100, Piers Cawley wrote:
> Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> > Unprototyped subs should not be allowed to modify their callers' data
> > simply by assigning to elements of the arg array.
> >
> > =head1 COMMENTS ON FREEZE
> >
> > This RFC gene
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Elements of @_ should be read-only by default
>
> =head1 VERSION
>
> Maintainer: John Tobey <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Last
Alan Gutierrez <[EMAIL PROTECTED]> writes:
> On 27 Sep 2000, Piers Cawley wrote:
>
> > Simon Cozens <[EMAIL PROTECTED]> writes:
> >
> > > On Wed, Sep 27, 2000 at 03:49:10PM +0100, Tom Christiansen wrote:
> > > > Don't change "use less" to "use optimize". We don't
> > > > need to ruin the cuten
54 matches
Mail list logo
