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.
>
>
Not to seem ungrateful, but is there any hope of getting the slides up as
well? You'd think it'd be a no-brainer, but there have been many Wall
speeches that have gone by with no slides on the web (well, none that I
could find, anyway.) I want to know what the audience is laughing at... :)
-Joh
On 4/5/01 6:36 PM, Nathan Torkington wrote:
> Better late than never! Chip's provided the slides for last year's
> Topaz talk at TPC5.
Ah, the speed of the Internet age! ;)
(but you're right, so thanks :)
-John
On 4/6/01 2:17 PM, Larry Wall wrote:
> P.S. Larry's Second Law of Language Redesign: Larry gets the colon.
My initial reaction: Larry can keep it! ;)
(go ahead, make me a believer... :)
-John
On 4/11/01 10:55 AM, Dan Sugalski wrote:
> It does fix the link issues, though. perl6.so won't ever have an
> unqualified function in it--they'll all have either a Perl_ or _Perl_
> prefix on them, and all global data will have a PL_ prefix on it.
Remind me again why it's PL_ and not PERL_? It s
On 4/11/01 4:38 PM, Dan Sugalski wrote:
> At 03:09 PM 4/11/2001 -0400, John Siracusa wrote:
>> On 4/11/01 10:55 AM, Dan Sugalski wrote:
>>> It does fix the link issues, though. perl6.so won't ever have an
>>> unqualified function in it--they'll all have either
On 4/23/01 3:59 PM, Nathan Wiger wrote:
>> Then how do you concatenate a number?
>
> Here's something I was thinking about at lunch:
>
> $concated_number = "$number" + "$other_number";
> $numerical_add = $number + $other_number;
>
> Why not require "" in the case when you want to forcible c
On 4/23/01 4:16 PM, Larry Wall wrote:
> What is it about . that seems to inspire allergic reactions in people?
> Surely it's not the . itself, but the requirement that you fit everything
> into that one syntactic mold. Perl's not going to do that.
I don't mind it, but I always imagined:
$ob
On 4/23/01 3:25 PM, Larry Wall wrote:
> : >From a trainer's point of view, having two operators which look very
> similar, : are used for the same thing in various different languages, and do
> *almost* : the same thing but not quite, is completely *asking* for confusion.
>
> So teach 'em :=, and
On 4/25/01 5:52 PM, Dan Brian wrote:
> the idea of a "dereference operator" dumbfounds lots of folks. "What's an
> object got to do with a reference, much less a pointer?" A p5 object is very
> confusing to others for this reason, and so is the syntax.
Then remove it from the reference syntax! :)
On 5/4/01 11:09 PM, Nathan Wiger wrote:
> The real trick is what to do with these:
Note: stabbing wildly here... :)
> %a = (%b, %c);
%a = (stringify(\%b) => \%c); # Perl 5-ish
%a = (%b.str => %c); # Perl 6 equiv.
> %d = (@e, @f);
%d = (stringify(\@e) => \@f); # Perl 5-ish
On 5/4/01 11:47 PM, Edward Peschko wrote:
> Horrors is right. The default perl5 behaviour is *useful*. I use the
> %b=(%a,%c)
> metaphor all of the time.
I believe you can get the Perl 5 functionality by throwing a few *
characters in there somewhere...
> Why not just keep it simple?
Based on A
On 5/5/01 12:06 AM, Nathan Wiger wrote:
> Maybe we need a way to say "flatten these together".
> I'm going to throw out a new ":" op here:
[snip]
> Hmmm... I kinda like that... Am I missing anything?
Maybe the fact that Larry's already claimed the colon? :)
-John
As a . doubter form the earlier threads, I'd just like to say that Apoc. 2
has gone a long way towards making me feel better about . as the method call
thingie...both by explaining all the neat things . does in Perl 6, and by
avoiding the potentially distressing introduction of the replacement str
I know I'm jumping ahead, but here goes...
Built-in classes in Perl 5 and 6 are uppercase: UNIVERSAL, ARRAY, HASH, etc.
By convention, "user" classes are Title::Cased. Simple guideline: don't use
UPPERCASE class names or risk being squished by a later revision of Perl.
Method names *sort of* fo
On 5/5/01 3:28 PM, Larry Wall wrote:
> I expect the real choice is between <$FOO and <$FOO>. I can convince
> myself pretty easily that a unary < is just another name for "next", or
> "more", or something.
Yeah, but it looks like "previous"! ;)
> maybe I should hold out for «» meaning qw() even
On 5/15/01 5:59 PM, Edward Peschko wrote:
> would be better off written as...
...speaking of which:
my int ($pre, $in, $post) is constant = (0..2);
What, no caps?
my int ($PRE, $IN, $POST) is constant = (0..2);
Looks nicer to me...or are all-caps vars reserved for
internal use in Perl
On 5/15/01 6:54 PM, Simon Cozens wrote:
> On Tue, May 15, 2001 at 06:49:53PM -0400, John Siracusa wrote:
>> Looks nicer to me.
>
> Did you know that other people might find other things nicer?
> TMTOWDTI has not been ruled out for Perl 6.
Yeah, yeah, but come on, who out there
Okay, this part has me confused. Here we build up a node hash:
my %node;
%node{LEFT} = undef;
%node{RIGHT} = undef;
%node{VALUE} = $val is Found(0);
$tree = %node;
What has the Found property here? I look at that and I think the value
associated with %node hash's VALUE
On 5/15/01 9:07 PM, Damian Conway wrote:
> Interestingly, the code would still have *worked* since the (originally
> unset) property on the node reference would have returned C which
> would undergo the usual boolean conversion in the C, and the usual
> promotion to zero in the numerical context o
On 5/18/01 9:23 PM, Damian Conway wrote:
> print %{(+$fh).prop};# All the value's properties
...and my question is: why is the %{...} there? Doesn't .prop return a
hash? Looks like it here:
> print keys $foo.prop; # prints "NumberHeard"
> print values $foo.prop; # prints
On 7/3/01 8:14 PM, Damian Conway wrote:
> You lost me here. Your ideas for properties are different from mine
> (which may well, in turn, be different from Larry's).
Anyone else get the feeling that properties are to Perl 6 what oo was to
Perl 5? :) It's like we'll finally be getting the oo bit
On 7/29/01 12:48 PM, Bryan C. Warnock wrote:
> Let's just arbitrarily assume that the
> major number of the version is equivalent to that version of the API.
> (In other words, Foo 1.05 gives us a promise that it uses the same API
> as 1.02 and 1.08. Foo 2.01 would use a different (however slight
(I figured it'd take me longer to track this information down myself than it
would to get a response from the list. Laziness... :)
Can properties be temp()orarily masked? For example:
foreach my $array (@arrays)
{
temp $array.sep = ', '; # assuming this is a real property
p
I just subscribed, so forgive me if this has been covered before (I haven't
read all of the archives yet)
STYLE:
> There should be tools, guidelines and processes to assist authors in writing
> quality modules. See also [EMAIL PROTECTED]
> Specifically:
> Style guide
> Naming guidelines
I kno
On 8/24/01 11:52 PM, John Siracusa wrote:
> I mentioned this on another list, and I thought I'd bring it up here as
> well. I think NeXT-style "bundles" offer an interesting solution for
> keeping several versions of a single library installed at the same time,
> wi
On 8/25/01 5:12 AM, Johan Vromans wrote:
> John Siracusa <[EMAIL PROTECTED]> writes:
>> If you ask any Java programmer which is "correct", myJavaMethod() or
>> My_Java_Method(), I think you'll get a straight answer.
>
> From experience I can assure you
On 8/25/01 1:51 PM, Kirrily Robert wrote:
> In perl.perl6.stdlib, you wrote:
>> Er, okay, well scratch that example then :) But my point still stands: I
>> think Perl 6 should have some sort of guidelines in this area, even if
>> they're only a codification of what "the majority" of Perl authors
On 8/25/01 10:37 AM, Dan Sugalski wrote:
> I'm currently thinking of using .pasm as the extension for parrot assembly
> code, and .pbc for precompiled bytecode. [...] Can anyone think of anything
> better? They seem rather lame.
I think they're just fine, actually. I like them better than anythi
On 9/9/01 11:47 AM, Dan Sugalski wrote:
>> http://www.allegedlyfunny.com/opcodes.html
>> I think DWIM might be a bit much, but HCF (Halt, Catch Fire) might be
>> fun :)
>
> Far too many of those are tempting... :)
Hey, if the PPC can have EIEIO, I see no reason Parrot can't sneak a few fun
ones
On 1/18/06 11:06 PM, Rob Kinyon wrote:
> Not to mention that 90% of the hacking done in Class:: and Object:: will
> handled by the fact that Perl6 has actual OO syntax. ("Look Ma, no hands!")
> You won't need Class::MakeMethods because Perl6 will make your accessors for
> you.
There's more to life
On 4/8/06 6:29 AM, Damian Conway wrote:
> I'm not enamoured of the .# I must confess. Nor of the #. either.
Thank goodness...I was beginning to think it was only me!
> Though, frankly, every one of the alternatives proposed so far is so ugly that
> I seriously doubt that anyone will actually want
On 4/10/06 8:38 PM, Larry Wall wrote:
> Even better is:
>
> =begin UNUSED
> sub foo
> {
> if foo { }
> }
> =end UNUSED
>
> And I don't really care if that's not what people are used to.
> The whole point of Perl 6 is to change How Things Work.
Do you care that it's hard
On 4/10/06 9:11 PM, Larry Wall wrote:
> I think commenting out code with # is sufficiently antisocial that
> you should probably do it with .
What's antisocial about it? What's the alternative for quickly commenting
out a few lines? Braced #[ ... ]# pairs are not as easy to "mindlessly"
On 4/30/06 7:44 AM, Juerd wrote:
> Jonathan Lang skribis 2006-04-29 19:08 (-0700):
>> Is there a reason that we've been insisting that a long dot should use
>> whitespace as filling?
>
> I don't know.
>
>> foo.___.bar
>
> Would still have the problem of clashing with .. when there's no _ i
Has anyone looked at LLVM lately?
http://llvm.org/
It seems to be making a lot of progress lately with the support of Apple
(which is using LLVM for its own purposes in Mac OS X). Is there anything
there Parrot can steal? Would it make sense for Parrot to target LLVM
bytecode and let LLVM do fu
On 8/23/06 4:09 PM, Aaron Sherman wrote:
> here's the problem with that: llvm is a very light layer, but it's yet another
> layer. To put it between parrot and hardware would mean that parrot is JITing
> to LLVM byte-code, which is JITing to machine code. Not really ideal.
...unless LLVM does a mu
On 6/4/02 12:22 PM, David Wheeler wrote:
> I think that if we can agree to forego backwards compatibility, we might
> also be in a better position to set up a CP6AN with much better quality
> control. All of the most important modules will be ported very quickly
> (e.g., the DBI), and a lot of the
On 6/4/02 12:34 PM, Steve Simmons wrote:
> As for CPAN . . . don't get me started. CPAN is a blessing, but has
> become a curse as well. It's contents need to be razed to the ground
> and better/more conistant rules set up for how to do installations
> into and out of the standard trees. If you
On 6/4/02 1:11 PM, David Wheeler wrote:
> On 6/4/02 9:59 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed:
>> 1b. 6PAN modules comply with an informal contract to maintain
>> backward-compatibility within all N.MM versions, where N is constant. In
>> other wor
On 6/4/02 1:26 PM, Larry Wall wrote:
> : Speaking of "CPAN for Perl 6" (or "CP6AN", or "6PAN"), what's the status of
> : this effort? Do we even have a vague idea of the requirements? Or does
> : everyone think CPAN (and module distribution/installation in general) as it
> : exists now it pretty
On 6/4/02 3:59 PM, Steve Simmons wrote:
>> : 1c. Distinctions like "alpha", "beta", and "stable" need to be made
>> : according to some convention (a la $VERSION...perhaps $STATUS?)
>>
>> Can probably burn that bridge when we get to it.
>
> Frankly, I'd argue that nothing in 6PAN ought to be in
On 6/5/02 2:59 PM, Steve Simmons wrote:
> Sticking just to the disk-intensive issue for a moment --
> [...]
> With the new one, we seem to have agreed that `most recent' will be
> used, not `first found'. That means that every tree must be probed,
> and probed with globs or sub-searches to match
On 6/6/02 2:43 AM, Damian Conway wrote:
> rule wordlist { (\w+) [ , (\w+) ]* }
No semicolon at the end of that line? I've already forgotten the "new
rules" for that type of thing... :)
-John
On 6/7/02 4:48 PM, Luke Palmer wrote:
> rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
>
> Then, you can match an img tag with:
>
> / /
>
> See, isn't that great?
Don't you mean, "see, isn't that massively over-simplified?" ;)
(but yeah, we get the idea... :)
-John
On 6/7/02 4:51 PM, Damian Conway wrote:
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
Then use those to make
On 6/7/02 5:44 PM, Damian Conway wrote:
> John Siracusa wrote:
>>> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
>>> released in the Grammar:: namespace. Including Grammar::HTML and
>>> Grammar::XML.
>>
>> Why no
Once nice thing about Java is the class naming convention that lets
individual companies (or even individuals, I guess) do custom development
that they can safely integrate with the "standard" Java classes and the work
of other companies/individuals without fear of namespace clashes. For
example,
On 6/16/02 1:50 AM, Luke Palmer wrote:
> On Sun, 16 Jun 2002, Michael G Schwern wrote:
>> Let's dump out the sack of namespace partitioning problems:
>>
>> What if Acme decides it wants to release part of it's code as Open Source?
>> (Happens a lot). Does it release it as Com::Acme::Text::Thing
On 6/18/02 6:10 PM, Damian Conway wrote:
> Larry has previously mentioned the prospect of Perl 6 module names being
> extended to include version number and author.
>
> If this were to be done, would seem reasonable for the "author" component to
> simply be the author's CPAN username. These are g
On 6/18/02 8:32 PM, Larry Wall wrote:
> I expect to end up with a multi-level system, where you can use anything from
> a DNS name (guaranteed to contain dots) through author IDs (no dots) to
> blessed top-level names for universally acclaimed modules, for some definition
> of universal.
I'm not
On 10/26/02 7:24 PM, Simon Cozens wrote:
> To the innocent bystanders, I hope you're not buying any of this crap
> about Perl 6 being more "regular" or removing the "inconsistencies" of
> Perl 5. It simply isn't true.
I was buying that right up until about a week or two ago when Larry emerged
fro
On 10/26/02 8:18 PM, Larry Wall wrote:
> On 27 Oct 2002, Simon Cozens wrote:
> : To the innocent bystanders,
>
> I'm afraid you're preaching to the null set here. :-)
I don't know whether to be flattered that you think I'm not just a
bystander, or insulted that you think I'm not innocent ;)
-Jo
On 10/29/02 3:13 PM, Damian Conway wrote:
> I suspect it will be quite unusual to see nested superpositions
> in code. Most folks are going to be using them for simple but
> very common checks like:
>
> [...]
>
> my $seen = $start | $finish;
> for <> -> $next {
> print $next unless $next == $seen;
On 10/31/02 5:33 PM, [EMAIL PROTECTED] wrote:
> Damian Conway writes:
>> BTW, Both Larry and I do understand the appeal of interleaving
>> sources and iterators. We did consider it at some length back
>> in January, when we spent a week thrashing this syntax out.
>>
>> Of course, I can't speak for
On 6/16/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> And I think that subs and methods *should* complain about all unused
> non-optional parameters *except* invocants.
This brings up something I've been thinking about. I sometimes write a
method in Perl 5 that does something or other and then c
On 6/17/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
> : Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
> : want to lose the abilities described above. How would those examples lo
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your message. I'm assuming it should just be ".")
>
> No. There's now also
(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)
On 6/17/05 6:18 PM, Damian Conway wrote:
> John Siracusa wrote:
>> (BTW, I'm not sure where those "./" thingies came from, but it's what GMail
>> showed in your
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:
On 6/17/05 10:42 PM, John Siracusa wrote:
> [...] I'm not, however, buying Damian's argument here:
>
> On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conwa
On 6/17/05 10:56 PM, David Storrs wrote:
> I'm not fond of .:: because I don't think it's sufficiently visually
> distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
.::internal_value(
On 6/18/05 12:23 AM, Adam Kennedy wrote:
> The reason we ended up at ./method was simply because it was the best
> suggestion anyone had.
That's what I'm trying to remedy :)
> It's other advantage is that (except for on nordic keyboards) dot and
> slash are generally right next to each other, so
On 6/18/05 2:40 PM, Darren Duncan wrote:
> As I recall, it was decided for a broad scope that public and private
> item invocation syntax was exactly the same but with the
> consideration that all private items have a ':' as the first
> character in their otherwise alphanumeric names (the ':' looks
On 6/18/05 7:54 PM, Juerd wrote:
>
>> [EMAIL PROTECTED]() .@:method()
>
> In Perl, @ has a VERY strong association with arrays, so except for
> specialised frameworks, I recommend against using it for other purposes.
The / character has very strong associations in nearly every programming
l
On 6/18/05 8:11 PM, Juerd wrote:
> John Siracusa skribis 2005-06-18 19:55 (-0400):
>> ./method() ./:method()
>> [EMAIL PROTECTED]() .@:method()
>> .>method() .>:method()
>> .-method() .-:method()
> [...]
>> ./method() .
On 6/18/05 8:28 PM, Juerd wrote:
> The unix shell and things resembling it will still be in use much fifteen
> years after today, Perl 5 will not.
Ooo, a bold prediction :)
-John
On 6/18/05 8:55 PM, Juerd wrote:
>> I'm just hoping there's an alternative that everyone will like better
>
> As long as I'm part of "everyone", that won't happen. I've listed
> numerous possibilities for myself, and found none that I liked better
> than ./method. I don't think you can come up wit
On 7/21/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> Have at it...
The only thing I immediately don't like is the use of the normal identifier
character "_" to indicate the "specialness" of a particular variable (or
attribute or whatever we're calling them these days). IMO, a "_" should
just be a
On 7/21/05 8:14 PM, Larry Wall wrote:
> On Thu, Jul 21, 2005 at 03:25:17PM -0400, John Siracusa wrote:
>> The only thing I immediately don't like is the use of the normal identifier
>> character "_" to indicate the "specialness" of a particular variable (o
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people to think of the private methods as being in a different
> namespace so that there's no confusion about the fact
Ack, I screwed up that last email with some bad copy and paste. Ignore it
in favor of this one please :)
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
> want people
Third time's the charm...really. Please ignore the last two messages from
me in favor of this one please. Sigh**2.
---
On 7/22/05 11:37 AM, Larry Wall wrote:
> The problem I have with "is private" is that, while there may very
> well be a trait of that name that you can interrogate, I really
>
On 8/16/05, Tim Bunce <[EMAIL PROTECTED]> wrote:
> I was a little dissapointed that there wasn't greater focus on using
> Perl6 features - especially as it would have helped kick-start my own
> understanding of Perl6 topics that I expect to be significant (such as
> Roles and Pairs, to pick two at
On 8/17/05 5:39 AM, Tim Bunce wrote:
> On Tue, Aug 16, 2005 at 03:58:54PM -0400, John Siracusa wrote:
>> I think it'll take years, and much actual production experience building
>> Perl 6 modules before the community learns what works and what doesn't for a
>> Perl
On 10/20/05 10:56 AM, Larry Wall wrote:
> I don't know how long this EuroOSCON net is going to stay up, so I'll be
> brief. I think we're having a new "class" sigil. Where we've been
> writing ::T, that will revert to meaning "an existing class T that
> we just might not see the declaration of fo
On 10/20/05 11:37 AM, Larry Wall wrote:
> On Thu, Oct 20, 2005 at 10:32:14AM -0500, Steve Peters wrote:
> : The idea of punishing programmers who choose to use certain operating system
> : or locales just doesn't seem right to me.
>
> That's why we provide ugly ASCII workarounds for all of them.
On 10/26/05, Larry Wall <[EMAIL PROTECTED]> wrote:
> A mandatory named parameter is now marked +:$nonoptionaloption.
Woo! :)
-John
On 12/4/02 2:16 PM, Michael G Schwern wrote:
> On Wed, Dec 04, 2002 at 02:03:06PM -0500, Dan Sugalski wrote:
DOS isn't an intended compilation target, no.
>>> Not even djgpp?
>>
>> Hadn't planned on it. What advantage does it give over windows?
>
> It'll compile C programs on a 386/SX, 20M o
On 12/6/02 4:41 PM, Michael Lazzaro wrote:
> my PersonName $name = .new(...);
> my FormalStr $s = $name;# "Dr. William P. Smith"
> my InformalStr $s = $name;# "Bill"
>
> Whether that is good, bad, or indifferent I leave to the OO Police.
I'm not even deputized, but I call foul: exces
On 12/11/02 1:10 PM, Michael Lazzaro wrote:
> I doggishly maintain my preference for treating "stringification for
> output" and "stringification for debugging" differently, but as long as
> I can specify an "AS_STRING" (sp?) method for a class, and _still_ get
> at a debugging version to print to
On 12/11/02 2:04 PM, Michael Lazzaro wrote:
> On Wednesday, December 11, 2002, at 10:36 AM, John Siracusa wrote:
>> Maybe "AS_STRING" and "AS_STRING_DEBUG"? Too long? "DEBUG_STRING"?
>> Are we married to the "AS_*" thing?
>
> Not
On 12/11/02 6:16 PM, Damian Conway wrote:
> There's no need for special methods or (gods forbid) more operators.
> Just:
>
>$obj1.id == $obj2.id
>
> That's what the universal C method is *for*.
I must have missed this (or forgotten it?) Any chance of it becoming .ID or
.oid or even ._id? I
On 12/11/02 11:41 PM, Luke Palmer wrote:
>> More generally, I really don't want to have too many (any?) "system" object
>> method names squatting in "my" all-lowercase object method namespace. It's
>> not hard to think of many kinds of objects that would naturally have an "id"
>> attribute, but mu
On 12/12/02 12:55 PM, Larry Wall wrote:
> As for namespace pollution and classes that use .id in Perl 5, I
> don't think it's going to be a big problem. Built-in identifiers
> do not have a required prefix, but they have an optional prefix,
> which is C<*>. I think we can probably parse
>
> $a
On 12/12/02 4:01 PM, Larry Wall wrote:
> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
> : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;
>
> If you wish to be precise, yes. But $a.id eq $b.id should work for most any
> class that uses the the term "id" in t
On 12/12/02 4:41 PM, Dave Whipp wrote:
> "John Siracusa" <[EMAIL PROTECTED]> wrote:
>> memory addresses is so infrequent that warrants a much
>> less common and/or longer method name than "id".
>
> Another reason for not making these synonymous:
&
On 12/13/02 5:09 AM, Luke Palmer wrote:
>> From: John Siracusa <[EMAIL PROTECTED]>
>> On 12/12/02 4:01 PM, Larry Wall wrote:
>>> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
>>> : So we'll _have_ to write $obj.*id when we mean $obj-&
On 12/13/02 10:49 AM, Garrett Goebel wrote:
> John Siracusa wrote:
>> Using the method/attribute named "id" for "this is
>> the same object" comparisons is just plain bad
>> Huffman coding. The "this is the same object"
>> method/attribut
On 12/13/02 12:44 PM, Michael Lazzaro wrote:
> On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
>> And I'd say (but who asked me -- IMHO, of course) that it should be
>> perfectly valid to write code like the above. (That IDs should be
>> unique across a process over all time.)
Has there been any discussion of how to create code in Perl 6 that's there
under some conditions, but not there under others? I'm thinking of the
spiritual equivalent of #ifdef, only Perlish.
In Perl 5, there were many attempts to use such a feature for debugging and
assertions. What everyone wa
On 1/9/03 9:01 PM, Luke Palmer wrote:
> Well, I just do:
>
> sub debug {
> print STDERR shift, "\n" if DEBUG;
> }
>
> And hopefully (I don't know P5 internals so well) that optimizes to a
> no-op so there's not even a function call there.
I don't know P5 internals so well either, but I'm guess
On 1/9/03 10:10 PM, Michael G Schwern wrote:
> I would assume it to be a compiler hint via subroutine attribute.
>
> sub debug ($msg) is off {
> print STDERR $msg;
> }
>
> some "this subroutine is a no-op if a flag is set" attribute.
Hm, not quite as convenient as setting a package globa
On 1/9/03 11:27 PM, Michael G Schwern wrote:
> On Thu, Jan 09, 2003 at 11:15:49PM -0500, John Siracusa wrote:
>> On 1/9/03 10:10 PM, Michael G Schwern wrote:
>>> I would assume it to be a compiler hint via subroutine attribute.
>>>
>>> sub debug ($msg
On 1/10/03 11:11 AM, Dan Brook wrote:
> On Thu, 09 Jan 2003 19:55:20 -0500
> John Siracusa <[EMAIL PROTECTED]> wrote:
>> Has there been any discussion of how to create code in Perl 6 that's
>> there under some conditions, but not there under others? I'm thinking
On 1/10/03 12:24 PM, Damian Conway wrote:
> "Immediate" subroutines are executed as soon as they are parsed (i.e. they're
> like named BEGIN blocks).
>
> Returning a closure/block from an immediate sub called in a void context
> (as C is in the example above) causes the immediate sub call to be
>
On 3/12/03 1:50 AM, Mark Biggar wrote:
> John Siracusa wrote:
>>> From A6:
>>> I worry that generalized wrappers will make it impossible to compile fast
>>> subroutine calls, if we always have to allow for run-time insertion of
>>> handlers. Of course, that
>From A6:
> I worry that generalized wrappers will make it impossible to compile fast
> subroutine calls, if we always have to allow for run-time insertion of
> handlers. Of course, that's no slower than Perl 5, but we'd like to do better
> than Perl 5. Perhaps we can have the default be to have wr
From an old summary:
http://www.perl.com/pub/a/2003/04/p6pdigest/20030427.html?page=2
> Paul Hodges took a crack at implementing for as a subroutine and came
up with
> something that didn't look too insane. Luke Palmer added a refinement
allowing
> for n at a time looping. However, for reasons
On Thursday, July 31, 2003, at 12:05 PM, Luke Palmer wrote:
Well, I don't think it's possible, actually. There's a flattening
list context at the beginning (implying a sugary drink from 7 eleven),
followed by a code block. But, as we know, slurpy arrays can only
come at the end of positional para
On 8/1/03 11:44 AM, Mark J. Reed wrote:
> Is it possible with the new parameter declaration syntax to declare
> a mandatory name-only parameter?
My earlier plea for this feature begins here:
http://archive.develooper.com/[EMAIL PROTECTED]/msg14666.html
I didn't think I made much headway, but thi
1 - 100 of 208 matches
Mail list logo
