Re: == vs. eq
Tom Christiansen wrote:
Unless I'm very wrong, there are more whole numbers than natural
numbers. An induction should prove that there are twice as many.
We're probably having a language and/or terminology collision. By natural
numbers, I mean the positive integers. By whole numbers, I mean the
natural numbers plus the number zero.
[...]
I meant naturals plus 0 plus negative integers by whole numbers.
Nonethelesss, I was wrong and stand corrected. I'll think about my posts
a little more thoroughly in future before hitting the send button.
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: == vs. eq
Tom Christiansen wrote:
[...]
The price of that consideration would be to give the Mathematicians
blank looks on *their* faces for a very long time instead. Certainly,
they'll be quick to tell you there are just as many whole numbers
as naturals. So they won't know what you mean by equal up there.
[...]
Unless I'm very wrong, there are more whole numbers than natural
numbers. An induction should prove that there are twice as many.
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: == vs. eq
Luke Palmer wrote:
Luke Palmer:
# The first thing I noticed was the == / eq distinction. This
# has been invaluable for scripting, but since Perl 6 is
# desiring to be more of a formal language, I'm wondering
# whether the distinction is profitable.
[...]
Brent Dax:
Your desired standard sort of equality is provided by smartmatch.
$a ~~ $b
Don't get too hasty here, I actually did put some thought into this.
Smart match was not what I was thinking of.
[...]
# The solution that springs to mind is to conform to other
# languages' thought and make == polymorphically compare
# equality. Thanks to context-forcing, the string/numeric
# distinction is still there, at the expense of a little extra
# verbosity:
#
# +$a == +$b; # Numeric compare
# ~$a == ~$b; # String compare
# $a == $b; # Generic compare
Conciseness and precision are lost. What's gained?
Sorry, but how's precision lost here? As Luke points out, we'd free up
the eq operator to do more sophisticated comparisons like (deeply)
checking for identity of data structures.
Admittedly, this would be a major break with Perl5's idioms, especially
since eq would work the same in some situations in Perl6 as it did in
Perl5, but even ignoring that it'd be slower, it'd break in other
situations where joe average-scripter used it as (s)he used Perl5's eq
operator.
[...]
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: A6 Request: Change .req to .arity
Damian Conway wrote:
Larry wrote:
On the other hand, I could see an argument that said anyone who
doesn't know what .arity means shouldn't be writing routines that
depend on it...
That was more or less my line of thought.
Now, I think I'll dare claim my English is not exactly bad for a 21
year-old non-native speaker. Being a physics and CS student, I do also
have mathematical background, but it still took me a few seconds to
figure out arity *in this context*. Maybe that's because I can't think
of an exact German equivalent either; maybe it's because I don't think a
function's arity is quite the same as it's *minimum* number of
parameters? I mean, it makes sense in a functional language... but you
don't have functions with a variable number of arguments there.
To cut this short: I think req or reqargs or somesuch would be better.
Why choose the method names that sound more like computer science for
the very sake of that?
Steffen
--
sub'_{q} tsuJ}}_();sub's{seek+DATA,0,0}sub'p{print_}sub'r{reverse$_[0]}
@_=(('')x2,split ,DATA);s!!s,$_=DATA;s/}.*?}/$_[$s+1]/
if$s;s/(}.*?})/r$1/e;eval$_;p,[EMAIL PROTECTED];
__DATA__
} rehtona} } lreP} },rekcah}
Re: A6 Request: Change .req to .arity
Larry Wall wrote:
[...]
[I wrote:]
: maybe it's because I don't think a
: function's arity is quite the same as it's *minimum* number of
: parameters? I mean, it makes sense in a functional language... but you
: don't have functions with a variable number of arguments there.
Sure, but one can imagine having functions with a given arity that
can nonetheless be modified adverbially. In this view, required
parameters contribute to arity, but optional parameters are only
used for, er, options.
I can see your point, but I still think this is kind of warping the way
people think of an n-ary function (if they do think of functions to have
an arity in the first place).
Steffen
--
@n=([283488072,6076],[2105905181,8583184],[1823729722,9282996],[281232,
1312416],[1823790605,791604],[2104676663,884944]);$b=6;@c=' -/\_|'=~/./g
;for(@n){for$n(@$_){map{$h=int$n/$b**$_;$n-=$b**$_*$h;[EMAIL PROTECTED]
0..11;[EMAIL PROTECTED],[EMAIL PROTECTED];[EMAIL PROTECTED]\n[EMAIL PROTECTED];
Re: @array = %hash
Nicholas Clark wrote:
[...]
And what happens if I write
%hash4 = (Something, mixing, pairs = and, scalars);
1 23 4 5
Perl5 says Odd number of elements in hash assignment at -e line 1.
And Perl6 should, too.
IMHO, your example isn't too good anyway. Something involving a pair at the
place where a Perl5-like behaviour would expect to set a value would be even
a bit more evil.
Let's use this example:
%h = ( 'a', pk = 'pv', 'b', 'c');
Other than that, some possible behaviours I could think of would be:
- If the list contains scalars, consider pairs as two scalars (bad).
Resulting hash (key=value)
a = pk
pv = b
c = undef
- If the list contains pairs, assign the pairs, then do the Perl5-thing of
alternatingly assigning keys and values from the scalars.
a = b
pk = pv
c = undef
- Fatal error.
- Wherever a pair starts but a value is expected, add an undef.
a = undef
pk = pv
b = c
I think the latter would be most intuitive. Maybe.
Steffen
--
n=(544290696690,305106661574,116357),$b=16,c=' ,JPacehklnorstu'=~
/./g;for$n(n){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}c(0..9);
push@p,map{$c[$_]}@c[c($b..$#c)];$#c=$b-1}print@p;sub'c{reverse _}
Re: Hypothetical synonyms
Piers Cawley wrote:
Uri Guttman [EMAIL PROTECTED] writes:
{...]
couldn't that be reduced to:
m{^\s* $stuff := [ (.*?) | (\S+) ] };
the | will only return one of the grabbed chunks and the result of
the [] group would be assigned to $stuff.
Hmm... is this the first Perl 6 golf post?
Well, no, for two reasons:
a) There's whitespace.
b) The time's not quite ready for Perl6 golf because Larry's the only one
who would qualify as a referee.
And we all know that's not a recreational task :)
Steffen
--
@n=(544290696690,305106661574,116357),$b=16,@c=' ,JPacehklnorstu'=~
/./g;for$n(@n){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}c(0..9);
push@p,map{$c[$_]}@c[c($b..$#c)];$#c=$b-1}print@p;sub'c{reverse @_}
Re: Hypothetical synonyms
Nicholas Clark wrote:
On Thu, Aug 29, 2002 at 12:00:55AM +0300, Markus Laire wrote:
And I'm definitely going to try any future PerlGolf challenges also
in perl6.
Is it considered better if perl6 use more characters than perl5? (ie
implying probably less line noise)
or less (getting your job done more tersely?)
From the bit of Perl6 information I've gathered from the Apocalypses, the
Exegesises (is that really the plural? Sounds horrible.), and my
perl6-language reading, I'd say Perl6 is not only going to be a bit more
verbose (unless you use the dreaded use Perl5; pragma ;) ), but it'll also
be a Good Thing.
Applying that to Perl Golf, however, isn't possible. It doesn't make sense
to ask whether less line noise is better in golf. Anybody who has seen any
of the winning solutions should realize that whoever wrote that either used
some random string generator or tried to do create ASCII art from a color
scan of bird droppings.
Maybe I am just a bit frustrated that I had such a hard time understanding
some of the solutions. :)
It would be interesting to see whether there are classes of problems
that go in different directions.
I guess over 90 percent of problems will be longer; possibly about 60
percent being significantly longer. (Mainly because of the changes of A5.)
Steffen
--
n=(544290696690,305106661574,116357),$b=16,c=' ,JPacehklnorstu'=~
/./g;for$n(n){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}c(0..9);
push@p,map{$c[$_]}@c[c($b..$#c)];$#c=$b-1}print@p;sub'c{reverse _}
Re: auto deserialization
Nicholas Clark wrote:
[...]
If the compiler were able to see that my Date $bday = 'June 25, 2002';
is one statement that both types $bday as Date, and then assigns a
constant to it, is it possible to do the conversion of that constant
to a constant $bday object at compile time? (and hence get compile
time checking) Without affecting general run time behaviour.
While that may be possible (I can't tell, I gladly take Dan's word for it),
it doesn't make much sense IMHO. It means that you can only initialize those
objects with constants. That's not a problem for people who know Perl well,
but it is going to be one hell of a confusion for anybody learning Perl. I
can see people whining on clpm why they can't do my Dog $rex =
sub_returning_string();. Again IMHO, taking Perl's flexibility in *some*
cases is much worse than making it Java.
Steffen
--
n=(544290696690,305106661574,116357),$b=16,c=' ,JPacehklnorstu'=~
/./g;for$n(n){map{$h=int$n/$b**$_;$n-=$b**$_*$h;$c[@c]=$h}c(0..9);
push@p,map{$c[$_]}@c[c($b..$#c)];$#c=$b-1}print@p;sub'c{reverse _}
