anonimity
Juerd
Scalar values
Arrays
Hashes
Rules
Subs
Classes?
Roles?
Modules?
Other things?
If anonymous roles exist, then does
$object does role { method quux { ... } };
really add a method to an *instance*? I see no use for it now, but
imagine it can be useful.
And is there a way to name something that is anonymous? For example,
naming an anonymous subroutine can help when debugging. In Perl 5,
this is possible with Sub::Name.
Juerd
Juerd
> On Sat, Nov 06, 2004 at 09:17:03PM +0100, Juerd wrote:
> : Which things can either have a name or be anonymous?
> (...)
> Lists (Lazy and Eager)
If lists can be named, then is there still any difference between array
and list, except for automatic (de)referencing?
> : And is there a way to name something that is anonymous? For example,
> : naming an anonymous subroutine can help when debugging. In Perl 5,
> : this is possible with Sub::Name.
> Easy, just one of
> my $named := anonymous();
> my @named := anonymous();
> my %named := anonymous();
> my &named := anonymous();
> my ::named := anonymous();
That's a lexical name. Are they used in error messages? (Can they be?)
> Just don't try
> *named = anonymous();
> or we'll hunt you down and put hot grits down your pants.
I'll try to remember that :)
Juerd
Larry Wall
: Larry Wall skribis 2004-11-06 13:32 (-0800):
: > On Sat, Nov 06, 2004 at 09:17:03PM +0100, Juerd wrote:
: > : Which things can either have a name or be anonymous?
: > (...)
: > Lists (Lazy and Eager)
:
: If lists can be named, then is there still any difference between array
: and list, except for automatic (de)referencing?
Lists can't in general be subscripted except by viewing them through the
lens of an array. If you do manage to subscript a Lazy list, you'll
find you have a list of generators, some of which are marked as logically
flattened because they happened in a list context. But generally
we try to hide all that mechanism behind a splat array.
: > : And is there a way to name something that is anonymous? For example,
: > : naming an anonymous subroutine can help when debugging. In Perl 5,
: > : this is possible with Sub::Name.
: > Easy, just one of
: > my $named := anonymous();
: > my @named := anonymous();
: > my %named := anonymous();
: > my &named := anonymous();
: > my ::named := anonymous();
:
: That's a lexical name. Are they used in error messages? (Can they be?)
Generally not, unless we make aliasing smart enough to latch onto the
first name and add it as a property to the anonymous object if it doesn't
already have one.
Larry
Larry Wall
the most recent versions of Apocalpses and Synopses may be found at
http://www.wall.org:~larry/apo
http://www.wall.org:~larry/syn
There are new S10, S11, S12, and S13 pods there.
Recent changes include:
Strictures and warnings are now the default in the main program.
Syntax of subtype and enum declarations more like normal declarations.
Subtypes are now declared with "subtype" keyword.
Symbolic ref syntax reverted back to ::($expr).
Syntax of operators now defined to leverage hash subscript syntax:
infix:«+» # op name always quoted now
circumfix:«[ ]» # multipart ops are now slices, no ... needed
circumfix:{'[',']'} # same thing
Special rule for splitting symmetrical operator names is gone, use slice.
Special rules for recognizing the ends of operator names are gone.
Current class is $?CLASS or ::?CLASS, not ::_.
Current sub is $?SUB, not &_.
There is no bogus first argument to the pair-arg variant of bless.
See the Synopses for details. Or read the Apocalypses, and search for
the string "Update:".
These files are all in utf-8. If you browser shows mojibake, try forcing
it to view as utf-8.
Larry
Larry Wall
: By the way, until I figure out how to drive combust on perl.org,
: the most recent versions of Apocalpses and Synopses may be found at
:
: http://www.wall.org:~larry/apo
: http://www.wall.org:~larry/syn
Er, s:2nd|:|/|...
Larry
Juerd
my terminals configured now, so that I can input and view them.
I don't understand why it is needed, though. Why wasn't infix:+ good
enough?
infix:<<+>> and infix:{'+'} are more linenoise, and IMHO it's far from
elegant.
Juerd
Jonathan Scott Duff
> Hurrah, even more use of «». But that is okay, as I have nearly half of
> my terminals configured now, so that I can input and view them.
Excellent! As soon as you have the other half configured you'll be
ready for perl6 (and by that time it'll be here! :-)
> I don't understand why it is needed, though. Why wasn't infix:+ good
> enough?
>
> infix:«+» and infix:{'+'} are more linenoise, and IMHO it's far from
> elegant.
It eliminates the hackish division of circumfix operators by making
each side explicit. This is an improvement if you ask me.
The only use of �� that really bothers me is as one of the secondary
sigils
$*foo # a truly global global (in every package)
$^foo # an autodeclared parameter variable
$.foo # a public attribute
$:foo # a private attribute
$?foo # a compiler variable
$=foo # a POD variable
$�foo� # a rule-scoped variable
That last one just doesn't fit with the others. I'd prefer something
like $~foo if I had a say.
-Scott
--
Jonathan Scott Duff
du...@pobox.com
Larry Wall
: It eliminates the hackish division of circumfix operators by making
: each side explicit. This is an improvement if you ask me.
More importantly, it avoids having to enumerate a list of characters
that have to be backslashed. The previous rule said any bracket
character or semicolon or commo had to be backslashed:
circumfix:\[\]
That was just too ugly to live. The problem was NOT the declaration,
which could always be terminated by whitespace, but rvalue use
of &foo:!@#$@#, which, as you can see even in English, has to be
smart enough to stop on comma, but not on # or @ or $. It was just
getting way too mindreadish, so I've been looking at different ways
to quote that so that I'd only have to look for one thing at the end,
like in HTML where & only has to look for the final semicolon.
Only after deciding it'd be much better to reuse an existing Perl
quoting mechanism did it occur to me that «» also solves the
two-part problem of circumfix operators because it can do slices
based on whitespace. So even though I knew people would carp about
Yet Another Use for «», it was the right thing.
: The only use of �� that really bothers me is as one of the secondary
: sigils
:
: $*foo # a truly global global (in every package)
: $^foo # an autodeclared parameter variable
: $.foo # a public attribute
: $:foo # a private attribute
: $?foo # a compiler variable
: $=foo # a POD variable
: $�foo� # a rule-scoped variable
:
: That last one just doesn't fit with the others. I'd prefer something
: like $~foo if I had a say.
Well, it was $?foo, but I stole that.
The problem is that rule-scoped variables aren't real variables.
They're really just elements in a hash, and get dereferenced as hash
elements. $«foo» is just syntactic sugar for $0«foo». If it were
just that, it probably wouldn't be sufficient reason, but we also
needed a way to distinguish capturing rules from non-capturing, and
the <...>/«...» distinction works nicely there too. I like it when the
contents of the visual "pill" are consistent from one place to another.
Larry
James Mastros
> On Sat, Nov 06, 2004 at 10:37:39PM +0100, Juerd wrote:
> : Larry Wall skribis 2004-11-06 13:32 (-0800):
> : > my $named := anonymous();
> : > my @named := anonymous();
> : > my %named := anonymous();
> : > my &named := anonymous();
> : > my ::named := anonymous();
> :
> : That's a lexical name. Are they used in error messages? (Can they be?)
>
> Generally not, unless we make aliasing smart enough to latch onto the
> first name and add it as a property to the anonymous object if it doesn't
> already have one.
It would seem, then, that the answer is "there's some property of
thingies that gives the name that error messages will use to refer to
them". (I want to thank the man who made "thingy" the proper technical
term, BTW.) So what's it called?
-=- James Mastros
Juerd
> It would seem, then, that the answer is "there's some property of
> thingies that gives the name that error messages will use to refer to
> them". (I want to thank the man who made "thingy" the proper technical
> term, BTW.) So what's it called?
Well then, that's obvious.
$thingy.errorthingy
:)
Juerd