Re: Suggested magic for "a" .. "b"
Aaron Sherman wrote: > There's just an undefined codepoint smack in the middle of the Greek > uppercase letters (U+03A2). I'm sure the Unicode specs have a rationale for > that somewhere, but my guess is that there's some thousand-year-old debate > about the Greek alphabet behind it. It becomes clearer if you also look at the corresponding lower-case characters: U+03A1 Greek capital letter rho U+03A2 (none) U+03A3 Greek capital letter sigma U+03C1 Greek small letter rho U+03C2 Greek small letter final sigma U+03C3 Greek small letter sigma Greek words written in lower-case that end in a sigma use a special glyph for that sigma; and Unicode allocates a codepoint to it for roundtripping to legacy character sets. There isn't a corresponding upper-case final sigma. Unicode leaves the gap in the upper-case Greek range for neatness, effectively: adding 0x20 to the numeric value of an upper-case character yields the corresponding lower-case version. > I think that "Ā" .. "Ē" should ĀĂĄĆĈĊČĎĐĒ If that's in the hope of producing a more "intuitive" result, then why not ĀB̄C̄D̄Ē? That's only partly serious. I'm acutely aware that choosing a baroque set of rules makes life harder for both implementers and users (and, in particular, risks ending up with an operator that has no practical non-trivial use cases). I note also that this A-macron and E-macron are in NFC. I think that, certainly by default, the difference between NFC and NFD should be hidden from users. That implies that, however "Ā" .. "Ē" behaves, the NFD version should behave identically; and that "B̄" .. F̄ should behave in the most equivalent way possible. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r28017 - in docs/Perl6/Spec: . S32-setting-library
David Green wrote: > Maybe setting $*CWD just calls chdir() under the hood? Same implementation, > brand new shiny Perl-style interface! I don't think that's a good idea. Suppose you have code like this: $*CWD = '/some/absolute/path'; $*CWD = '../relative/path'; my $cwd = $*CWD; Assuming that no exception was thrown, should $cwd now be '/some/absolute/relative/path' or '../relative/path' ? If the former, you've broken the user's reasonable expectation that a value assigned to a variable can be retrieved by looking in the same variable. If the latter, $*CWD is a relative path name that doesn't exist in the current directory. Now that I think about it, I'm having doubts about whether it makes sense to have a $*CWD variable at all. Suppose the current directory is /a/b/c, and a different process renames /a/b to /surprise. Should reading $*CWD reflect that? Calling a POSIX-like getcwd() would do, but that's surprising in just the same way. But if $*CWD doesn't reflect external changes, you can't expect to be able to opendir its value; at that point, it doesn't seem very useful. If the motivation for $*CWD is simply so that it can be temporized, perhaps it would be better to provide a more direct method of doing that (preferably using fchdir where available). -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r27106 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: > +The C type is derived from C, with the additional constraint > +that it may only contain validly encoded UTF-8. Likewise, C is > +derived from C, and C from C. What does "validly encoded UTF-8" mean in this context? The following questions come to mind: 1. Four-byte UTF-8 sequences are enough to handle any Unicode character. Are the obvious five- and six-byte extensions permitted? If so, how about a seven-byte extension (needed to allow any 32-bit value to be encoded)? Whichever sequence length is chosen, is there an additional constraint on the maximum permitted codepoint? For example, four-byte UTF-8 sequences can easily represent values up to 0x1f_, but Unicode stops at 0x10_. Or if seven-byte sequences are permitted, are codepoints limited to 2**32-1? 2. Are over-wide encoded sequences (0xC0 0x41 for U+0041, and so on) permitted? (I hope not.) 3. Are encoded codepoints corresponding to UTF-16 surrogates permitted? 4. Are noncharacter codepoints (0xFFFE, 0x, etc) permitted? 5. Are unallocated codepoints permitted? If so, that doesn't seem very "valid"; but if not, a program's behaviour might change under a newer version of Unicode. Perhaps programs should be given the opportunity to declare which Unicode version's list of allocated characters they want. 6. Are values that begin with combining characters permitted? Of those, question (3) applies to UTF-32, and questions (4), (5), and (6) to both UTF-16 and UTF-32. Further, a variant of (1) applies to UTF-32: are code units greater than 0x10 permitted? I assume that the C type forbids invalid surrogate sequences. I'm also tempted to suggest that the type names should be C, C, C. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25775 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: > Modified: >docs/Perl6/Spec/S05-regex.pod > +The result object is available in the C object via a C<< . >> > lookup. I think I understand the reasoning behind this change. However, using . in particular says "boolean" to me. How about .<*> instead, with its suggestion of "whatever the Match found"? -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25182 - docs/Perl6/Spec
Leon Timmermans writes: > On Wed, Feb 4, 2009 at 4:37 PM, wrote: > > +=item method IO dup() > > Do we really want that? If we label a thing as "POSIX", it should certainly make all the POSIX functionality available, IMHO. I'd consider arguments that we should pick different names for specific functions where the POSIX names are particularly awkward, but I think a good default would be to match the names as well. Or else avoid the label "POSIX". > POSIX' dup does something different from what many will expect. In > particular, the new file descriptors share the offset, which can > result in some really confusing situations. To my knowledge, there's no alternative -- that is, there's no POSIX functionality which allows the creation of a file descriptor open on the same underlying object as an existing fd, but with its own file offset. Assuming I'm right, that doesn't mean users shouldn't get access to POSIX dup() for when it *is* what they want. I agree that also providing a less surprising method would be a good thing, assuming it can be widely implemented. But it needn't live in IO::POSIX. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25182 - docs/Perl6/Spec
Daniel Ruoso writes: > Em Qua, 2009-02-04 às 16:45 +0000, Aaron Crane escreveu: > > pugs-comm...@feather.perl6.nl writes: > > > +=item method Int read($buf is rw, int $length) > > I'm not sure that using a native int is the right thing here. If > > whatever the implementation uses as int is narrower than size_t, that > > forces the programmer to use an Int and do the necessary loop. > > native int can't be undefined, failures are undefined. The use of Int > here is to support it returning unthrown exceptions. Sorry, it was the native-int $length parameter I was talking about -- I think it should be a boxed Int instead. > > POSIX-ish read(2), write(2) > > That actually surprised me, for some reason I did think read and write > were standard C, not POSIX C stdio has fread(), fwrite() working on FILE*, with APIs similar (but not identical) to POSIX read(), write(). C stdio doesn't known anything about POSIX-ish file descriptors. > That probably means IO::POSIX does IO::Readable does IO::Writeable. Yes, indeed. Sorry, I should have thought of that. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25182 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: > +=item method Int read($buf is rw, int $length) I'm not sure that using a native int is the right thing here. If whatever the implementation uses as int is narrower than size_t, that forces the programmer to use an Int and do the necessary loop. On the other hand, accepting Int allows bignums. If a bignum $length is too big to be represented by a native int, but still small enough to use as a byte count for an I/O operation, then .read can do the loop internally, freeing the programmer from worrying about such things. (And if $length is too big for the memory space, or otherwise inappropriate for .read, we can throw an exception.) > +Tries to read $lenght bytes and store in $buf. The contents of $buf Typo; should be "$length", obviously. > +=head2 IO::Writeable FWIW, I prefer the traditional spelling, "writable". Google suggests that "writeable" is more common on the web, though; 4.8 versus 3.7 Mghits. > +=head2 IO::POSIX > + > +Indicates that this object can perform standard posix IO operations. I don't like that wording, but getting it right seems tricky. The problem is that I don't think you mean for IO::POSIX to contain methods corresponding to POSIX-ish read(2), write(2), given that methods of those names exist in other roles. But those are precisely what I'd think of as most obviously falling into the category of "standard POSIX I/O operations". > +=item method Bool flock(:$r,:$w) I realise this part of the specification still seems to be at the stub stage, but I'll note that: * We'll also need a way of getting at the LOCK_NB behaviour * The normal terms for flock() are "shared" and "exclusive" locks, not "read" and "write" locks * It seems a little odd to put an flock method in an IO::POSIX role, given that POSIX specifies fcntl(F_SETLK) in place of traditional BSD-ish flock(). I'd be in favour of having .fcntl in IO::POSIX, but with an additional role providing .flock (IO::Flock, presumably). -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r24809 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: > +=item -x > + > +Run program embedded in ASCII text. Infrequently used, and doesn't > +deserve its own command-line option. I understand the use case for that option is piping a mail or news message to `perl -x` to run a script contained within it. If that use case is to be handled, it pretty much does need to be able to be triggered from the command line, even if not with a single-char option. I'd be in favour of either explaining why this ability is not considered valuable (if that is indeed the case), or (preferably) restoring a simple command-line-accessible way of achieving the same thing. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: [svn:perl6-synopsis] r14522 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +++ doc/trunk/design/syn/S02.pod Mon Mar 17 10:37:26 2008 > +infinite memory, and are willing to wait a long time. To expand an > +interator object to completion, iterate it with C<< prefix:<=> >> Typo -- I believe that should be "iterator". > +++ doc/trunk/design/syn/S03.pod Mon Mar 17 10:37:26 2008 > +In any case, list assignment is defined to be arbitrarily lazy, > +insofar is it basically does the obvious copying as long as there And "insofar as". -- Aaron Crane ** http://aaroncrane.co.uk/
Re: [svn:perl6-synopsis] r14442 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +defaults to a sequence of 0 values. If any native type is explicitly > +initialized to C<*> (the C type), it is left unitialized. s[un <( )> it] = 'in'; (Assuming I've got that syntax correct, anyway.) -- Aaron Crane
Re: [svn:perl6-synopsis] r14432 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +Placeholder names may only be lowercase, not because we're mean, but > +because it helps us catch references to obsolete Perl 5 variables such as > $^O. That seems unnecessarily restrictive. How about "may not consist solely of uppercase letters" instead? That would still permit things like $^Item, or caseless letters (Han characters, Japanese kana, Hangul, Devanagari, Thai, Hebrew, Arabic, etc). Maybe even "may not consist solely of uppercase Latin-script letters"; that would permit uppercase Greek and Cyrillic and so on. -- Aaron Crane
Re: Generalizing ?? !!
Daniel Hulme writes: > On Fri, Jun 22, 2007 at 03:40:37PM +0100, Aaron Crane wrote: > > my $b = 1 && 0 || 42; > > # Now $b is 17 > s/17/42/ or vice-versa, I think. Uh, yes. Serves me right for trying to change metasyntactic numbers midstream. -- Aaron Crane
Re: Generalizing ?? !!
Peter Scott writes: > can someone tell me why you can't just use && ... || in place of ?? > ... !!, now that && and || propagate context to both sides? You get the wrong result when the antecedent is true and the consequent is false: my $a = 1 ?? 0 !! 42; # Now $a is 0 my $b = 1 && 0 || 42; # Now $b is 17 -- Aaron Crane
Re: [svn:perl6-synopsis] r14414 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > @@ -562,10 +625,10 @@ > @list xx $count > > Evaluates the left argument in list context, replicates the resulting > -Capture value the number of time specified by the right argument and > +C value the number of time specified by the right argument and Presumably that should be "number of times". -- Aaron Crane
Re: request new Mapping|Hash operators
David Green writes: > In the meantime, Darren's proposal still raises a lot of interesting > language questions. For example, how *do* you rename a hash key? That's easy even in Perl 5. This modifies %hash in-place: my @values = delete @[EMAIL PROTECTED]; @[EMAIL PROTECTED] = @values; While there's certainly motivation to wrap this up in a function or operator, it doesn't strike me as something particularly difficult, or necessarily more worthy of inclusion in Perl 6.0.0 than anything else. -- Aaron Crane
Re: [svn:perl6-synopsis] r14323 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +The C<:i> (or C<:ignorecase>) modifier causes case distinctions to be > +ignore in its lexical scope, but not in its dynamic scope. That is, That should read "ignored", I dare say. -- Aaron Crane
Re: request new Mapping|Hash operators
Darren Duncan writes: > I believe that there is some room for adding several new convenience > operators or functions to Perl 6 that are used with Mapping and Hash > values. > I also want to emphasize that I see this functionality being generally > useful, and that it shouldn't just be shunted off to a third-party > module. Um, why not? Or rather, why do these need to be part of standard Perl 6.0.0? Even assuming that they are "generally useful", the volunteers donating their time to implement Perl 6.0.0 shouldn't feel compelled to build every last feature that might be considered generally useful. (As it happens, I'm not entirely convinced that these operations are generally useful in the same way as, say, multiplication, or string concatenation, or cross hypering, but I think that's a side issue.) I think it would be reasonable for someone who believes that these operations are generally useful to attempt to write a Perl 6 module that provides them. If that effort goes well, maybe the module will be included in Perl 6.0.0. If the module can't be written, or can't be made efficient, that is presumably interesting to the designers of the language and of its implementation(s). But "I need these operations" does not imply "Perl 6.0.0 needs these operations". -- Aaron Crane
Re: [svn:perl6-synopsis] r13700 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +be referred to as C<< COMPILING<$?LINE> >> if the bare C<$?LINE> would That looks like it's missing a double-colon. -- Aaron Crane
[OT] Re: [svn:perl6-synopsis] r13540 - doc/trunk/design/syn
Nicholas Clark writes: > Also, I'm never totally confident on what isn't quite undefined behaviour in > C, but something like > > $a = $b + ++$b; > > doesn't appear to have multiple side effects, yet it ought to be undefined. It is undefined in C. The standard says that between any adjacent pair of sequence points, an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be accessed only to determine the value to be stored. C modifies b once, reads it once to determine the value to be stored (C<++b), and also reads it one further time (to determine the result of the addition), so it's undefined. -- Aaron Crane
Re: [svn:perl6-synopsis] r13516 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +the top rule. This may be overridden in either the base grammar or a > +derived grammer by explicitly naming a rule "top", or defining your There's a typo there -- "grammer" for "grammar". -- Aaron Crane
Re: [svn:perl6-synopsis] r12398 - doc/trunk/design/syn
TSa writes: > I'm very glad, too. Even though I would like the new operator > spelled / for aesthetic reason. I think there'd be problems making that work. It's a prefix operator, so it has to appear in term position, and we already have terms that begin with C, in the form of regexes. Forcing regexes to always use the C or C prefix sounds inadvisable on Huffman grounds. -- Aaron Crane
Re: [svn:perl6-synopsis] r11287 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > +To pass a regex with leading whitespace you must use the parenthsized form. ... > +To pass a string with leading whitespace you must use the parenthsized form. Hi. I think that needs an s:g/parenthsized/parenthesized/ -- Aaron Crane
Re: multi-line comments, C macros, & Pod abuse
Stuart Cook writes:
> On 8/19/06, Larry Wall <[EMAIL PROTECTED]> wrote:
> >if 0 {
> >...
> >}
>
> The one disadvantage of that approach is that it will break if the
> "commented-out" code temporarily fails to compile. If that's a
> problem, though, you could always write your own macro.
You don't actually need a macro in that case:
if 0 { q<
...
> }
And if you have unbalanced quote-delimiting brackets in the "...", you can
switch to different bracketing characters (including arbitrary Ps/Pe or
bidi-mirroring Unicode pairs), or simply add more brackets:
if 0 { q<<<<
... # >>> with unmatched pointies
>>>> }
--
Aaron Crane
Re: [svn:perl6-synopsis] r10758 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > Modified: doc/trunk/design/syn/S02.pod > +Some object types can behave as value types. Every object can produce > +a "safe key identifier" (C for short) that uniquely identifies the > +object for hashing and other value-base comparisons. Normal objects Is that meant to say "value-based"? -- Aaron Crane
Re: [svn:perl6-synopsis] r10539 - doc/trunk/design/syn
[EMAIL PROTECTED] commits: > +If the first character is a plus or minus, the initial identifier taken > +as a character class, so s/taken/is taken/ -- Aaron Crane
Re: [svn:perl6-synopsis] r9725 - doc/trunk/design/syn
[EMAIL PROTECTED] writes: > Log: > Change "env" variables to "context" variables. > -$+foo environmental variable > +$+foo contextual variable > -ENV > +CONTEXT > SUPER > COMPILING > -lexical variable must be declared using "C" rather than C to be > +lexical variable must have the trait "C" to be I realise this comment is a little late, but it occurred to me on seeing Audrey's recent blog entry mentioning this change. The motivation for s/environmental/contextual/ is clear: avoiding a term that's already used for something else. But, on the same grounds, I'm not sure that "contextual" is the right term, and especially not C -- Perl already has contexts, and this isn't one. How about "ambient variables" instead? I believe that captures the same sense as "environmental". It's also an adjective, which I think reads more naturally, especially in declarations: my $foo is context; say CONTEXT::<$foo>; versus my $foo is ambient; say AMBIENT::<$foo>; -- Aaron Crane
Re: S04 - forbidden coding-style
Larry Wall writes: > Maybe we should just make statement modifiers uppercase and burn out > everyone's eye sockets. :) I like statement modifiers, and I want them to continue to exist in Perl 6. But it seems to me that a lot of the most awkward decisions about Perl 6 syntax are awkward precisely because EXPR if EXPR; BLOCK and EXPR; if EXPR BLOCK are so similar. Bearing that in mind, would the eye-socket-burning return $foo IF $something; really be so bad? Alternatively, perhaps it's possible to find some other morphological or syntactic device to distinguish statement_modifier: from statement_control:, for both humans and the compiler. One option might be to require an extra token (a postfix complementizer?) before a statement modifier. Maybe something like this: return $foo --- if $something; -- Aaron Crane
Re: Perl5 -> Perl 6 Translations Design Document
Sage La Torra writes:
> http://infohost.nmt.edu/~slatorra/conversionstageone.txt
You say this:
-Hash in interprative context: "%hash" -> "%hash{}" (also @{[...]} ->
{...})
Hashes don't interpolate in Perl 5, so that's not an issue (unless I'm
misunderstanding what you meant). But using "{...}" instead of "@{[...]}"
is definitely a good thing.
--
Aaron Crane
Re: new sigil
Kaoru Maeda writes: > Darren Duncan wrote: > > the next best is £ > Isn't that 0x23 in UK? I imagine that someday all the comment lines > cause syntax errors in UK... U+00A3 "POUND SIGN" is at 0x23 in ISO 646-GB (aka BS 4730), true. Fortunately, that character set is almost never used. I think the last time I encountered it was on a dot-matrix printer manufactured in the 1980s. Hmmm. Encode.pm doesn't seem to have support available for any of the ISO 646 character sets. I feel a patch coming on. -- Aaron Crane
Re: Nested captures
Damian Conway writes: > Just as $42 is a shorthand for $/[42], so too $ is a > shorthand for $/. Isn't $42 a shorthand for $/[41] ? I think that having 1-based digit-variables but 0-based array indexes on $/ is really confusing; mistakes of this sort seem to confirm my view. -- Aaron Crane
Re: The Sort Problem
Luke Palmer wrote:
> Aaron Crane writes:
> > @unsorted
> > ==> sort &infix:<=>, desc => 1, key => { $_.foo('bar').compute }
> > ==> @sorted;
>
> I don't like the C flag. But I can't, at the moment, think of any
> way around it short of:
>
> @unsorted
> ==> sort { $^b <=> $^a }, key => { .foo('bar').compute }
> ==> @sorted
>
> Which people have made pretty clear that they don't like.
One option might be an 'rsort' function, but I think that's somewhat lacking
in the taste department.
Another might be as simple as
@unsorted ==> sort ==> reverse ==> @sorted;
But I can see an argument that C<< ==> reverse >> is quite a large code
burden for something so conceptually simple.
I have one other idea, but I can't decide if I like it:
@unsorted ==> sort &rinfix:cmp ==> @sorted;
That is, rinfix: (or some other name) is like infix:, but gives you a
function that reverses its arguments before actually running the operator.
Perhaps it could even be implemented as a macro.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: The Sort Problem
Luke Palmer wrote:
> Any other ideas?
How about something like this, modulo any errors in my Perl 6 syntax?
sub sort(?&cmp = &infix:cmp, +$key, +$desc, [EMAIL PROTECTED]) { ... }
I think that allows all of these:
# P5: @sorted = sort @unsorted;
@sorted = sort @unsorted;
The simplest case is the same as the Perl 5, which seems a pleasant feature.
# P5: @sorted = sort { $a <=> $b } @unsorted;
@sorted = sort { $^a <=> $^b } @unsorted; # or:
@sorted = sort &infix:<=> <== @unsorted;
This also seems reasonable.
# P5: @sorted = sort { $a->foo('bar')->compute <=> $b->foo('bar')->compute }
# @unsorted
# or: @sorted = map { $_->[1] }
# sort { $a->[0] <=? $b->[0] }
# map { [ $_->foo('bar')->compute, $_ ] }
# @unsorted
@sorted = sort &infix:<=>, key => { $_.foo('bar').compute } <== @unsorted;
I think my suggestion wins big here. We've only had to specify how to
extract the key, and sort itself takes care of everything else. And it looks
to me like this sort function has enough information about the programmer's
intent for it to optimise in all sorts of exciting ways -- it should be able
to do the equivalent of the GRT internally, for example.
Just for kicks, this one demonstrates all the features. It's the same as
before, but in descending order:
@unsorted
==> sort &infix:<=>, desc => 1, key => { $_.foo('bar').compute }
==> @sorted;
What problems can anyone spot with this suggestion?
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: is static?
Smylers writes:
> I don't find the Perl 5 approach ugly: I actually like it, because it does
> exactly what it looks like it's doing, and doesn't require learning any
> special syntax or keyword.
>
> To have a variable exist beyond outside a sub, you declare it outside that
> sub. To prevent that variable being accessed from anywhere else, you put
> it in a block. It's simple yet provides the power you need, and it's
> completely obvious what's going on.
I disagree that it's simple.
#! /usr/bin/perl -lw
use strict;
print id();
{
my $next = 17; # the first ID is 17
sub id {
return $next++;
}
}
Unfortunately, that completely fails, because the block containing the
declarator hasn't been evaluated the first time you call the sub. So you
get 0 as the answer (because ++ is sufficiently magic). It can be fixed by
making the block a BEGIN block, but suddenly it doesn't seem so simple. It
doesn't help that when you do this in a module, you probably don't see the
problem (because 'use Foo;' effectively does a require in a BEGIN block).
I'd argue that the requirement for BEGIN when you want a so-called-static
variable in your main program (and you define the sub after using it) makes
this approach less than simple.
In addition, I don't think it 'provides the power you need'. With the Perl5
approach, you can't have so-called-static variables scoped to anything other
than (a group of) subroutines -- they can't be scoped to a loop within a
sub, for example.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: Comparing Object Identity
Piers Cawley writes:
> I found myself mulling over:
>
> $obj.is($other_obj);
>
> Which seems to work reasonably well, and I'd be rather surprised if it
> clashed with anything with different semantics...
I quite like it. It also has the advantage of disallowing the equivalent
of:
my $stored_identity = $obj.id;
# Time passes...
if ($other_obj.id == $stored_identity) {
# Massive breakage ahoy
}
There just isn't any way you can get .is() to compare identities at different
times.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: Comparing Object Identity (was: Re: Stringification of references (Decision, Please?))
Damian Conway writes: > There's no need for special methods or (gods forbid) more operators. > Just: > > $obj1.id == $obj2.id > > That's what the universal C method is *for*. How universal are universal methods? That is, can a programmer override .id() in a user-defined class? If so, simply comparing .id for numeric equality isn't a good enough way of comparing object identity. I think you'd have to do something like $obj1.UNIVERSAL::id == $obj2.UNIVERSAL::id which is getting fairly verbose. But I also have a feeling of non-specific unease at the idea that I might _not_ be able to override a universal method. Another question. Consider the integer 17. There are two plausible representations for it -- one boxed, and one unboxed. There might also be several distinct boxed 17s that aren't object-identical. My question is whether all of those should have the same .id(). That is, should the programmer be allowed to determine whether two apparently-identical numbers have the same representation, or should .id() fudge the issue by pretending that all representations of a number of a given type are identical. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: purge: opposite of grep
Sean O'Rourke writes:
> On Thu, 5 Dec 2002, Sean O'Rourke wrote:
> > how 'bout "tang" for "Tog's A Negated Grep"?
>
> Gah. s/Tog/Tang/.
Wouldn't that mean we had to rename grep to 'gnat'? ("Gnat's Not A Tang",
presumably, never mind rot13 and reversal...)
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: seperate() and/or Array.cull
Michael G Schwern writes: > I'd love to be able to do it with a grep like thing. > > (@switches, @args) = seperate /^-/, @ARGV; Yes. I've written that function in Perl 5, which isn't ideal, because you have to return array refs, not arrays. However, I don't think it should be called 'seperate'. I also don't think it should be called 'separate', because that word seems to be commonly misspelled... It's hard to come up with a good name, though. Bad ones I've thought of include: grepboth - The unpleasant name my Perl 5 implementation has split - Overloaded meaning -- but we could perhaps get away with scalar-split and array-split being different characterize - Or do I mean 'characterise'? partition classify - These are the two I dislike least >@switches = @ARGV.cull /^-/; > > Array.cull would remove and return a list of every element in @ARGV which > matched. I'm not so fond of that -- I don't think it's as obvious that you're doing a two-way classification. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: [RFC] Perl6 HyperOperator List
Larry Wall writes: > @a ^[+] @b I like this one in preference to plain ^+, but (unless I'm missing something) it still leaves the question of what to do with xor. > @a '[+] @b Doesn't this reinvent the $Package'symbol problem? > The * has obvious mnemonic value of the splat sort, but also mentally clashes > with the notion of multiplication when using mathematical ops inside. Hmm. @a *[+] @b @a *[*] @b @a *[**] @b I think I could cope, if only because the brackets highlight the vectorised operator more than the outside symbol. How about tilde? @a ~[+] @b If I'm successfully playing along at home, I think that means the match operator has to be ~~ or =~, but I can live happily with either of those. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/course/perl/
Re: [RFC] Perl6 HyperOperator List
Jonathan Scott Duff writes: > @a `+ @b Ick. In my experience, many people actually don't get the backtick character at all. They can't find it on the keyboard, and they don't really see what's so different about it from apostrophe. Indeed, many typefaces (including common print-media faces, like Courier) make it _really_ hard to distinguish backtick from apostrophe. I always hate teaching people what backticks do -- not because the concept is difficult, but because the syntax is so alien to so many people. So I teach qx// for Perl, and $() for Unix shell, and I throw in backticks as an extra 'you might also see this' affair. Anyway, that was a bit of a rant, but what I mean is: I'd actually be in favour of avoiding backtick entirely in operators. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: Perl6 Operator List, Damian's take
Damian Conway writes: > My personal favorite solution is to use square brackets (for their dual > array and indexing connotations, and because they highlight the operator > so nicely): > > $count = @a + @b; > @sums = @a [+] @b; Mmm, yummy. I do have a question though (and apologies if I've merely missed the answer). We've got two productive operation-formation rules: one saying "add a final = to operate-and-assign", and the other saying "wrap in [] to vectorise". But no-one's said which order they apply in. That is, which of these should I type: @x [+]= @y; @x [+=] @y; Of course, the rule ordering didn't matter with the "add a leading ^ to hype" rule. I think I prefer the first one, by the way -- it strikes me as more obviously a vector add. -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
Re: perl6 operator precedence table
Luke Palmer writes:
> Some of my students want to go:
>
> if ($x == 1 || 2) { ... }
>
> Now they can:
>
> if $x == 1 | 2 { ... }
I like that a lot. (Some of my students also want to do that.)
You can write an equivalent thing in Icon:
if x = (0 | 1)
though (if memory serves) the parens are required. And in Icon it's done
with backtracking, not superpositions.
--
Aaron Crane * GBdirect Ltd.
http://training.gbdirect.co.uk/courses/perl/
Re: perl6 operator precedence table
Larry Wall writes: > Alternately, we take | and & away from bitwise ops and do something > more useful with them. I for one would be extremely happy to see that happen. Giving the bitwise operations single-character names, while reasonable in the historical context of (B and) C, suggests that they're useful way more often than they actually are. (That applies particularly for a high-level language like Perl, in my experience.) I find the problem particularly apparent when delivering Perl training. Many problem domains have little if any use for bitwise operations, and few students have a background leading to familiarity with bitwise ops. What I normally do is simply avoid teaching those operators to groups that won't need them -- but there's often a student who's heard of them and who asks questions about them. Vaguely heretical, I know, but I'd be inclined to do something like this: Perl 5 Proposed Perl 6 $x && $y $x & $y $x || $y $x | $y $x & $ybitand($x, $y) $x | $ybitor($x, $y) Using functions instead of operators for these operations seems reasonable to me given how often they're useful. I'm not especially fond of the names bitand and bitor, but they're accurate, reasonably short, and have prior art in C and C++. Two things about this proposal: * This leaves && and || available for other purposes, but I can't off the top of my head think of anything else I'd want them for. * Does this make it harder to write overloaded bitwise ops for your classes? -- Aaron Crane * GBdirect Ltd. http://training.gbdirect.co.uk/courses/perl/
