Re: Protocols
On Wednesday, July 23, 2003, at 05:57 PM, chromatic wrote: The first is a deeper question -- besides inheritance, there's delegation, aggregation, and reimplementation (think mock objects) that can make two classes have equivalent interfaces. I'd like some way to mark this equivalence *without* having to inherit from an abstract base class and I wish that interface equivalence were checked before inheritance, as per Luke's idea. Sounds like you want Java-style "interfaces" to me. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Protocols
On Thursday, July 24, 2003, at 09:25 AM, Kurt Starsinic wrote: Sounds like you want Java-style "interfaces" to me. Follow the thread back. Objective-C had them way first, and their ur-name is "protocols." D'oh! Sorry, I had read that, but then forgot. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Alternately named arguments
On Sunday, October 26, 2003, at 05:05 PM, Damian Conway wrote: Err, no. Or at least: "Please, No!". ;-) That would certainly be a way cool abbreviation, but I suspect it would be a Very Bad Idea for unary plus to have two unrelated meanings out in the actual code. I suspect that the "named-only" markers are only available within actual parameter lists. Damian Welcome back, Damian. Lo, how we've missed you and Larry these many long months! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Control flow variables
On Tuesday, November 18, 2003, at 06:11 PM, Joseph Ryan wrote:
Not to be a jerk, but how about:
my $is_ok = 1;
for @array_of_random_values_and_types -> $t {
if not some_sort_of_test($t) {
$is_ok = 0;
last;
}
}
if $is_ok {
yada() # has sideeffects...
}
Isn't that just:
for @array_of_random_values_and_types, 'ok' -> $t {
when 'ok' { yada(); last }
last unless some_sort_of_test($t);
}
IOW, the topic is only 'ok' when all of the items in the array have
been processed, which in your code is what happens when
some_sort_of_test($t) returns a true value.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://www.kineticode.com/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Kineticode. Setting knowledge in motion.[sm]
Re: Control flow variables
On Tuesday, November 18, 2003, at 06:44 PM, Joseph Ryan wrote: And also if @array_of_random_values contains 'ok'. D'oh! See Damian's solution, then. ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Vocabulary
On Dec 16, 2003, at 10:20 PM, Rafael Garcia-Suarez wrote: There's a need (more or less) for special blocks that can be run at the end of the compilation phase of any arbitrary compilation unit. This would be especially useful in an environment such as mod_perl, where CHECK and INIT blocks currently _never_ execute, no matter when they're declared. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Vocabulary
On Dec 17, 2003, at 1:39 AM, Simon Cozens wrote: The desire to optimize the hell out of Perl 6 is a good one, but surely you optimize when there is a problem, not when before. Is there a problem with the speed you're getting from Perl 6 at the moment? Yes, it's taking too long to be released! ;-) Regards, David (Who wants to start writing Perl 6 applications yesterday.) -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: Semantics of vector operations
On Feb 2, 2004, at 5:20 PM, Larry Wall wrote: That being said, we can potentially use × U+00D7 MULTIPLICATION SIGN. (Though my vim can't seem to decide whether it's a single-width or a double-width character, urgh...) I realize this is a tad OT, but can anyone tell me how I can get Emacs to properly display Unicode characters? I expect that others on the list could benefit, too. Cheers, David
Re: Semantics of vector operations
On Feb 2, 2004, at 9:53 PM, Kurt Starsinic wrote: I realize this is a tad OT, but can anyone tell me how I can get Emacs to properly display Unicode characters? I expect that others on the list could benefit, too. (require 'un-define) Since I really don't understand Lisp, and since that simply didn't work, I'm going to assume it was some kind of joke. :-) Am I right? David
Unicode in Emacs (was: Semantics of vector operations)
On Feb 3, 2004, at 7:13 AM, Kurt Starsinic wrote: No joke. You'll need to have the "mule-ucs" module installed. A quick Google search turns up plenty of sources. Oh, I have Emacs 21.3.50. Mule is gone. You'll also need to have the appropriate fonts installed, of course. You may need to set your $LANG environment variable to a suitable value (I use "en_US.UTF-8"). I'm on Mac OS X. The fonts I use show most Unicode characters correctly when I use them in TextEdit... Thanks, David
Re: Funky «vector» operator
On Mar 19, 2004, at 11:58 AM, Karl Brodowsky wrote: just for the Emacs-users among you: C-x 8 < yields « and C-x 8 > yields ». Nice to know, even though my Emacs only displays empty squares for these characters. I have yet to figure out how to get it to properly display Unicode (I'm using 21.3.50.2, which doesn't have mule). Do you know how to make it display Unicode characters, Karl? Thanks, David
Re: Funky «vector» operator
On Mar 20, 2004, at 1:32 PM, Calle Dybedahl wrote: You don't need Unicode display « and », just plain old ISO 8859-1. True, but I'd like to get Unicode working for other projects, as well. They're characters number 171 and 187 there. And AFAIK every Emacs version released in the past ten years handles ISO-8859-1 out of the box. It's more likely that you're using a font that doesn't have the characters. No, the font works perfectly in TextEdit. There's some configuration change I need to make to Emacs to get it to work. And no, I can't install Mule, because, AFAICT, Emacs in CVS has removed it in favor of something else. I'll post to the Emacs developer list to see if I can get any joy there. Regards, David
Re: Funky «vector» operator
On Mar 22, 2004, at 5:02 PM, Piers Cawley wrote: Try this: (cond ((eq window-system 'mac) (when (string= default-directory "/") (setq default-directory "~/")) (setq mac-command-key-is-meta t mac-reverse-ctrl-meta nil process-connection-type nil mac-keyboard-text-encoding kTextEncodingISOLatin1) (create-fontset-from-fontset-spec "-apple-courier-medium-r-normal--14-*-*-*-*-*-fontset-courier14, ascii:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac-roman, latin-iso8859-1:-apple-courier-medium-r-normal--14-*-75-75-m-*-mac- roman") (modify-frame-parameters (selected-frame) '((font . "fontset-courier14") (pushnew (lambda (frame) (modify-frame-parameters frame '((font . "fontset-courier14" after-make-frame-functions) No joy: An error has occurred while loading `/Users/david/.emacs': Symbol's function definition is void: pushnew Fontsets are weird. Emacs and Lisp are weird. Cheers Piers. David
Re: Funky «vector» operator
On Mar 22, 2004, at 10:28 PM, Piers Cawley wrote: (require 'cl) somewhere before that code chunk. I thought everyone already did that. Thanks. I put only the code you sent me in my .emacs, and a handy Unicode file I have still doesn't display properly. *sigh* I'll wait and see what I hear back from the Emacs developers. In the meantime, there's TextEdit. Thanks, David
Re: Funky «vector» operator
On Mar 22, 2004, at 10:36 PM, David Wheeler wrote: I'll wait and see what I hear back from the Emacs developers. In the meantime, there's TextEdit. I've heard back that it may be that Unicode support simply isn't included in the Carbonized version of Mac OS X. They plan to look into it. Regards, David
Re: backticks
On Apr 16, 2004, at 7:19 AM, Simon Cozens wrote:
I'll bet you the actual most *common* use of modulus is:
until ( my ($percent_done=done()) == 100 ) {
do_work();
print $percent_done,"\n" unless $percent_done % 10;
}
And I'll bet it's something like this:
for my $i (0..$#thingies) {
my $css_class = $i % 2 ? 'blue' : 'yellow';
print "$thingies[$i]\n";
}
Pretty useful, actually.
Regards,
David
Re: backticks
On Apr 16, 2004, at 10:14 AM, Juerd wrote: Even with the "xx Inf"? Why? Oh, right, missed that. Sorry. David
Re: Synopsis 2 draft 1
On Aug 14, 2004, at 5:52 PM, Larry Wall wrote:
If one goes with a standard method name, we also want to see what it
looks like as an indirect object:
for more $*IN
for iter $*IN
for every $*IN
for read $*IN
for in $*IN
for shift $*IN
Of these, I like C best.
Like I say, all the good ones are taken:
for all $*IN# all() is junction
for each $*IN # each method wants closure if we follow Ruby
for next $*IN # next $foo is a loop exit
Hmm. Maybe the problem is that we shouldn't follow Ruby on .each's
signature. How about we have .apply or .filter do the Ruby implicit
iteration thing, and keep .each for iterating iterators.
Hmm.
@bar = filter @foo: { $_ * 2 };
@bar = @foo.filter:{ $_ * 2 };
@bar = @foo.filter({ $_ * 2 });
filter @foo: { $_ * 2 } ==> @bar;
C is good for this; I like it. But if you decide you need to
keep it as C,
then I personally really don't mind using C for the iterator
method.
Just my $0.02.
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: Return with no expression
On Aug 19, 2004, at 9:41 AM, Matt Diephouse wrote: If the parameter does not exist at all, then param() will return undef in a scalar context, and the empty list in a list context. Sure enough. And I've even read a large percentage of the (unwieldy) CGI.pm docs. But I was using C as an example. The behavior would exist with any subroutine that used C. It would be nice if Perl thought that => was scalar context for the expression that follows it. But then it wouldn't be just like a comma, would it? Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: Return with no expression
On Aug 19, 2004, at 11:07 AM, Aaron Sherman wrote: First off, in Perl 6, I *think* that that C<< => >> will enforce a scalar context (it's a tuple operator, last I recall). W00t! Second, in Perl 5 it should not be hard to identify such situations for warning purposes. C<< => >> may be a synonym for C<,>, but that doesn't mean that you can maintain some little smidge of state in the op that tells you that your right hand side should not be and expression that returns a list of more or less than one element. Yes, that would be very helpful. I get bit by this all the time myself. But even more helpful would be if C<< => >> enforced a scalar context in Perl 5, too. Regards, David smime.p7s Description: S/MIME cryptographic signature
Iterators and C
On Sep 9, 2004, at 9:14 AM, Larry Wall wrote: I just borrowed the -> from Perl 5 because I knew it was available, and I thought it read better for C loops than the Ruby approach. Interestingly, I was at PDX.pm last night for a presentation entitled, "Ruby for Perl Programmers." One of the things that the presenters said was typical idiomatic Ruby was the use of blocks (I think that's what they called them) with iterators, such that you almost *never* see the use of C in Ruby. Might a similar thing happen with Perl 6 code blocks and iterators? Regards, David
Re: Still about subroutines...
On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C<=> secondary sigil for POD is a no-brainer. s/uppercase/lowercase/ ? David
Re: Still about subroutines...
On Sep 17, 2004, at 12:21 PM, Larry Wall wrote: No, not the verbs, the uppercase nouns we see like =begin COMMENT ... =end COMMENT Oh, I wasn't sure, because in the Synopses you've been using propercase for =head1 POD. But maybe it's not the subjects of the header and item type verbs you're concerned with... Thanks, David
Re: Angle quotes and pointy brackets
On Nov 30, 2004, at 2:23 PM, Larry Wall wrote:
Correct. The p5-to-p6 translator will turn any
while () {...}
into
for @$handle {...}
I assume that each value would be still fetched from the file handle
lazily, yes?
Regards,
David
Re: Angle quotes and pointy brackets
On Nov 30, 2004, at 2:46 PM, Larry Wall wrote: : I assume that each value would be still fetched from the file handle : lazily, yes? Um, that was the question my "Correct" was answering. D'oh! Sorry. David
Re: specifying the key Type for a Hash
On Dec 4, 2004, at 10:57 AM, Larry Wall wrote: Well, I just put "is shape" because that's what the PDLers settled on, but as far as I'm concerned linguistically, it could just be "is dim". That would settle the "make-it-like-English" question by making it not at all like English. On the aesthetic hand, "shape" is a much prettier word than "dim". Yes, to me, "dim" means "not bright", as in dumb. Cheers, David
Re: Arglist I/O [Was: Angle quotes and pointy brackets]
On Dec 6, 2004, at 7:38 AM, Austin Hastings wrote:
for =<> {...}
I dub the...the fish operator!
:-)
David
Re: Perl 6 Summary for 2004-11-29 through 2004-12-06
On Dec 6, 2004, at 6:27 PM, Matt Fowles wrote: getters and setters John Siracusa wanted to know if Perl 6 would allow one to expose a member variable to the outside world, but then later intercept assignments to it without actually having to switch to using getters and setters in all of the code that uses the variable. The answer: yes, yes you can. And I would consider this a huge improvement over Perl 5's otherwise useful lvalue-able subs. Cheers, David
Re: Pick's randomness (was Re: Fun with junctions (was Sets vs Junctions))
On Feb 13, 2005, at 3:54 PM, David Storrs wrote: Ok, so it requires actually overriding the rand function and providing your own implementation. I was hoping for something a bit more automagical (probably involving a property or role, since they seem to be the answer to everything these days), but this will work fine. Write a module for it and put it on 6PAN. Regards, David smime.p7s Description: S/MIME cryptographic signature
Re: Fun with junctions (was Sets vs Junctions)
On Feb 15, 2005, at 11:06 AM, Larry Wall wrote: So maybe the actual pragma name is use qubits; Note: the pragma is not "use junctions", since they're already allowed to use junctions, as long as they don't try to observe them. :-) To quote Noah, what's a qubit? http://www.jr.co.il/humor/noah4.txt :-) Regards, David
Re: Fun with junctions (was Sets vs Junctions)
On Feb 15, 2005, at 11:16 PM, Larry Wall wrote: I admit that calling the .brainf*ck method is problematic several ways... And what of .c#? Regards, David
Re: Junction Values
On Feb 18, 2005, at 2:04 AM, Brent 'Dax' Royal-Gordon wrote:
Junctions are equivalent to the English sentence "Get eggs, bacon, and
toast from the store". (In Perl, that'd be something like C<<
$store->get("eggs" & "bacon" & "toast") >>.) It's just a bit of
orthogonality that allows you to give "eggs, bacon, and toast" a name
and use it later.
Junctions are "grocery lists", then.
Regards,
David
Re: should we change [^a-z] to <-[a..z]> instead of <-[a-z]>?
On Apr 14, 2005, at 7:06 PM, Patrick R. Michaud wrote: So, <[a.z]> matches "a", ".", and "z", while <[a..z]> matches characters "a" through "z" inclusive. I was going to say that that was inconsistent, but since you never need to repeat a letter in a character class, well, I guess it isn't. But the first person to write <[a...]> gets what's comin' to 'em. Regards, David -- David Wheeler President, Kineticode, Inc. http://www.kineticode.com/ Kineticode. Setting knowledge in motion.[sm]
Re: Code classes
On May 3, 2005, at 00:04 , Luke Palmer wrote: I agree with you there. $Larry has said that he wants `when` to work Shouldn't that be @Larry[0]? Cheers, David smime.p7s Description: S/MIME cryptographic signature
Re: When scoping
On May 4, 2005, at 22:31 , Larry Wall wrote:
given "hello" {
when /hello/ {
say "One";
if /hello/ { say "Two"; }
if /hello/ { say "Three"; }
continue;
}
say "Four";
}
Is there no more
say "Two" if /hello/;
?
Regards,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: When scoping
On May 4, 2005, at 23:19 , Larry Wall wrote:
You must have missed the implied "..." at the end of my list of
other WTDI.
You can also do any of:
say "Two" if /hello/;
/hello/ && say "Two";
/hello/ and say "Two";
/hello/ ?? say "Two" :: leave;
infix:(/hello/, { say "Two" })
continue unless /hello/; say "Two";
/hello { say "Two" }/;
s/hello/{ say "Two" }$0/;
({}, { say "Two" })[?/hello/]();
and probably a few more I can't think of off the top of my head.
Okay then, pay no attention to my piddling contribution of a single
example. :-)
Best,
David
smime.p7s
Description: S/MIME cryptographic signature
Re: reduce metaoperator
On May 5, 2005, at 11:28 , John Williams wrote: How does [+] know you mean reduce &infix:<+>, @array; instead of reduce &prefix:<+>, @array; which is nonsense, but the [+] is in a prefix position. Because [] applies only to infix operators, as I understand it. With the hyper metaoperator, the real operator is always in the place where it would normally be parsed. But this metaoperator pulls the real operator out of its usual pre/in/post position. Well, if it was in its place, you wouldn't need to reduce it, would you? I suppose users will need to know the answer when they start trying to write their own metaoperators. They should write them only for infix operators. I can see how to ask for a binary (hence infix) operator, but how do I ask for a prefix or postfix operator specifically, which +<< and >>+ do? Maybe there are Operator::Prefix, etc, roles defined so you can ask for them? Ask for them for what? Regards, David smime.p7s Description: S/MIME cryptographic signature
RE: General Feelings on Apoc 3
On Tue, 2001-10-09 at 22:42, Damian Conway wrote: > Brent asked: > >> If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a >> low-precedence version of this? > > I actually suggested exactly that to Larry a few weeks back. > > He likes the idea, but is having trouble finding an acceptable name for the > operator. I think the time has come, at last, to suggest a new operator -- and perhaps this would be a good place for it. We need the 'doh' operator. And to borrow from another thread, we might even be able to say doh! ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Indenting
On Tue, 2001-10-16 at 03:56, Bart Lateur wrote:
> Which reminds me... one of the less attractive features of here docs
is
> the fact that the quoted document always has to end in a newline. That
> is annoying at times.
That's part of the reason that I almost never use here docs, but the
qq{} operator, instead. No need for a closing newline.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
Yahoo!: dew7e
Jabber:
[EMAIL PROTECTED]
RE: Some Apocalypse 4 exception handling questions.
On Thu, 2002-01-24 at 08:48, Garrett Goebel asked: > So which Apoc will be the OO one? Apoc 12, to go by the chapters of the 3rd Camel. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 11:00 AM, "Mike Lambert" <[EMAIL PROTECTED]> claimed:
> Speaking of which, how do we ensure the immutability of keys being put
> into the hash? I think Perl copied the string, so that:
>
> $b = "aa";
> $a{$b} = 1;
> chop $b;
> print $a{"aa"};
>
> still works.
>
> If we start storing full thingies into the keys of a hash, we either need
> to make deep copies of these, or copy enough to ensure the hashing
> function has all that it needs.
>
> Say we do:
> $b = new Cat();
> $a{$b} = 1;
> $b->somefunctionthatchangesthehashvalue();
> $a{$b} doesn't find anything, since $b was hashed under it's old identity.
But these aren't really equivalent, are they? In the first, you use a
variable ($b) to create the key, and then a constant ("aa") to reference it.
In the second example, you use the variable to both create and reference the
hash value. So really you should do the same for the Perl 5 example:
$b = "aa";
$a{$b} = 1;
chop $b;
print $a{$b}; # No key found (will it be autovivified, BTW?)
Or you should do the opposite, make the Perl 6 example equivalent.
# "aa" will be used for the hash key, as specified by Cat's
# C spec.
$b = new Cat("aa");
$a{$b} = 1;
$b->somefunctionthatchangesthehashvalue();
$a{"aa"}; # Key found.
> I personally liked the stringification of keys. It made things a LOT
> simpler. :)
I suspect that you'll still be able to do this.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 11:57 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed: > Personally I'd like the default hash to return some immutable, unique > and probably opaque object id (something the like > 'Foo=HASH(0x81e2a3c)' you get from unoverloaded objects in Perl5, but > probably not identical). This isn't going to change as an object's > contents change. I would agree that such a default would be preferable, as long as I could overload it with my own idea of what the hash key should be. This will be useful for database applications, where I could have two separate objects that loaded the same data from the database, and are therefore "the same object," even though they wouldn't have the same OID. So I'd want to be able to say, for hash keys, use a key I define (probably including a primary key ID from the database). Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Hashes, Stringification, Hashing and Strings
On 4/16/02 12:27 PM, "Larry Wall" <[EMAIL PROTECTED]> claimed: > You guys are thinking in terms of a single $obj.hash method. I think > there will be more than one hashish (er...) method available, and each > hash will be able to choose at least whether it wants to hash by $obj._ > (the default), by $obj.hash (mutable), or by $obj.id (immutable). The > hash function is not sufficient in cases of hash collision, so you also > need to think in terms of multiple comparison methods. Wow, that will be pretty cool, I think. > Since these are just properties of the hash, the hash could even have > properties containing closures that define the hash and/or comparison > functions. These properties can force the issue, regardless of whether > the object in question cooperates. So you could hash objects on any > attribute or combination of attributes, for instance. Yes, this sounds ideal to me. > But the default is gonna look a lot like Perl 5. That's certainly good enough for me! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
C loop variations
In Exegesis 4, Damian writes:
It's important to note that writing:
for @a; @b -> $x; $y {...}
# in parallel, iterate @a one-at-a-time as $x, and @b one-at-a-time as
$y
is not the same as writing:
for @a, @b -> $x, $y {...}
# sequentially iterate @a then @b, two-at-a-time as $x and $y
Now, I love that the for loop can do both of these things, but the subtlety
of the difference in syntax is likely, IMO, to lead to very difficult-
to-find bugs. It's very easy to miss that I've used a comma when I meant to
use a semicolon, and vice versa. And what's the mnemonic again?
Is there any way the syntax could be made different? Could the two
approaches be differently named? Perhaps the first could be C, and
the second could be C, and they could both use commas. Or am I just
being paranoid?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: C loop variations
On 4/17/02 5:38 AM, "Piers Cawley" <[EMAIL PROTECTED]> claimed:
> I've got the horrible feeling that doing it this way will lead to
> nasty ambiguities in parsing, but if that's not the case then I must
> confess that I prefer this syntax. Especially if you want to do
> something like:
>
> for @a, @b ; @c, @d -> $x ; $y {...} # Apocalypse
> for @a, @b -> $x ; @c, @d -> $y {...}
>
> I think the second version of that looks cleaner, but neither of them
> is exactly gorgeous.
I have to agree that the second syntax is a lot cleaner for me to read. But
I see two problems with it. First, it breaks the consistency of the user of
the -> operator, since that operator is now a way of declaring the arguments
to the closure that follows it. That is to say, this
for @a -> $x {...}
Is more or less equivalent to
for @a sub ($x) {...} # pseudocode
So if you have more than one arrow operator, you're declaring more than one
subroutine closure. The arguments for each -> would go into only one
closure, and it's a syntax error to not follow each one with its own
closure.
The second issue is that this syntax doesn¹t appear to support parallel
processing (or mixed processing!) unless you still use different separators
',' and ';'. IOW, in this example:
for @a, @b -> $x, $y ; @c, @d -> $z {...}
Does the $x go with @a and the $y with @b? Or are @a and @b flattened and $x
and $y take two items at a time? This is the reason for the distinction
between '.' and ';' in the current proposal.
So really, I can't think of a syntax other than the one that Larry has
proposed without either violating the current rules governing the ->
operator or creating new ambiguities.
FBOFW, I think we'll just have to start thinking about formatting the
proposed syntax so that it's easier to read (but obfuscators can still be
happy with cramming it all on one line). To quote Damian:
One thing that might help is to get yourself into the habit of writing
sequential iterations on a single line:
for @x, @y -> $a, $b {...}
and parallel iterations on two lines:
for @x ; @y
-> $a ; $b {...}
That generalizes nicely on the very rare occasions that you need to use
both:
for @x, @y ; @z
-> $a ; $b, $c {...}
And then we just have to be aware that this could be the source of subtle
bugs, and use the formatting to help us spot it.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
// in Perl 5.8?
Anyone know what the chances are that some enterprising C hacker can/will/did get the // and //= operator into Perl 5.8? Seems like it wouldn't be a huge deal to add, and I'd love to have it sooner rather than later. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: C loop variations
On 4/17/02 1:20 PM, "Aaron Sherman" <[EMAIL PROTECTED]> claimed: > This gets ugly when you mix in traditional C for (are we keeping that in > Perl6?): Yes, but it's name is changing to C. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: // in Perl 5.8?
On 4/17/02 1:51 PM, "Dave Mitchell" <[EMAIL PROTECTED]> claimed: > I hope you're referring to 5.8.x for some x != 0 ??? :-) Do you know how late in the development process the $coderef->() feature was added to Perl (in whatever release that was)? Ask Randal to talk about it sometime. ;-) But maybe things are more rigorous now, and it should be 5.8.1. Personally, I'd rather see it sooner than later. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: // in Perl 5.8?
On 4/17/02 2:17 PM, "Graham Barr" <[EMAIL PROTECTED]> claimed: > The problem with // is that it already has a meaning and although perl6 will > redefine it > can we do so in perl5 ? I don't think we can. Oh yeah, you're right. Perl 5 would have to require that it be m//, and that would break a lot of existing code. Good point, I hadn't thought of that. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Please rename 'but' to 'has'.
On 4/20/02 3:02 PM, "Me" <[EMAIL PROTECTED]> claimed: > banana now red; > "foo" now false; > banana now foo; > banana now tainted; > > I read 'now' as somewhat suggestive of changing something. I actually rather like this keyword. It not only suggests that something has changed, but that it has changed at a particular time -- runtime. Compile time properties just *are* (is), no matter what, unless and until you say, at runtime, that it is *now* something else. -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Loop controls
On 4/29/02 1:41 PM, "Luke Palmer" <[EMAIL PROTECTED]> claimed: > My point is that, IMO, this whole "els" thing is completely preposterous. > I'm the kind of person that likes to keep down on keywords. And I never > liked Perl5's C anyway; I always preferred C. I really > don't understand what at all is appealing about C. Why, for Perl poetry that wants to talk about "the boat" in Spanish! :-P David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: // in Perl 5.8?
On 4/17/02 10:02 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > I'm working on a preliminary version right now. So far it's been > surprisingly easy--touches toke.c, perly.y, opcode.pl, pp.c, and > pp_hot.c. (Of course, it's also off an old bleadperl, but I doubt those > files change that actively.) I'm not a p5p, so I was wondering how this was going. I expect it won't go into 5.8.0, eh? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: // in Perl 5.8?
On 5/1/02 12:11 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > It's far too late to make it into 5.8, but it looks like it'll be in > 5.10 when that comes out (in a year or two). I figured. Too bad. ;-) A year or two is long time to wait! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
"Attribute" vs. "Property"
I just want to verify that I properly understand the use of these two terms in Perl 6. * An "attribute" is a data member of a class. * A "property" is a piece of metadata on a...uh...thing -- e.g., on an attribute, on a class, or on a method. Do I have it right? For some reason, I've always referred to class data members as "properties", and thought of metadata on such things as "attributes" -- the reverse of the above. This despite the use of "attribute" in the above usage in Damian's book. So do I just need to turn myself around (at least when talking about Perl), or is there a chance that the language designers would decide that the way I use the terms is ever-so-much-better? ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: "Attribute" vs. "Property"
On 5/11/02 2:48 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed: > Well, I suppose there's always a *chance* that we'd both completely reverse > our careful thinking on this issue and ignore the common usage of "attribute" > in the OO literature. But I do think it would be easier all round if you just > went with our chosen terminology for Perl 6. ;-) Damn. I was afraid you were going to say that! :-) Thanks for the reply. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
On 5/11/02 2:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
> method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
> method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I like the latter best -- and it beats the hell out of "instanceof" ;-)
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Backslashes
On 5/20/02 8:04 PM, "Luke Palmer" <[EMAIL PROTECTED]>
claimed:
> 'You think I' _ q{'} _ 'm knit-picking!'
Ugh. If you really don't like back-slashing single quotes, do this:
q{You think I'm knit-picking!};
I would agree that in a q{} context, it is silly that a double-backslash
prints a single backslash when a single backslash prints a single backslash
-- even when it precedes a single quote!
But there are Perl 5 nits, really.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
On 5/21/02 9:56 AM, "Aaron Sherman" <[EMAIL PROTECTED]> claimed: > I guess the run-time checks will be required, and inlining of small > chunks of code will never really be all that useful (as you cannot rip > open that scope and optimize the whole context). I think that a number of these issues of inlining methods were considered by p5p about two years ago, when Doub MacEachern submitted a patch that optimized Perl 5 method calls. Simon wrote about it here: http://www.perl.com/lpt/a/2000/06/dougpatch.html Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Idea
On 5/22/02 11:18 AM, "Michael G Schwern" <[EMAIL PROTECTED]> claimed: > It would be nice to have a way to check if something is an integer better > than the regexes in perlfaq4 I completely agree with this sentiment. In the meantime, if you don't want to worry about the regexes, check out my Data::Types module on the CPAN. It offers functions for checking integers and other numeric types. 'Course, in Perl 6, builtin types will make this a non-issue. I look forward to that day! Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Half measures all round
On 6/4/02 8:13 AM, "Simon Cozens" <[EMAIL PROTECTED]> claimed: > Yes, there's a lot of legacy crap out there. Much of the important parts of it > are XS, which we can't hope to support. (No, Dan, be realistic) So, let's go > through the CPAN argument: Personally, I'm still really jazzed about Perl 6, but I certainly see your point, Simon. As a CPAN contributor myself, I intend, once Perl 6 is delivered, to port my modules to Perl 6 (where appropriate -- Data::Types likely won't even be necessary anymore!), and leave the Perl 5 stuff to slowly die off. 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 cruft will be left to die (at least from the Perl 6 perspective). And I like the idea that the designers mentioned on Use Perl the other day, that Perl 6 may not ship with any add-ons, and there would instead be development kits available. This will have the affect of establishing n packages that are officially endorsed by the planners/maintainers, but don't burden the distribution. So I guess I'm agreeing with you, Simon. I have no problem with thinking of Perl 6 as a completely new language, and will be happy to work in both P5 and P6 in parallel for a while. And if my Perl 5 modules don't work in Perl 6, I will be motivated to port them. Plenty of folks are still dedicated to Perl 5, and it will likely to continue moving forward for some time -- it may never die. And I think that's true regardless of whether Perl 6 supports Perl 5 or not. So it's okay by me to dump it. Lots of people will freak out, but many won't. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
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 words, incompatible API changes are only allowed by incrementing the > "major version" (e.g. going from 1.xx to 2.xx), and upgrades from one minor > version to the next (e.g. 1.05 to 1.11) MUST be "safe" (i.e. > "backward-compatible"). This might be asking too much -- it's not very perlish, in the sense of TIMTOWTDI. It might make sense for DKs, but different people may want to use the conventions their comfortable with. Perl is there for you to create applications (and APIs) the way you want, not the way the gods demand. > Thoughts? Or has this stuff already been hashed out elsewhere and I missed > it? :) One thing I think is as important -- or perhaps more important -- is to enforce the presence of unit tests. There are a lot of modules on the CPAN that have no tests, and most of them suffer for it. It shouldn't be required that all tests pass, however. A statement showing what platforms they pass on and what platforms they don't at the top of the download page would be good enough. But the tests have got to be there. Regard, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On 6/4/02 10:21 AM, "John Siracusa" <[EMAIL PROTECTED]> claimed: > Well, there are already "suggested" conventions for version number formats. > > Anyway, CPAN is supposed to be organized! It's not a free-for-all dumping > ground for modules. Let the version numbering and API anarchists use > SourceForge, I say! :) It's not like we're demanding EJB-like API rigidity. > So we'll continue to have $foo.setBlah() and $foo.blah() and $foo.Set_Bar() > in 6PAN, for better or for worse. All I'm asking for is some small meaning > behind version numbering. Is that so wrong? :) Okay, I'll buy that. And I think that suggested guidelines for compatibility between version numbers would be valuable, but I wouldn't think that we should enforce it. There may be good reasons to break backward compatibility in some cases. > Heh, I was going to suggest that new minor-version 6PAN submissions > automatically have all the earlier minor-version test suites run against > them before allowing them to go into the archive... :) Hmmm...perhaps as a warning: All regression tests not passed. Do you still want to upload this module? That'll stop the vast majority of offenders, and those who upload anyway will be more likely to have documented changes. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: 6PAN (was: Half measures all round)
On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed: >> It shouldn't be required that all tests pass, however. A statement showing >> what platforms they pass on and what platforms they don't at the top of the >> download page would be good enough. But the tests have got to be there. > > Actually, for 6PAN I think they should have to pass. And maybe we > need a bug submission setup, and status checks, and . . . OK, OK, I'll > stop now. They're nice ideas, but who bells the cat? The again, if > Tim O'Reilly wants to fund me I'd be happy to do it. :-) On what platform(s)? Who's going to pay for the test bed for every possible combination of perl version, OS, various libraries, etc., etc.? I think that *requiring* that all tests pass is unrealistic. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Half measures all round
On 6/4/02 4:08 PM, "Brent Dax" <[EMAIL PROTECTED]> claimed: > Why bother? You've already put P::RD and T::B effectively in the core! > ;^) And Switch. And Next? And Q::S? Larry, have you decided on that one yet? :-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
On 6/6/02 11:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed: >> / $2:=(.*?), \h* $1:=(.*) / >> >> Does this imply that $1, $2, etc are now read-write outside of regexen? > > No. Maybe this is a RTFM question, but does Perl 6 (or Perl 5, for that matter) have some magical array that holds all the matches from the last match? e.g., ($1, $2, $3, ...)? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
On 6/7/02 10:12 AM, "Jonathan E. Paton" <[EMAIL PROTECTED]> claimed: > A5, under "RFC 072: Variable-length lookbehind": > > "Did I mention that the magical @+ and @- arrays are gonna be real dead? >Never could remember which one was which anyway..." Not to mention kinda useless. I was hoping for a magic array that would hold the actual *matches*, rather than pointers to their character positions. 'Course, such a thing might be rather resource intensive. And probably unnecessary, since Perl 6 regexes can simply assign to an array. Perl 5 is another matter. > I guess the golfing community would appreciate a mini-exegsis for what > Perl 6 can do for them :) [hint, hint] I rather expect that whatever Perl 6 does for golfers is a side-effect of what Perl 6 is doing for programmers who just need to get their work done. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
On 6/7/02 11:21 AM, "David Wheeler" <[EMAIL PROTECTED]> claimed: > Not to mention kinda useless. I was hoping for a magic array that would hold > the actual *matches*, rather than pointers to their character positions. And it appears to be C<@$0>. Duh. Sorry for the noise, folks. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6-language@perl.org
On Thursday, August 1, 2002, at 04:05 PM, Mark J. Reed wrote:
> Having the subscript operator change the topic is, IMHO, a rather strong
> violation of the principle of least surprise.
I'm inclined to agree. I think I'd much rather not have it change there,
since I'll frequently do stuff like this:
my %hash;
for qw(one two three) {
%hash{$_} = 1; # $_ should *not* == %hash here!
}
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Wednesday, August 28, 2002, at 06:11 AM, [EMAIL PROTECTED]
wrote:
> Is there some kind of third option? I have to admit I've always found
> Java
> commands like "Date bday = new Date('June 25, 2002')" somehow
> redundant.
I have to agree with this. Ideally, IMO, there'd be some magic going on
behind the scenes (maybe with a pragma?) that automatically typed
variables so we wouldn't have to be so redundant, the code would look
more like (most) Perl 5 OO stuff, and I'd save my tendonitis. What I
mean (ignoring for the moment the even simpler syntax suggested earlier
in this thread) is this:
my $date = Date.new('June 25, 2002');
Would automatically type C<$date> as a Date object.
Thoughts?
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Wednesday, August 28, 2002, at 09:56 AM, Larry Wall wrote:
> my Date $date { 'June 25, 2002' };
>
> Either way, this makes data declarations more like sub declarations
> in syntax, though the semantics of what you do with the final closure
> when are obviously different. That is, for ordinary data a bare {...}
> is equivalent to "is now", while for a subroutine definition it's more
> like "is on_demand".
I actually rather like that as a sort of compromise. Syntactic sugar,
good.
I'm assuming, however, that the difference in syntax between the two
different uses of {...} would be easily identifiable via the assignment
operator, viz:
my Date $date { 'June 25, 2002' };
vs.
my $sub = { ... };
Correct?
Also, this leads me to wonder, is a closure is actually a typed object?
my Closure $sub = { ... };
And if so, does it matter?
> Whatever. My coffee stream hasn't yet suppressed my stream of
> consciousness.
I think we're all the better for it! :-)
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Saturday, August 31, 2002, at 06:52 AM, Damian Conway wrote:
> my Date $date = Date.new('June 25, 2002');
>
>> my Date $date is now { .init 'June 25, 2002' };
>
> As is that.
Yes, but this:
my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
2002' };
Is shorter than this:
my Really::Long::Package::Name::Ugh $date =
Really::Long::Package::Name::Ugh.new( 'June 25, 2002' );
It's not the short package names like "Date" that exacerbate my
tendonitis!
> I'd suggest that redundancy in syntax is often a good thing and
> that there's nothing actually wrong with:
>
> my Date $date = Date.new('June 25, 2002');
No, nothing wrong. It's just not lazy enough (and my arms will want to
increase their tendonitis only by shooting you ;-)).
Perhaps there could be a way to mark a variable as statically typed at
compile time, and have the compiler apply the static typing so that I
don't have to do all that extra typing.
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote: > Sure. But the right solution is to permanently eliminate the > sesquipedalian > name (so you don't have to retype it for every single typed variable): > > class Date is Really::Long::Package::Name::Ugh; Oh, that's nice. As long as one is careful about not creating conflicting class names... Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Monday, September 2, 2002, at 03:44 AM, Damian Conway wrote:
>> my Date $date .= new('Jun 25, 20002');
>
> H. That's a very interesting idea.
> I like it.
Hallelujah! I like it, too! It's only one character more than my
original suggestion!
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: auto deserialization
On Monday, September 2, 2002, at 10:00 AM, Damian Conway wrote: > No, I never said (nor intended to imply) that. Note that I carefully > avoided the > word "alias" in my description of this technique. ;-) That was my doing. Sorry folks. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Multimethod Dispatch
On Tuesday, September 3, 2002, at 05:08 PM, Dan Sugalski wrote: > We call that concept "multimethod dispatch". That's what you're asking > for. Dan, can you explain what "multimethod dispatch" is? Thanks! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Multimethod Dispatch
On Tuesday, September 3, 2002, at 06:12 PM, Dan Sugalski wrote: > Damian can explain it better than I can, but it's essentially when you > dispatch based on sub or method signature. You're allowed to have > multiple versions of a single sub as long as they differ in their > parameter signature. Ah, yes, the same thing exists in Java. I remember, now. Thanks Dan, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Multimethod Dispatch
On Wednesday, September 4, 2002, at 06:58 AM, Dan Sugalski wrote: > No. They can be both compile time things or runtime things, depending > on the characteristics of the language. So if it's compile-time for a given language, how is it different from the Java concept of overloading? And will Perl 6 do it at compile-time or at run-time? Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
On Thursday, October 17, 2002, at 11:49 AM, Shapiro, Jonathan wrote: Well, let's look at a few possibilities: 1) if( $vec bit| $mask bit& $mask2 ) 2) if( $vec b| $mask b& $mask2 ) 3) if( $vec |b $mask &b $mask2 ) 4) if( $vec |bit $mask &bit $mask2 ) I think I would have an easier time explaining #4 to someone Yes, except that &bit is a subroutine reference, IIRC, not an operator. That's why it makes more sense to put the punctuation character at the end of the operator name. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
On Wednesday, October 16, 2002, at 04:55 PM, Smylers wrote: How about keeping caret for xor? $a ~^ $b # bitwise xor $a ^^ $b # logical xor Hm, the "seagull operator"? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote: On the other hand, the current rule for recognizing the *end* of a name in the style of operator:=+ is to go till the next whitespace, on the assumption that we'll never have (shudder) whitespace operators. Oooh, I nominate whitespace to be the concatenation operator! my $foo = $bar $bat; ;-) David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: perl6 operator precedence table
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote: In 'C', we have: a = b+c; In Perl, we can have: $a = $b$c; (Parseable as $a = $b operator:spacespace operator:tab operator:spacespace $c;) Oh frabjous day! Good Lord, you're sicker than I am! :-D David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Wh<[ie]>ther Infix Superposition ops
On Tuesday, October 29, 2002, at 09:58 AM, Larry Wall wrote: What kindergartener can't understand a logically entangled list of nouns? I want a tricycle or a video game or a teddy bear for Christmas. I want a tricycle and a video game and a teddy bear for Christmas. That's no different from: $self.want($tricycle | $video_game | $teddy_bear); $self.want($tricycle & $video_game & $teddy_bear); I think that this (and the remainder of your message) is a beautiful demonstration of the utility of the superposition operators. I notice that the naysayers suddenly quieted down after this message. So I would look favorably on finding a replacement for "superposition". Well, I like "set operators," too, but what's the grammatical term for the above "logically entangled list of nouns"? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Wh<[ie]>ther Infix Superposition ops
On Wednesday, October 30, 2002, at 07:18 AM, Jonathan Scott Duff wrote: The only thing this inspires in my brain is Schoolhouse Rock flashbacks. o/~ Conjuction Junction, what's your function? o/~ Heh. That's what I heard, too. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 12:17 PM, Michael Lazzaro wrote: I can't see that right (MacOSX Jaguar) in the email; to me it looks like a forwardtick and an, um, underlined 'a' -- but in spite of that, I'm game. It's just so pretty (when it works!) On my Mac, it's spelled «op» -- can others see that correctly, or do we have a sorry disconnect in the fonts, here, for us Mac folks? I use Mail.app, and saw the same thing you did. When I looked at the headers for Larry's email, I saw: Content-Type: text/plain; charset=UTF-8; But when I saw yours, you had: Content-Type: text/plain; charset=ISO-8859-1; format=flowed This tells me that Mail.app, for some reason, didn't know that it was supposed to use UTF-8 when showing Larry's mail. When I pasted his mail into a UTF-8 document in Emacs, it looked fine. Given that it's probably UTF-8 that Perl 6 source code is written in, I think that you and I might be better off using a smarter mailer. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 12:47 PM, Larry Wall wrote: This is currently running in a window that does Latin-1 rather than UTF-8. Do these French quotes come through? @a ´+ª @b Nope. But given that I don't even know where to go to type them in, and doing so will likely be a PITA...even though I *love* the idea of using these characters, might it be better to abandon them for now? Regards, David PS: What do they look like in this reply? -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:35 PM, Graham Barr wrote: On Wed, Oct 30, 2002 at 01:25:44PM -0800, Austin Hastings wrote: --- Larry Wall <[EMAIL PROTECTED]> wrote: Do these French quotes come through? @a «+» @b Odd, I see them in this message. But In the message from Larry I see ?'s And I didn't see them in Austin's message, but I see them in yours. Your mailer did the right thing, it looks like. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:43 PM, Michael Lazzaro wrote: Oh, don't say that! I already know what all of these should mean! :-) ≈ … ∫ § ¿ ∆ ∑ Ω ø ¶ º ≠ ≤ ≥ ‹ › ‡ Ø ˇ ¬ Ç Œ ∞ ¡ • Nice, I can see all of those. Your mailer is the same as mine, Apple Mail, and the headers are: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Which is correct. But let me ask you -- how did you input those characters? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl6 Operator List, Take 5
On Wednesday, October 30, 2002, at 01:52 PM, Michael Lazzaro wrote: Applications/Utilities/"Key Caps" (Again, OSX) which shows you where they all are. The «» quotes, for example, are option-\ and shift-option-\ Oh, well, I guess those aren't *too* far out of the way... David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Perl6 Operator (REMAINING ISSUES)
On Thursday, October 31, 2002, at 11:36 AM, Me wrote: A ^ prefix visually interferes a lot more with the op being hypered. I didn't understand that until I first saw use of square brackets (interestingly, use of angle brackets didn't grab my attention, though that may have been due to other factors). If we're talking about operators being "hypered," then I think that «op» makes a lot of sense. It reminds me of Perl 5's "spaceship" operator, <=>, and I think of a spaceship taking the operator and jumping into hyperspace. What could be a better analogy than that, quantumly speaking? Plus, it turns out not to be at all hard to type on Mac OS X. ;-) Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Primitive Boolean type?
On Thursday, October 31, 2002, at 02:43 PM, Michael Lazzaro wrote: Q: Can bits/bools be undefined? Perl conventions would indicate yes. IIRC, native data types, which are all lowercase (e.g., int, bit, long, etc.) cannot be undef. However, their class equivalents (e.g., Int, Bit, Long, etc) can be undef. HTH, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Primitive Boolean type?
On Thursday, October 31, 2002, at 10:36 PM, Michael Lazzaro wrote: So while I understand the philosophical/semantic reasons for the absence of a true boolean type, I wonder how easy it will be to describe the principle to newcomers, and if it's worth it. When someone asks "what's the boolean type in Perl?" I'd rather answer "bit" than "Perl doesn't have one", if for no other reason than the latter answer will completely freak them out. :-) How do you answer that question when it's asked of Perl 5? David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Primitive Boolean type?
On Friday, November 1, 2002, at 12:24 PM, Michael Lazzaro wrote:
So what is the "official" way to efficiently store the result of a
boolean expression, for example? If not as a "bit", then what?
If anything, I would suggest a primitive type, "bool", that has no
promoted type "Bool". It can just be a placeholder -- a "bit" alias
-- but I still don't understand the compelling reason for saying:
has bit $.is_plugged_in;
when WYM is, unambiguously:
has boolean $.is_plugged_in;
The problem with this is that you have explicitly introduced true and
false into the language, and have therefore destroyed the utility of
context:
my boolean $bool = 0; # False.
my $foo = ''; # False context.
if ($foo eq $bool) {
# Oops!
}
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: [RFC] Perl Operator List, TAKE 6
On Friday, November 1, 2002, at 12:21 PM, Michael Lazzaro wrote: ^[op] - [maybe] synonym for «op» - [maybe] synonym for »op« I think that would be: `<> - synonym for «op» `>>op<< - synonym for »op« Unless I misunderstood Larry's post, in which case it might be: `<>` - synonym for «op» `>>op<<` - synonym for »op« Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: UTF-8 and Unicode FAQ, demos
On Friday, November 1, 2002, at 04:06 PM, Simon Cozens wrote: More and more conversations like this, (and how many have we seen here already?) about characters sets, encodings, mail quoting issues, in fact, anything other than Perl, will be rife on every Perl-related mailing list if we persist with this idiotic idea of having Unicode operators. You keep saying or suggesting that the idea of using Unicode operators is "idiotic." Perhaps you could make an argument in support that assertion (as Luke and Paul have done). I for one would be interested to hear your reasoning. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: UTF-8 and Unicode FAQ, demos
On Saturday, November 2, 2002, at 08:33 AM, Simon Cozens wrote: More and more conversations like this, (and how many have we seen here already?) about characters sets, encodings, mail quoting issues, in fact, anything other than Perl, will be rife on every Perl-related mailing list I guess I don't see much of an argument there. That a discussion leads to discussions on other mail lists is not a reason not to use Unicode operators. Or so it seems to me. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Unicode Checker
For all you Mac OS X fans out there: http://www.earthlingsoft.net/UnicodeChecker/ Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: More junctions
On Saturday, November 16, 2002, at 04:52 PM, Damian Conway wrote:
if $moe|$larry|$curly == $hurt {...} # i.e. any of them hurt
and:
if $moe|$larry|$curly != $hurt {...} # at least one not hurt
and also between:
if $moe&$larry&$curly == $hurt {...} # all hurt
and:
if $moe&$larry&$curly != $hurt {...} # none hurt
Although I admit I don't mind the lack of space on either side of the
C<|> operator, it bugs me with the C<&> operator. Couldn't C<&$larry>
in the above snippet dereference a code reference? I really hope that,
stylistically, we'll more often see code like this:
if $damian | $larry | $dan == $hurt {...} # i.e. any of them hurt
if $damian & $larry & $dan == $hurt {...} # all hurt
Regards,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: String concatentation operator
On Monday, November 18, 2002, at 05:47 PM, Luke Palmer wrote: It's either that or have your functions, which were perfectly logical suddenly be subject to junction logic. That is, if $x == 2 and $x == 3 both being true, when your code relies on them not both firing. I think it's a very good decision to make sure that functions know they might be getting junctions and making it explicit. My god, I just realized that junctions are going to *completely* do away with the complaints of JAPH fans that Perl 6 will be too verbose, too hard to make obscure... Oh well, price of power, I guess. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Continuations elified
On Monday, November 18, 2002, at 06:51 PM, Damian Conway wrote:
for <$fh> {...}# Build and then iterate a lazy array (the elements
# of which call back to the filehandle's input
# retrieval coroutine)
for <$iter> {...} # Build and then iterate a lazy array (the elements
# of which call back to the iterator's coroutine)
for fibs() {...} # Loop once, setting $_ to the iterator object
# that was returned by C
for {...} # Build and then iterate a lazy array (the elements
# of which call back to the coroutine of the
# iterator returned by C
How will while behave?
while <$fh> {...}# Iterate until $fh.readline returns EOF?
while <$iter> {...} # Iterate until $iter.each returns false?
while fibs() {...} # Infinite loop -- fibs() returns an
# iterator every time?
while {...} # I'm afraid to ask!
Best,
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Continuations elified
On Monday, November 18, 2002, at 08:05 PM, Damian Conway wrote:
while <$fh> {...}# Iterate until $fh.readline returns EOF?
More or less. Technically: call <$fh.next> and execute the loop body
if that method
returns true. Whether it still has the automatic binding to $_ and the
implicit
definedness check is yet to be decided.
That's a scalar context? I assumed it was list context from your
previous post:
In a list context:
<$fh> # Calls $fh.each
At any rate, I hope that it's bound to $_ -- nice conversion from Perl
5's behavior, that.
David
--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
