RE: General Feelings on Apoc 3
Bart Lateur: # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote: # # Binary // # # The analogy to || is probably a bit too clever. My first reaction # was it's some sort of weird division operator. But it's servicable. # # I think it's very cute. I think of it as a skewed or, which is, er, # both what it both is, and what it looks like. If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
RE: NaN semantics
Jonathan Scott Duff # On Tue, Oct 09, 2001 at 10:17:26AM -0400, Dan Sugalski wrote: # Depending on what Larry's planning, we may weld in support # for imaginary # numbers. While they're mind-warping, in some ways they're # better than # having a line labeled Beyond here be dragons or something. # # Neat. It'd be nice to have the i syntax as well: 3+2i # # I can hear the crys now though Oh no! First ``x'', then ``v'', now # ``_'' and ``i''. Sheesh! When will it end?!? ;-) For consistency, I'd prefer to use is: 3+(2 is i). Well, either way, this is a good thing for properties to handle. GO PROPERTIES! ;^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 They *will* pay for what they've done.
Re: General Feelings on Apoc 3
On Tue, Oct 09, 2001 at 08:35:10AM -0700, Brent Dax wrote: Bart Lateur: # On Thu, 4 Oct 2001 03:22:55 -0400, Michael G Schwern wrote: # # Binary // # # The analogy to || is probably a bit too clever. My first reaction # was it's some sort of weird division operator. But it's servicable. # # I think it's very cute. I think of it as a skewed or, which is, er, # both what it both is, and what it looks like. If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? I like dor. default also seems natural, but long. Then again, I don't think else is ever legal unless if appears between braces, so that's another possibility if we wish to recycle syntax. $live.happy else die Sad Looks pretty nice. Perhaps confusing if folks think else and or mean the same thing. If else seems to iffish, perhaps it could even be or else, which is also not currently legal, AFAIK $live.happy or else die Sad Hmm gets me thinking evil thoughts... like having else be the low-prec. //, and then or else be synonymous with ``else die $!'' so you get: $live.happy or else Read my lips: NO NEW TOKENS! ;-) -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
RE: NaN semantics
Damian Conway wrote:
but I still have immense difficulty with the notion that:
$x == NaN
doesn't return true if $x contains NaN.
Anyone with a hardware background should have no difficulty with
this concept. All common HDLs have multi-valued logic systems,
including values like '0', '1' and 'x' (Some systems distinguish
9 different values!).
The language Verilog has 2 equality operators. The most common is
a == b, which returns false if a and/or b contains 'x'. But it
also provides a === b; which will return true if a and b are
identical (thus true if a and b are 'x').
The correct value of NaN == NaN should, of course, be NaN.
This value should exponentially spread through the code:
if ('cat' == 'dog')
{
$foo = 1
}
else
{
$foo = 0
}
assert($foo.isNaN); # true!
However, Perl6 is not a hardware simulator, so I have no expectation
that these semantics will be supported.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086
tel: 408 523 8071; http://www.fast-chip.com
Opinions my own; statements of fact may be in error.
Re: NaN semantics
Damian Conway wrote: Sigh. I *do* see your point of view (Laziness), but I still have immense difficulty with the notion that: $x == NaN doesn't return true if $x contains NaN. I *like* the proposed Perl6 semantics; it's DWIMier. The problem is just the name collision. Why not 'inval' (for invalid), or some such (badval?). This would preserve NaN in its IEEE sense for the numerical algorithm crew to use. I see the next problem, though; profusion of 'false' values. 0, , undef, inval, NaN, ... ??? There was a long thread that touched on this in the context of tristate logic in discussion of and around RFC 263, I think. -- -- Tim Conrow [EMAIL PROTECTED] |
Re: General Feelings on Apoc 3
Brent Dax wrote: If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? Oh man. If we've gone so far as 'dor', why not make it 'doh' :-) print stomach_state @beer,@donuts doh burp!!! -- -- Tim Conrow [EMAIL PROTECTED] |
Re: General Feelings on Apoc 3
On Tue, Oct 09, 2001 at 11:49:15AM -0700, Tim Conrow wrote: Brent Dax wrote: If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? Oh man. If we've gone so far as 'dor', why not make it 'doh' :-) print stomach_state @beer,@donuts doh burp!!! Well, that opens up a few possibilities... First of all, we'll want to have a unary defaulting operator. For example, $donuts should check the type of $donuts and do the same thing as $donuts is default The universal definition of default should return undef so that $donuts doh burp!!! Would do what you expect. In our next issue, I'll be getting into the intricacies of the chainable diddly-aye-o suffix operator -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
Re: NaN semantics
A quarter-baked idea: How about punting by using nan (all lowercase) as a boolean logic not-a-number, leaving NaN for someone to (later) create an IEEE style tristate not-a-number. Later: $foo == NaN; # NaN literal is not same as nan literal use NaN; NaN(expr);
string representations
In Python there are two string representations for objects: the canonical representation repr() and the normal (human readable) string representation str(). Would we want this dichotomy in perl 6 as well? The main difference between the two is that strings returned from repr() are directly evalable. e.g., the following would be equivalent: $a = foo\r\n; print $a; print _$a; print eval(repr($a)); That's probably a poor example of its utility, but I'm not as well versed in python to give repr() its due in a perl example. So ... comments? Anyone out there know python well enough to say why they have both repr() and str()? -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Just a thought...
On Tue, Oct 09, 2001 at 11:22:02AM +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier? I quite like the ruby/scheme idiom of
having boolean methods ending in a question mark. eg:
sub is_visible? {...}
I was gonna suggest that pre-Apoc 3 but ran into the same trouble with ?:
Hmm, $obj.meth! is a syntax error, but func! isn't. Damn.
For those of you that don't know, func! is another Ruby idiom that
differentiates between the version of a function that returns it's
results and the one which alters it's arguments in place. So, for
example:
# this would act like the perl5 chomp
my $num_chars = chomp! $string;
# this would leave $string alone and return the chomped string.
my $chomped_string = chomp $string;
Perhaps a little more useful:
# Sort as we know it.
my @sorted = sort @array;
# Sort in place.
sort! @array;
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
The eye opening delightful morning taste of expired cheese bits in sour milk!
Re: Just a thought...
On Tue, Oct 09, 2001 at 04:18:31PM -0400, Michael G Schwern wrote:
On Tue, Oct 09, 2001 at 11:22:02AM +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier? I quite like the ruby/scheme idiom of
having boolean methods ending in a question mark. eg:
sub is_visible? {...}
I was gonna suggest that pre-Apoc 3 but ran into the same trouble with ?:
Hmm, $obj.meth! is a syntax error, but func! isn't. Damn.
For those of you that don't know, func! is another Ruby idiom that
differentiates between the version of a function that returns it's
results and the one which alters it's arguments in place.
So, could you then apply that to method invocation as well:
$obj.meth1!.meth2!.meth3
I'm just trying to avoid:
$obj is meth1 is meth2.meth3
Which does not scan in my primative primate brain.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: string representations
On Tue, Oct 09, 2001 at 03:13:22PM -0500, Jonathan Scott Duff wrote:
the following would be equivalent:
$a = foo\r\n;
print $a;
print _$a;
print eval(repr($a));
That's probably a poor example of its utility, but I'm not as well
versed in python to give repr() its due in a perl example.
sub repr { my $str = shift; qq{\Q$str\E} }
or, Perl6ish:
sub repr ($str) { qq{\Q$str\E} }
Dunno what it's useful for, but Perl's got it.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Just a thought...
On 09 Oct 2001 11:22:02 +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier?
I'm sure it won't be. The reasoning for replacing ? with ?? is that
? is worth too much as a single character symbol, to sacrifice it on
such a rather lowly used operator. And now you want to reclaim it... for
no operator at all? That, I'm sure, is going into the entirely wrong
direction.
As in Lisp, you can use p.
sub is_visiblep { ... }
;-)
--
Bart.
Re: Just a thought...
Michael G Schwern [EMAIL PROTECTED] writes:
On Tue, Oct 09, 2001 at 11:22:02AM +0100, Piers Cawley wrote:
Does the change from ?: to ??:: mean that we can have '?' as a valid
character in an identifier? I quite like the ruby/scheme idiom of
having boolean methods ending in a question mark. eg:
sub is_visible? {...}
I was gonna suggest that pre-Apoc 3 but ran into the same trouble with ?:
Hmm, $obj.meth! is a syntax error, but func! isn't. Damn.
For those of you that don't know, func! is another Ruby idiom that
differentiates between the version of a function that returns it's
results and the one which alters it's arguments in place.
Actually, I think it was a scheme thing first, and once you know it
it's a really handy convention.
--
Piers
RE: General Feelings on Apoc 3
Brent asked: If we have 'and', 'or' and 'xor', can we have 'dor' (defined or) to be a low-precedence version of this? I actually suggested exactly that to Larry a few weeks back. He likes the idea, but is having trouble finding an acceptable name for the operator. Damian
RE: NaN semantics
Dave observed: but I still have immense difficulty with the notion that: $x == NaN doesn't return true if $x contains NaN. Anyone with a hardware background should have no difficulty with this concept. Yep. You, me, and the (comparative) handful of others in that category. ;-) Damian
Re: NaN semantics
Tim suggested: I *like* the proposed Perl6 semantics; it's DWIMier. The problem is just the name collision. Why not 'inval' (for invalid), or some such (badval?). This would preserve NaN in its IEEE sense for the numerical algorithm crew to use. And thus we circle back towards Cfail. I'll mention this to Larry (who's probably watching silently over us anyway). Damian
Re: NaN semantics
Tim suggested: How about punting by using nan (all lowercase) as a boolean logic not-a-number, leaving NaN for someone to (later) create an IEEE style tristate not-a-number. Err, I think not. Having CNaN and Cnan that differ so markedly in behaviour is probably a Recipe For Disaster. Better to have a totally different name if we must cowtow to the IEEE. Besides, I know you just want this so you can: write nan and pop; ;-) Damian
Re: NaN semantics
Damian == Damian Conway [EMAIL PROTECTED] writes: Damian Sigh. I *do* see your point of view (Laziness), but I still have immense Damian difficulty with the notion that: Damian $x == NaN Damian doesn't return true if $x contains NaN. Just think of it as a quantum number that hasn't collapsed. :) No two NaNs are alike! Read it as one of many non-numbers, chosen at random. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
