Re: new sigil
On Thu, 20 Oct 2005 16:52:04 -0600, Thom Boyer wrote (in part): Thom On 10/20/05, Juerd [EMAIL PROTECTED] wrote: 2. How can it be typed with X character composition, vim's digraphs and major international keyboards? For X11 composition, where getting into compose state is up to your X environment: compose/c In my case (for a more concrete example), that's ctrl-alt-space/c. --s.
Re: definitions of truth
At some point in history, Paul Hodges wrote (in part):
ph So a null byte is still Boolean true. Ugh, yarf, ack, etc.
No. And it never has been (at least in my world view). However, asking
that question explains some things. See below for more.
ph But as long as I know -- easy enough to check explicitly.
ph But just tell me thisam I the only guy who thinks this *feels*
ph wierd? Understanding the reason doesn't make it any more
ph ~comfortable~.
I believe, from the way you asked your question, that you don't have the
right mental map to make it comfortable. As I see it, at least, with
respect to what you're asking about testing, Perl has strings and
integers, but not 'characters'. (And see another p6l thread about
graphemes and language-dependence and bytes, etc., for why that's a Good
Thing(TM).)
For example, take this test in C:
if ('\0') ...
It corresponds to this in Perl:
if ord \0 {...}
Consider this test in Perl:
if \0 {...}
Its equivalent in C is this:
if () ...
You need ord() for character/grapheme/byte/whatever testing that's
equivalent to what C does. Since C doesn't really have strings, and Perl
does, this is just one of those differences between the languages where
(essentially, and perhaps abusing some linguistics theory and terminology)
you've run into a 'false cognate'.
Hope this helps,
--s.
--
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://users.rcn.com/spiderb/
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: Arrays: Default Values
On 29 Jan 2003 14:29:52 -0500, Aaron Sherman wrote (in part): ajs As for the argument that testing for true non-existentness is a ajs burden, check out the way Perl5 does this. Hint: there's a central ajs sv_undef, and that's not what array buckets are initialized to Either you're dead wrong, or you typo'd there. After my @a; $a[4] = 1; The array buckets @a[0..3] most certainly ARE initialized to PL_sv_undef in p5. That's how Cexists $a[2] knows to return false (PL_sv_no) instead of true (PL_sv_yes). And, yes, Cdelete $a[4] re-sets that slot to point to the one true central undef again. This is different from what happens on Cundef $a[1]; -- that actually makes a new SV which is a *copy* of the central undef and makes that the new value in that slot. Thus, even with just the above sequence, Cexists $a[1] would now be true in p5. Please, folks, this discussion's getting complicated enough without making mistaken claims about what p5 currently does, even when that's by accident. -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://users.rcn.com/spiderb/ PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: Do we really need eq?
On Sun, 20 Aug 2000 17:50:20 -0600 (MDT), Nathan Torkington wrote (in part): Nat Ed Mills writes: Is eq needed? Can't == be used for either context? $a == 'cat' is readily distinguishable from $a == 2; so the compiler should be able to determine context. Nat if ($a == $b) Nat Is that string comparison or numeric comparison? Consider that case in particular when $a and $b are each dual-valued (valid as both string and number). -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://www.ultranet.com/~spiderb PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: RFC 49 (v1) Objects should have builtin string SCALA
On Sun, 06 Aug 2000 16:43:36 -0700, Peter Scott wrote (in part):
Peter Call me old-fashioned, but I don't see what's wrong with
Peter use overload '""' = sub { $_[0]-to_string };
Peter for anything that wants to take such a relatively odd
Peter action.
Larry's commented (in p5p) on his own experience in trying to
have properly "stringified" objects. He wound up with a bunc of
classes doing exactly what you suggest, which is using the
existing overload mechanism *for just that one operation*. He
speculated then that this particular one might be at the wrong
level -- it might be a candidate for being made easier.
That said, if we do this, I think that the implicitly-consulted
method should follow the "parts of speech" rule that someone
(TomC?) listed. Paraphrased: "A method is a function is a
subroutine is an action should be a verb." I nominate
-STRINGIFY. It's a verb, even though it's a neologism, and it's
handier to type than the equivalent -MAKE_STRING would be. It's
also sufficiently mnemonic for those of us who've read the
existing Perl documentation and know what "$thing" does.
--
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://www.ultranet.com/~spiderb
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: RFC 37 (v1) Positional Return Lists Considered Harmf
[cc to perl6-announce removed]
On Sun, 6 Aug 2000 04:54:03 +1000 (EST), Damian Conway wrote (in part):
Damian I've proposed that the want() function will be able to
Damian distinguish a HASHREF context (there the return value is
Damian used as a hash reference).
Damian $subname = caller(0)-{subname}; # hashref context
Don't forget Larry's propsed syntax (which is related to the possibility
of getting rid of typeglobs):
\%myhash = \%yourhash;
which would seem to lead to
\%hashname = call();# hashref context
--
Spider Boardman (at home) [EMAIL PROTECTED]
The management (my cats) made me say this.http://www.ultranet.com/~spiderb
PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
Re: RFC 29 (v1) unlink() should be left alone
On Fri, 4 Aug 2000 16:33:41 -0700, Damien Neil wrote (in part): Damien On Fri, Aug 04, 2000 at 04:39:24PM -0400, Spider Boardman Damien wrote: The C (POSIX.1) remove() function is NOT just unlink() in drag. Damien Not everywhere, at least: Damien REMOVE(3) FreeBSD Library Functions Manual REMOVE(3) Hmm. OK, the reference I have is a combined one for UNIX95, so this may be a question of XPG-only or of *which* POSIX.1 (199309 or 199506), but at least *some* versions of remove(3) are not simply unlink(2) by another name. -- Spider Boardman (at home) [EMAIL PROTECTED] The management (my cats) made me say this.http://www.ultranet.com/~spiderb PGP public key fingerprint: 96 72 D2 C6 E0 92 32 89 F6 B2 C2 A0 1C AB 1F DC
