Re: Mutating methods
On Sat, 13 Mar 2004 05.30, John Siracusa wrote:
> The only case that seems even
> remotely onerous is this one:
>
> my My::Big::Class::Name $obj = My::Big::Class::Name.new();
> vs.
> my My::Big::Class::Name $obj .= new()
There's also the related issue of in-place operations on some
difficult-to-write lvalue:
@{$coderef.("argument").{hashelem}} =
sort @{$coderef.("argument").{hashelem}};
Did I get the text the same both times? What about maintaining that code?
What about side effects on the subroutine I called there?
Someone Damian-shaped will probably come in and point out how to prettify that
using "given", but it still wouldn't be as short as last week's
$coderef.("argument").{hashelem}.self:sort();
--
Debbie Pickett
http://www.csse.monash.edu.au/~debbiep
[EMAIL PROTECTED]
Re: Latin-1-characters
On 2004-03-13 at 09:02:50, Karl Brodowsky wrote: > For these guys Unicode is not so attractive, because it kind of doubles the > size of their files, Unicode per se doesn't do anything to file sizes; it's all in how you encode it. The UTF-8 encoding is not so attractive in locales that make heavy use of characters which require several bytes to encode therein, or relatively little use of characters in the ASCII range; but that's why there are other encoding schemes like SCSU which get you Unicode compatibility while not taking up much more space than the locale's native charset. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754
Re: Mutating methods
Deborah Pickett writes:
> Someone Damian-shaped will probably come in and point out how to prettify that
> using "given", but it still wouldn't be as short as last week's
>
> $coderef.("argument").{hashelem}.self:sort();
But that still has problems. What's the important thing in this
"sentence"? The way it's written, you'd think C<$coderef>, while the
correct answer (as I see it) is C.
Assuming we go with =sort as the sort mutator, this could be nicely
written:
=sort $coderef.("argument").{hashelem};
Using indirect-object syntax. Saying C (or C,
which I prefer) doesn't obscure it much.
Luke
hash subscriptor
On Wed, 10 Mar 2004, Larry Wall wrote:
> You subscript hashes with {...} historically, or these days, «...»,
> when you want constant subscripts. So what you're looking for is
> something like:
>
> if / ... ... { $?foo{'baz'} ... $?baz } .../
> or
> if / ... ... { $?foo«baz» ... $?baz } .../
I'm probably a bit behind on current thinking, but did %hash{bareword}
lose the ability to assume the bareword is a constant string?
And why «»? Last I heard, that was the unicode version of qw(), which
returns an array. Using an array constructor as a hash subscriptor is
not a "least surprise" to me.
~ John Williams
RE: Mutating methods
> This brings me to another "idea" I have.. although I have a feeling you guys
> have already thought of it.
>
> Instead of ...
> $x = $a + $b + $c + $d;
> How about ...
> $x = +«$a $b $c $d»
The closest way to what you have written is this:
$x = 0;
$x »+=« ($a, $b, $c, $d);
Or the slightly less attractive (IMHO) syntax invented recently:
$x +=« ($a, $b, $c, $d);
Of course, perl6 will have a built-in reduce function as well (RFC76):
$x = reduce {$^a + $^b} $a, $b, $c, $d;
~ John Williams
Re: Mutating methods
On Mon, Mar 15, 2004 at 12:10:40PM -0700, John Williams wrote: : Or the slightly less attractive (IMHO) syntax invented recently: : : $x +=« ($a, $b, $c, $d); The latest guess is that we're not using lopsided ones for binary ops, but only for unary ops. Larry
Re: Mutating methods
On Sat, Mar 13, 2004 at 12:03:35AM +0200, arcadi shehter wrote:
: some time in the past there was a talk about ... ?? ... :: ... operator being
: a combination of two binary : ?? and :: . But I dont know the ruling.
: If one factorize trinary ??:: to two binary operators,
: ?? could act a postfix topicalazer while :: becomes binary
: operator :
: $a :: $b evaluates to left or right argument according to true/false property of
the _current topic_
: something like infix:::($a,$b){ given CALLER::_ { when .true return $a ; return $b
} but it evaluate $b only
: if necessary.
By that argument, ordinary "if" should topicalize, and I don't think
we should be confusing boolean evaluation with topicalization.
Conditionals are so often "smaller" than the current topic.
We shouldn't force topicalizing on what is essentially a bit. Usually
it's some minor aspect of the current topic that we're testing,
and narrowing the scope of the topic is not what the user will want
or expect.
Larry
Re: Mutating methods
On Fri, Mar 12, 2004 at 03:47:57AM -0500, Austin Hastings wrote:
: > -Original Message-
: > From: Larry Wall [mailto:[EMAIL PROTECTED]
: > On Thu, Mar 11, 2004 at 11:38:11AM +, Andy Wardley wrote:
: > : Larry Wall wrote:
: > : > multi sub *scramble (String $s) returns String {...}
: > : [...]
: > : > Or you can just call it directly as a function:
: > : > scramble("hello")
: > :
: > : Can you also call scramble as a class method?
: > :
: > : class String is extended {
: > : method scramble { ..etc... }
: > : }
: > :
: > : String.scramble("hello")
: >
: > Not unless you write a class method that takes an extra argument.
: > Otherwise you're passing a class where it expects a string, and a
: > string where it expects nothing. However, much like in Perl 5 you
: > can always force which class's method to call with
: >
: > "hello".String::scramble();
:
: But it would work as a "class multi", right?
:
: class String is extended {
: multi scramble(String $s) {...}
: }
You probably have to decide whether that's a multi sub or a multi method,
at least syntactically. Though it may not matter which you pick because...
: "hello".scramble();
: String::scramble("hello"); # Way overspecified for a multi...
For a single argument function, those probably come out to the same thing
in the end. With more arguments you have to start distinguishing single
dispatch from multiple dispatch.
Larry
Re: Operators that keep going and going...
On Sun, Mar 14, 2004 at 05:38:33PM -0500, Matt Creenan wrote: : It just goes to show.. the perl community has already thought of : everything.. Plus a few things beyond everything, if you're into surreal numbers. Larry
Re: Compile-time undefined sub detection
On Sat, Mar 13, 2004 at 08:39:02PM +0100, James Mastros wrote: : Larry Wall wrote: : >And how would it differ from END? You can't predict when the last : >time a module is going to get used... : : Unless we support an explicit unload action on modules. This seems : highly useful for long-running processes. (I don't think making them : DODable is useful, since there's no way to tell if a future eval STRING : (or equiv) might be useful.) Then the explicit unload can call an explicit routine in the module for cleanup, I suspect. We don't really need a special name for it in the language, except perhaps to set something up by convention. We might not even need that if we require an unloadable module to register its unloadability, in which case the module can pass a closure to be called back at unload time. Larry
Re: Compile-time undefined sub detection
On Mon, Mar 15, 2004 at 12:30:51PM -0800, Larry Wall wrote:
: On Sat, Mar 13, 2004 at 08:39:02PM +0100, James Mastros wrote:
: : Larry Wall wrote:
: : >And how would it differ from END? You can't predict when the last
: : >time a module is going to get used...
: :
: : Unless we support an explicit unload action on modules. This seems
: : highly useful for long-running processes. (I don't think making them
: : DODable is useful, since there's no way to tell if a future eval STRING
: : (or equiv) might be useful.)
:
: Then the explicit unload can call an explicit routine in the module
: for cleanup, I suspect. We don't really need a special name for it
: in the language, except perhaps to set something up by convention.
: We might not even need that if we require an unloadable module to
: register its unloadability, in which case the module can pass a closure
: to be called back at unload time.
Okay, to be perfectly fair, that registration might then look exactly
like a funny block:
UNLOAD {...}
Larry
Re: Mutating methods
On Fri, Mar 12, 2004 at 05:32:33AM -0500, Austin Hastings wrote:
: Boo, hiss.
:
: Two things:
:
: 1- I'd rather use "inplace" than self.
What is this "place" thing? I want the object to do something to itself
reflexively, which may or may not involve places...
: 2- I'd rather it be AFTER, than BEFORE, the name, because
:
: method sort
: method sort:inplace
:
: reads, and more importantly SORTS, better than
:
: method inplace:sort
: method sort
Well, that's a point that has some weight, but...
: To wit:
:
: method :infix:<=>(Array, Array) returns Scalar
: method :infix:==(Array, Array) returns Boolean
: method :infix:!=(Array, Array) returns Boolean
: method :infix:===(Array, Array) returns Boolean
: method :infix:!==(Array, Array) returns Boolean
: method :infix:x(Array) returns Array
: method :infix:x:inplace(Array is rw)
:
: ### Note: How to handle [undef]? return-undef, or PHP-like push?
: method :postfix:[](Array is rw, ?Scalar) returns Scalar
:
: ### Inplace-only?
: method clear(Array is rw) returns Boolean
:
: method compact(Array) returns Array
: method compact:inplace(Array is rw)
: ### Inplace-only?
: method delete(Array is rw, Int) returns WHAT, exactly?
:
: method difference(Array, Array) returns Array #A-B
: method differences(Array, Array) returns Array #(A-B) + (B-A)
: method exists(Array, Scalar) returns Boolean
: method flatten(Array) returns Array
: method flatten:inplace(Array is rw) returns Array
: method grep(Array, Code) returns Array
: method includes(Array, Scalar) returns Boolean
: method index(Array, Scalar) returns Int
: method intersect(Array, Array)
: method is_empty(Array) return Boolean
: method join(Array, String)
: method length(Array)
: method map(Array, Code) returns Array
: method pack(Array, String) returns String
: method reverse(Array) returns Array
: method reverse:inplace(Array is rw)
: method rindex(Array) returns Int
:
: ### Boy are these likely to be wrong!
: method sort(Array, ?Code) returns Array
: method sort:inplace(Array is rw, ?Code)
:
: ### Inplace-only?
: method splice(Array is rw, ?Int, ?Int, ?Array)
:
: method union(Array, Array) returns Array
: method unique(Array) returns Array
: method unique:inplace(Array is rw)
:
: ### Inplace-only?
: multi method fill(Array is rw, Scalar, Int, Int)
: multi method fill(Array is rw, Scalar, Int)
: multi method fill(Array is rw, Scalar, Array)
: ### Inplace-only?
: multi method pop(Array is rw, ?Int) returns Array
: multi method pop(Array is rw) returns Scalar
: ### Inplace-only?
: multi method unshift(Array is rw, Scalar) returns Array
: multi method unshift(Array is rw, Array) returns Array
: ### Inplace-only?
: multi method push(Array is rw, Array) returns Array
: multi method push(Array is rw, Scalar)
: ### Inplace-only?
: multi method shift(Array is rw, Int) returns Array
: multi method shift(Array is rw) returns Scalar
:
: multi sub each(Array) returns Iterator # HOW does this work?
But you can put the declarations in whatever order you want regardless
of the default collation order, so this is kind of a weak argument unless
you're writing a tool, in which case you could certainly ignore whatever
prefixes you like when you sort.
: (Note also that :...fix sorts better than in-, post-, and pre-. I'd like to
: suggest changing
: them, since it costs nothing and results in a mild improvement in automation
: behavior.)
The main reason those are out front is to reduce grammatical ambiguity
when you use an operator sub name where a term is expected. That is,
it's harder to parse:
$x = +:foo();
correctly than
$x = foo:+();
Even with sort:inplace, how does the parser know that the name is
"sort:inplace", or whether the user is trying to pass a pair :inplace
to the "sort" routine? The foo:-style prefixes are "reserved" in
general, but the :foo pair is not, and it would be a mistake to start
introducing reserved pairs, I think, much like the Perl 5 problem
that ARGV is truly global while ARGH is not.
: > > Another interesting question, if the "postfix:.=foo" mess is defined
: > > with as self:foo, should infix:+= be defined as self:+ instead?
: > > In other words, should the = syntax really be a metasyntax like
: > > hyperoperators, where you never actually have to define a C<»+«>
: > > operator, but the hyperoperator is always autogenerated from ordinary
: > > C<+>? So basically any infix:= gets remapped to self:.
: >
: > I think that would be cleaner.
:
: Alternatively, is there a valid reason to *need* to define your own
: hyperoperator?
:
: That is, can you code C< @a +« $x > better than C< @a.map {return $_ + $x}
Re: Compile-time undefined sub detection
At 12:30 PM -0800 3/15/04, Larry Wall wrote: On Sat, Mar 13, 2004 at 08:39:02PM +0100, James Mastros wrote: : Larry Wall wrote: : >And how would it differ from END? You can't predict when the last : >time a module is going to get used... : : Unless we support an explicit unload action on modules. This seems : highly useful for long-running processes. (I don't think making them : DODable is useful, since there's no way to tell if a future eval STRING : (or equiv) might be useful.) Then the explicit unload can call an explicit routine in the module for cleanup, I suspect. That's going to be the only way to reasonably unload a module, and even then there'll be some interesting repercussions. Like... what happens when you unload a module with instantiated objects? How can you tell if there are secondary modules that need unloading? Does unloading actually unload, or just remove as many links to the module as we can and we then unload it when the last real reference to it goes away? Can we *re*load a module that's been unloaded? (The answer to that last one's no, for some modules that load in external libraries) It's an interesting problem. Modules leave debris around which can make it difficult to properly deal with, and allowing them to be unloaded requires a fair amount of thought. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Latin-1-characters
Mark J. Reed wrote: Unicode per se doesn't do anything to file sizes; it's all in how you encode it. Yes. And basically there are common ways to encode this: utf-8 and utf-16 (or similar variants requiring >= 2 bytes per character) The UTF-8 encoding is not so attractive in locales that make heavy use of characters which require several bytes to encode therein, or relatively little use of characters in the ASCII range; utf-8 is fine for languages like German, Polish, Norwegian, Spanish, French,... which have >= 90% of the text with ASCII-7-bit-characters. but that's why there are other encoding schemes like SCSU which get you Unicode compatibility while not taking up much more space than the locale's native charset. These make sense for languages like Japanese, Korean, Chinese etc, where you need more than one byte per character anyway. But Russian, Greek, Hebrew, Arabic, Armenian and Georgian would work fine with one byte per character. But the kinds of of encoding that I can think of both make this two bytes per character. So for these I see file sizes doubled. Or do I miss something? Anyway, it will be necessary to specify the encoding of unicode in some way, which could possibly allow even to specify even some non-unicode-charsets. IMHO the OS should provide a standard way to specify such a charset as a file attribute, but usually it does not and it won't in the future, unless the file comes through the network and has a Mime-Header. Best regards, Karl
Re: Latin-1-characters
At 12:28 AM +0100 3/16/04, Karl Brodowsky wrote: Anyway, it will be necessary to specify the encoding of unicode in some way, which could possibly allow even to specify even some non-unicode-charsets. While I'll skip diving deeper into the swamp that is character sets and encoding (I'm already up to my neck in it, thanks, and I don't have any long straws handy :) I'll point out that the above statement is meaningless--there *are* no Unicode non-unicode charsets. It is possible to use the UTF encodings on non-unicode charsets--you could reasonably use UTF-8 to encode, say, Shift-JIS characters. (where Shift-JIS is both an encoding and a character set, and it can be separated into pieces) It's not unwise (and, in practice, at least in implementation quite sensible) to separate the encoding from the character set, but you need to be careful to keep the separation clear, though many of the sets and encodings don't go out of their way to help with that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Latin-1-characters
At 11:36 PM + 3/15/04, [EMAIL PROTECTED] wrote: Another possibility is to use a UTF-8 extended system where you use values over 0x10 to encode temporary code block swaps in the encoding. I.e., some magic value means the one byte UTF-8 codes now mean the Greek block instead of the ASCII block. You could do that, but then I'd be forced to do something well and truly horrible to you, and we'd rather not have that. :) Character set and encoding are metadata, and ought be stored out-of-band, at least once the data makes it into your program. Twiddling the internal representation of the bytes is a fairly sub-optimal way to do that, so I'd as soon not mandate that we have to. (I do dislike publically breaking mandates like that. Terribly inconvenient) > At 12:28 AM +0100 3/16/04, Karl Brodowsky wrote: >Anyway, it will be necessary to specify the encoding of unicode in >some way, which could possibly allow even to specify even some >non-unicode-charsets. While I'll skip diving deeper into the swamp that is character sets and encoding (I'm already up to my neck in it, thanks, and I don't have any long straws handy :) I'll point out that the above statement is meaningless--there *are* no Unicode non-unicode charsets. It is possible to use the UTF encodings on non-unicode charsets--you could reasonably use UTF-8 to encode, say, Shift-JIS characters. (where Shift-JIS is both an encoding and a character set, and it can be separated into pieces) It's not unwise (and, in practice, at least in implementation quite sensible) to separate the encoding from the character set, but you need to be careful to keep the separation clear, though many of the > sets and encodings don't go out of their way to help with that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Mutating methods
- Original Message -
From: "Deborah Pickett" <[EMAIL PROTECTED]>
To: "Perl 6 Language" <[EMAIL PROTECTED]>
Sent: Sunday, March 14, 2004 10:44 PM
Subject: Re: Mutating methods
> On Sat, 13 Mar 2004 05.30, John Siracusa wrote:
> > The only case that seems even
> > remotely onerous is this one:
> >
> > my My::Big::Class::Name $obj = My::Big::Class::Name.new();
> > vs.
> > my My::Big::Class::Name $obj .= new()
>
> There's also the related issue of in-place operations on some
> difficult-to-write lvalue:
>
> @{$coderef.("argument").{hashelem}} =
> sort @{$coderef.("argument").{hashelem}};
>
> Did I get the text the same both times? What about maintaining that code?
> What about side effects on the subroutine I called there?
>
> Someone Damian-shaped will probably come in and point out how to prettify
that
> using "given", but it still wouldn't be as short as last week's
>
> $coderef.("argument").{hashelem}.self:sort();
Why not just do
@{$_} = sort @{$_} given $coderef.("argument").{hashelem};
Joe Gottman
Re: hash subscriptor
On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
: On Wed, 10 Mar 2004, Larry Wall wrote:
: > You subscript hashes with {...} historically, or these days, «...»,
: > when you want constant subscripts. So what you're looking for is
: > something like:
: >
: > if / ... ... { $?foo{'baz'} ... $?baz } .../
: > or
: > if / ... ... { $?foo«baz» ... $?baz } .../
:
: I'm probably a bit behind on current thinking, but did %hash{bareword}
: lose the ability to assume the bareword is a constant string?
It's thinking hard about doing that. :-)
: And why «»? Last I heard that was the unicode version of qw(), which
: returns an array. Using an array constructor as a hash subscriptor is
: not a "least surprise" to me.
We'd be trading that surprise for the surprise that %hash{shift} doesn't
call C. Plus we get literal hash slices out of it for free.
Plus it also works on pair syntax :foo«some literal words». And probably
trait and property syntax as well.
And basically because I decided :foo('bar') is too ugly for something
that will get used as often as switches are on the unix command line.
The %hash syntax is just a fallout of trying to be consistent with
the pair notation. Once people start seeing :foo«bar» all over,
they won't find %hash«bar» surprising at all, and will appreciate the
self-documenting literalness of argument.
And unfortunately it's an unavoidable part of my job description to
decide how people should be surprised. :-)
Larry
Re: Compile-time undefined sub detection
On Mon, Mar 15, 2004 at 04:22:27PM -0500, Dan Sugalski wrote: : That's going to be the only way to reasonably unload a module, and : even then there'll be some interesting repercussions. Like... what : happens when you unload a module with instantiated objects? How can : you tell if there are secondary modules that need unloading? Does : unloading actually unload, or just remove as many links to the module : as we can and we then unload it when the last real reference to it : goes away? Can we *re*load a module that's been unloaded? (The answer : to that last one's no, for some modules that load in external : libraries) : : It's an interesting problem. Modules leave debris around which can : make it difficult to properly deal with, and allowing them to be : unloaded requires a fair amount of thought. Which is all good reason to assume a module is not unloadable unless it declares its intent to be unloadable--and then it's just on a "best effort" basis. "Best effort" is one of those phrases that doesn't mean what it means... Larry
Re: Mutating methods
On Mon, Mar 15, 2004 at 08:36:23PM -0500, Joe Gottman wrote:
:
: - Original Message -
: From: "Deborah Pickett" <[EMAIL PROTECTED]>
: To: "Perl 6 Language" <[EMAIL PROTECTED]>
: Sent: Sunday, March 14, 2004 10:44 PM
: Subject: Re: Mutating methods
:
:
: > On Sat, 13 Mar 2004 05.30, John Siracusa wrote:
: > > The only case that seems even
: > > remotely onerous is this one:
: > >
: > > my My::Big::Class::Name $obj = My::Big::Class::Name.new();
: > > vs.
: > > my My::Big::Class::Name $obj .= new()
: >
: > There's also the related issue of in-place operations on some
: > difficult-to-write lvalue:
: >
: > @{$coderef.("argument").{hashelem}} =
: > sort @{$coderef.("argument").{hashelem}};
: >
: > Did I get the text the same both times? What about maintaining that code?
: > What about side effects on the subroutine I called there?
: >
: > Someone Damian-shaped will probably come in and point out how to prettify
: that
: > using "given", but it still wouldn't be as short as last week's
: >
: > $coderef.("argument").{hashelem}.self:sort();
:
:
:Why not just do
: @{$_} = sort @{$_} given $coderef.("argument").{hashelem};
Er, let me guess. Because it still wouldn't be as short as last week's
$coderef.("argument").{hashelem}.self:sort();
maybe? :-)
My other guesses are: the end-weight problem, the forward reference
on the multiple pronouns, the fact that you still need to recognize
that the argument is the same as the result, or the general grottiness
of @{$_} as a deref syntax compared to dot. Did I get it right?
Larry
Re: hash subscriptor
Larry Wall writes:
> On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
> : On Wed, 10 Mar 2004, Larry Wall wrote:
> : > You subscript hashes with {...} historically, or these days, Â...Â,
> : > when you want constant subscripts. So what you're looking for is
> : > something like:
> : >
> : > if / ... ... { $?foo{'baz'} ... $?baz } .../
> : > or
> : > if / ... ... { $?fooÂbaz ... $?baz } .../
> :
> : I'm probably a bit behind on current thinking, but did %hash{bareword}
> : lose the ability to assume the bareword is a constant string?
>
> It's thinking hard about doing that. :-)
>
> : And why ÂÂ? Last I heard that was the unicode version of qw(), which
> : returns an array. Using an array constructor as a hash subscriptor is
> : not a "least surprise" to me.
>
> We'd be trading that surprise for the surprise that %hash{shift} doesn't
> call C.
And how often is that, compared with the frequency of doing
%hash{optname}, %hash{root}, etc? %hash{~shift} isn't so bad, and it's
one of those quirks that people will just have to learn. Perl has
plenty of those, and people don't mind once they know them. I'm
grateful for most of them, now that I'm more experienced.
It's one of those things you'll have to mention when you talk about hash
subscripting, that's all. After all, why isn't a hash subscripted with
[]? And why isn't the inside of a subscript a closure? These are as
"inconsistent" as quoting a single {word}.
> Plus we get literal hash slices out of it for free. Plus it also
> works on pair syntax :fooÂsome literal wordsÂ. And probably trait and
> property syntax as well.
>
> And basically because I decided :foo('bar') is too ugly for something
> that will get used as often as switches are on the unix command line.
> The %hash syntax is just a fallout of trying to be consistent with
> the pair notation. Once people start seeing :fooÂbar all over,
> they won't find %hashÂbar surprising at all, and will appreciate the
> self-documenting literalness of argument.
Except the six extra keystrokes involved in typing them. Yeah, I know,
I could reduce that, but Perl's already used up the rest of the
keyboard! :-)
Luke
Re: hash subscriptor
On Mon, Mar 15, 2004 at 07:54:09PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > On Mon, Mar 15, 2004 at 11:56:26AM -0700, John Williams wrote:
: > : On Wed, 10 Mar 2004, Larry Wall wrote:
: > : > You subscript hashes with {...} historically, or these days, «...»,
: > : > when you want constant subscripts. So what you're looking for is
: > : > something like:
: > : >
: > : > if / ... ... { $?foo{'baz'} ... $?baz } .../
: > : > or
: > : > if / ... ... { $?foo«baz» ... $?baz } .../
: > :
: > : I'm probably a bit behind on current thinking, but did %hash{bareword}
: > : lose the ability to assume the bareword is a constant string?
: >
: > It's thinking hard about doing that. :-)
: >
: > : And why «»? Last I heard that was the unicode version of qw(), which
: > : returns an array. Using an array constructor as a hash subscriptor is
: > : not a "least surprise" to me.
: >
: > We'd be trading that surprise for the surprise that %hash{shift} doesn't
: > call C.
:
: And how often is that, compared with the frequency of doing
: %hash{optname}, %hash{root}, etc? %hash{~shift} isn't so bad, and it's
: one of those quirks that people will just have to learn. Perl has
: plenty of those, and people don't mind once they know them. I'm
: grateful for most of them, now that I'm more experienced.
Yeah, and guess who had to trust his gut-level feelings for that? :-)
: It's one of those things you'll have to mention when you talk about hash
: subscripting, that's all. After all, why isn't a hash subscripted with
: []? And why isn't the inside of a subscript a closure? These are as
: "inconsistent" as quoting a single {word}.
Well, all context dependencies are created equal, but some are more
equal than others...
: > Plus we get literal hash slices out of it for free. Plus it also
: > works on pair syntax :foo«some literal words». And probably trait and
: > property syntax as well.
: >
: > And basically because I decided :foo('bar') is too ugly for something
: > that will get used as often as switches are on the unix command line.
: > The %hash syntax is just a fallout of trying to be consistent with
: > the pair notation. Once people start seeing :foo«bar» all over,
: > they won't find %hash«bar» surprising at all, and will appreciate the
: > self-documenting literalness of argument.
:
: Except the six extra keystrokes involved in typing them. Yeah, I know,
: I could reduce that, but Perl's already used up the rest of the
: keyboard! :-)
It's really the visual disambiguation that convinces me. It's extra
keystrokes for me too, y'know, and my finger joints complain to me
every day. I mostly just ignore 'em, but they do make a fearful
crackling most of the time... But my eyes are bad too, so I have
to cater to them too...
But really, it's my brain that's my weakest organ, and I can't fix that,
so I figure I'll just have to feature it.
Larry
