> Maintainer: Bart Lateur <[EMAIL PROTECTED]>
> Date: 28 Sep 2000
> Last Modified: 1 Oct 2000
> Mailing List: [EMAIL PROTECTED]
> Number: 348
> Version: 2
> Status: Frozen
> [can't find a good quote]
It'd be somwhat useful, I think, if you could return somthing like \matched
to
let
Graham Barr wrote:
>
> I would suggest that anyone want to contribute to this discussion should
> first read the thread about the addition of this pragma to perl5 in
> the perl5-porters archives
>
>
>http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/perl5-porters?query=use+namespace+pragma&errors=0&
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
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Also, don't assume that the key passed in is just a string. It could well
> be a string/hashval pair, or a string/hashval/magic triple, and we use the
> fast method with the others as fallbacks.
In other words, it
> >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
In message <20001002221632$[EMAIL PROTECTED]>
Uri Guttman <[EMAIL PROTECTED]> wrote:
> hmm, that means 'next' does a lookup based on the key passed
> in. currently next uses the iterator state which is much faster. i think
> next should be faster than a regular lookup but the semantics
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
> Yep, that's something to investigate. I'd like to encode the bytecode
> version at the head of any bytecode stream. There's also been a request for
This version info could quite naturally live in my proposed 'declaration
block' or 'bytecode header'.
> I agree, platform native is a good idea
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
On Mon, 2 Oct 2000 12:46:06 -0700 (PDT), Dave Storrs wrote:
> Well, the main reason is that @/ worked best for my particular
>brain.
But you cannot use it in an ordinary regex, can you? There's no way you
can put $/[1] between slashes in s/.../.../. BAckslashing it doesn't
work.
>@&
>woul
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
On Mon, Oct 02, 2000 at 04:35:29PM -0400, Dan Sugalski wrote:
> I agree, platform native is a good idea generally, as long as we have some
> means of indicating how the platform encodes the data. The bytecode needs
> to be transportable across platforms--I want the same bytecode to be able
> to
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I'd rather not store the iterator in the optree or, if we do, make
DS> it lexically scoped. I'd actually *really* like to make iterators
DS> explicit objects all by themselves, but it's too much work for
DS> most uses of iterators
At 07:21 AM 10/2/00 -0500, Jarkko Hietaniemi wrote:
>[random thoughts I had one week ago at YAPC::Europe and am jotting down now;
> was unsubscribed from the p6 lists during that time, awfully sorry if this
> subject has already been beaten to death]
We haven't touched this yet. Bytecode's on t
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?
At 11:12 PM 9/30/00 +0200, Bart Lateur wrote:
>On 28 Sep 2000 19:40:01 -, Perl6 RFC Librarian wrote:
>
> >=head2 How iterators might work in perl 6
> >
> >In perl 6 the keys and values functions should no longer use the
> >same iterator as the each function - each use of keys and values
> >sho
"Peter Buckingham" <[EMAIL PROTECTED]> writes:
> ... but it may be simpler than just doing everything from
> scratch in xfig.
Check Tgif (http://bourbon.cs.umd.edu:8001/tgif/).
-- Johan
[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.
Exactly. 'can' walks the ISA tree searching for a name and
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
At 04:34 PM 9/29/00 -0400, John Porter wrote:
>Dan Sugalski wrote:
> >
> > I've no experience with UML, though. Got a pointer to a quick overview?
>
>Without a doubt, "UML Distilled" is the bible of the genre.
I'll have to go pick that up on Thursday and add it to the Darned Big Pile
of books I
At 03:42 PM 10/2/00 +0200, Paolo Molaro wrote:
>On 09/27/00 Ken Fox wrote:
> > Dave Storrs wrote:
> > > It isn't terribly clear to me either
> >
> > Well, he does give a couple references that would clear it up.
> > X11 Atoms are well documented.
> >
> > > saying is that you can qs() a method name
These references should have made it into the RFC:
cons
http://www.dsmit.com/cons/
pmake
http://www.cpan.org/modules/by-authors/id/N/NI/NI-S/Make-1.00.tar.gz
Mark Leighton FisherThomson Consumer Electronics
[EMAIL PROTECTE
On Sun, 1 Oct 2000, Bart Lateur wrote:
> It's not clear to me why you picked @/ as the name for the array. For
> mnemonic reasons, i.e. similarity with existing special variables, @& or
> @+ (see $& and $+) would make more sense. Well, @+ is taken...
Well, the main reason is that @/ w
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
> I'm trying to stick to a general philosophy of what's in a reg-ex, and I can
> almost justify assertions since as you say, \d, ^, $, (?=), etc are these
> very sort of things. I've been avoiding most of this discussion because
> it's been so odd, I can't believe they'll ultimately get accepted.
> > would need to know a fair bit about particular user-defined types that have
> > been loaded in, on order to make clever interpretations of literals.
>
> Precisely. Assume I want
>
> $a = 2 + 3i;
>
> to work...
Which I what I suggest we abandon attempts to make the parser do intellig
> would need to know a fair bit about particular user-defined types that have
> been loaded in, on order to make clever interpretations of literals.
Precisely. Assume I want
$a = 2 + 3i;
to work...
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we
> >the $c will be an NV of of 5.000, or thereabouts, een
> >while $a and $b are IVs.
>
> Note: integers have an exact representation in floating point. There is
...as long as they are [minint, maxint].
> no "thereabouts". It is exactly 5.000.
Yeah, bad example. Yours i
> > version of add() would be called, and an IV SB would result.
>
> "The IV version of add()"? Beware of combinatorial explosion:
> addII, addIU, addUI, addUU, addIN, addNI, addNN, addblahbah
Ah, but you've forgotten the point of my orginal posting (back in
prehistory ;-)
where given 2 mi
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 copyright lawyers to look it over pro-bon
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
> For the record: I hate the current policy of defaulting to NVs for
> arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of
> 2.000. Currently if I say
>
> $a = 2;
> $b = 3;
> $c = $a + $3;
>
> the $c will be an NV of of 5.000, or thereabouts, een
> whi
> $x = 2^1000;
>
> would evaluate 2^1000 at compile time, and if it didnt fit into an NV
> (or IV if 'use integer' is in effect), create a compile-time error.
For the record: I hate the current policy of defaulting to NVs for
arithmetic ops. If I say '2' I do mean an IV of 2, not an NV of
2.000
> > > Don't forget bigrats.
> >
> > I'm not too familiar with the concept of rational numbers in a computing
> > complex. What's your definition of a (big)rat? Fixed point??
>
> bigint1 / bigint2. Possibly represented as a triad of bigints,
> bigint1 + bigint2 / bigint3.
I'm tempted to suggest
On 09/27/00 Ken Fox wrote:
> Dave Storrs wrote:
> > It isn't terribly clear to me either
>
> Well, he does give a couple references that would clear it up.
> X11 Atoms are well documented.
>
> > saying is that you can qs() a method name, get a "thingie" out, store the
> > thingine in a scalar, a
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 Sun, Oct 01, 2000 at 11:49:51AM -0700, Randal L. Schwartz wrote:
> Please take your paranoia elsewhere. I think if you actually sat down
> and had lunch with each of the parties involved, and those further out
> but well-informed, you'd find a consistent view of reality that
> doesn't match AN
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Class Collections: Provide the ability to overload classes
>
> =head1 VERSION
>
> Maintainer: Greg Williams <[EMAIL PROTECTED]>
> Date: 17 Se
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
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Consolidate the $1 and C<\1> notations
I still say that this is a pointless change to scratch an itch that
only exists for woolly thinkers.
--
P
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
David Grove <[EMAIL PROTECTED]> writes:
> > Java is one language that springs to mind that uses interface
> > polymorphism. Don't let this put you off -- if we must steal something
> > from Java let's steal something good.
>
> Interface inheritance is probably the least dignified thing to steal
[EMAIL PROTECTED] (Johan Vromans) writes:
> Piers Cawley <[EMAIL PROTECTED]> writes:
>
> > Actually, I'd like to see something similar done to Universal::can
>
> my @methods = $class->can(pattern)
>
> where pattern is a perl pattern matching method names. For a full
> list, use
>
> $clas
57 matches
Mail list logo
