Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sun, Apr 11, 2010 at 10:54 AM, Damian Conway dam...@conway.org wrote: Hyphen/underscore equivalence would allow those (apparently elite few) who can correctly use a hyphen to correctly use the hyphen That's about the only advantage of this scheme that I can think of. The disadvantages, which affect everyone, are many and bigger: search/replace headaches, novice confusion, adding to Perl's syntax infamy, etc. (Besides, I'm sure you can Acme::-up something that implements this scheme in Perl 6 for your own devious purposes anyway… ;) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 6:14 AM, Mark J. Reed markjr...@gmail.com wrote: I'd much rather see a single consistent style throughout Yeah, that's was my main point/question. I wanted to know if it was it some intentional convention (e.g., all methods that change the object state use hyphens, and all others use underscores) or if it was just meaningless inconsistency. Perl 6 does need some sort of convention in this area. Since it has a wider range of possible method names, there are more options. It took a little while for Perl 5 to converge on method_names_like_this() (after trying methodNamesLikeThis and LikeThis and so on), but many of those experiments and false starts still linger on CPAN and in end-user code. It'd be nice to avoid all that in Perl 6. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 5:25 PM, Damian Conway dam...@conway.org wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). That's certainly an example of how hyphens might gain meaning in Perl 6 names, but I don't think I can endorse it as a convention. People can't even use hyphens correctly in written English. I have very little faith that programmers will do any better in code, leading to the worst of all possible worlds: a convention that is confusing and employed incorrectly much of the time. -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 7:17 PM, Damian Conway dam...@conway.org wrote: And is it really so hard to teach: use underscore by default and reserve hyphens for between a noun and its adjective? Perhaps it *is*, but then that's a very sad reflection on our profession. I'm not sure if the intersection of people who speak English and people who program is better or worse than average when it comes to grammar, but I do know (from editing my share of writing) that the average is very bad and, further, that many programmers do not speak English as a first language, or at all. I'm having trouble imaging any convention that involves mixing word separators being successful. Maybe a completely deterministic one like hyphens after vowels, underscores after consonants, but that's pretty nonsensical. I think it has to be all hyphens or all underscores within a single method name, with the only wiggle room being a possible convention that dictates a different word separator for different kinds of methods. (My personal preference: methods_like_this(), just like in Perl 5. My second choice: methods-like-this(). Either way, no grammar knowledge required beyond knowing where one word ends and another begins—and even that's not a universal skill!) -John
Re: underscores vs hyphens (was Re: A new era for Temporal)
On Sat, Apr 10, 2010 at 8:23 PM, Daniel Ruoso dan...@ruoso.com wrote: Em Sáb, 2010-04-10 às 19:53 -0400, John Siracusa escreveu: I'm having trouble imaging any convention that involves mixing word separators being successful. But the convention Damian is proposing is simply use underscores. Basically camelCase and with_underscores are conventions on how to circunvent the fact that we can't use spaces in our identifiers. What is proposed here is that the p5 convention should be preserved. The hyphen is *not* a space, so it doesn't even get into the discussion of this convention. The basic difference is that when a programmer with sufficient communication skills have a composed word (i.e.: week-day), he will have the ability to use the hyphen instead of either supress it or use an underscore... These nuances are exactly what will be lost on people who see classes that use both underscores and hyphens in their method names. -John
Re: A new era for Temporal
Forgive me if this is a question the reveals how poorly I've been following Perl 6 development, but what's the deal with some methods using hyphen-separated words (e.g., day-of-week) while others use normal Perl method names (e.g., set_second)? -John
Re: Concerns about {...code...}
On 12/21/07 5:54 AM, Larry Wall wrote: To you and me, the fact that there are single quotes means there's something there to hide. But other people think the other way and see double quotes as indicating there's something to interpolate. I think PBP comes down on that side, but to me, single quotes are a little harder to see. And maybe there's some bias from seeing double quotes used non-interpolatively in American English. FWIW, my reasoning in this area is based on Laziness: single quotes mean I don't have to scan the string looking for interpolated stuff when reading code. Double quotes mean I do, and I'm annoyed at the waste of time when I scan and find nothing. Why didn't this guy just use singles here? It's (mildly) misleading. (There are obviously edge cases, even in Perl 5, but even naive adherence to this guideline is a good first approximation, with a second look only required in the rarest of cases.) -John
Re: Is Parrot 1.0 too late?
On 4/24/07 6:31 PM, Nikolay Ananiev wrote: As we all know, parrot has been in development for 7 years now. That's a lot of time and many things have changed since then. From my point of view one of the biggest strengths of Parrot is that it's a target for many (and why not all?) dynamic languages and as I know there's no other VM like it. Well... since now. Check this article: http://blogs.zdnet.com/microsoft/?p=404 Microsoft announces a dynamic layer for CLR, so they will be able to support dynamic languages on their VM. And JVM 1.6 already has this, plus it's opensource and has support for the mainstream platforms. So, is one of parrot's biggest strengths gone? Are we too late? Why would the developers use Parrot instead of JVM/CLR/Mono? I think the role Parrot aims to fill is remains unfilled, although it is being approached from both sides. Check out this LLVM presentation, for example: http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.html Look towards the ends of the slides: http://llvm.org/pubs/2007-03-12-BossaLLVMIntro.pdf An excerpt: Call for help! OSS community needs to unite work on various scripting languages Common module to represent/type infer an arbitrary dynamic language Who will provide this? pypy? parrot? llvm itself someday (hlvm)? HLVM is actually in progress: http://hlvm.org/ Judging by how fast LLVM has progressed since Apple's been backing it (almost two years now) LLVM/HLVM may be something to watch (or work with...) -John
Re: LLVM and HLVM
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 much better job of native code generation than the existing Parrot code, that is. Optimization seems to be LLVM's thing. -John
LLVM and HLVM
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 further optimization and native code generation? There's also the predictably named HLVM: http://hlvm.org/ which looks vaguely Parrot-ish. Check out the comparison chart: http://hlvm.org/docs/FAQ.html Anyway, I'm just thinking out loud, here. Sorry if it's all old news to the Parrot dev gurus. -John
Re: A shorter long dot
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 _ in between. foo.___:bar Would suffice for my needs. Not sure if people are willing to give up their underscore-only method names, though. No one's going to use either of these because they're ugly. Lining things up is at least partly about making things pretty for most people. -John
Re: Another dotty idea
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 harder to visually pick out the commented-out portions
of a file at a glance using that syntax? I really don't want to give up
s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use
triple ### for the thicker parts in my little ASCII art comment header
thingies.
###
### Blah blah
###
## Lorem ipsum dolor sit amet, consectetuer adipiscing elit.
## Ut et magna. Sed feugiat sollicitudin purus. Duis eget sem
## faucibus nibh dapibus sollicitudin. Sed egestas, nisl quis
## pharetra lacinia, libero urna tempus enim, non varius pede
sub foo
{
## bar();
## my $baz = blee();
## $baz--;
return 123;
}
No sir, I don't like it.
-John
Re: Another dotty idea
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 place quickly as a few # at the start of each line. -John
Re: Another dotty idea
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 to use them Agreed, especially... ...when there are cleaner alternatives for aligning postfixes already standard in the language: [...] foo$obj: $arg = $get_foo( $arg ); barb $obj: $arg = $get_barb($arg ); bazaar $obj: $arg = $get_bizarre( $arg ); Maybe we're trying too hard to let people have their postfix dotted space (and eat it too). I could almost swallow #[ ... ] as a multi-line comment...almost. The others with the dot just rub me the wrong way. -John
Re: Perl 6 OO and bless
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 than simple get/set accessors. Method-makers will have and a long and glorious life in Perl 6, I assure you :) -John
Re: +$arg changed to :$arg
On 10/26/05, Larry Wall [EMAIL PROTECTED] wrote: A mandatory named parameter is now marked +:$nonoptionaloption. Woo! :) -John
Re: new sigil
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 for dynamic reasons. Instead, the new sigil is the cent sign, so ::T is now written ¢T instead. How about an ASCII version and/or a class() built-in that means the same thing? ¢T == class(T) == ?T ^ | Dunno what to put there -John
Re: new sigil
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. We just haven't decided what the appropriate ugly ASCII workaround for ¢ should be. So...no joy on the class(T) builtin/macro/whatever? Does it look too much like a cast? -John
Re: DBI v2 - The Plan and How You Can Help
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 6 API (let alone implementation). So trying to pin down a properly Perl-6-ish API before Perl 6 is even through the language design process strikes me as a Very Bad Idea. I remember the early years of Perl 5 development, when a new feature was added there'd be a period of over-zealous use followed by a hangover as all the problems and edge-cases became apparent. Early years? Just look at inside-out objects or MI with NEXT today! Maybe it never ends...for some people, anyway ;) With Perl 6 there's going to be some almighty hangovers :) Understatement of the week :) Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999 after that. Basically, get one or two willing DBD authors who will help you to test and then throw away the first two attempts at a Perl 6 DBI API. Then at least you'll have some confidence when you commit to a DBI 2.0 API...which will be several years after Perl 6 is released, I hope. It'll be DBI 2 as DBI 1 still has a very long life ahead of it, but it'll be DBI 2.0.00xxx for quite a while :) I just meant that there should be several, possibly very different, attempts at DBI2 before the real DBI2 API is pinned down. Making the experiments have a 1.99x version helps to prevent people from thinking this is DBI2! when it's really just the first or second prototype. As for the actual 1.x DBI reaching 1.99, well, all I can say is to start using that hundredths place! :) -John
Re: DBI v2 - The Plan and How You Can Help
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 random). Perhaps the community of
Perl6+DBI users is too small at this point.
I'm afraid that DBI2 for Perl 6 will fall into the trap that I sometimes
feel like DBI1 fell into: the curse of being designed before the idioms and
Best Practices of API design in the language have been established.
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 6 API (let alone implementation). So trying to pin down a properly
Perl-6-ish API before Perl 6 is even through the language design process
strikes me as a Very Bad Idea.
That could explain why there were so few Perl 6 related suggestions: no one
knows how to design a good Perl 6 API yet, and any guess is very likely to
be wrong. Instead, suggestions have focused on what we do know: DBI in Perl
5 and Perl 5 API design. In that spirit, here's my suggestion: no more
configuration through magic/tied hashes. (e.g., $dbh-{'AutoCommit'} = 1)
(Probably goes without saying, but I wanted to make sure someone said it ;)
Anyway, it maybe worthwhile to have a DBI 1.99 first, and then maybe a 1.999
after that. Basically, get one or two willing DBD authors who will help you
to test and then throw away the first two attempts at a Perl 6 DBI API.
Then at least you'll have some confidence when you commit to a DBI 2.0
API...which will be several years after Perl 6 is released, I hope.
Of course, *someone* has to go first so we can all learn what works best
in Perl 6. I'm just saying that maybe DBI, which took the bullet in Perl 5
to some degree, is under no obligation to do so again. (This assumes that
we'll have some way to use Perl 5 DBI within Perl 6 to tide us over, of
course...)
-John
Re: Do I need has $.foo; for accessor-only virtual attributes?
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 that you can
have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named foo with an auto-generated
non-virtual accessor.
* Define a public rw attribute named foo with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the same name issue by, well, not giving both the
attributes the same name. Instead of two attributes both named foo, the
private one is now named _foo. This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the _ magic, I first have to find a way to
differentiate a private rw attribute with an auto-generated non-virtual
accessor from a private rw attribute with no auto-generated accessor. I
proposed some sort of trait for that earlier:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw accessor, not virtual, name class scoped
has $foo is private;
where the private name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
foo, so we can't use the accessor name itself to differentiate.
But both those two foos are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $foo is private;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named foo,
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $foo is private;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
Ah ha! you say. Isn't that an example of the private interface
interfering with the public interface? Exactly--but AFAICT, the original
proposal suffers from the same problem!
# private rw, no accessors, not virtual, name lexically scoped
has $foo;
# private rw, rw _foo accessor, not virtual, name class scoped
has $_foo;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
The point is, if you really want to the namespaces of the public and private
attribute accessors to be entirely isolated from each
Re: Do I need has $.foo; for accessor-only virtual attributes?
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 to think of the private methods as being in a different
namespace so that there's no confusion about the fact that you can
have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named foo with an auto-generated
non-virtual accessor.
* Define a public rw attribute named foo with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the same name issue by, well, not giving both the
attributes the same name. Instead of two attributes both named foo, the
private one is now named _foo. This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the _ magic, I first have to find a way to
differentiate a private rw attribute with an auto-generated non-virtual
accessor from a private rw attribute with no auto-generated accessor. I
proposed some sort of trait for that earlier:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor.
has $.foo is rw;
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor.
has $foo is private rw;
where the private name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
foo, so we can't use the accessor name itself to differentiate.
But both those two foos are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named _foo
has $foo is private rw;
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named foo
has $.foo is rw;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named foo,
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named _foo
has $foo is private rw;
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named foo
has $.foo is rw;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
Ah ha! you say. Isn't that an example of the private interface
interfering with the public interface? Exactly--but AFAICT, the original
proposal suffers from the same problem!
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
Re: Do I need has $.foo; for accessor-only virtual attributes?
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
want people to think of the private methods as being in a different
namespace so that there's no confusion about the fact that you can
have a private method and a public method of the same name.
Er, but can you ever have a public method that begins with an underscore
under your new system? If not, then there'd never be any of the overlap
that you want people not to be confused about. See, now I'm confused...
I get this part:
The problem with
$?SELF.:foo()
is that people see that as a .: operator on the foo method.
and like I said, I'm not insistent on using the colon. But I would like to
find a way to remove the proposed contextual magic of the leading underscore
and replace it with something a bit more explicit and obvious--in both the
calling syntax and the declaration syntax.
So, the problem looks like this. We want to find a way to:
* Define a private rw attribute named foo with an auto-generated
non-virtual accessor.
* Define a public rw attribute named foo with an auto-generated
virtual accessor.
* Call both of the accessors above with no ambiguity between the calls,
even though both attributes have the same name.
The proposed solution:
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has $_foo;
# Define a public rw attribute with an auto-generated
# virtual accessor.
has $.foo is rw;
# Call both of the accessors above with no ambiguity between the calls,
# even though both attributes have the same name.
$?SELF._foo(); # private accessor
$?SELF.foo(); # public accessor
kind of sidesteps the same name issue by, well, not giving both the
attributes the same name. Instead of two attributes both named foo, the
private one is now named _foo. This makes the accessor calls unambiguous,
but it doesn't really succeed in emphasizing the separateness of the private
and public namespaces.
Since my goal is to remove the _ magic, I first have to find a way to
differentiate a private rw attribute with an auto-generated non-virtual
accessor from a private rw attribute with no auto-generated accessor. I
proposed some sort of trait for that earlier:
# Define a public rw attribute with an auto-generated
# virtual accessor.
has $.foo is rw;
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor.
has $foo is private rw;
where the private name is up for grabs. Or it could be turned around:
has private $foo;
The next problem to solve is how to differentiate the calls. The colon is
out because it looks like an operator. The attribute names are really both
foo, so we can't use the accessor name itself to differentiate.
But both those two foos are in separate namespaces, right? That's why we
can have both of them in the same class. So how do we indicate the
namespace separation in the call? In the spirit of the (now dead?) SUPER::
from Perl 5, this immediately springs to mind:
$?SELF.foo(); # public
$?SELF.PRIVATE::foo(); # private
That's ugly and long, but at least it's clear. And it doesn't look like an
operator, that's for sure. How about some shorter alternatives:
$?SELF.OWN::foo();
$?SELF.MY::foo();
The bottom line, I think, is that if you really want private and public
accessors to live in totally different namespaces, you need to explicitly
namespace one or both of the calls. Name mangling isn't enough. For
example, imagine this:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named _foo
has $foo is private rw;
# Define a public rw attribute named foo with an auto-generated
# virtual accessor also named foo
has $.foo is rw;
$?SELF.foo(); # public
$?SELF._foo(); # private
A silly example, perhaps, but it does make two attributes both named foo,
one public and one private. The calls are disambiguated because the
auto-generated non-virtual accessor for the private attribute has a leading
underscore added to the actual attribute name--IOW, name mangling. But now
look at this:
# Define a private rw attribute named foo with an auto-generated
# non-virtual accessor named _foo
has $foo is private rw;
# Define a public rw attribute named foo with an auto-generated
# virtual accessor also named foo
has $.foo is rw;
has $._foo; # BOOM - compile-time error: method _foo() already exists
method _foo { ... } # ditto
Ah ha! you say. Isn't that an example of the private interface
interfering with the public interface? Exactly--but AFAICT, the original
proposal suffers from the same problem!
# Define a private rw attribute with an auto-generated
# non-virtual accessor.
has
Re: Do I need has $.foo; for accessor-only virtual attributes?
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 _ no matter where it occurs. Making a leading _ mean something special (triggering a slew of new semantics) in a particular context seems a bit hacky to me. Damian may not like the colon, but I couldn't help thinking that the _ could be replaced with : and things would be cleaner. Example: has $x; # private rw, no accessors, not virtual, name lexically scoped has $:x;# private rw, rw _x accessor, not virtual, name class scoped has $.x;# has read-only method # $.x always virtual # implies existence of real $:x internal variable # $.x is itself read-only even in this class # $:x may be set in methods or submethods # both names are class scoped ...and so on. Other than that, I like where it's going. I would like to see some example scenarios to convince myself that it really does address the concerns indicated at the start of the explanation, however. Maybe Luke and Sam can whip some up? :) -John
Re: Do I need has $.foo; for accessor-only virtual attributes?
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 (or
attribute or whatever we're calling them these days). IMO, a _ should
just be a _ no matter where it occurs. Making a leading _ mean
something special (triggering a slew of new semantics) in a particular
context seems a bit hacky to me.
Damian may not like the colon, but I couldn't help thinking that the _
could be replaced with : and things would be cleaner.
Well, but the _ really is part of the name, insofar as it's trying to
isolate the namespace. Even with : we had to say that it would probably
be stored in the symbol table with the leading colon.
Eh, an implementation detail (or, arguably, syntactic sugar for symbol table
lookups, depending on how it was really implemented in Parrot).
Plus history is on the side of leading _ meaning private implementation
detail
Sure, by *convention*, not as imperative magic :)
and the : is awfully confusing in the neighborhood of adverb pairs. If it
were just sigiled variables, the : would probably be fine, but
method :foo() {...}
just has a strangeness to it that won't go away. Arguably that's a feature,
but I'm mostly worried with visual confusion with all the other colons
in Perl 6.
I'm not married to the colon. Speaking of traits and adverbs, why not use
one of those in the has declaration instead? That'd certainly be a lot
more explicit than the magic leading underscore (although I'm at a loss as
to what the trait would be named...)
-John
Re: ./method defunct
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 the expense of using it is two chars and one fingering position, as they would likely be hit by fourth and fifth fingers (for touch typist style) and some other two fingers for the rest of us, and only 1 cm travel for hunt and peck. As I noted, . and : are also right next to each other. Yes, there's a modifier (shift) for one of them, but I didn't see anyone crying when .: was originally proposed, and .:: is just a double-tap on the 2nd key. IMO, the RSI index is basically a wash between .: and ./. The ugliness and appropriateness indexes, OTOH, heavily favor .: and .::, IMO. BTW, I'm still not sure which will be more common, private or public implicit-invocant method calls. I assigned .:: to private because it simply looks more internal to me. And I dislike having a THIRD sigil even more than I dislike the second. Objective-C has some spare characters if you're feeling adventurous :) [.method()] # ha, jk .-method() [EMAIL PROTECTED]() Hm, that last one actually isn't half bad, the mnemonic being call this 'at' the current object...or something. Again, maybe it's not feasible due to parsing constraints. How about resurrecting the spirit of the arrow? .method() That actually looks more private to me. Let's line 'em up again: PUBLIC PRIVATE -- -- ./method() .:method() [EMAIL PROTECTED]() .:method() .method() .:method() .:method() .method() .:method() .::method() I'm just trying to get some more suggestions out there on paper, because it seemed to me that the old thread jumped from ^ to ./ with less exploration than I'd like. -John
Re: ./method defunct
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 like part of an operator but it isn't). Doh! If that's the case, then your revised table is indeed the place to start. I'll throw one more on for good measure. PUBLIC PRIVATE -- -- ./method() ./:method() [EMAIL PROTECTED]() .@:method() .method() .:method() .-method() .-:method() I was also thinking about putting something before the . instead of after it. That actually makes more sense as a location for a syntax for an implicit invocant, since the invocant would come before the . too. Unfortunately, a that syntax is used for member variables and such, so the usual sigils are out ($ @ % ), and the rest start to look like unary operators on method calls implicitly made on $_ (e.g., -.method()) So we're back to the table above, I guess. I miss .::method(), but of the above choices I think I'd rank them this way, from best to worst. PUBLIC PRIVATE -- -- [EMAIL PROTECTED]() .@:method() # best .method() .:method() # . .-method() .-:method() # . ./method() ./:method() # worst It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) -John
Re: ./method defunct
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 language with division. In Perl it's also strongly associated with regexes, albeit in pairs. In Unix and URLs, it's associated with file paths. At least @ is vaguely associated with method calls in one existing programming language (Objective-C). .method() .:method() I think has just enough purposes, and that it should be left alone now. gt = pair == pipe qw qw +, ~ shift -, - sub I don't think there's any confusion between .method() and the other uses. In fact, I'd say there's less potential ambiguity about the in .method() than in some of other uses of the character. And that's what's important: ambiguity, not some arbitrary limit on the number of places that a character should be used. Also, in the context of Perl, 's historic usage in as the method caller thingie - in Perl 5 and its Perl 6 usage as the sub thingie - ties to method/function calls much more strongly than /. -John
Re: ./method defunct
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() ./:method() # worst Why exactly is the slash not acceptable for you? Almost everyone has said they like it. I personally find ./method prettier and easier to type than any of the alternatives. I think it's jarring. It definitely doesn't look like a method call to me. It looks out of place, like a typo of some kind. That was my honest initial reaction, as I posted earlier. I literally didn't even consider that it could be some sort of new syntax--and that's saying a lot considering I was reading p6l. I though GMail had mangled the text while trying to interpret quoting or something. It was a tough battle for last place, but in the end I think - even is a nicer placeholder for an implicit something. I just can't get over the path-y-ness of ./ (not to mention the division-y-ness) The pathiness was on purpose. In fact, ./pugs inspired it and a metaphor between cwd and $?SELF plays for mnemonic. I understand that, but I don't think it's a very applicable analogy. First, I think it's a long bridge from the file/path world to method calls. Second, even ignoring that, ./ in file/path context is a composition of two well-defined primitives, rather than the single unit proposed for Perl 6, the call this on $?SELF operator. (That could also be why I was breaking ./ down into . and / earlier, proposing alternatives for the / part alone.) The divisioniness is something you'll just have to get over. Do you see any division in /\w+/? No, because it's in pairs there (and because of ~12 years of perl 4-5 :) Or any addition in $foo +| $bar? Or any comparison in =, +, or ? Or any price in $var? Or any percentage in %hash? Or any conjunction in sub? I do see a bit of addition in +|. The constructs mostly look arrow-y to me, which is usually the intention (again, except in pairs where it looks bracket-y). Price in $var, well, years of shell combine there with years of perl (not to mention BASIC or whatever :) % and mostly ride on the perl 4-5 wave mentioned above. Anyway, I'm just giving my opinion. At least three other people agree with me, although we do seem to be in the minority so far. I'm just hoping there's an alternative that everyone will like better :) -John
Re: ./method defunct
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
Re: ./method defunct
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 with a pretty and easy-to-type and unambiguous ASCII based operator that I haven't considered yet. I think I'd be just as happy if we found an alternative that everyone but Juerd liked better (just as I'm sure you'd be okay if everyone but me liked ./ the best ;) Anyway, this isn't really a democracy. Who knows what evil syntax lurks in the mind of Larry... (well, other than The Shadow, natch :) -John
Re: Ignoring parameters
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 look
: in native Perl 6 code? (i.e., Without forcing all methods to have a
: single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
Something like:
# Do something then proceed with call as usual
method foo ([EMAIL PROTECTED])
{
./do_something_new(123, 'abc');
./SUPER::foo(@args);
}
Hm, but will that still catch cases where I call foo() with incorrect
arguments? I like the idea of method signatures that help catch incorrect
calls, but I don't quite understand how I can be ignorant of the super
method's signature while (essentially) delegating to it after doing my
thing. Looking at the above, I wonder if my overridden foo() would
basically remove the benefit signatures, allowing me to call it any which
way. (Whereas the superclass foo() might have a really strict signature and
catch any bad calls.)
(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 .)
But you probably want to avoid super semantics and write that:
method foo ()
{
./do_something_else(val = %_xyz);
next;
}
I've also taken the liberty of deleting your delete, on the assumption
that your next method might want to see the same argument and do
something else with it. A set of next methods need a consistent
parameter namespace in any event, so there's no harm in leaving the
parameter in %_, and some performance benefit in not doing something
better performed by GC (we hope).
What do you mean by a consistent parameter namespace? Surely they don't
need to have the same signature(?) That's kind of the point of my second
example: to override a method, add stuff to the signature, act on the new
params, and then delegate the rest to the superclass, calling it as if the
subclass's added params were never there. That's why I deleted the param
from the hash in the Perl 5 example.
In Perl 6, I'd expect the superclass to puke at runtime if I try to pass it
a parameter that's not in its signature. I thought you had to explicitly
slurp up any other args in your signatures, but I guess I misremembered.
Anyway, I guess I'm just trying to have my cake and eat it too. I want Perl
5's ability to transparently pass any remaining/all args to a superclass
without having to know what kind of args the superclass expects, but I
*also* want to get all of the benefits of strict method signature checking,
even in my subclass method. So...
class MySubClass; # a subclass of MyClass
method foo(MyClass::foo's signature, custom args, if any)
{
# do stuff with custom args, removing them when done
# call MyClass::foo with the remaining args
}
...all without ever knowing or caring what MyClass::foo's signature actually
is, of course. Maybe I'm asking for too much? (Or maybe I just have to
wait for Damian to come up with some clever technique to do it... ;)
-John
Re: Ignoring parameters
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 a unary ./ operator in Perl 6. Unary . calls a specified method on the current topic. Unary ./ calls a specified method on the current invocant. The point being that methods no longer topicalize their invocant. So you need to use ./ instead of . to call methods on an implicit invocant. Wow, that..er...how did I miss that? It looks a lot like running an executable in the current dir instead of letting the shell search its path. Was that intentional? Was this syntax discussed on a mailing list or elsewhere? I really liked plain old .foo(), but I guess I'll just use explicit invocants and look like an old fuddy duddy... :) (also, at least it's not /. shudder ;) -John
./method defunct
(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 message. I'm assuming it should just be .) No. There's now also a unary ./ operator in Perl 6. Unary . calls a specified method on the current topic. Unary ./ calls a specified method on the current invocant. The point being that methods no longer topicalize their invocant. So you need to use ./ instead of . to call methods on an implicit invocant. Someone pointed me to the giant p6l thread on this issue (which I now recall seeing in my email client months ago but totally ignored at the time for some reason). As you might guess from my initial identification of this syntax as some sort of text mangling bug in Gmail, I'm not a fan. I get the shell connection but that / just screams file path to me, not object or invocant. Forgive me for coming in late, but here's hoping it's better than never :) I was all ready to suggest .:method, but then I was reminded of that syntax's other purpose. I'm not, however, buying Damian's argument here: On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said: This missing design rationale here is that the colon acts as part of the unary operator: ./unary public-method-call-on-invocant .:unary private-method-call-on-invocant It strikes me as more of a rationalization than a rationale--picking out patterns after the fact, because that's what our brains like to do. So if you're willing to give up this nugget of comforting symmetry, I propose this: .: unary public-method-call-on-invocant .::unary private-method-call-on-invocant Okay, now maybe it looks like a package separator instead of a file path, but at least that's in the OO ballpark. I also admit to not fully understanding any possible parse/lex implications. But assuming it's possible, I like it a lot better than ./ All three keys are in a tight little cluster, so the odds of typo-ing a public method call to a private method call seem about equally likely in both cases, even allowing for the different uses of shift. One is not much more difficult to type than the other either. The .:: also looks deeper to me, suggesting private. See what I mean about picking out patterns after the fact? ;) But the truth is that / really does look file-path-y to me, and just plain old ugly. I think at least two other people had similar reactions (Martin Kuehl and Carl Franks). Maybe .:: has even more detractors, I dunno. All I know is that I dislike ./ and I'm trying to come up with an alternative. What say you all? Too many dots in .::? Surely ./ isn't as good as it gets... Anyway, sorry for the thread necromancy, but I let - drift away with barely a whimper and so I think latent guilt may be driving me to fight for this one at least a little bit... :) -John
Re: ./method defunct
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 Conway) said: This missing design rationale here is that the colon acts as part of the unary operator: ./unary public-method-call-on-invocant .:unary private-method-call-on-invocant So the rule is: One-character operator -- call on $_ Two-character operator -- call on $?SELF It strikes me as more of a rationalization than a rationale--picking out patterns after the fact, because that's what our brains like to do. [...] -John
Re: ./method defunct
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();
.:public_value();
I don't mind it, dots and all. I also think the .:: is quickly identifiable
as thicker than .: even at a glance. YMMV.
I don't have a better suggestion...but that's mostly because I
dislike this entire concept of secondary sigils. I already get to
have the Perl is line noise! conversation _way_ too often...I don't
feel that we need to give the trolls more ammunition.
I think $ is way more objectionable to the lily-white non-Perl heathens, but
I don't really care about them either way. I'm just saying ./ screams file
path to me, or maybe even typo-ed Java/C++ comment or something.
Certainly not method invocation or implicit invocant. The .: thing,
OTOH, totally works for me and I've always liked it. I'm just trying to
stretch it to cover both public and private. Maybe there's something better
than both.
(You know, if I had a nickel for every minute I've spent staring at my
keyboard's key caps while reading the p6 lists over the years...)
-John
Re: Ignoring parameters
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 calls the superclass
method of the same name, passing all arguments. Or sometimes I pull off an
argument or two that only make sense to my method, leaving the rest for the
superclass method. This is all easy when args are just items in the @_
array.
Here are some Perl 5 examples:
# Do something then proceed with call as usual
sub foo
{
$_[0]-do_something_new(123, 'abc');
shift-SUPER::foo(@_);
}
# Pull off some args, do something, then proceed with call as usual
sub foo
{
my($self, %args) = @_;
$self-do_something_else(val = delete $args{'xyz'});
$self-SUPER::foo(%args);
}
Note that in both cases my foo() method doesn't know or care what
SUPER::foo()'s arguments are.
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 look
in native Perl 6 code? (i.e., Without forcing all methods to have a
single slurpy [EMAIL PROTECTED] argument, emulating the Perl 5 mechanisms.)
-John
Re: Python is not Java...but will Perl 6 be?
On Fri, 3 Dec 2004 20:37:40 +0100, Juerd [EMAIL PROTECTED] wrote: John Siracusa skribis 2004-12-03 14:05 (-0500): From http://dirtsimple.org/2004/12/python-is-not-java.html In Java, you have to use getters and setters because using public fields gives you no opportunity to go back and change your mind later to using getters and setters. So in Java, you might as well get the chore out of the way up front. In Python, this is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class. So, don't write getters and setters. I'd like to be able to s/Python/Perl 6/ above, but after many discussions on this topic, I'm still not sure if I can. Anything can be anything. I'm sure that despite the ability to run all the code you want upon reading/writing an attribute, some people will still write setters and getters. I guess I wasn't asking if it would be possible (I think that's been established), but if it would be easy, reasonable, or clean (as it appears to be in Python, although I'm just going by what the quoted web page says). I recall some discussions about the best way to this in Perl 6, but don't recall if it converged on anything nice. Anyway, I thought it was interesting to see the ease of forward compatibility for simple attributes touted as a feature of Python. I'd like to tout it as a feature of Perl 6 too, because I also hate writing getters and setters... :) -John
Re: Python is not Java...but will Perl 6 be?
On Fri, 3 Dec 2004 22:06:43 +0100, Paul Johnson [EMAIL PROTECTED] wrote: http://www.nntp.perl.org/group/perl.perl6.language/9576 Wow, that's a blast from the past. I wonder how much of it is still valid... :) -John
Re: Angle quotes and pointy brackets
On 11/30/04 9:54 PM, Matt Diephouse wrote: use CGI «:standard»; [...] use CGi :standard; Who is doing this? I'm just saying... use CGI ':standard'; It really ain't all that broke, is it? -John
Re: [off topic] an amusing side note
On 11/24/04 7:27 PM, Tim Bunce wrote: I predict a burst of wild creativity from authors enjoying the exploration of all the wonderful tools in the perl6 toolbox. Then, after a year or three of fun, sawn off limbs, and bloodied fingers (and after a few good books get published) most of us will converge towards a common subset of accepted good practice. ...much like what happened with Perl 5...although the last phase has been hampered somewhat but the utility of some of those early, crazy efforts :) -John
S5: array interpolation
An interpolated array:
/ @cmds /
is matched as if it were an alternation of its elements:
/ [ @cmds[0] | @cmds[1] | @cmds[2] | ... ] /
As with a scalar variable, each one is matched as a literal.
Like this? (Assuming single quotes don't interpolate @foo[...])
@a = ('a', 'b', 'c');
'@a[0]' ~~ m:/ @a /; # true
'@a[2]' ~~ m:/ @a /; # true
'@a[9]' ~~ m:/ @a /; # false
If so, that seems pretty wacky...
-John
Re: No Autoconf, dammit!
On Wed, 8 Sep 2004 15:46:17 +, Herbert Snorrason [EMAIL PROTECTED] wrote: I suggest we institute a Rule One for Dan. (And number two, too, while we're at it.) It'd be easier that way. That rule already exists, but I think Dan still feels insecure about it ;) The Larry Way(tm) is to include the decision in the middle of a mind-numbing, globe trotting spew of information. That way, there are plenty of jucier tidbits to distract people. He also usually gives a one or two sentence reason, which might help here too. An example: No Autoconf because Autoconf assumes the existence of more things than Parrot can. Parrot has to build anywhere that has C89 support, but Autoconf requires sh, among other things. I don't even know if that's accurate, but in lieu of Larry's Where's Waldo Hidden Decree technique, I think there needs to be something more than because I said so to keep the natives from becoming restless :) -John
Re: Bundles
On 9/7/04 6:31 PM, Gregory Keeney wrote: Dan Sugalski wrote: Though it really ought to be on perl6-internals, since it's not really a perl thing at all, rather a parrot thing. I don't think I've the cycles to think about it for a while, though. Sounds like I need to dig through the mail archives, RFC's, etc. and try to come up with a coherent picture of the state of Perl 6 app bundling. I suspect it is not an issue for Parrot only or perl only or Perl only, but something that all three will have to play nice about. I will try to work out a nice summary for everyone to argue over. (Maybe John Siracusa will be willing to look it over before I post it; he is good with this kind of stuff.) I just want to make sure that people are thinking about it on all levels, not just the Parrot level. An ideal solution spans all levels. Unfortunately, in the absence of a design for such a solution (or even a concrete set of requirements) its hard to know what each part has to do. In these situations, it's best to just make sure the topic is in play, and then let the geniuses stew on it for a while :) The the Parrot folks go really nuts, they could end up implementing 90% of the solution, in which case the perl 6 executable support is simple and the stdlib and third party library ecosystem follow naturally. At that point, the only remaining debate is which lib, if any, is the 'default' or 'official' lib? Anyway, I think I need to think about it some more too. And being the bottom-up kind of guy that I am (witness my religious reading of per6-internals despite the fact that I loathe C and a lot of the discussion goes over my head) I think I'll have a better picture of what's possible when Dan finally does get around to giving it some thought (and then having his thoughts endure the crucible that is p6i :) -John
Re: What Requires Core Support (app packaging)
On 9/6/04 3:48 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It *could* do this, but loading bytecode in Perl 5 is slower than loading and compiling source, so there's not really much point. What's so magic about bytecode, anyway? Don't you think it's preferable to temp-expanding and compiling at runtime? I'd rather not have to write files to disk just to launch... Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. In what way? How have you managed to break it? The slides about the internals do start with Here begins the scary part and claim that PAR invokes four areas of Perl arcana, some of which were, or still are, undocumented. As for breaking it, I suppose all I'd have to do is try to use it on a platform that has perl but is not supported by PAR. Don't get me wrong, PAR is a great, impressive collection of code. But part of the reason that it's so impressive is that it's not easy to get Perl 5 to do this type of thing without a lot of clever tricks. I'd like it if this kind of thing doesn't have to be quite so clever in the Perl 6 age :) -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/6/04 12:13 PM, Nicholas Clark wrote: On Sat, Sep 04, 2004 at 09:44:54PM -0400, John Siracusa wrote: Finally, platform independent execution of any packaged or precompiled single file will *require* cooperation (core support) from the perl executable itself. PAR is neat, but it doesn't even match up that well with JAR, which allows the same file to work everywhere Java works. I just don't I'm confused here - specifically what can cause a PAR file not to run anywhere? The only reason I can think of is that it contains bundled up platform-specific shared libraries. Which means non-core C code. As long as perl lets you link in C code it's going to have to be pre-compiled for your platform. I can't see how JAR could avoid this problem if JAR were used for anything other than pure Java bytecode. I guess its kind of apples and oranges since Java has all its own libs, whereas Perl tends to piggyback on existing C libs (or include its own C parts) for certain things. -John
Re: What Requires Core Support (app packaging)
On 9/6/04 12:21 PM, Nicholas Clark wrote: I think packaging has the same characteristics. But unlike CPAN, packaging does require some minimum amount of core support to meet what I consider to be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Hm, well, features of the perl6 executable itself aren't really fodder for the parrot lists (are they?)...although I forget where they've been discussed in the past. Anyway, the long-suffering internals guys are still hashing out whether or not to have a STRING type or use PMCs for that, yada yada, so I think this is an issue to save for a bit later on... :) -John
Re: What Requires Core Support (app packaging)
On 9/4/04 11:42 PM, chromatic wrote: On Sat, 2004-09-04 at 18:44, John Siracusa wrote: To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. I think the specially structured dir of files and its single-file packaged (and precompiled) variants are important enough to be standardized, or core, or whatever you want to call it. ... you can find almost anyone arguing this point for almost any feature. I'm inclined to distrust it. Yes, this is a hard aspect to get consensus on, but that doesn't mean it's not important. Totally avoiding this kind of question is not the solution, IMO. That said... I just don't see a way to achieve this level of transparency and elegance without core support. That's a much better gauge for whether a feature should go into the core. I don't know how this particular case fares with that metric, but it's one of the right questions to ask. I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. On 9/5/04 3:02 AM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. That is only true if you accept the fundamentalist principle that one should never reinvent wheels. If that were true, then we wouldn't be working on Perl 6. Perl 6 will do many things that Perl 5 can't, so its more aptly described as an upgrade :) The standardized class, method, submethod, and so on in Perl 6 will be an absolute breath of fresh air. Don't worry; people will soon create their own helper modules anyway. There'll still be More Than One Way To Do It, like it or not. Maybe, but I'll wager there'll be a lot less variety since the standard system is more than capable enough for most purposes. Even if it's tweaked a little, if you know the standard system then you have a huge head start on whatever a particular program is doing. Wholesale reinvention will likely be confined to Damians. Furthermore, every non-core implementation will necessarily be uglier than the built-in system. Again, this is dogma. If the core specifies every minute detail of what you can do with the language, it's going to be far uglier than any module or implementation you can come up with. It's not specifying what you can do, it's providing one (good) way to do it. This brings up (again) the issue of core vs standard lib and all that. Some features are naturally library functions, but some things either can't or shouldn't be done without core support. The packaging issue spans the whole range: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is needed to unzip/untar/whatever the rest of the stuff in the package file before execution. Trying to inline pure perl unzip/untar at the header of each SDoF Package file doesn't seem elegant to me, but it could be technically possible to bootstrap that way using only the perl 6 executable. 3. The single-file, platform independent, non-source executable (P6exe). This is bytecode or some other platform neutral representation of the SDoF. I just don't see how to do this at all without core support. (Well, I suppose it could try to #! boostrap as well, but then you'd have to inline a bytecode interpreter or find some way to feed the bytecode to the right part of perl 6, which seems like it also leads to some sort of core support.) The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do this better. The perl 6 core needs to be designed with this type of stuff in mind. Regardless of whether it's core or stdlib, I think Java benefited greatly from having the JAR format. Perl 6 should one-up Java here like it does everywhere else :) Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only
Re: What Requires Core Support (app packaging)
On 9/5/04 8:31 PM, Luke Palmer wrote: John Siracusa writes: I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or precompiled bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. So have you, um, seen PAR? PAR doesn't compile or precompile to bytecode, it packages, temp-expands, and runs. It's closest to item #2 in my feature list, but it's something very different than compiling down to bytecode. Within the realm of what it does, PAR is pretty amazing. But the internals are (necessarily) very ugly and fragile. I suspect the PAR author would love to list the things he needs in the perl 6 core to implement PAR6 in a reliable, straight-forward manner. As for making bytecode packages and cross-platform single-file executables, maybe that's within the realm of the Parrot people. But the perl 6 executable would still to understand such things. -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/4/04 5:38 PM, Larry Wall wrote: On Sat, Sep 04, 2004 at 08:17:36PM +0100, Piers Cawley wrote: : John Siracusa [EMAIL PROTECTED] writes: : Ah ha, I didn't realize macros could override/replace existing control : structures. Okay, ship it! :) : : They'd be no fun if they couldn't. There is one caveat, of course. Precompiled modules won't see the change, so you'd have to precompile your own set of modules if you want the startup speed of precompilation. The precompiled what now? Actually, the other day I was thinking about how I tend to create any useful perl program that I plan to distribute in the form of a big, monolithic script. Take the distribution out of the equation and I'd write a series of generic modules, blah blah, the usual nicely factored design. But the headaches of trying to get users to install modules before they can run my wonderful program always leads me to flatten it all into a tradition Big Honkin' Script (ah, the days of Perl 4...) Anyway, it'd be nice if Perl 6 supported some sort of equivalent to Mac OS X's application wrappers: a dir tree containing all the files needed to run Your Wonderful Perl Program. To execute it, either run YourApp.pmx/run or some standard path, or run perl YourApp.pmx and perl would know what to do. In both cases, there'd have to be some automatic @INC changes, etc. The next step is precompiling that dir tree into a single executable file (bytecode?), but it'd be nice to have the Plain Old Dir of Source Files option too. -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/4/04 6:58 PM, Nicholas Clark wrote: On Sat, Sep 04, 2004 at 05:59:18PM -0400, John Siracusa wrote: Anyway, it'd be nice if Perl 6 supported some sort of equivalent to Mac OS X's application wrappers: a dir tree containing all the files needed to run Your Wonderful Perl Program. To execute it, either run YourApp.pmx/run or some standard path, or run perl YourApp.pmx and perl would know what to do. In both cases, there'd have to be some automatic @INC changes, etc. What of this doesn't PAR on Perl 5 give you today? Well isn't that a well kept secret :) Anyway, what it'll give me is official support for this type of thing. In particular, the Perl 6 executable itself should know what to make of such a specially formed dir tree how to adjust @INC automatically for me, what to run, etc.--in the same way that Perl 5 knows to look for Foo/Bar.pm in @INC when I use Foo::Bar. It's just nice to have some things built-in to avoid too much tedious bootstrapping. -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/4/04 7:31 PM, Simon Cozens wrote: [EMAIL PROTECTED] (John Siracusa) writes: Anyway, what it'll give me is official support for this type of thing. Call me a crazy man, but I *like* the lack of official support. I actually count it as a Good Thing that perl can be made to do cool stuff without Larry having to explicitly declare that it's OK. On 9/4/04 7:32 PM, Luke Palmer wrote: Basically what you're saying is that official support for this will be better than PAR in some way, since it's official. [...] In this case, I don't see any reason for this to be core. It has no effect on the way the rest of the language will go, it introduces no idioms, it has nothing to do with the language at all. If you can adjust @INC like you can in Perl 5, you can do everything you need to do to support this in a module. This gets back to my lone Perl 6 RFC. (Remember those? Ah, we were so young and foolish then...) To paraphrase: Yeah, it was cool that Perl 5 could be used to do OO programming in a nearly limitless variety of ways (see Damian's book), but it was most definitely not an ideal situation. In Perl 6, Larry made some decisions about how OO was going to work. You can still go your own way (even more so, in fact) but Perl 6 will definitely benefit from having an official way to do objects and classes. And when there's an official way, you'll certainly see less wheel reinvention than in Perl 5. This is a good thing. The use and require directives are another example. They're standard, and useful enough that there is very little call for for weird alternatives. A lesser language would simply provide require (or even just #include :) and leave more complex semantics to the community. Then you'd end up with 50 different use-like thingies, and reading anyone's code would have to start with deciphering how their used or with or import directives work. And those would all have to be bootstrapped with the anemic built-in features anyway, making everything uglier. Getting back to Perl 5 OO, it's in the same boat. Before reading anyone's OO Perl 5 code, you're almost certainly in for a trek into whatever pet OO helper system he's using: use base? use fields? Class::MethodMaker? Params::Validate? Class::Contract? All of the above? None of the above? The standardized class, method, submethod, and so on in Perl 6 will be an absolute breath of fresh air. To bring it home, I think packaging and distribution is important enough to warrant a standard, core-supported implementation. Yes, it's great to be able to roll your own solution, but forcing the issue by providing nothing but the most basic features required to bootstrap a custom solution leads to too much variety and confusion. For some features, familiarity and standardization are more important. Furthermore, every non-core implementation will necessarily be uglier than the built-in system. Only through a built-in can you simply run perl MyApp.pmx (where MyApp.pmx is a directory) and have things Just Work(tm). No non-core, community solution is going to be able to pull that off. Again, it's like use() and require(), or OO in Perl 6 -- provide a good, common, standardized set of features and the community won't waste its time re-implementing it over and over and over. But fail to provide it and you end up with a bazillion different Ways to Do It. Sometimes that's good--survival of the fittest and all that--but sometimes it's not an overall win. Pulling the Larry quote from the RFC: Although the Perl Slogan is There's More Than One Way to Do It, I hesitate to make 10 ways to do something. I think the specially structured dir of files and its single-file packaged (and precompiled) variants are important enough to be standardized, or core, or whatever you want to call it. I also think that the official implementation will have significant advantages in terms of simplicity, since no one else can change what's in the perl executable itself. (Well, they can, but forking perl itself is a bad thing, right? Yet another example of when having a standard is more important that community diversity and TMTOWTDI :) Finally, platform independent execution of any packaged or precompiled single file will *require* cooperation (core support) from the perl executable itself. PAR is neat, but it doesn't even match up that well with JAR, which allows the same file to work everywhere Java works. I just don't see a way to achieve this level of transparency and elegance without core support. -John
S4: Can PRE and POST be removed from program flow?
Synopsis 4 says: PRE and POST must return boolean values that are evaluated according to the usual Design by Contract rules. Do the usual Design by Contract rules include the ability to turn off (i.e. remove from program flow) PRE and POST blocks for performance reasons in production, or is than an anathema to the DBC crowd? :) I know you can do debug-assertions-like things with macros, but then you have to decide how expensive your pre/post checks are. The very expensive checks have to go into macros that you can turn off in production. But the cheaper stuff can stay in PRE/POST blocks (assuming they can't be turned off). Seems like an odd split...or am I over/under-thinking this? -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/3/04 6:03 PM, Larry Wall wrote: On Fri, Sep 03, 2004 at 04:35:56PM -0400, John Siracusa wrote: : Synopsis 4 says: : : PRE and POST must return boolean values that are evaluated according to the : usual Design by Contract rules. : : Do the usual Design by Contract rules include the ability to turn off : (i.e. remove from program flow) PRE and POST blocks for performance reasons : in production, or is than an anathema to the DBC crowd? :) : : I know you can do debug-assertions-like things with macros, but then you : have to decide how expensive your pre/post checks are. The very expensive : checks have to go into macros that you can turn off in production. But : the cheaper stuff can stay in PRE/POST blocks (assuming they can't be turned : off). Seems like an odd split...or am I over/under-thinking this? I don't see how we could prevent someone from clobbering the global definitions of PRE and POST to be no-ops if they wanted to. Seems to me that the whole point of putting the program in charge of its own compilation is to let it be in charge of its own compilation, n'est pa? Hm, okay, but there'd still be the call (or whatever) to the overridden versions. I guess that is no-oping them, but they're still technically in the program flow, unlike disappearing macros or #defines in C or whatever. Any facility for totally nuking them? -John
Re: S4: Can PRE and POST be removed from program flow?
On 9/3/04 6:45 PM, Damian Conway wrote:
John Siracusa wrote:
I don't see how we could prevent someone from clobbering the global
definitions of PRE and POST to be no-ops if they wanted to. Seems to
me that the whole point of putting the program in charge of its own
compilation is to let it be in charge of its own compilation, n'est pa?
Hm, okay, but there'd still be the call (or whatever) to the overridden
versions. I guess that is no-oping them, but they're still technically in
the program flow, unlike disappearing macros or #defines in C or whatever.
Any facility for totally nuking them?
macro PRE (block) {}
macro POST(block) {}
Ah ha, I didn't realize macros could override/replace existing control
structures. Okay, ship it! :)
-John
Re: Numeric semantics for base pmcs
On Wed, 25 Aug 2004 07:48:03 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: John Siracusa [EMAIL PROTECTED] wrote: On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? I thought about that during BigInt hacking. It could be a nice optimization if we go: Int - Int64 - BigInt on 32-bit systems that have 64-bit integer support. OTOH it makes type promotion a bit more complicated and dependent on configuration settings. Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? Either way, it'll definitely be a boon to fast integer math if 64-bit ints are used to stave off promotion to BigNum when possible. This may be especially true for languages like Perl 6 which (AFAIK) doesn't have an int64 native type specifier. So either Perl 6's int type is 64-bit where possible, or is a 32-to-64-auto-promoting type. -John
Re: Numeric semantics for base pmcs
On Thu, 26 Aug 2004 11:10:59 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: At 10:56 AM -0400 8/26/04, John Siracusa wrote: Why make a stop in 32-bit land at all in that case? If the system supports 64-bit ints, why not use them for everything right up until you promote to BigNum? Is it a memory bandwidth issue or something? If you've built parrot to use 64 bit ints, it will. Hm, but does that also mean that it'll expect all ints to be 64 bit? I'm thinking of hybrid situations like Mac OS X on a G5, where the OS and all system libs are still 32-bit, but the CPU can handle 64-bit integers. We still have to generally address the whole 64 bit integer question. I've been avoiding it, but I'm not sure that's ultimately feasable. Obviously someone needs to buy you a G5 in order to adequately motivate you... ;) -John
Re: Numeric semantics for base pmcs
On Tue, 24 Aug 2004 14:46:53 -0400, Dan Sugalski [EMAIL PROTECTED] wrote: The big question is whether being clever and producing the tightest type is worth the time to figure out what that type is, as well as the potentially uncertain output type. Tangentially related: will promotion be suitably delayed on systems with support for 64-bit ints? More generally, what is the state-of/plan-for 64-bit support (whatever that may mean) in Parrot? -John
Re: Synopsis 2 draft 1 -- each and every
On 8/20/04 5:30 PM, Austin Hastings wrote: How about scalar? The fact that one person, one time, came up with a need to invoke it doesn't mean we have to race it up the huffman tree. P6 is winning the DWIM race most of the time contextually. Maybe [#] as a macro, if you like. Yeah, that's my feeling too. I was going to suggest sc, but I don't think having to writ out scalar is too much of a hardship. I think the drive for a single-char version is driven more by symmetry than expected usage frequency. (I also think S is ugly and _ looks like a typo in many situations) -John
Re: A12: Required Named Parameters Strike Back!
On 5/5/04 6:24 PM, Austin Hastings wrote:
To answer Dan's posting: I fully expect to never use any of these
sigils, myself. I'm sure there will be traits for this- nice
verbose traits. (Signatures are about as write-once as you can get...)
method x(
requires:invocant $me,
requires $requisite,
$mandatory,
$necessary,
optional $maybe,
$possible,
$potential,
$unlikely,
named$yclept,
$hight,
$aka,
named:* %named,
va_list @list)
{...}
What happened to my poor required, named? Oh, the pain!
method foo (+$bar is required) { ... }
method foo (~$bar is required) { ... }
Eh, I've never been a fan of ~ (even for concatenation...sigh, dot has
ruined me forever). Anyway, once we're spelling things out, don't forget to
throw in some traits for params that are required and must be provided as
pairs. Damian promised! ;)
-John
Re: Required Named Parameters Strike Back - P6 Summary Clarification
From the recent P6 Summary:
Larry's response is a masterpiece of conciseness:
Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.
Larry's response also didn't really address the issue, since parameters
marked with a + in the signature are optional, not required.
Discussion continued after this of course, but it was mostly concerned
with making sure things worked as expected.
The continuing discussion revealed why it is not possible to check for
required params at compile time (well, for methods, anyway), but I still
wanted a way to tell Perl 6 to do runtime checks for me in response to a
particular signature.
Damian suggested an is required trait for signatures:
sub foo(+$a is required, +$b is required) { ... }
which I'm all for, even if it is only a runtime check, but I'm not sure if
this is just one of Damian's Crazy Ideas(tm) or if it'll actually end up as
a standard part of the Perl 6 language.
-John
MethodMaker techniques in Perl 6
Based on the default accessors and encapsulation thread, it seems like a
Perl 6 equivalent of Class::MethodMaker will be still be useful in our (or
at least my) Brave New World. I've been pondering the best way to create
such a beast in Perl 6.
The most common two Perl 5 techniques are:
1. Use a string eval: build up a big string that looks the code for the
method that I would have typed myself if I wasn't so lazy, then eval the
string and assign the resulting code ref to the appropriate typeglob.
Example:
$attr = 'baz';
*{Foo::$attr} = eval qq(sub { \$_[0]-{'$attr'} });
This technique seems to have the best runtime performance in Perl 5 (by a
small margin), but it's also much more expensive (not to mention tedious and
persnickety) to create the method in the first place. For whatever reason,
it's always just struck me as wrong (sort of like source filtering where
code is just seen as a giant string--something that Perl 6 blessedly saves
us from :)
2. Use a closure: build a method by assigning what would normally be
constant values to a set of variables, then capturing their state in a
closure. Example:
$attr = 'baz';
*{Foo::$attr} = sub { $_[0]-{$attr} };
Making the method this way has always seemed cleaner to me, but it bothers
me that $attr a full blown variable that has to be read from every time the
method is run. Really, it should be a constant, which is probably why the
string eval version has a speed edge at runtime.
Obviously, simple get methods like the above wouldn't have to be written
at all in Perl 6. Instead, I'd just use a public, read-only attribute (has
$.baz) and be done with it. (As far as I can tell, the user of my class
wouldn't be able to determine (or care) how $o.baz is implemented--whether
as method baz() { ... } or as has $.baz. Correct me if I'm wrong :)
Set methods, OTOH, will still have to be either written manually or
auto-generated if, like me, you are not inclined to accept the contract
implied by has $.foo is rw Perl 6 attributes.
But beyond simple get/set methods, there's a whole world of increasingly
more complex kinds of generic methods to be made. Just look at Perl 5's
Class::MakeMethods::* for some examples. So finally, getting back to my
original point, I'm wondering how best to create a good MethodMaker in Perl
6.
The two Perl 5 techniques still seem like they will work (albeit with
different syntax), but I'm sure there are better ways...perhaps something
involving macros? The ideal solution has the strengths of both Perl 5
techniques, but none of their weaknesses. Creation should be fast and
clean, and there should be no wasted overhead when calling the generated
methods. It should be just as if I wrote the methods myself.
I haven't retained enough Perl 6 syntax to have any idea what this would
look like, so I'm looking for suggestions. Which Perl 6 features are best
suited to creating a good Perl 6 MethodMaker? Anyone want to post some
simple examples?
-John
Re: A12: Required Named Parameters Strike Back!
On 4/22/04 5:33 PM, Aaron Sherman wrote:
On Tue, 2004-04-20 at 10:51, John Siracusa wrote:
Hm, so how would the is required trait that Damian posted work? Would it
simply be shorthand for a run-time check that I don't have to write myself?
I was under the impression that it would work the way I described earlier:
sub foo(+$a is required, +$b is required) { ... }
Your example is a non-multi sub, which AFAIK means that you can do this
at compile time. But for multis and methods, I think Larry and Dan's
comments still hold.
The likelyhood that P6.0.0 will make this distinction is another thing.
I'd rather have a language that works than one that is complete. Plenty
of time to complete it later, but those who are thinking of taking on
large-scale development with it (e.g. converting over large CPAN modules
or implementing new Perl6ish libraries) just want something that runs :)
Yes, it appears that runtime checks for the existence of required params
will continue to be a necessary part of Perl programming. I suppose a
saving grace is that Perl 6 will support real assertions that disappear
entirely from the program flow when a switch is flipped.
-John
Re: A12: Required Named Parameters Strike Back!
On 4/22/04 6:52 PM, John Siracusa wrote: Yes, it appears that runtime checks for the existence of required params will continue to be a necessary part of Perl programming. ...of course, there are at least two ways to do runtime checks: * runtime checks that the programmer has to write himself * runtime checks that the compiler generates automatically (presumably using a trait like is required) I'm sure someone will write the latter if it's not part of the core language...hint hint :) -John
Re: A12: Required Named Parameters Strike Back!
On 4/19/04 7:16 PM, Larry Wall wrote:
On Mon, Apr 19, 2004 at 01:44:53PM -0400, John Siracusa wrote:
: ...named and required, or named and optional? IOW, is this all true?
:
: sub foo(+$a, +$b) { ... }
:
: foo(); # compile-time error!
: foo(1, 2); # compile-time error!
: foo(a = 1, 2); # compile-time error!
: foo(a = 1);# compile-time error!
:
: foo(a = 5, b = 7); # ok
: foo(b = 1, a = 2); # ok
Well, no, we're still stuck at run-time validation of that. In the case
of methods you can't really do anything else anyway, generally speaking.
Why is that?
For subs, we could make the compiler pay attention to something in the
declaration:
sub foo(+$a is req, +$b is req) { ... }
sub foo(+$a = fail, +$b = fail) { ... }
But I still don't think it rates a strange character of its own.
I'd even be willing to type out is required. I just want the feature :)
The is fail technique looks slightly icky...
Possibly there's something going on with multi subs and invocants.
I'm not sure what 6.0.0 will make of a declaration like:
multi sub foo(+$a, +$b: +$c) { ... }
since we've told the Parrot people they don't have to worry about
anything but positional parameters for 6.0.0.
Can we do some magic behind the scenes that will make required named
params look positional to parrot?
-John
Re: A12: Required Named Parameters Strike Back!
On 4/19/04 9:05 PM, Damian Conway wrote:
You want:
sub foo(+$a is required, +$b is required) { ... }
Yes, that would be just fine :)
-John
Re: A12: default accessors and encapsulation
On 4/20/04 1:25 AM, Luke Palmer wrote:
John Siracusa writes:
The will STORE stuff covers the easy cases, but can I extend it all the
way up to a name() that's a multimethod with a ton of optional args? I
supposed you can (technically) do all of that with will STORE, but it
seems an odd place for what would more naturally be code in the name()
method itself.
I think a role on the attribute is not the right place to put it. What
you're doing is returning a proxy object that knows how to set both the
name and the gender.
That's a bit too example-specific. Really what I was getting at was
arbitrary, simple extensibility to do anything in response to $obj.foo
(with and without args) down the road, not just to do the specific thing
that I described in my example.
With a boring Perl 5 style get/set accessor API, I can just rewrite method
foo { } until the cows come home. I find that a lot more straight-forward
than the role playing you describe, but YMMV :)
-John
Re: A12: Required Named Parameters Strike Back!
On 4/20/04 10:42 AM, Dan Sugalski wrote:
At 9:50 AM -0400 4/20/04, John Siracusa wrote:
On 4/19/04 7:16 PM, Larry Wall wrote:
Well, no, we're still stuck at run-time validation of that. In the case
of methods you can't really do anything else anyway, generally speaking.
Why is that?
Because at compile time all you have is a generic thing, a (possibly
indirectly accessed) method name, and a list of parameters. There's
no good way to tell which method will ultimately be called, and
validating against all declared methods of that name won't get you
anything useful there since the result's likely going to be pretty
contradictory.
Hm, so how would the is required trait that Damian posted work? Would it
simply be shorthand for a run-time check that I don't have to write myself?
I was under the impression that it would work the way I described earlier:
sub foo(+$a is required, +$b is required) { ... }
foo(); # compile-time error!
foo(1, 2); # compile-time error!
foo(a = 1, 2); # compile-time error!
foo(a = 1);# compile-time error!
foo(a = 5, b = 7); # ok
foo(b = 1, a = 2); # ok
It really is a shame about the inability to do it at compile-time with
methods, but shorthand for a run-time check in that case would be welcome
too :)
-John
Re: A12: default accessors and encapsulation
On 4/20/04 2:37 PM, Larry Wall wrote: On Tue, Apr 20, 2004 at 01:15:24PM -0400, John Siracusa wrote: : With that has line alone, you auto-magically get an accessor that works : like this: : : $obj.foo# get value of $.foo : $obj.foo(5) # set $.foo = 5 I don't care what syntactic sugar you put underneath, but if you expose this interface to the user, it's fundamentally flawed. This is my argument from the Apocalypse, and it hasn't changed. It's wrong to introduce a fundamental asymmetry that breaks the contract that an accessor can be used as a variable. Er, I think we have different definitions of accessor. I'm perfectly happy to never allow anyone to do $obj.foo = whatever. I just don't want to write trivial methods that get and set an attribute behind the scenes. -John
Re: A12: default accessors and encapsulation
On 4/20/04 4:08 PM, Aaron Sherman wrote: On Tue, 2004-04-20 at 15:40, John Siracusa wrote: On 4/20/04 2:37 PM, Larry Wall wrote: It's wrong to introduce a fundamental asymmetry that breaks the contract that an accessor can be used as a variable. Er, I think we have different definitions of accessor. I'm perfectly happy to never allow anyone to do $obj.foo = whatever. I just don't want to write trivial methods that get and set an attribute behind the scenes. Eh? Why would you never allow anyone to use a simple syntax? $oldfoo = $obj.foo; $obj.foo = 1; What's the problem here? The problem is when foo() becomes a complex method some time in the future. It's some work to upgrade foo from a simple is rw attribute to a full-blown method while also maintaining the end user's ability to say $obj.foo = whatever. What Larry's trying to get at is that: $status = $thread_shared_data.status(lock=1); could be defined as a multi which gets the value of the status variable, but also asserts that thread synchronization or some form of threadsafe locking must be performed. You're not SETTING status, you're reading it, but you are passing parameters to the read accessor. How do you do that if parameters force a write? If that's your situation, you can make status() a getter only and add a set_status() setter. Or you could make foo() say if I get a single scalar (i.e. non-pair) arg, then set, otherwise get with options. But maybe that's as evil to some people as writing trivial get/set accessors is to me :) -John
A12: Required Named Parameters Strike Back!
Those with encyclopedic knowledge of the perl6-language list will recall my
impassioned, but ultimately futile plea for required named parameters--that
is, required arguments to a function that must be supplied as pairs rather
than positionally.
Here's a post from the middle of that old thread:
http://www.nntp.perl.org/group/perl.perl6.language/14689
Okay, so no one seemed to buy my argument the last time around, but now I'm
reading A12 and I see things like this:
http://www.perl.com/pub/a/2004/04/16/a12.html?page=7#the_default_constructor
The arguments for the default constructor are always named arguments, hence
the *%_ declaration to collect all those pairs and pass them on to bless.
http://www.perl.com/pub/a/2004/04/16/a12.html?page=9#multi_submethod_build
It is not likely that Perl 6.0.0 will support multiple dispatch on named
arguments, but only on positional arguments. Since all the extra arguments to
a BUILD routine come in as named arguments, you probably can't usefully multi
a BUILD (yet).
These passages may not seem directly relevant to my earlier argument, but I
think they do add something to the topic.
The first one confuses me a bit. The default constructor has a *%_
signature, which means it slurps up all the named parameters. It's obvious
that the default constructor is only interested in named params, but the
signature doesn't really enforce this, AFAICT. If I call a default
constructor like this:
$dog = Dog.new(name = 'Fido', age = 7, 2, 'Brown', Collar.new());
then Perl 6 won't say boo at either compile time or runtime. Or maybe I'm
wrong, but either way this isn't really an argument for required named
params since there are no required args to the default constructor anyway.
But I'm getting there (I hope), so bear with me :)
I'm not sure what the above would do, assuming the default new() doesn't
have a [EMAIL PROTECTED] term waiting at end of its signature to slurp up the args 7,
'Brown', and Collar.new(). Would those args just be ignored? And what if
it was called like this?
$dog = Dog.new(2, name = 'Fido', age = 7, 'Brown', Collar.new());
Is that a compile-time or runtime error? Hm. Anyway, let's move on.
Let's supposed that I don't like the default constructor and want to replace
it with one of my own. I decode that an object of my Dog class cannot be
instantiated without a name, age, and id. But being a good Perl 6 citizen,
I document the usage of my constructor like this:
$dog = Dog.new(name = 'Fido', age = 7, id = 2);
After all, according to A12, arguments for the default constructor are
always named arguments, so I'm trying to follow suit. I don't want my
customized constructor to be needlessly different than the default
constructor. Unfortunately, the signature for my constructor has to be:
method new($name, $age, $id, *%rest) { ... }
which means that, regardless of how I document the API, someone can do this:
$dog = Dog.new('Fido', 2, 7);
and there's nothing I can do to stop them.
...so, did you catch the fact that the second example is a two year-old dog
instead of a seven year-old dog? Maybe, maybe not, which is part of why I,
as the API designer, decided that those params should named.
Even more importantly, I decided to use named params because there's no
natural or implied order for the name, age, and id attributes. It's
completely arbitrary.
Okay, so it's arbitrary. Then why can't I just maintain that arbitrary
order forever and ever? In fact, if I do nothing, it will be maintained.
So what's the problem?
Yes, the answer is that it's the principle. Name, age, and id are
required, but there is no implied order. I want them to be named params. I
am the API designer. I think it will reduce errors and make code that uses
my Dog object easier to read and maintain.
It's not as if I'm forbidding Dog users from using the indirect object
syntax or something like that. My demands are modest, useful, and
certainly no more onerous or BD-esque than choosing method names or
deciding which arguments are required or any of the other things that an API
designer does.
Obviously the Perl 6 Language Design Illuminati have at least a few thoughts
in a similar direction. The arguments for the default constructor are
always named arguments because constructors often initialize lots of
attributes, and those attributes rarely have a natural or implied order.
Constructors just plain look and work better with named params. (The only
possible exception is a special-case for a single argument.)
But, ha ha, that's too bad if you also decide that some of the constructor
params are required! Even if nothing has changed about the lack of a
natural or implied order of the arguments, you, as the API designer, are
forced to both *choose* and *maintain forever* an arbitrary order for your
params!
I think this is a bad thing.
This may seem like it has turned into just a repeat of the Synopsis 6
discussion, but I wanted to
Re: A12: Required Named Parameters Strike Back!
On 4/19/04 1:30 PM, Larry Wall wrote:
On Mon, Apr 19, 2004 at 01:14:57PM -0400, John Siracusa wrote:
: I know we are running out of special characters, but I really, really think
: that required named parameters are a natural fit for many common APIs. A12
: has reinforced that belief. Save me, Dami-Wan Wallnobi, you're my only
: hope...
Well, actually, we saved you last summer when we decided to make +
mean that the parameter must be named.
...named and required, or named and optional? IOW, is this all true?
sub foo(+$a, +$b) { ... }
foo(); # compile-time error!
foo(1, 2); # compile-time error!
foo(a = 1, 2); # compile-time error!
foo(a = 1);# compile-time error!
foo(a = 5, b = 7); # ok
foo(b = 1, a = 2); # ok
-John
A12: default accessors and encapsulation
Let's say I have a class with some attributes: class Dog; has $.name is rw; has $.age is rw; has $.gender is rw; I initially decide to accept the default accessors. $dog.name = 'Ralph'; print $dog.age; This works well for a while, but then I decide to update Dog so that setting the name also sets the gender. $dog.name = 'Susie'; # also sets $dog.gender to 'female' How do I write such a name() method? Do I just check the arg, set the gender, and then return $.name as an lvalue or something? If so, what happens if, some time down the road, the $.name attribute goes away entirely? I can't return it as an lvalue now, can I? Basically, I'm wondering how much of the object's internals I'm exposing by accepting the default accessors. -John
Re: A12: Naming Police - P6opaque
On 4/19/04 3:36 PM, Larry Wall wrote: On Mon, Apr 19, 2004 at 02:04:55PM -0400, John Siracusa wrote: : So, how about Perl6opaque (or Perl6Opaque), just to be safe :) How 'bout just Opaque, meaning Parrot's native object type, or whatever the native opaque type is for the platform in question. But I really don't care, as long as I have the 0 shortcut. I'm disappointed that you didn't suggest 0paque ;) I'm fine with Opaque too. I just object to needless (and possibly ambiguous) abbreviation. -John
Re: A12: default accessors and encapsulation
On 4/19/04 3:58 PM, Austin Hastings wrote:
I initially decide to accept the default accessors.
$dog.name = 'Ralph';
print $dog.age;
This works well for a while, but then I decide to update Dog so that setting
the name also sets the gender.
$dog.name = 'Susie'; # also sets $dog.gender to 'female'
How do I write such a name() method?
has $.name is rw
will STORE { .set_name($^name); };
The will STORE stuff covers the easy cases, but can I extend it all the
way up to a name() that's a multimethod with a ton of optional args? I
supposed you can (technically) do all of that with will STORE, but it
seems an odd place for what would more naturally be code in the name()
method itself.
You can leave the name attribute around as a placeholder and let the STORE
block update the official location, or you could return some sort of
proxy-lvalue object that wasn't really a part of Dog
Heh, getting progressively more scary :)
From the point of view of the person coding the new, fancier name() method,
it would be nice if some magic would make all existing calls to
$dog.name = 'foo';
look like this inside the new name() method
$dog.name('foo');
but I supposed that really hoses the meaning of = :)
The alternate techniques suggested are powerful, but they also strike me as
slightly heroic. I can imaging using them to patch or extend some existing
code, but starting a Perl 6 class from scratch, I'd really have to think
about the costs of using the default accessors at all.
One work-around might be an alternate kind of default accessor that doesn't
allow assignment:
$dog.name # get
$dog.name('foo') # set
$dog.name = 'foo' # compile-time error
That is a lot more directly (and simply) future-proof than the is rw
accessor.
I'd either like a way to more cleanly extend the default accessor's
assignment behavior down the road (i.e. by just writing a new name() method,
not by hacking away at STORE traits and adding private worker subs) or a way
to auto-generate the slightly more boring default accessor shown above.
I'd prefer the former since I'm hoping to avoid the likes of
Class::MethodMaker as long as possible in the world of Perl 6 :)
In the absence of both, I can imaging that 5 years into the life of 6PAN, a
substantial portion of the Perl 6 modules will have STORE hooks on what they
originally thought would be simple attributes that don't need full-blown
accessors... :)
-John
Re: A12: default accessors and encapsulation
On 4/19/04 4:47 PM, [EMAIL PROTECTED] wrote:
On 4/19/04 3:58 PM, Austin Hastings wrote:
One work-around might be an alternate kind of default accessor that doesn't
allow assignment:
$dog.name # get
$dog.name('foo') # set
$dog.name = 'foo' # compile-time error
I think we already have this. Just define a non-rw attribute and then
add your own writer as a multi-method.
has Str $.name;
multi method name(Str $n) {$.name = $n;}
Yeah, that's exactly what I don't want to type over and over :) It's not
much better than the old Perl 5 standby:
sub name { @_ 1 ? $_[0]-{'name'} = $_[1] : $_[0]-{'name'} }
since once I have to write something, the time and effort savings is pretty
much cancelled out.
-John
Re: Apocalypse 12
On 4/17/04 6:22 AM, Piers Cawley wrote: chromatic [EMAIL PROTECTED] writes: Warning -- 20 pages, the first of which is a table of contents. But it's all excellent good stuff. Well done Larry and Co. Now, if you could all just hold off with the questions 'til Monday you'll make a summary writer's life a good deal easier. Putting it off will only make things worse for you later! ;) I have many A12 questions and comments in the queue, but alas I am busy this weekend so you're safe for now... -John
Re: Load paths
On 3/24/04 1:58 PM, Brent 'Dax' Royal-Gordon wrote: And I do think URIs aren't a horrible idea, although it doesn't matter since you disagree. Ah well... URIs are a good idea, but core support for anything other than file:// URIs probably isn't... :) Anyway, if you use URIs, then you can be like every badly behaved OS vendor and start making up your own crazy URI schemes: filehandle://, pmc://, sharedmem:// (Okay, maybe it's not such a good idea after all... :) -John
Re: Mutating methods
On 3/11/04 4:04 PM, Larry Wall wrote: On Thu, Mar 11, 2004 at 12:43:22PM -0800, Larry Wall wrote: : Which is precisely the problem with something like : : $a cmp= $b : : insofar as $a is being treated as a string at one moment and as a boolean : at the next. Well, okay, not a boolean. More like a troolean. Back in my daaa, we used to call that a scalar. And we liked it, because it was all we had! ;) -John
Re: Dates and Times
On 3/4/04 5:09 PM, Dan Sugalski wrote: If the local system returns localtime, I can see adjusting to GMT or UTC, or whatever, as that ought to be a trivial transform. Er, I'm not so sure about that. That means you'd have to be 100% sure that you can determine the local timezone without any ambiguity. That has not proven to be the case if the DateTime.pm project is any indication... -John
Re: This week's summary
On 1/5/04 1:55 PM, Lars Balker Rasmussen wrote: The Perl 6 Summarizer [EMAIL PROTECTED] writes: I confess I wouldn't be surprised if, by the end of the year, we haven't seen the full implementation of at least one of the big non-Perl scripting languages on top of Parrot. I'm confused, are you optimistic or pessimistic in that last sentence? I'm not not licking toads... (Hey, the list needs traffic ;) -John
Re: E6 question
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 this...
On 8/1/03 5:52 PM, Damian Conway wrote:
Probably.
...is encouraging :)
I think that the '?', '*', and '+ prefixes are abbreviations for
traits (Cis optional, Cis List, Cis optional is named). So
a named, mandatory parameter would be:
sub foo($bar is named) {...}
Good, but a single-letter prefix would also be nice :)
Alternatively, you could just specify a mandatory parameter that has to be a
Pair:
sub foo(Pair $bar) {...}
(though then you'd have to use C$bar.value for the value).
Ick.
-John
Perl 6's for() signature
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 that I can't quite put my finger on, I'm not quite sure that either method has got the sub signature quite right, and I'm not entirely sure how you would express for's signature as a Perl 6 signature anyway. Answers on a mailing list please. Did this ever get resolved to anyone's satisfaction? While reading EX6, I found myself wonder exactly what for() would look like in Perl 6 code... -John
Re: Wrappers vs. efficiency - quick comment
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'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 wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) I don't see how a sub being inline-able prevents being wrap-able. I did say may... :) (anyway, my original point still stands) -John
Wrappers vs. efficiency - quick comment
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 wrappable subs, and then turn that off with specific declarations for speed, such as is inline. I think there's a lot of room between allow this subroutine to be wrapped and inline this subroutine. Whatever the specific declaration for speed is that forbids runtime wrapping of a subroutine, it should not be spelled inline. (although inline may imply dontwrapmeplease or whatever :) -John
Re: Disappearing code
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) 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 global (constant)
somewhere. Maybe that same off bit could be set from a distance at
compile time?
That would be the if a flag is set part. Point is, its easily handled
by some sort of subroutine attribute which looks at some flag somewhere.
Well, er, don't we need to decide what the subroutine attribute is, so that
the compiler will know to honor it and make the code disappear? It
doesn't seem like a feature that can be added from userland after the fact
(but maybe I'm wrong...)
-John
Re: Disappearing code
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 of the spiritual equivalent of #ifdef, only Perlish. If the perl6 command-line options are anything like perl5 then you can just use the -P switch if preprocessor commands are your thing. Source filtering is not exactly the solution I'm looking for... :) -John
Re: Disappearing code
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 Cdebug is in the example above) causes the immediate sub call to be replaced -- during compilation! -- by the returned closure/block. Voila! Perl 6 is its own macro language. Sweet :) -John
Disappearing code
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 wanted to do was write code like this: debug(Doing foo with $bar and $baz); foo($bar, $baz); And then have the entire call to debug() just plain disappear when the program was run with a certain flag, or when a particular constant was set, or whatever. The closest we got in Perl 5, AFAIK, was stuff this: use constant DEBUG = 0; ... debug(Doing foo with $bar and $baz) if DEBUG; foo($bar, $baz); But all those if DEBUGs or DEBUG s were a pain. So I'm wondering what the solution will be in Perl 6. -John
Re: Disappearing code
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 guessing you'll still get
the function call to debug().
But it's a negligible overhead anyway.
Hey, it adds up! Okay, maybe it doesn't...but still, Perl 6 Should Be Able
To Do This! :) And I'd also like inline constructs like:
ASSERT $foo 5 is_happy(blah);
that may or may not be the same as the debug situation in Perl 6.
I don't see how you could do much without actually labeling what you
wanted to disappear.
I basically want a language-level guarantee that the call to debug()
disappears entirely under certain conditions. I don't want to have to rely
on details of the optimizer or whatever.
-John
Re: Disappearing code
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 global (constant)
somewhere. Maybe that same off bit could be set from a distance at
compile time?
-John
Re: Comparing Object Identity
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-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 the typical fashion.
I still feel like we're talking past each other here. What I was saying is
that, regardless of any admonitions to the contrary, I think people will
still write this:
$a.id == $b.id
and expect it to compare memory addresses.
And presumably, anyone who overrides .id in their own class knows what
they're doing. They, in fact, Iwant statements like that to behave
that way.
I think you're missing my point. I'm saying that there are many kinds of
objects that naturally want to have an id method or attribute that has
nothing whatsoever to do with this is the same object comparisons. But if
id is chosen as the name of the global this is the same object method in
Perl 6, then no one can safely use a method named id (overridden or
otherwise) for anything but this is the same object comparisons.
I think this is a bad idea because this is the same object comparisons are
relatively rare, and do not deserve to be hogging the short, direct method
name of id.
Example: Instead of getting a user id via $user.id and a product id via
$product.id, Perl 6 programmers will be forced to mark-up their methods
names ($user.uid, $product.pid) and then deal with the differences in any
heterogeneous collection:
# Too bad the method named id is taken by a value that
# you're rarely interested in, huh :P
for @users, @products, @transactions, @mixed - $thing
{
print $thing.type, id ;
given $thing.type
{
when 'user'{ print $thing.uid }
when 'process' { print $thing.pid }
when 'transaction' { print $thing.tid }
...
}
print \n;
}
As opposed to:
# Ah, blessed sanity...
for @users, @products, @transactions, @mixed - $thing
{
print $thing.type, id , $thing.id, \n;
}
(Yes, you could just decide that all your objects will use oid or
something else, but that would be another symptom of the problem: Perl 6 is
forcing you to (slightly) obfuscate your code. Your first thought was to
simply use the well understood name id like you always have, but you're
out of luck.)
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/attribute should have a name that reflects the relative rarity of its
use.
-John
Re: Comparing Object Identity [x-adr][x-bayes]
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/attribute should have a name that reflects the relative rarity of its use. Other common names for the proposed .id are: UUID: Universal Unique Identifier (DCE) http://www.opengroup.org/onlinepubs/9629399/apdxa.htm GUID: Globally Unique Identfier (EFI) http://ulita.ms.mff.cuni.cz/pub/techdoc/ia64/EFISpec_092.pdf (page 319) Of the 2, usage of GUID seems to be more common IMHO. Both of the above are identical in implementation. And won't rollover until 3400AD ;) ...and if we also (or instead) want to have a universal method for getting Perl 5-style memory address hashes (FOO(0x12345)), then that should have a name without the phrase or idea of identifier anywhere in it, IMO: memhash, memaddr, etc. -John
Re: Comparing Object Identity
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.) If that'd require that an object's ID be a combination of the header address and a generation counter, that's OK. It means a serilization point in the allocator, but I think we'd need one no matter what (Dan?). I'm more worried about storing them than creating them. The good thing about using memaddresses is that they're free; you don't need to store a separate ID in each and every object you ever create, on the off chance that something will want to use it. Having an actual internal ID associated with every object would mean you'd have to store all those IDs, which could get very big very fast. You could always just autovivify them. Since most objects will never have their UUIDs accessed, the overhead should be very small. I think the odds of you wanting a truly unique ID for any given class are so low that we'd probably be better off leaving it as a DIY project. I think it's important enough to be in the core, if only to prevent fragmentation in the world of object persistence. -John
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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 must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. I'd argue that you'd better pick a better name than .id anyway. You wouldn't use .foo_id and .bar_id, you'd use .descriptor or .index (though that one's not too much more descriptive than .index). I'd say .id should be kept short and sweet, because it's going to be used on a wider variety of objects than your database .id. I use the id attribute of my database objects much more often than I compare object identities. IMO, common method names like id should be in the user's domain, to be used as is applicable to each kind of object. -John
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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.*id == $b.*id if you really need to get to Object.id(). That'll only work out if everyone always writes it as *id. If not, my Perl 6 objects that override id() won't work correctly with any other classes or functions that simply call id and expect it to really be *id But I suspect the reverse will happen. Everyone will just expect $a.id to be functionally the same as $a.*id, so no one will actually ever write $a.*id. And so I'm back to losing the ability to have id attributes on objects in Perl 6 that represent anything other than a place in memory, and back to my complaint about a system method hogging a common (IME) and sensible method name for many kinds of objects, using it to store information that is very infrequently accessed. Is one extra letter going to kill anyone? .uid? .oid? C'mon, throw me a bone here... :-} -John
Re: Comparing Object Identity (was: Re: Stringification of refere nces (Decision, Please?)) [x-adr][x-bayes]
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 the typical fashion. I still feel like we're talking past each other here. What I was saying is that, regardless of any admonitions to the contrary, I think people will still write this: $a.id == $b.id and expect it to compare memory addresses. That is not the typical fashion for an object method named id to work, IMO. The need to compare memory addresses is so infrequent that warrants a much less common and/or longer method name than id. -John
Re: Comparing Object Identity
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: [...] If memory addresses can change over time, then we need a more fundamental concept to act as the ID! Heh, it seems like you're supporting my position, but you're really not :) Whatever the this is the same object value actually is, I don't think it deserves to live under the method name id. -John
Re: Stringification of references (Decision, Please?)
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 other (debugging-related) strings, I think we're all basically happy. That implies, however, that we need at least two methods per type/class: AS_STRING, and AS_DEBUG, for lack of better names. By default, the first calls the second. Can we at least get something about strings in the name of the debug method? AS_STRING is pretty clear, but AS_DEBUG could mean a lot of things...and at first glance, it doesn't seem related to AS_STRING at all. Maybe AS_STRING and AS_STRING_DEBUG? Too long? DEBUG_STRING? Are we married to the AS_* thing? That naming scheme always seems too cute to me... (I also beg people to stop thinking about testing for equality/equivalence between two objects as being related to their stringification. You shouldn't be stringifying objects merely to test if they're the same object -- yuck. It was an artifact of Perl5 that we should be replacing.) So, what is the Perl 6 way to test this? -John
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
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 Cid method is *for*. I must have missed this (or forgotten it?) Any chance of it becoming .ID or .oid or even ._id? I'm kind of attached to using an id method on objects that represent things in a database... :-/ 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 must now have foo_id and bar_id methods because the (probably rarely used) id method from UNIVERSAL (or whatever it is today) is hogging it. (The more I think about it, the more I like some kind of reserved prefix like _ or even perl_...but I'd accept oid :) -John
