Re: C/C++ White-Box Unit Testing and Test::More
Andrew Pimlott [EMAIL PROTECTED] writes: On Wed, Jun 09, 2004 at 08:18:30AM -0700, Ovid wrote: As for porting a Test::More style framework, I tried doing that with Python and was actually doing well with it, but I was shot down pretty quickly. Any specific reasons why (is the discussion archived)? Is there any site that compares the styles? The xUnit style framework does a much better job of enforcing test isolation than Test::More does (but you have to remember that what Test::More thinks of as a test, xUnit thinks of as an assertion to be used *in* a test).
Re: our own decimal math lib
Uri Guttman wrote: SB == Scott Bronson [EMAIL PROTECTED] writes: SB Has anybody inquired to the GMP project as to the possibility of SB relaxing that restriction? If GMP truly is the best bignum SB implementation, I definitely think it's worth asking. Not AFAIK. Please try. i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. We can always switch the internals, as long as we keep it consistent at the surface. uri leo
Re: Another small task for the interested
Dan Sugalski wrote:
On Sun, 20 Jun 2004, Ion Alexandru Morega wrote:
Dan Sugalski wrote:
I checked in more of PDD 17, detailing parrot's base types. Some of
those types definitely don't exist (like, say, the string and bignum
type...) and could definitely use implementing. Should be fairly
straightforward, and would be a good way to get up to speed on writing
PMC classes.
Hello, i'm new to this list and to parrot programming, so i decided to
start with something simple. I implemented a String PMC that is pretty
much complete, it compiles, but i haven't tested it yet. It would be
great if someone had a look at it, and later when i write some tests
i'll check in a patch. The .pmc is attached.
Sorry this one sat so long. (Piers reminded me with the summary) I checked
in the PMC. Tests would be cool, to be sure. :)
Thanks much.
Actually Leo answered pretty quickly, and then you did too... but why
split hairs? :)
In the mean time i fixed some things that were wrong, added a few
functions and the tests. I found some weird things while doing this,
probably bugs. So here's the patch i promised.
The function string_make() in src/string.c reads in the documentation:
the the string reperesentation will default to enum_stringrep_unknown.
This doesn't happen. I changed a line in classes/undef.pmc which used this.
As i understand, the default implementation for the function
is_equal_str() in a PMC is to fall back to is_equal(). This works OK.
But when i actually tried to implement is_equal_str(), it turns out the
return condition is used backwards (true means false :). BTW i didn't
find any documentation for is_equal_str(), it was generated by
genclass.pl. I commented out my implementation of is_equal_str() and the
tests pass now... it's still there if anyone wants to play with it.
Now back to the String class. I should say that much of the code was
inspired by PerlString, and the tests, well, i just took them from
perlstring.t. There's still some original code there tough :)
Leo suggested to subclass PerlString from String, but it's already
subclassed from PerlScalar, do PMC's have multiple inheritance?
And a noob question: what does the $Id: line at the top of each file do?
Is it generated or do I have to uptade it myself?
alexm
diff -ruN parrot/MANIFEST my_parrot/MANIFEST
--- parrot/MANIFEST 2004-06-23 18:00:09.0 +0300
+++ my_parrot/MANIFEST 2004-06-23 21:35:26.0 +0300
@@ -94,6 +94,7 @@
classes/scratchpad.pmc[]
classes/sharedref.pmc []
classes/slice.pmc []
+classes/string.pmc[]
classes/stringarray.pmc []
classes/sub.pmc []
classes/timer.pmc []
@@ -2749,6 +2750,7 @@
t/pmc/sarray.t[]
t/pmc/scratchpad.t[]
t/pmc/signal.t[]
+t/pmc/string.t[]
t/pmc/sub.t []
t/pmc/sys.t []
t/pmc/threads.t []
diff -ruN parrot/classes/string.pmc my_parrot/classes/string.pmc
--- parrot/classes/string.pmc 1970-01-01 02:00:00.0 +0200
+++ my_parrot/classes/string.pmc2004-06-23 21:31:07.0 +0300
@@ -0,0 +1,668 @@
+/*
+Copyright: 2003 The Perl Foundation. All Rights Reserved.
+$Id: string.pmc,v 1.0 2004/06/21 20:31:57 alexm Exp $
+
+=head1 NAME
+
+classes/string.pmc - String PMC Class
+
+=head1 DESCRIPTION
+
+CString extends Cmmd_default to provide a string for languages
+that want a Cstring type without going to an S register. Acts as a
+wrapper for the functions in /src/string.c
+
+=head2 Methods
+
+=over 4
+
+=cut
+
+*/
+
+#include parrot/parrot.h
+
+pmclass String {
+
+/*
+
+=item Cvoid init()
+
+Initializes the string.
+
+=cut
+
+*/
+
+void init () {
+PMC_str_val(SELF) =
+string_make_empty(INTERP, enum_stringrep_one, 0);
+PObj_custom_mark_SET(SELF);
+}
+
+/*
+
+=item Cvoid mark()
+
+Marks the string as live.
+
+=cut
+
+*/
+
+void mark () {
+if(PMC_str_val(SELF))
+pobject_lives(INTERP, (PObj *)PMC_str_val(SELF));
+}
+
+/*
+
+=item CPMC* clone()
+
+Creates a copy of the string.
+
+=cut
+
+*/
+
+PMC* clone () {
+PMC* dest = pmc_new_noinit(INTERP, SELF-vtable-base_type);
+PObj_custom_mark_SET(dest);
+PMC_str_val(dest) = string_copy(INTERP,PMC_str_val(SELF));
+return dest;
+}
+
+/*
+
+=item CINTVAL get_integer()
+
+Returns the integer representation of the string.
+
+=cut
+
+*/
+
+INTVAL get_integer () {
+STRING *s = (STRING*) PMC_str_val(SELF);
+return string_to_int(INTERP, s);
+}
+
+/*
+
+=item CFLOATVAL get_number()
+
+Returns the floating-point representation of the string.
+
Re: The Pie-thon benchmark
Dan Sugalski wrote: it's not exactly exciting watching two people hit return three times in front of a roomful of people. Although watching two people hit each other in the face with custard pies three times in front of a roomful of people may be a lot more fun. Progamming language benchmarks vs pie throwing. No contest. A
Re: cmd line like switches for functions and operators.
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:
It's already being done:
rename $orig, $new :verbose;
sub rename($orig, $new, +$verbose) {
say Renaming `$orig' to `$new' if $verbose;
On Tue, 22 Jun 2004, Luke Palmer wrote:
No, builtins can and will have named arguments. And you can even add
your own to builtin functions:
Well, much of what has been said here seems to be quite a bit above my
head as far as my Perl6 knowledge is concerned. However I'd like to
provide some context for my proposal: one motivation is to give yet
more WTDI, and another one is to give a quick'n'easy WTD certain things.
AIUI the first point is already addressed as explained in your mails
above. As for the second one, the key concept is that of suitable
defaults. For example, using Perl5 syntax, here's what I mean:
perl -le 'unlink and print removing $_ or warn something: $!\n for *.txt'
Well, it would be nice if that may just be
perl -e 'unlink *.txt :v'
And here of course I do *not* want to roll my own version of unlink to
manage the verbose info, otherwise it wouldn't be easier than in the
first attempt above. Even if put in a package, it would imply more
typing:
perl -MVerbose -e 'unlink *.txt :v'
^^^ or even more letters!!
Of course you may ask why not using
rm -v *.txt
from start instead, but then there are indeed situations in which perl is
actually useful. For example one I can think of (and done in practice) is
this:
perl -lne 'rename $_, do{($t=$_)=~s/.../.../; $t}' files.txt
^^ fake!
[no strictures for one-liners!]
Well, IMHO it would be a Good Thing(TM) to have a few letters long (or a
one letter long) switch to print verbose info... of course it would be
most useful in one-liners but as many other things it would come handy
also in more complex scripts...
Michele
--
Se non te ne frega nulla e lo consideri un motore usa e getta, vai
pure di avviatore, ma e' un vero delitto. Un po' come vedere un
cavallo che sodomizza un criceto!!!
- Cesare/edizioni modellismo sas su it.hobby.modellismo
A stack for Perl?
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 consequence of which is that it supports an (undocumented, AFAIK!) alternative RPN syntax. Now Perl is not like that, although internally Perl5's bytecode is stack-based, whereas it's known that Perl6's one will be register-based. 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 deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... Any thoughts? Michele -- Comments should say _why_ something is being done. Oh? My comments always say what _really_ should have happened. :) - Tore Aursand on comp.lang.perl.misc
user-defined operators?
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 to create user-defined operators. I had tried sml (a functional language) and despite its being really simple if compared to Perl, it provided this functionality... Michele -- Dante, _The Inferno_, in particular the line about, ``Abandon all hope ye who enter here.'' - William F. Adams in comp.text.tex, Re: Book Suggestion for MS Word?
Re: Another small task for the interested
Ion Alexandru Morega wrote: In the mean time i fixed some things that were wrong, added a few functions and the tests. I found some weird things while doing this, probably bugs. So here's the patch i promised. Can you please rediff string.pmc - it is in the CVS already, but you did provide the whole file. I've checked in the other changes though. (3 tests failing - likely becausof missing pieces from string.pmc) The function string_make() in src/string.c reads in the documentation: the the string reperesentation will default to enum_stringrep_unknown. A new string will get the default / global settings from the interpreter, which we don't have yet. As i understand, the default implementation for the function is_equal_str() in a PMC is to fall back to is_equal(). This works OK. is_equal_str() forces both sides being strings. This is the default for strings is_equal, so they are the same. But when i actually tried to implement is_equal_str(), it turns out the return condition is used backwards (true means false :). Its modeled like strcmp(). Now back to the String class. I should say that much of the code was inspired by PerlString, and the tests, well, i just took them from perlstring.t. There's still some original code there tough :) Leo suggested to subclass PerlString from String, but it's already subclassed from PerlScalar, do PMC's have multiple inheritance? Not really albeit OrderedHash does it. But for PerlString its totally ok to inherit from String only. Most of the functionality is the same. And a noob question: what does the $Id: line at the top of each file do? Is it generated or do I have to uptade it myself? Its generated by CVS. The variable $Id$ gets expanded to what you see there -- so no. alexm Thanks, leo
Re: user-defined operators?
-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 specify a (finite number of) argument(s) on the left of functions, thus | allowing to create user-defined operators. I had tried sml (a functional | language) and despite its being really simple if compared to Perl, it | provided this functionality... If SML is anything like Haskell, user-defined operators are really just syntactic sugar around normal function definitions, with appropriate allowances in the grammar for arbitrary operators to exist and be parsed correctly. Haskell also has an interesting backticks operator, which turns any two-argument function into an infix operator, and is generally used for readability purposes. Thus, although you can do modulus with the 'mod' function like this: mod 3 4 you can also write 3 `mod` 4 which can be handy when trying to get an arithmetic-type feel to your programs. I doubt Perl would need something like this though. Haskell of course also lets you do things like infixr 3 +++ which defines a right-associative infix operator at precedence level 3, denoted by the token '+++' and later you can say something like (+++) :: Num a = a - a - a x +++ y = x + y which defines the +++ operator to have exactly the same effect as + (although probably with different precedence, I have no idea what the numeric precedence level of + is in Haskell, and indeed if + is right or left associative, as I always get those two muddled up, so that might be different too) when applied to numbers. Pretty pointless really, unless you wanted a tight-binding + or a backwards one, but you get the idea. Most combinator parsing libraries use user-defined operators to denote parser combination and choice, and GUI libraries tend to use them to denote things like signal connection, property setting and so forth. Wrangling this back to some sort of on-topicness, it would be great if Perl could have user-defined operators that actually work properly. I'm thinking new operator characters (Unicode's got lots left), and also the ability to define short-circuit operators like C's and || (I can't remember what they've become in Perl 6, did they change? I seem to remember them changing). Not being able to do this is a major weakness in C++'s operator overloading, because it effectively means that and || are untouchable unless you really want to mess with other people's heads, and demonstrate the only point operator overloading has against it (that is the potential disruption of expected semantics; this is all IMO of course). So can we at least have the ability to define short-circuit operators, even if we can't define new ones? -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA2rP20UvYjCBpIlARAsFKAJoCBjgP8+wmbQP3XO1HLD+6AC43DQCfVvj3 kTT9cYnblCADyVCWCrpcpD0= =G7FE -END PGP SIGNATURE-
Re: our own decimal math lib
LT == Leopold Toetsch [EMAIL PROTECTED] writes: LT Uri Guttman wrote: SB == Scott Bronson [EMAIL PROTECTED] writes: SB Has anybody inquired to the GMP project as to the possibility of SB relaxing that restriction? If GMP truly is the best bignum SB implementation, I definitely think it's worth asking. LT Not AFAIK. Please try. i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. LT The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon LT benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. LT We can always switch the internals, as long as we keep it consistent LT at the surface. sorry about the timing. and dan and i discussed the ability to swap the lib later so that is how we should go with my lib. but it still needs work so if anyone wants to get into parrot this way, let me know. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
[perl #30444] [PATCH] string.pmc
# New Ticket Created by Ion Alexandru Morega
# Please include the string: [perl #30444]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30444
Here's the patch, all the tests should pass now. I'm working on some
more tests and then i'll rewrite perlstring.pmc and possibly the other
perlscalar subclasses (derive them from Float, Integer, etc) if that's
needed.
--- parrot/classes/string.pmc 2004-06-23 18:36:04.0 +0300
+++ my_parrot/classes/string.pmc 2004-06-24 15:14:21.0 +0300
@@ -1,6 +1,6 @@
/*
-Copyright: 2004 The Perl Foundation. All Rights Reserved.
-$Id: string.pmc,v 1.1 2004/06/23 15:36:04 dan Exp $
+Copyright: 2003 The Perl Foundation. All Rights Reserved.
+$Id: string.pmc,v 1.0 2004/06/21 20:31:57 alexm Exp $
=head1 NAME
@@ -12,7 +12,7 @@
that want a Cstring type without going to an S register. Acts as a
wrapper for the functions in /src/string.c
-=head2 Functions
+=head2 Methods
=over 4
@@ -22,16 +22,10 @@
#include parrot/parrot.h
-pmclass String extends mmd_default {
+pmclass String {
/*
-=back
-
-=head2 Methods
-
-=over 4
-
=item Cvoid init()
Initializes the string.
@@ -41,8 +35,9 @@
*/
void init () {
+PMC_str_val(SELF) =
+string_make_empty(INTERP, enum_stringrep_one, 0);
PObj_custom_mark_SET(SELF);
-PMC_str_val(SELF) = string_make_empty(INTERP, enum_stringrep_one, 0);
}
/*
@@ -54,6 +49,7 @@
=cut
*/
+
void mark () {
if(PMC_str_val(SELF))
pobject_lives(INTERP, (PObj *)PMC_str_val(SELF));
@@ -68,6 +64,7 @@
=cut
*/
+
PMC* clone () {
PMC* dest = pmc_new_noinit(INTERP, SELF-vtable-base_type);
PObj_custom_mark_SET(dest);
@@ -84,6 +81,7 @@
=cut
*/
+
INTVAL get_integer () {
STRING *s = (STRING*) PMC_str_val(SELF);
return string_to_int(INTERP, s);
@@ -98,6 +96,7 @@
=cut
*/
+
FLOATVAL get_number () {
STRING *s = (STRING*) PMC_str_val(SELF);
return string_to_num(INTERP, s);
@@ -113,6 +112,7 @@
=cut
*/
+
BIGNUM* get_bignum () {
/* XXX */
return (BIGNUM*)0;
@@ -127,6 +127,7 @@
=cut
*/
+/* XXX useless? */
STRING* get_string () {
return (STRING*) PMC_str_val(SELF);
}
@@ -140,6 +141,7 @@
=cut
*/
+
INTVAL get_bool () {
STRING *s = (STRING*) PMC_str_val(SELF);
return string_bool(INTERP, s);
@@ -154,6 +156,7 @@
=cut
*/
+
void set_integer_native (INTVAL value) {
PMC_str_val(SELF) = string_from_int(INTERP, value);
}
@@ -167,6 +170,7 @@
=cut
*/
+
void set_number_native (FLOATVAL value) {
PMC_str_val(SELF) = string_from_num(INTERP, value);
}
@@ -181,6 +185,7 @@
=cut
*/
+
void set_bignum_native (BIGNUM* value) {
/* XXX */
}
@@ -194,6 +199,7 @@
=cut
*/
+
void set_string_native (STRING* value) {
PMC_str_val(SELF) = value;
}
@@ -207,8 +213,10 @@
=cut
*/
+
void assign_string_native (STRING* value) {
-PMC_str_val(SELF) = string_copy(INTERP, value);
+PMC_str_val(SELF) =
+string_set(INTERP, PMC_str_val(SELF), value);
}
/*
@@ -221,15 +229,17 @@
=cut
*/
+
void set_string_same (PMC* value) {
-PMC_str_val(SELF) = PMC_str_val(value);
+PMC_str_val(SELF) =
+string_set(INTERP, PMC_str_val(SELF), PMC_str_val(value));
}
/*
=item CVOID set_pmc(PMC* value)
-Sets the value of the string to the value of
+Sets the value of the string to the string value of
the specified CPMC.
=cut
@@ -243,7 +253,7 @@
=item CVOID assign_pmc(PMC* value)
-Sets the value of the string to the value of
+Sets the value of the string to the string value of
the specified CPMC.
=cut
@@ -251,7 +261,7 @@
*/
void assign_pmc (PMC* value) {
STRING *s = VTABLE_get_string(INTERP, value);
-PMC_str_val(SELF) = string_copy(INTERP, s);
+PMC_str_val(SELF) = string_set(INTERP, PMC_str_val(SELF), s);
}
/*
@@ -275,7 +285,7 @@
=item CVOID bitwise_xors_str(PMC* value, PMC* dest)
=cut
=item CVOID bitwise_nots(PMC* value)
-=cut
+
These functions perform bitwise operations on entire
strings, and place the result in Cdest.
@@ -285,68 +295,74 @@
void bitwise_or (PMC* value, PMC* dest) {
STRING *s = PMC_str_val(SELF);
STRING *v = VTABLE_get_string(INTERP, value);
-VTABLE_set_string_native(INTERP, dest, string_bitwise_or(INTERP, s, v, NULL));
+VTABLE_set_string_native(
+INTERP, dest, string_bitwise_or(INTERP, s, v, NULL));
}
void bitwise_and (PMC* value, PMC* dest) {
STRING *s = PMC_str_val(SELF);
STRING *v = VTABLE_get_string(INTERP, value);
-VTABLE_set_string_native(INTERP, dest, string_bitwise_and(INTERP, s, v, NULL));
+VTABLE_set_string_native(
+INTERP, dest,
confused parameter order asking for trouble
I've just fallen into this trap, and I doubt I'll be the last one:
void Parrot_PMC_set_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc, Parrot_Int
value, Parrot_Int key) {
VTABLE_set_integer_keyed_int(interp, pmc, key, value);
}
Is there any reason why the vtable is key, value but the extension interface
is value, key? This parameter transposition strikes me as asking for trouble.
I'll patch everything in core to make value last if consensus is that this
is the right thing to do.
Nicholas Clark
Re: A stack for 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 deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... In the interest of laziness, it's best to identify a clear need (and clear semantics!) before implementing something. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
definitions of truth
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 Perl5 has some notions of truth that confuse some folk. I mean, I can understand 00 being true, even if it seems a little odd to me personally, but \0??? How is a single null byte *true*? Okay, so it's binary data. So is 0 and 0, if you look at it that way. I realize the internal representations are different, but the programmer shouldn't have to care about that. I just figure that if my bit of $data contains one byte, and I'm checking that $data for boolean truth, I'd expect a null to be false, as would ba-zillions of C programmers (from which backgroud I came). I know we aren't trying so hard to imitate C behavior anymore, but still, doesn't this violate the principle of least surprise? So my question is this, with apology for the ramble aside from P6's other changes, is a single null byte of binary data still going to register as TRUE, or will it now be what seems to me the more sensible FALSE? Paul * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 113
xUnit vs. Test::More
--- Piers Cawley [EMAIL PROTECTED] wrote: The xUnit style framework does a much better job of enforcing test isolation than Test::More does (but you have to remember that what Test::More thinks of as a test, xUnit thinks of as an assertion to be used *in* a test). After working with xUnit style testing for almost a year, I definitely agree with this assessment. However, I think each style has its merits. With xUnit frameworks, each test will set up its data in the database, run through its asserts and then rollback the data. The setup and teardown methods ensure that each test is isolated from all other tests and you thus don't have accidental dependencies. The also impose a considerable overhead. At my current position, we've managed to get our test suite (xUnit style) running fast enough that it takes about 50 minutes to run. At my previous job, a comparable size test suite using Test::More took less than 5 minutes to run (I judge comparable sized by comparing Test::More tests to xUnit asserts.) Between the two, the 50 minute tests suite is probably more robust, but taking 10 times as long to run means that we've been bitten a few times by programmers who are in a hurry and don't run the full suite for a change that can't break anything. The other concern I've had with our style of xUnit testing is that we're testing behavior, but not the actual data. With Test::More, we tested against a copy of the live database (when possible -- but this definitely caused some issues) and we sometimes caught data problems that xUnit style testing seems less likely to catch. The reason for this is quite simple: when you setup the data, you're setting up your *idea* of what the data should be. This might not match what your data actually is. Am I missing something fundamental? The long test times and the lack of real data testing are two weaknesses that I would like to correct in our current system, but I see how beneficial xUnit testing is, so I'm concerned about introducing fixes that weaken our testing strategy. How do others deal with this? Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Devel::Cover bug
Hi,
I've run into Can't call method add_statement on an undefined value
running Devel::Cover. Apologies if this was reported before, but the
list archive is not searchable. I am using perl 5.8.4 and Devel::Cover 0.46.
To reproduce the bug, run
/opt/perl/bin/perl -MDevel::Cover -MFooBar -e FooBar-new-test_foo
The files FooBar.pm and CodeRef.pm are attached.
The bug occurs while calling $sub in CodeRef::to_string. It is probably
related to using B::Deparse, but I was not able to minimize the code
further and still reproduce the error.
Simon
--
Simon (Vsevolod ILyushchenko) [EMAIL PROTECTED]
http://www.simonf.com
Terrorism is a tactic and so to declare war on terrorism
is equivalent to Roosevelt's declaring war on blitzkrieg.
Zbigniew Brzezinski, U.S. national security advisor, 1977-81
package FooBar;
sub new {
my $proto = shift;
my $self = {};
bless $self, $proto;
return $self;
}
use CodeRef;
my $sub = sub {
my $str1 = shift;
};
my $assertion = CodeRef-new($sub);
*{FooBar::test_foo} =
sub {
my $self = shift;
$assertion-do_assertion(@_);
};
1;
package CodeRef;
use strict;
sub new {
my $class = shift;
my $code = shift;
bless \$code = $class;
}
sub do_assertion {
my $self = shift;
$self-to_string(aaa);
}
sub to_string {
my $self = shift;
require B::Deparse;
my $deparser ||= B::Deparse-new(-p);
$deparser-coderef2text($$self);
}
1;
Re: Q: class name hashes
Dan Sugalski [EMAIL PROTECTED] wrote: I just went digging through the docs to make sure I knew what was going on. __repr__ is the python-visible name for our get_string vtable method. We don't need any support beyond tying names together in the namespaces, so far as I can see. Sure? x=0.3 str(x) '0.3' repr(x) '0.2' s=a\n str(s) 'a\n' repr(s) 'a\\n' Dan leo
Re: Basics of the base PMC class set
Dan Sugalski [EMAIL PROTECTED] wrote: At 2:38 PM +0200 6/11/04, Bernhard Schmalhofer wrote: how about having complex numbers as another basic PMC? At least QCL, http://tph.tuwien.ac.at/~oemer/qcl.html, C99 and PDL, http://pdl.perl.org/, have them as a basic type. As well as Python. For right now I want to hold off--the basic PMC types all correspond to a low-level type, and we don't have a complex low-level type. We can think about complex numbers later on, probably as part of the library. Think faster :) I think that a complex PMC type is in order. We can move it to a Python library later, when we do classes cleanup. Dan leo
Re: xUnit vs. Test::More
The other concern I've had with our style of xUnit testing is that we're testing behavior, but not the actual data. With Test::More, we tested against a copy of the live database (when possible -- but this definitely caused some issues) and we sometimes caught data problems that xUnit style testing seems less likely to catch. The reason for this is quite simple: when you setup the data, you're setting up your *idea* of what the data should be. This might not match what your data actually is. I take the approach that these are fundamentally two different things. first, as a developer you need to code against what your idea of the data is, taking the known data gives expected results approach to your tests. a good example is a subroutine that uses a regex to parse the data - the best you can do while developing the routine is to make sure your regex handles the conditions of some sample data (which you may in fact be making up in your head). once that is done, you can bang against the routine with real data and see how it holds up. if you find that you get a condition that you didn't think about before, you now have two tests you can use - the real data that caused the error, and some minimal data extracted from the real data that isolates the problem which can be added to your developer tests. this is what I have been doing lately. call them whatever you like, as I'm sure that the XP people have some fancy nomenclature for it, but the idea is to separate developer-level (used while coding) from API-level tests (real-world API usage) and use both in your testing process. the former is what I use for coverage purposes, tracing through the logical branches in as isolated a context as possible. with the latter I try to tie in live (test) databases, servers, and so on, relying on that to fill in the gaps that are exposed in an isolated test environment. HTH --Geoff
Re: C/C++ White-Box Unit Testing and Test::More
On 24 Jun 2004, at 07:09, Piers Cawley wrote:
[snip]
The xUnit style framework does a much better job of enforcing test
isolation than Test::More does (but you have to remember that what
Test::More thinks of as a test, xUnit thinks of as an assertion to be
used *in* a test).
To be fair to Test::More and friends xUnit doesn't /enforce/ test
isolation any more than Test::More prevents it. Writing isolated tests
with Test::More is trivial, just do something like:
sub make_fixture {
return ( Cash-new(10), Cash-new(20) );
};
isa_ok( $_, 'Cash' ) foreach make_fixture();
{
my ($ten, $twenty) = make_fixture();
is_deeply $ten + $twenty, Cash-new(30);
};
... etc ...
I had a mild rant about this on the TDD list a few months back. You can
write isolated tests in a procedural style quite easily. You can also
easily write tightly-coupled tests in an xUnit style. It's all reliant
on developer discipline. xUnit provides some infrastructure that helps,
but it doesn't enforce it. Developers do that.
(Apologies for rant. Consider it a symptom of the number of ghastly
xUnit test classes that I've seen with 100 line test methods and no
setup methods.)
Where xUnit wins for me are in the normal places where OO is useful
(abstraction, reuse, revealing intention, etc.). Where xUnit loses are
the times when you don't need it all the extra infrastructure and it
just becomes overhead that gets in the way of understanding the test
suite.
Where the Perl testing framework wins for me:
- it gives me the flexibility to do both procedural and xUnit styles as
I see fit
- it also provides SKIP and TODO tests, which I've not come across
elsewhere. TODO test in particular I find useful for tracking technical
debt
- Test::Harness has a nice ASCII protocol that I can use to feed
non-Perl stuff into the testing framework
Anyway enough rambling ;-)
Adrian
Re: user-defined operators?
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 (finite number of) argument(s) on the left of functions, thus : allowing to create user-defined operators. I had tried sml (a functional : language) and despite its being really simple if compared to Perl, it : provided this functionality... Yes, this is already provided for with infix/postfix operators/macros, with the caveat that if you wish to specify multiple arguments to the left, you'll have to do one of: 1) give your operator a looser precedence than comma 2) group the arguments with some kind of brackets or parens to make them a single argument 3) put some kind of introductory macro out front that parses things the way you want 4) write the definition of your infix/postfix macro to have incestuous knowledge of the parser in order to slurp the leftwise arguments that have already been reduced by the ordinary grammar. Simple. :-) Actually, I suspect that infix macros have precedence much like operators, so #4 probably reduces to #1. (Macros differ from ordinary operators in how they treat the subsequent text, not the preceding text.) Larry
Re: definitions of truth
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 vigilant programmers, has led to a great '0' hole, where many Perl programs correctly handle all possible input except for one: a string consisiting of a single 0. To ensure that your program doesn't suffer from the '0' hole, you need to use frob($k) if defined($k) length($k); anywhere you would normally just say frob($k) if $k. This somewhat strange incantation has become idiomatic in Perl5. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? As I understand it, the addition of properties in Perl6 (See the Apocalypse 12 article) allows for even undefined values to be true if you choose to make them so. That's the way I understand it too. You can also do the same in reverse, making it so your function can return, say, Failure! but evaluate to false. 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 can be false for floats, etc. Unfortunately, so that machine-converted Perl5 code still works, I think that untyped variables will probably still need to follow this oddball rule. Am I understanding correctly? Thanks, - Scott
Re: user-defined operators?
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 : | 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 to create user-defined operators. I had tried sml (a functional : | language) and despite its being really simple if compared to Perl, it : | provided this functionality... : : If SML is anything like Haskell, user-defined operators are really just : syntactic sugar around normal function definitions, with appropriate : allowances in the grammar for arbitrary operators to exist and be parsed : correctly. Same in Perl 6. For instance, to call the binary addition operator C $a + $b by its true name, you'd say C infix:+($a,$b) . When you define an operator, you always use the true name form. : Haskell also has an interesting backticks operator, which turns any : two-argument function into an infix operator, and is generally used for : readability purposes. Thus, although you can do modulus with the 'mod' : function like this: : : mod 3 4 : : you can also write : : 3 `mod` 4 : : which can be handy when trying to get an arithmetic-type feel to your : programs. I doubt Perl would need something like this though. It would be easy to define a meta-operator in Perl 6 to do this, but I also doubt that Perl will need it to be standard. : Haskell of course also lets you do things like : : infixr 3 +++ : : which defines a right-associative infix operator at precedence level 3, : denoted by the token '+++' : : and later you can say something like : : (+++) :: Num a = a - a - a : x +++ y = x + y : : which defines the +++ operator to have exactly the same effect as + : (although probably with different precedence, I have no idea what the : numeric precedence level of + is in Haskell, and indeed if + is right or : left associative, as I always get those two muddled up, so that might be : different too) when applied to numbers. Pretty pointless really, unless : you wanted a tight-binding + or a backwards one, but you get the idea. : Most combinator parsing libraries use user-defined operators to denote : parser combination and choice, and GUI libraries tend to use them to : denote things like signal connection, property setting and so forth. And here we see a weakness of Haskell's approach: you need to know the numeric precedence level. In Perl 6, all precedence levels are defined relative to existing operators. You don't have to care about the numeric level, and in fact, the actual precedence levels are probably encoded with strings internally rather than numbers, because that makes it trivial to add an arbitrary number of precedence levels between any other two precedence levels without having to resequence. Precedence levels are a bit like surreal numbers in that respect. But the user doesn't have to know that... : Wrangling this back to some sort of on-topicness, it would be great if : Perl could have user-defined operators that actually work properly. I'm : thinking new operator characters (Unicode's got lots left), Gee, I'm thinking the same thing. Fancy that. 'Course, the fact that I already said as much in the Apocalypses could have something to do with it. :-) : and also the : ability to define short-circuit operators like C's and || (I can't : remember what they've become in Perl 6, did they change? I seem to : remember them changing). Not being able to do this is a major weakness : in C++'s operator overloading, because it effectively means that and : || are untouchable unless you really want to mess with other people's : heads, and demonstrate the only point operator overloading has against : it (that is the potential disruption of expected semantics; this is all : IMO of course). Well, any operator or function that knows how to call a closure can function as a short-circuit operator. The built-in short-circuit operators are a bit special insofar as they're a kind of macro that treats the right side as an implicit closure without you having to put braces around it. No reason in principle you couldn't write your own infix macro to do the same thing. : So can we at least have the ability to define short-circuit operators, : even if we can't define new ones? Already there. You can even define new short-circuit operators. The new ones can even be Unicode operators, if you're willing to go into hiding for the next five years or so till most everyone learns how to type Unicode. Alternately, be willing to stare down the occasional lynch mob... On the other hand, we've tried to make it trivially easy to defer evaluation of a chunk of code. All you have to do is slap some curlies around it. Larry
Re: definitions of truth
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
Re: definitions of truth
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 can be false for floats, etc. I think this makes sense: string: undef, number: undef, 0 (implies 0.0) other: convert to number and then decide. Anything that can't naturally be converted to a number (i.e. would be invalid syntax if unquoted) is true. /me wanted to write this in Perl 6, but couldn't think of a good way to represent true and false when returning from is_true :) Perhaps having real true and false values (where true cannot be false and false cannot be true) would make a lot of things much easier. I, for one, would like return true; (where true is undef-ish: a keyword that always returns the same value). Juerd
Re: cmd line like switches for functions and operators.
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 (code, +$times = Inf) {
: code() for 1..$times;
: }
:
: This is a plausable routine. Now look how it's called:
:
: repeat {
: print I'm ;
: print doing ;
: print stuff\n;
: } :times(4);
:
: This is a horrid violation of the end weight principle.
Fer shure.
: Much nicer is the illegal:
:
: repeat :times(4) {
: print I'm ;
: print doing ;
: print stuff\n;
: }
For some time I have been contemplating allowing (at least) a single
closure parameter to come at the end after the list parameter. Otherwise
it becomes rather difficult to write a Cfor loop without chicanery.
It's not clear to me, though, how cascaded if/elsif/else blocks should
come in. I'm leaning towards thinking that it still comes in as a
single closure, but with properties that contain the cascaded closures.
We'll have to be careful to make sure the list can be unambiguously left
out entirely, particularly when we want to pipe to such a function. Also,
a form like
for 1... { foo() }
reminds us that we can't just evaluate the list and pop off the closure at
at run time. :-)
Larry
Re: definitions of truth
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 strings, undef and 0 can be false : for integers, undef, 0, and 0.0 can be false for floats, etc. : : I think this makes sense: : : string: undef, : number: undef, 0 (implies 0.0) : other: convert to number and then decide. Anything that can't : naturally be converted to a number (i.e. would be invalid syntax if : unquoted) is true. Nope, various user-defined types will want to define their own version of truth. That's precisely what you're doing when you say 0 but true, for instance. : /me wanted to write this in Perl 6, but couldn't think of a good way to : represent true and false when returning from is_true :) 0 and 1 works pretty well, according to Professor Boole... :-) : Perhaps having real true and false values (where true cannot be false : and false cannot be true) would make a lot of things much easier. I, for : one, would like return true; (where true is undef-ish: a keyword : that always returns the same value). 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 call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) It's likely that untyped scalars will still treat the string 0 as false, but that any kind of explicitly typed string will treat only the null string as false. (The special 0 rule will not pose as much trouble for Perl 6 as for Perl 5, because most iteration will be done with Cfor rather than Cwhile, and a Cfor terminates when its iterator runs out, not when the data becomes false. Plus we'll have the // operator.) Larry
Re: definitions of truth
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 false is sensible. 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. So it really wouldn't make sense to have them being treated differently for truth purposes. As a related question, why is 0 false, but 0.0 is true? Floats are second-class citizens? '0' is the string representation of zero. 0.0 is also zero. But 0 and 0.0 (and 0x, and 2 - 2, and ...) are all the same zero, and all stringify to '0'. '0.0' is not a representation of that same zero; it's a string that would evaluate to zero if converted to a number, but it isn't interchangeable with the other zeros. If you think '0.0' should be false, what about '0x' or '2 - 2' or '$x - $x'? Smylers
Re: definitions of truth
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 call away for known types within known conditionals, of course. It had better, or evaluating the truth of .boolean will end up calling .boolean again... :-) I didn't know about the (to-be) existence of .boolean. It makes things fun and easy, though. However, is the name boolean final? I would prefer true, perhaps with a corresponding false. That is, assuming that there will be $foo.defined and $foo.empty. Hm. I wonder where (and if) I read about .empty. Can't find it. not when the data becomes false. Plus we'll have the // operator.) I'll be wanting a length-or. Perl 6 will make coding it easy enough to not need it in the core. But the operator needs a symbol. I'm assuming infix: will work. But will there be a way to ask Perl if syntax can be used without introducing possible ambiguity? A circumfix ++ operator won't work for several reasons. What will Perl do if you try defining one? Please don't say that picking a random sequence of at least 5 different unicode dingbats will be the best way to be sure :) Juerd
Re: Another small task for the interested
Dan Sugalski [EMAIL PROTECTED] writes: On Sun, 20 Jun 2004, Ion Alexandru Morega wrote: Dan Sugalski wrote: I checked in more of PDD 17, detailing parrot's base types. Some of those types definitely don't exist (like, say, the string and bignum type...) and could definitely use implementing. Should be fairly straightforward, and would be a good way to get up to speed on writing PMC classes. Hello, i'm new to this list and to parrot programming, so i decided to start with something simple. I implemented a String PMC that is pretty much complete, it compiles, but i haven't tested it yet. It would be great if someone had a look at it, and later when i write some tests i'll check in a patch. The .pmc is attached. Sorry this one sat so long. (Piers reminded me with the summary) It worked then ' I checked in the PMC. Tests would be cool, to be sure. :)
Re: C/C++ White-Box Unit Testing and Test::More
On Thu, Jun 24, 2004 at 07:09:40AM +0100, Piers Cawley wrote:
The xUnit style framework does a much better job of enforcing test
isolation than Test::More does
I see this more as a limitation than a feature. It seems to mean that
- You need to use the same setup/teardown for all your tests.
- You're restricted to one test == one method, so you can't paramatrize
your tests by data (eg, second example below).
- You don't have much control (correct me if I'm wrong) about the order
of tests, or the relationship between tests, eg you can't say if this
test fails, skip these others. This is straightforward in
Test::More's simple procedural style.
If I need isolation, why can't I just ask for it directly?
with_test_setup {
run_tests();
}
and even
foreach (@my_test_data) {
with_test_setup {
run_tests($_);
}
}
(but you have to remember that what
Test::More thinks of as a test, xUnit thinks of as an assertion to be
used *in* a test).
This is the one point of actual difference, but I think we can take care
of it. For starters,
SKIP: {
ok(something) || skip
is(this, that) || skip;
}
Even better would be to put Test::Builder in skip mode, where it skips
automatically whenever a test fails:
skip_mode {
ok(something);
is(this, that);
}
This can't play nice with test counts, but that's a brain-dead idea
anyway.
Every time I hear about xUnit, I figure there must be something other
than setup and teardown in its favor. If that's all there is, I'm not
sold.
Andrew
Re: Another small task for the interested
On Thu, 24 Jun 2004, Piers Cawley wrote: Dan Sugalski [EMAIL PROTECTED] writes: Sorry this one sat so long. (Piers reminded me with the summary) It worked then ' And not for the first time either. :) Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: C/C++ White-Box Unit Testing and Test::More
On Thu, Jun 24, 2004 at 05:08:44PM +0100, Adrian Howard wrote: Where xUnit wins for me are in the normal places where OO is useful (abstraction, reuse, revealing intention, etc.). Since you've thought about this, and obviously don't believe it's OO so it's better, I'd be interested in seeing an example if you have one in mind. Andrew
Re: definitions of truth
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 the abstract. (The optimizer is : free to optimize the method call away for known types within known : conditionals, of course. It had better, or evaluating the truth of : .boolean will end up calling .boolean again... :-) : : I didn't know about the (to-be) existence of .boolean. It makes things : fun and easy, though. : : However, is the name boolean final? I would prefer true, perhaps : with a corresponding false. Well, the type/property name doesn't have to be boolean--it could be truth, instead. But we mustn't confuse the type (false, true) with either true or false. In general, the name of a property is a type, so the truth property is something like boolean or truth, with an underlying base type of bit. According to A12, you can use a value of an enumerated type as a shorthand, so if you say $x.true it's short for something like $x.boolean == boolean::true And when you say 0 but true a whole bunch of magic happens that creates a type with a .boolean method that returns the value true. : That is, assuming that there will be $foo.defined and $foo.empty. Hm. I : wonder where (and if) I read about .empty. Can't find it. I'm afraid .empty was just a p6l speculation. But .defined is a real property/method. : not when the data becomes false. Plus we'll have the // operator.) : : I'll be wanting a length-or. Perl 6 will make coding it easy enough to : not need it in the core. What do you mean by length? Length is not a generic concept in Perl 6, and there is no .length method. You'll have to be more specific about what *kind* of length you're talking about: byte length, codepoint length, grapheme length, element length, etc. However, for most types possessing one or more kinds of length, it works out that the boolean value will be true if there is any length and false otherwise. (Untyped scalars still have the caveat about string 0 though.) So you don't need a length-or at all. (Or if you do, you need it less than Perl 5 did, and we've gotten by without it for quite a while now there.) : But the operator needs a symbol. I'm assuming : infix: will work. But will there be a way to ask Perl if syntax can be : used without introducing possible ambiguity? Good question. I expect we can manage to give an optional warning if one operator completely hides another. On the other hand, it might be intentional. (However, infix: wouldn't necessarily hide anything, since it would only be looked for where an operator is expected. prefix: is another matter... But it's probably a bad idea anyway since you'd screw up the lookahead that determines whether you can drop the parens on a method call.) : A circumfix ++ operator won't work for several reasons. What will Perl : do if you try defining one? Probably depends on whether Perl decides the initial circumfix + is indistinguishable from a unary +. While it's theoretically possible to attempt to parse as circumfix and then backtrack to prefix if that doesn't work, it's probably a bad plan from a human understandability point of view. Backtracking is a wonderful concept till you have to do it. On the other hand, if you declare your circumfix:++ with is forced or some such, then maybe it just hides prefix:+ without a warning. : Please don't say that picking a random sequence of at least 5 different : unicode dingbats will be the best way to be sure :) Oh, I'd never say that. The Perl Way is that the computer always tries insanely hard to serve your needs. In Soviet Russia (and similar places) the computer is served by you. However, visual distinctions might well be the best way to keep the *human* reader clued to his terminal, so you might want to keep those five random dingbats close to hand... Larry
Re: C/C++ White-Box Unit Testing and Test::More
On Thu, 2004-06-24 at 11:59, Andrew Pimlott wrote: Every time I hear about xUnit, I figure there must be something other than setup and teardown in its favor. If that's all there is, I'm not sold. It's the best option for languages that enforce a nominally pure OO style. (During the tech review of the XP Pocket Guide, Dave Thomas pointed out that many of the XP techniques come from the way Smalltalk forced Ward and Kent to work. xUnit qualifies there.) -- c
Re: definitions of truth
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 interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... The problem is, how should Perl compare two values when it doesn't know what they are? Larry solved this by creating a whole new set of operators to explicitly force a context: num str ==vs. eq vs. lt etc. OK, comparison is handled. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), otherwise you will suffer from the '0' hole (where the string 0 is handled differently from all other strings in your program). So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. Well, other than PHP, whose string handling is even screwier than Perl's. :) I think that Ruby is an example of a scripting language that has solved this problem very well (and I think Python is similar...?). So, in summary, though 0==false appears to work, it leads to a number of strange boundary conditions and, therefore, bugs. It's hard for new programmers to grasp and even old hacks are still sometimes tripped up by it. It just feels inconsistent. That's why I'd love to see this straightened out for Perl6. - Scott
Re: definitions of truth
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 for conversion to a certain type, simply the type name can be
used as a method. Then $foo.int and $foo.bool make the same kind of
sense. (Or $foo.Int and $foo.Bool, but then int $foo would be strange
(I assume int $foo returns a fully functional scalar integer))
[length-or]
What do you mean by length? [bytes, graphemes, etc]
Good question. Probably byte length. If there is one byte, that has to
represent at least one of the other length-units, right?
Not having 'length' will be hard to get used to. Perhaps I'll try to
make it easier (and thus harder in the longer term) for myself by
defining something that does .isa('Str') ? .chars : .isa('str') ? .bytes
: .isa('Hash') ? .keys : .isa('Array') ? .elements : 1.
Synopsis 6 describes 'str' as 'native string'. Is my assumption that
such a string is one that doesn't have multi-byte characters correct?
Juerd
Q: bignum vtables
There are currently 19 bignum vtable slots, which take a BIGNUM* value argument of some kind. These are IMHO useless. We don't have a Parrot basic type like BIGNUM. A BIGNUM (BigInteger, BigNumber) will just be a PMC, AFAIK. So I think these entries should just get deleted. leo
Re: C/C++ White-Box Unit Testing and Test::More
On Thu, Jun 24, 2004 at 02:59:30PM -0400, Andrew Pimlott wrote: I see this more as a limitation than a feature. It seems to mean that - You need to use the same setup/teardown for all your tests. Those that need different things aren't testing the same thing and should move to a different class. - You're restricted to one test == one method, so you can't paramatrize your tests by data (eg, second example below). I'm not sure what you mean here. You can have lots of tests in a single method. And subclasses can add their own extra tests to the parent's tests. - You don't have much control (correct me if I'm wrong) about the order of tests, or the relationship between tests, eg you can't say if this test fails, skip these others. This is straightforward in Test::More's simple procedural style. You can group dependant tests into one method and have the method return or die at any point... Every time I hear about xUnit, I figure there must be something other than setup and teardown in its favor. If that's all there is, I'm not sold. The big gain for me with Test::Class is inheritable tests. Subclasses can ensure they still pass all their parent's tests, as well as all of their own, without me having to copy all the tests, or set up a really clumsy testing environment. And of course you get to refactor the test suite quite nicely too so that it's really obvious what each test is doing. If I'm not testing something with a lot of inheritance, then Test::Class loses about 90% of its attraction. Tony
Re: definitions of truth
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 documented.
Re: C/C++ White-Box Unit Testing and Test::More
--- Tony Bowden [EMAIL PROTECTED] wrote: The big gain for me with Test::Class is inheritable tests. Subclasses can ensure they still pass all their parent's tests, as well as all of their own, without me having to copy all the tests, or set up a really clumsy testing environment. And of course you get to refactor the test suite quite nicely too so that it's really obvious what each test is doing. I also like the thought of inheriting tests, but I know not everyone is fond of this idea. There was a moderately interesting discussion about this on Perlmonks: http://www.perlmonks.org/index.pl?node_id=294571 Cheers, Ovid = Silence is Evilhttp://users.easystreet.com/ovid/philosophy/indexdecency.htm Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/
Re: cmd line like switches for functions and operators.
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 Jun 2004, Brent 'Dax' Royal-Gordon wrote:
It's already being done:
rename $orig, $new :verbose;
sub rename($orig, $new, +$verbose) {
say Renaming `$orig' to `$new' if $verbose;
On Tue, 22 Jun 2004, Luke Palmer wrote:
No, builtins can and will have named arguments. And you can even add
your own to builtin functions:
Well, much of what has been said here seems to be quite a bit above my
head as far as my Perl6 knowledge is concerned. However I'd like to
provide some context for my proposal: one motivation is to give yet
more WTDI, and another one is to give a quick'n'easy WTD certain things.
AIUI the first point is already addressed as explained in your mails
above. As for the second one, the key concept is that of suitable
defaults. For example, using Perl5 syntax, here's what I mean:
perl -le 'unlink and print removing $_ or warn something: $!\n for *.txt'
Well, it would be nice if that may just be
perl -e 'unlink *.txt :v'
Well it's certainly not going to be that, since the glob operator is
going far, far away.
At first I thought it would be a good idea to just make it a perl
command-line argument:
perl -ve 'unlink glob *.txt'
Since it would seem that one-liners would be their primary use. But now
I think about the many times I've written in longer scripts:
print Moving $old to $new\n;
rename $old = $new or die Move failed: $!\n;
# ...
And indeed I would love to have written:
rename $old = $new :verbose;
Instead.
And here of course I do *not* want to roll my own version of unlink to
manage the verbose info, otherwise it wouldn't be easier than in the
first attempt above. Even if put in a package, it would imply more
typing:
perl -MVerbose -e 'unlink *.txt :v'
^^^ or even more letters!!
Oh dear. Not that.
I understand your logic, but I believe this case is tolerable if it need
exist.
Of course you may ask why not using
rm -v *.txt
from start instead, but then there are indeed situations in which perl is
actually useful. For example one I can think of (and done in practice) is
this:
perl -lne 'rename $_, do{($t=$_)=~s/.../.../; $t}' files.txt
^^ fake!
Just as a side note, that awful en passant substitution has been cleaned
up to a functional version something like:
perl -lne 'rename $_, do { .s/.../.../ }' files.txt
Or perhaps:
perl -lne 'rename $_, do { .subst(/.../, { ... }) } files.txt
Luke
Re: A stack for Perl?
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 is behind the scenes, a consequence of which is that it supports an (undocumented, AFAIK!) alternative RPN syntax. Now Perl is not like that, although internally Perl5's bytecode is stack-based, whereas it's known that Perl6's one will be register-based. 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 deprecated. But it's somewhat anomalous amongst perl's functions I'd say. To be fair I've *never* felt the need to have a stack like that in Perl, but who knows? It may come handy in some cases... To be honest, I have no idea what you're asking for. Might you explain in a little more detail? Luke
Re: definitions of truth
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 pragma. What do you mean by character? Do you mean codepoint or grapheme? And if grapheme, language dependent or language independent? (Leaving aside the fact that ten years ago character generally meant byte.) : I don't think it matters which one you pick as default, as long : as it's clearly documented. Documentation has not kept people from saying length(@array) over and over in Perl 5. In such cases it's better not to have a default, as long as it's not too onerous to be specific. In Perl 6 you never ask for the length(). You ask for things like bytes(), codepoints(), graphemes(), or elems(). This is an area where clarity must be enforced. Muddy concepts like characters and length will only produce muddy programs. Larry
Re: definitions of truth
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 meant to be interchangeable in Perls 1 through 5. You should not care if a varaible is represented internally using a string or an int or a float or a bignum or... Uh-huh. But what about evaluating to true or false without comparison? The representation problem still exists. If Larry had solved this problem the same way he did comparison, he would have created even more operators and control structures: num str ! vs. not ifvs. sif while vs. swhile For whatever reason, he chose to solve this problem differently. Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Instead of creating stringy evaluation, he decided to have 0 evaluate false. On the surface, and in practice, this trick seems to work pretty well. Well, not always, as you point out -- often input of 0 is an edge-case that doesn't do the right thing; it's just that in many programs it's an edge-case that doesn't matter. Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. I wasn't claiming that having '0' be false is unquestionably a good thing; merely that it makes sense from 0 being false. Unfortunately, it leaves a lot of weird behavior lying around the edges. What about 0.0? Or 00? And your example, 0x00? Those are all perfectly valid ways of reperesenting 0. If strings and ints truly were interchangeable, all of these strings would be false, woudln't they? No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. If you want to emit the string '0' then you can either use that string or the number zero, and that number can be calculated from an expression or be a constant in your program that is typed in your Perl source code as 0 or 0.0 or 0x00. But if you want to emit the string '0.0' then you have to have that exact string; there is no numeric value at all which is interchangeable with '0.0' such that printing it will yield exactly that output. So 0, 0.0, 0x00, 2 - 2, and '0' _are_ all different ways of representing the same thing; '0.0' is a different thing, which isn't interchangeable with any of the first lot. And what about when you KNOW an expression should be evaluated as a string? You need to remember to use defined($s) length($s), I've honestly never used that; I hadn't even considered it to be an idiom till you mentioned it. For cases when Cif ($s) doesn't apply I've always found Cif (defined $s) to be adequate. What I am looking forward to is the Perl 6 C// operator: when writing Perl 5 I keep finding places where I want to use it and either have to write uglier code or just use C|| and accept that a value of 0 won't be recognized. So it really wouldn't make sense to have them being treated differently for truth purposes. OK, name another language that does this. I'm not really familiar with any other programming language where numbers and strings are used interchangeably, where it isn't necessary to use some explicit conversion function or cast syntax to convert from one to the other. I'm not claiming that Perl 5's way is _the_ definitive right way of doing things, but it is consistent with other aspects of Perl 5. 'MySQL' kind-of blurs the boundaries between numbers and strings. It treats things as false if the evaluate to zero in a numeric context, so '0.00' is false but so is 'stottie'. That is also consistent ... but I get the feeling that defining all non-numeric strings as false wouldn't actually be to your liking either? 'Bash' goes the other way and treats all non-empty strings as true, therefore '0' is true, but so is 0. I think that Ruby is an example of a scripting language that has solved this problem very well I don't know Ruby; could you elaborate how this has been done. Smylers
Re: definitions of truth
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 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Dave.
Re: definitions of truth
--- 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 .boolean method, at least in the abstract. My reading of A12 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? 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. :) =Austin
Re: definitions of truth
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: some_routine() == true or die; # I just knew everything would be fine! some_routine() == false and die; # I just knew everything would be go wrong! Or I suppose I could just use any() ;) -scott
Re: definitions of truth
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 would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. But all this only by default, because every one of these three can be overriden. And actually, I don't think I understand it correctly. It's been a while since I had a feeling of understanding Perl 6 :) Is this complexity really needed? Juerd
Re: definitions of truth
--- 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 correctly, having both .boolean and casting via as would mean that $foo.boolean and $foo as Bool and $foo as Bit mean the same in boolean context, but the first literally is 1 or 0, the second is true or false and the third is 1 or 0 again. I don't think so. Specifically, I'd expect $x = 0 but true; print $x.boolean; # 1 print ($x as Bit); # 0 # (I don't know about 'Bool') Is this complexity really needed? I'd say yeah, it is. 0-but-true is pretty nice to have. (Finally the system calls can return something other than -1.) Juerd =Austin
Re: definitions of truth
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
Re: C/C++ White-Box Unit Testing and Test::More
On Thu, Jun 24, 2004 at 09:10:09PM +0100, Tony Bowden wrote: On Thu, Jun 24, 2004 at 02:59:30PM -0400, Andrew Pimlott wrote: I see this more as a limitation than a feature. It seems to mean that - You need to use the same setup/teardown for all your tests. Those that need different things aren't testing the same thing and should move to a different class. What about running the same tests with different sample data (so different setup/teardown)? I suppose you could create a sub-class for each data set, but that seems like busy-work. (Unless you can create all those sub-classes automatically from the data) - You're restricted to one test == one method, so you can't paramatrize your tests by data (eg, second example below). I'm not sure what you mean here. You can have lots of tests in a single method. And subclasses can add their own extra tests to the parent's tests. But (I thought) the idea was that every test needs the same setup. If they're all in one method, they won't get that. Also, if you add lots of tests in a single method, (again as I understand) they will stop after the first failure, which is not ideal if the rest of the tests can still run. - You don't have much control (correct me if I'm wrong) about the order of tests, or the relationship between tests, eg you can't say if this test fails, skip these others. This is straightforward in Test::More's simple procedural style. You can group dependant tests into one method and have the method return or die at any point... As above, they won't all get the setup/teardown. The big gain for me with Test::Class is inheritable tests. I see. Andrew
Re: definitions of truth
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
Slices
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
just a single hashref or hash.
Comments?
RE: definitions of truth
-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 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 leads me to expect this to be defined as a coercion, using the as operator, not dot: $foo as boolean What am I missing? Why not just use say ?$foo Isn't the prefix ? operator designed specifically for this use? Joe Gottman
Re: definitions of truth
On Thu, 2004-06-24 at 14:17, Smylers wrote: Because the above would've been insane: saying that Csif ($x) treats $x as a string would be pretending that Cif always treats its arguments as numbers, but something such as Cif ($x eq 'frog') doesn't have any numbers in it. Doesn't it? perl -e '$x = frog; print(($x eq frog) . \n);' No; none of the above strings are interchangeable. All of those strings have the numeric value of zero when treated as a number, but then so does the string crumpet. Being interchangeable involves swapping them either way round. Erm, we're talking about boolean context, right? All those strings evaluate to true. I'm asking about being interchangeable when used in a conditional statement; of course they're not interchangeable with each other. :) Larry's plan to drop this in Perl 6 for things explicitly typed as strings sounds sensible to me. 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. :) - Scott
Re: definitions of truth
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 corner smoking cigs.)
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 { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
Paul
--- Hodges, Paul [EMAIL PROTECTED] wrote:
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 Perl5 has some notions of truth that confuse some
folk. I mean, I can understand 00 being true, even if it seems a
little odd to me personally, but \0??? How is a single null byte
*true*?
Okay, so it's binary data. So is 0 and 0, if you look at it that
way. I realize the internal representations are different, but the
programmer shouldn't have to care about that. I just figure that if
my bit of $data contains one byte, and I'm checking that $data for
boolean truth, I'd expect a null to be false, as would ba-zillions of
C programmers (from which backgroud I came). I know we aren't trying
so hard to imitate C behavior anymore, but still, doesn't this
violate the principle of least surprise?
So my question is this, with apology for the ramble
aside from P6's other changes, is a single null byte of binary data
still going to register as TRUE, or will it now be what seems to me
the more sensible FALSE?
Paul
__
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
Re: definitions of truth
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 ogling girls on the street corner smoking cigs.)
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 { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
And if the answer is because I've somehow botched my syntax, please
correct it and answer the question I obviously *meant* to ask as well?
=o)
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
Luke
Re: our own decimal math lib
On 24/06/2004, at 6:31 PM, Leopold Toetsch wrote: i still have my stillborn bignum (using bcd registers and efficient algorithms) implementation if anyone wants to pick it up. i have some working base code and the overall design. The major problem is: we need bignum now^Wtomorrow^WRSN. The Pie-thon benchmarks does use long (integer?) arithmetics: +, - *, //, % AFAIK. Is there a big problem with using GMP for the purposes of the demo? And, what does Python use for arbitrary-precision integers? It only seems fair to be using the same library as Python, if you want a decent bignum speed comparison. -- % Andre Pang : trust.in.love.to.save
Re: definitions of truth
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 :-)
Re: definitions of truth
--- 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 { print undef\n; } # I assume this won't print.
But my question is, will this:
if \0 { print null\n; } # Is this going to print, or not?
As far as things are currently defined, yes, it will print. And your
syntax is perfect... well, maybe not:
if undef { print undef\n; }
Might be interpreted as:
if undef( { print undef\n; } ) # syntax error, expecting {
But close enough anyway.
Maybe I should have been more specific:
if undef() { whatever(); }
But it's a moot point, since only a moron would test what he knowks the
answer to -- unless it's one of those wierd cases, and then he could
just use 0 instead..
So, putting it back into the context of real things.
If you must check for a null byte, it's as simple as:
unless $chr { print 0, '', or '0' }
unless ord $chr { print null byte }
So a null byte is still Boolean true.
Ugh, yarf, ack, etc.
But as long as I know -- easy enough to check explicitly.
But just tell me thisam I the only guy who thinks this *feels*
wierd? Understanding the reason doesn't make it any more ~comfortable~.
Paul
__
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
Re: definitions of truth
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:
my $foo = '0';
my String $bar = '0';
if $foo { say 'foo true' }
if $bar { say 'bar true' }
Would print 'bar true', but not 'foo true'. (In other words, variables
of type Any keep the Perl 5 behavior, but variables of type String have
the behavior you want.)
--
Brent Dax Royal-Gordon [EMAIL PROTECTED]
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
