Scott Bronson wrote:
That's the plan? Happy day! I was not aware of that. Because I didn't
see anything about this in Perl 6 Essentials, I just figured that
Perl5's '0'==undef was being brought forward into Perl6. The horror!
Sorry for the bad assumption. :)
Perhaps not as happy as you think:
--- Luke Palmer <[EMAIL PROTECTED]> wrote:
> Paul Hodges writes:
> > So, in P6:
> >
> > if 0 { print "0\n"; } # I assume this won't print.
> > if '0' { print "'0'\n"; } # I assume this won't print.
> > if ''{ print "''\n";} # I assume this won't print.
> > if undef { pr
Juerd wrote:
That we already have. "0 but true". (perldoc -f fcntl)
It's 1 but false that's really special :)
No, what's really special is the ability to return entirely
different things in string versus numeric context, like the
magic $! does in Perl5.
That, or interesting values of undef :-)
Paul Hodges writes:
> I seemed to have opened a can of worms, lol
> But did anybody see the one that had something to do with my question
> crawling around? (I've obviously missed a couple of messages. They're
> probably hanging out down at the router in the cyberspace equivelent of
> teenagers
I seemed to have opened a can of worms, lol
But did anybody see the one that had something to do with my question
crawling around? (I've obviously missed a couple of messages. They're
probably hanging out down at the router in the cyberspace equivelent of
teenagers ogling girls on the street c
On Thu, 2004-06-24 at 14:17, Smylers wrote:
> Because the above would've been insane: saying that C treats
> $x as a string would be pretending that C always treats its
> arguments as numbers, but something such as C doesn't
> have any numbers in it.
Doesn't it?
perl -e '$x = "frog"; print(($x
> -Original Message-
> From: Dave Whipp [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 24, 2004 5:22 PM
> To: [EMAIL PROTECTED]
> Subject: Re: definitions of truth
>
> "Larry Wall" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > This is Perl 6. Everything is an o
Rod Adams writes:
> Come the glorious age of Perl6, will hash slices be enhanced to allow
> things like the following?
>
> [EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Well, you can always do this:
[EMAIL PROTECTED] = [EMAIL PROTECTED];
But I definitely look forward to the definitions
Come the glorious age of Perl6, will hash slices be enhanced to allow
things like the following?
[EMAIL PROTECTED]'expected'} = [EMAIL PROTECTED];
Specifically, having the slice be something other than the last element.
This likely dictates having {} be able access a list of of hashrefs, not
jus
On Thu, Jun 24, 2004 at 03:24:25PM -0700, Scott Walters wrote:
: I want an "okay". Routines should be able to "return okay" to indicate
: an ambivalent degree of success. "okay" would be defined as "true | false",
Some messages want to be simultaneously Warnocked and not Warnocked...
Larry
Austin Hastings skribis 2004-06-24 15:54 (-0700):
> I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the
> system calls can return something other than -1.)
That we already have. "0 but true". (perldoc -f fcntl)
It's 1 but false that's really special :)
Juerd
--- Juerd <[EMAIL PROTECTED]> wrote:
> Austin Hastings skribis 2004-06-24 14:29 (-0700):
> > > $foo as boolean
> > "This is Perl 6. Everything is an object, or at least pretends to
> > be one. Everything has a .boolean method that returns 0 or 1."
>
> If I understand the current design correctl
Austin Hastings skribis 2004-06-24 14:29 (-0700):
> > $foo as boolean
> "This is Perl 6. Everything is an object, or at least pretends to
> be one. Everything has a .boolean method that returns 0 or 1."
If I understand the current design correctly, having both .boolean and
casting via "as" woul
On 0, Juerd <[EMAIL PROTECTED]> wrote:
>
> However, is the name "boolean" final? I would prefer "true", perhaps
> with a corresponding "false".
I want an "okay". Routines should be able to "return okay" to indicate
an ambivalent degree of success. "okay" would be defined as "true | false",
so:
--- Dave Whipp <[EMAIL PROTECTED]> wrote:
> "Larry Wall" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> >
> > This is Perl 6. Everything is an object, or at least pretends to
> be one.
> > Everything has a .boolean method that returns 0 or 1. All
> conditionals
> > call the .bool
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> This is Perl 6. Everything is an object, or at least pretends to be one.
> Everything has a .boolean method that returns 0 or 1. All conditionals
> call the .boolean method, at least in the abstract.
My reading of A12 l
Scott Bronson writes:
> On Thu, 2004-06-24 at 11:34, Smylers wrote:
>
> > But you're fine with 0 being false? 0 and '0' are pretty much
> > interchangeable in Perl 5 -- wherever you can use one, you can use
> > the other and it gets coerced to it.
>
> Let's back up... Strings and numbers are m
On Thu, Jun 24, 2004 at 04:19:25PM -0400, Jonadab the Unsightly One wrote:
: Larry Wall wrote:
:
: >What do you mean by "length"?
:
: For a string, it obviously either means number of bytes or number
: of characters. Pick one, document it, and let people who want the
: other semantic use a pra
Michele Dondi writes:
> This is yet another proposal that is probably a few years late. I've had
> some (admittedly limited) experience with S-Lang in the past: the language
> has currently a syntax that resembles much that of C but was originally
> designed to be strongly stack-based and still
Michele Dondi writes:
> On Tue, 22 Jun 2004, Juerd wrote:
>
> > > rename -v => 1, $orig, $new;
> [snip]
> > I think just using named arguments would be better and much easier.
> >
> > sub rename ($old, $new, +$verbose) {
> > say "Renaming '$old' to '$new'" if $verbose;
>
>
> On Tue, 22 Ju
Larry Wall wrote:
What do you mean by "length"?
For a string, it obviously either means number of bytes or number
of characters. Pick one, document it, and let people who want the
other semantic use a pragma.
I don't think it matters which one you pick as default, as long
as it's clearly documen
Larry Wall skribis 2004-06-24 12:24 (-0700):
> Well, the type/property name doesn't have to be "boolean"--it could
> be "truth", instead.
I understand that 'true' and 'false' can't be used.
However, "truth" is in the same category as "definedness", and
$foo.definedness looks awful :)
Perhaps fo
On Thu, 2004-06-24 at 11:34, Smylers wrote:
> Scott Bronson writes:
> But you're fine with 0 being false? 0 and '0' are pretty much
> interchangeable in Perl 5 -- wherever you can use one, you can use the
> other and it gets coerced to it.
Let's back up... Strings and numbers are meant to be int
On Thu, Jun 24, 2004 at 08:44:45PM +0200, Juerd wrote:
: Larry Wall skribis 2004-06-24 11:29 (-0700):
: > This is Perl 6. Everything is an object, or at least pretends to be one.
: > Everything has a .boolean method that returns 0 or 1. All conditionals
: > call the .boolean method, at least in t
Larry Wall skribis 2004-06-24 11:29 (-0700):
> This is Perl 6. Everything is an object, or at least pretends to be one.
> Everything has a .boolean method that returns 0 or 1. All conditionals
> call the .boolean method, at least in the abstract. (The optimizer is
> free to optimize the method c
Scott Bronson writes:
> On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote:
>
> > > In Perl5, the following values are FALSE: undef, '0', 0, and ''.
>
> > ... The really special case is '0', which is false for arcane (but
> > very sensible) reasons.
>
> I don't agree that '0' being fa
On Thu, Jun 24, 2004 at 08:04:10PM +0200, Juerd wrote:
: Scott Bronson skribis 2004-06-24 10:44 (-0700):
: > However, it seems that because Perl is finally getting a typing system,
: > this hack can be fixed in Perl itself! No programmer intervention
: > needed. Undef and '' can be false for stri
On Tue, Jun 22, 2004 at 11:50:03AM -0600, Luke Palmer wrote:
: That one doesn't work. Named arguments have to come at the end of the
: parameter list (just before the "data list", if there is one). This is
: a decision I'm gradually beginning to disagree with, because of:
:
: sub repeat (&co
Scott Bronson skribis 2004-06-24 10:44 (-0700):
> However, it seems that because Perl is finally getting a typing system,
> this hack can be fixed in Perl itself! No programmer intervention
> needed. Undef and '' can be false for strings, undef and 0 can be false
> for integers, undef, 0, and 0.0
On Thu, 2004-06-24 at 10:44, Scott Bronson wrote:
> I don't agree that '0' being false is sensible...
I don't mean to imply that I think it's senseless. Just that, to me, it
smells suspiciously like a hack. :)
- Scott
On Thu, Jun 24, 2004 at 11:59:03AM +0100, Matthew Walton wrote:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: Michele Dondi wrote:
:
: | I don't know if this is already provided by current specifications, but
: | since I know of Perl6 that is will support quite a powerful system of
: | fu
On Thu, 2004-06-24 at 08:04, Jonadab the Unsightly One wrote:
> > In Perl5, the following values are FALSE: undef, '0', 0, and ''.
> ... The really special case is '0', which
> is false for arcane (but very sensible) reasons.
I don't agree that '0' being false is sensible. This, plus less than
vi
On Thu, Jun 24, 2004 at 12:34:44PM +0200, Michele Dondi wrote:
: I don't know if this is already provided by current specifications, but
: since I know of Perl6 that is will support quite a powerful system of
: function prototyping ("signatures"?), I wonder wether it will be possible
: to specify a
In Perl5, the following values are FALSE: undef, '0', 0, and ''.
What you fail to note is that each of these is false for a reason.
undef is false so that you can test an object for truth; if it
is undef it obviously contains no data, so it's false. 0 is false
so that you can test numbers for tru
Every now and then I have this discussion with people at work that involve Perl's
ideas of boolean truth. I usually break it down like this:
In Perl5, the following values are FALSE: undef, '0', 0, and ''.
Anything not in that list is considered TRUE in a boolean context. That means that
Perl
On Thu, Jun 24, 2004 at 12:06:14PM +0200, Michele Dondi wrote:
> However I wonder if an implicit stack could be provided for return()s into
> void context. It is well known that currently split() in void context has
> the bad habit of splitting into @_, which is the reason why doing that is
> de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michele Dondi wrote:
| I don't know if this is already provided by current specifications, but
| since I know of Perl6 that is will support quite a powerful system of
| function prototyping ("signatures"?), I wonder wether it will be possible
| to speci
I don't know if this is already provided by current specifications, but
since I know of Perl6 that is will support quite a powerful system of
function prototyping ("signatures"?), I wonder wether it will be possible
to specify a (finite number of) argument(s) on the left of functions, thus
allowing
This is yet another proposal that is probably a few years late. I've had
some (admittedly limited) experience with S-Lang in the past: the language
has currently a syntax that resembles much that of C but was originally
designed to be strongly stack-based and still is behind the scenes, a
conse
On Tue, 22 Jun 2004, Juerd wrote:
> > rename -v => 1, $orig, $new;
[snip]
> I think just using named arguments would be better and much easier.
>
> sub rename ($old, $new, +$verbose) {
> say "Renaming '$old' to '$new'" if $verbose;
On Tue, 22 Jun 2004, Brent 'Dax' Royal-Gordon wrote:
> I
40 matches
Mail list logo
