Type Conversion Matrix (Take 1)
Michael Lazzaro
These are what conversions are _POSSIBLE_ to make automatic, not which
ones _ARE_ automatic. That's what we need to decide.
+: Automatic conversion, conversion is not lossy
L: Lossy... possible, but not automatic?
FROM -> str Str int Int num Num bit Bit bool Bool
TO: str - L + L + L + L + L
Str + - + + + + + + + +
int L L - L L L + L + L
Int L L + - L L + + + +
num L L + L - L + L + L
Num L L + + + - + + + +
bit L L L L L L - L + L
Bit L L L L L L + - + +
bool L L L L L L + L - L
Bool L L L L L L + + + -
Everything marked with an 'L' is a decision that needs to be made... do
we accept a lossy (automatic) conversion, or report it as an error?
The ref,Ref,Array,Hash types have some autoconversions, too.
The Code,Package,Grammar types don't autoconvert at all(?).
MikeL
Luke Palmer
>
> These are what conversions are _POSSIBLE_ to make automatic, not which
> ones _ARE_ automatic. That's what we need to decide.
>
> +: Automatic conversion, conversion is not lossy
> L: Lossy... possible, but not automatic?
>
> FROM -> str Str int Int num Num bit Bit bool Bool
So what's the difference between Bit and Bool? I thought it was just
going to be "Bit" (which I though was a great idea, since Bit's are by
definition 1 or 0, where bools are the less defined true and false.)
Luke
Paul
--- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> > FROM -> str Str int Int num Num bit Bit bool Bool
>
> So what's the difference between Bit and Bool? I thought it was just
> going to be "Bit" (which I though was a great idea, since Bit's are
> by definition 1 or 0, where bools are the less defined true and
> false.)
I suppose it depends on what you mean.
if $foo ....
might enforce a boolean context, which was guaranteed to *evaluate* to
a 0 or 1, but P5's definition of false had some definite freakishness.
0 => false
"0" => false
"" => false
undef => false
but
"00" => true
"\0" => true # !?!?!
Imagine my surprise when, coming from a C background, I *knew* that my
data was going to be a single NULL byte in a given situation, but my
program evaluated that as a boolean true......
So if you have a Bit type, I can see it's values as being true or false
in the boolean sense, or maybe 0 or 1 in some numeric context, or even
"" or "1" in string contexts.... but if I try to assign a NULL byte to
it, how would it coerce? Hell, for that matter, how is P6 going to
define true and false? Because in P5 it seems false is defined by "is
it one of those listed above?" and true is everything else.
I have no problem with unifying Bit and Bool, but I do think of them
differently; I think of Bit as being one binary digit, and Bool as
being a statement of Truth or Falsehood. I do not compose binary
numbers using Bools, I use Bits.
For all practical purposes, though, I could see the entire Bool class
defined as a macro substitution using Bit. :)
__________________________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo
http://search.yahoo.com
Austin Hastings
--- Michael Lazzaro <mlaz...@cognitivity.com> wrote:
> Whoops, found an error already. Updated version:
>
> These are what conversions are _POSSIBLE_ to make automatic, not
> which
> ones _ARE_ automatic. That's what we need to decide.
>
> +: Automatic conversion, conversion is not lossy
> L: Lossy... possible, but not automatic?
>
I'm guessing that you marked the Upper-to-Lower conversions as lossy
because of the potential loss of properties. That is, {0 but true} ->
0.
Is that the only reason, or is there some other "loss" possible I
haven't thought of?
> FROM -> str Str int Int num Num bit Bit bool Bool
> TO: str - L + L + L + L + L
> Str + - + + + + + + + +
> int L L - L L L + L + L
> Int L L + - L L + + + +
> num L L + L - L + L + L
> Num L L + + + - + + + +
> bit L L L L L L - L + L
> Bit L L L L L L + - + +
> bool L L L L L L + L - L
> Bool L L L L L L + + + -
(Is Bool real? ISTR whinging about bool being just C<bit>.)
I'll claim that all type.tolower() conversions should be automatic,
since we're treating that as a "stowage class" -- IOW, telling you to
store this in "compressed mode" is enough of a warning, given a
"strongly typed" surrounding context. Comment?
Also, (and I should have included this in my P6Objects summary) Damian
has declared that all literals are of type Scalar. You should probably
include a separate entry FROM Scalar for that reason if no other.
Aside: I am really apalled at the thought that
sub foo(int $x) {...}
my $a = 1;
foo(1); # Works -- LiteralScalar -> int
foo($a); # Might not work under strict types.
>
Michael Lazzaro
I don't know. They're probably synonyms, or close to it. But they're
both in A6.
We proposed 'bool' as a way to express what context this was:
if ($a) {...} # $a is in 'bool' context
Saying 'bit' doesn't go so well there. And saying 'bool' doesn't work
well when you're talking about bits. So I like having them both, even
if they're absolutely synonymous.
It may also be that 'bit' is optimized for storage, while 'bool' is
optimized for speed (e.g. 'bool' is represented as a native int).
MikeL
Luke Palmer
I think Bool works well as a context, and Bit works well as a value.
Larry said he had a problem with actually storing "true" somewhere (as
do I). Certain values can be true, but there is no "true" value.
Similarly for false.
That's why I liked Bit so much, is that it isn't true and false, it's
1 and 0 which just happen to be true and false. The problem with Bool
is that novices tend to do this:
if ($x == true) {...}
Which is just wrong. Best not to include Boolean values at all.
Luke
Michael Lazzaro
On Wednesday, April 23, 2003, at 01:18 PM, Austin Hastings wrote:
> I'm guessing that you marked the Upper-to-Lower conversions as lossy
> because of the potential loss of properties. That is, {0 but true} ->
> 0.
Yes, and because 'undef' is lost. (C<Int> can be undef, but C<int>
can't be, last I heard.)
> I'll claim that all type.tolower() conversions should be automatic,
> since we're treating that as a "stowage class" -- IOW, telling you to
> store this in "compressed mode" is enough of a warning, given a
> "strongly typed" surrounding context. Comment?
I don't think the compressed cases can be set to undef, since by
definition it'd take more than the minimal amount of storage to do
that, and Larry has said he wants an array of 64k 'bit's to take
something dang close to (64/8) Kbytes of memory. :-)
So those conversions are lossy -- we may choose to allow them, or not,
but they're definitely lossy. And if they aren't, there's no reason to
have lowercase/uppercase distinctions in the first place.
> Also, (and I should have included this in my P6Objects summary) Damian
> has declared that all literals are of type Scalar. You should probably
> include a separate entry FROM Scalar for that reason if no other.
Oh, fudge. I forgot to add that column. But I think conversions from
anything to Scalar are lossy, and anything _from_ Scalar are lossy,
because Scalar is a junction type. But that doesn't necessarily mean
we shouldn't do those conversions.
MikeL
Austin Hastings
> > I'm guessing that you marked the Upper-to-Lower conversions as
> lossy
> > because of the potential loss of properties. That is, {0 but true}
> ->
> > 0.
>
> Yes, and because 'undef' is lost. (C<Int> can be undef, but C<int>
> can't be, last I heard.)
>
> > I'll claim that all type.tolower() conversions should be automatic,
> > since we're treating that as a "stowage class" -- IOW, telling you
> to
> > store this in "compressed mode" is enough of a warning, given a
> > "strongly typed" surrounding context. Comment?
>
> I don't think the compressed cases can be set to undef, since by
> definition it'd take more than the minimal amount of storage to do
> that, and Larry has said he wants an array of 64k 'bit's to take
> something dang close to (64/8) Kbytes of memory. :-)
>
> So those conversions are lossy -- we may choose to allow them, or
> not, but they're definitely lossy. And if they aren't, there's no
> reason to have lowercase/uppercase distinctions in the first place.
Granted they're lossy. I say "allow them and don't complain." Convince
me I'm wrong.
>
> > Also, (and I should have included this in my P6Objects summary)
> Damian
> > has declared that all literals are of type Scalar. You should
> probably
> > include a separate entry FROM Scalar for that reason if no other.
>
> Oh, fudge. I forgot to add that column. But I think conversions from
>
> anything to Scalar are lossy, and anything _from_ Scalar are lossy,
> because Scalar is a junction type. But that doesn't necessarily mean
>
> we shouldn't do those conversions.
sub foo(int $x) {...}
foo(1);
We're doing them, and doing them quietly for the most part, I hope.
=Austin
Michael Lazzaro
On Wednesday, April 23, 2003, at 01:28 PM, Luke Palmer wrote:
> I think Bool works well as a context, and Bit works well as a value.
> Larry said he had a problem with actually storing "true" somewhere (as
> do I). Certain values can be true, but there is no "true" value.
> Similarly for false.
Yes; absolutely.
The core problem is that if you're asking for the context of this:
my $b is Array of bit;
$b[ $i ] = $x; # What's the context for $x, here?
you expect it to be C<bit> context, not C<bool> context -- and it would
be darn surprising for those names to not match. Likewise, saying:
if ($x) {...} # What's the context for $x, here?
you'd be darn surprised to have it say it's in C<bit> context.
> That's why I liked Bit so much, is that it isn't true and false, it's
> 1 and 0 which just happen to be true and false. The problem with Bool
> is that novices tend to do this:
>
> if ($x == true) {...}
>
> Which is just wrong.
Agreed, but just because C<bool> is a type doesn't mean it has to have
representable values. :-) It could be 1/0 in num context, and '1'/'0'
in str context, and whatever the nebulous definition of true/false is
in it's own context, but you'd never actually need the keywords C<true>
or C<false> anywhere, because you'd typically be assigning the results
of comparisons or other already-boolean values:
my bool $b = ($a eq $b);
or using the autoconversion from strings/ints/nums/whatever:
my bool $b = 1;
And whenever you access $b, it's going to produce 1/0/'1'/'0', never
the words 'true'/'false'. 'true' and 'false' are just the internal
concepts.
One difference between the two could be that you could meaningfully say:
my Bit $b = 0 but true;
but you couldn't meaningfully say
my Bool $b = 0 but true;
because bools don't actually have a place to store values... they'd
just be the 'but' part. Maybe.
MikeL
Paul
> > Also, (and I should have included this in my P6Objects summary)
> > Damian has declared that all literals are of type Scalar. You
> > should probably include a separate entry FROM Scalar for that
> > reason if no other.
>
> Oh, fudge. I forgot to add that column. But I think conversions
> from anything to Scalar are lossy, and anything _from_ Scalar are
> lossy, because Scalar is a junction type. But that doesn't
> necessarily mean we shouldn't do those conversions.
??
my Int $i = 1;
my $x = $i; # what's it losing?
$x = 2;
$i = $x; # again, what's it losing?
I can see Int => int as lossy, because int can't be "0 but true", as
mentioned.
Then again,
$x = "foo";
$i = $x; # OBVIOUSLY lossy if allowed....
Michael Lazzaro
On Wednesday, April 23, 2003, at 01:40 PM, Austin Hastings wrote:
>> So those conversions are lossy -- we may choose to allow them, or
>> not, but they're definitely lossy. And if they aren't, there's no
>> reason to have lowercase/uppercase distinctions in the first place.
>
> Granted they're lossy. I say "allow them and don't complain." Convince
> me I'm wrong.
You're not wrong... that first matrix just shows known-lossy and
known-not-lossy _possible_ conversions, and doesn't make any judgments
on if they should be allowed.
It would probably be surprising if they weren't allowed -- same for the
to/from Scalar example.
One question we've entertained is whether or not different levels of
strictness allow _all_ these conversions, or _some_, selectively, or
_none_. For example, cases like num --> int are *considerably* more
lossy than Num --> num. Should both be allowed, or none, or only one?
MikeL
Paul
> > it's 1 and 0 which just happen to be true and false. The problem
> > with Bool is that novices tend to do this:
> >
> > if ($x == true) {...}
> >
> > Which is just wrong.
I mentioned the idea of "0 but true" to a friend of mine the other day
and became the recipient of a 20-minute harangue on how the
introduction of boolean types into computer science was one of the
great evils. I have no idea what sort of silliness was going on in his
head, but he said "1 and 0 are all you need," and followed it with a
significant bit (pun intended) of cursing.
> Agreed, but just because C<bool> is a type doesn't mean it has to
> have representable values. :-) It could be 1/0 in num context,
> and '1'/'0' in str context, and whatever the nebulous definition
> of true/false is in it's own context, but you'd never actually
> need the keywords C<true> or C<false> anywhere, because you'd
> typically be assigning the results of comparisons or other
> already-boolean values:
> my bool $b = ($a eq $b);
> or using the autoconversion from strings/ints/nums/whatever:
> my bool $b = 1;
But we *do* need to be able to predict what is true or false, so that I
can code accordingly. I assume any non-false value is true, according
to the tradition of previous programming languages, so all we need to
define is false. When I say
if ($x) { # ...
what possible values of $x will cause that not to execute?
*Particularly* in cases where no boolean overriding trait has been
set.... I do *not* want to have to compare it to some predefined value,
but do need to know what values it might have that evaluate as a
bollean false.
> And whenever you access $b, it's going to produce 1/0/'1'/'0', never
> the words 'true'/'false'. 'true' and 'false' are just the internal
> concepts.
But I assume I could still say
if (undef) { #...
and expect that to guarantee the following block of code to be skipped.
> One difference between the two could be that you could meaningfully
> say:
> my Bit $b = 0 but true;
> but you couldn't meaningfully say
> my Bool $b = 0 but true;
> because bools don't actually have a place to store values...
Now THAT is a neat thought that hadn't occured to me!
> they'd just be the 'but' part. Maybe.
I'd say the value of zero would be evaluated in a boolean context, but
that the parser would see the boolean override and throw the zero away.
That does make me wonder, though.... "0 but true" means "true" is a
keyword with some value, even if it's only a trait. It may not be the
ONLY possible value for true -- had better not be -- but the keyword
exists. Could I then sugar-skip the value part and say
my Bool $b = true; # ?
Or even
while true { ... } # ?
or must I say
my Bool $b = "some arbitrary true value";
and
while 1 {}
I don't mind "while 1" so much, but to explicitly declare a boolean
value I'd like to be able to use something to initialize it that didn't
have extraneous information. A 1 is clear enough; I'm just grumping.
If I have to choose between having
while true {}
and allowing
if ($x == true) {}
then I can do without it entirely....
but there ARE people who would rather write
if ($b == true) {}
than just
if ($b) {}
if it really is a Bool.
I don't know *why*.....
Austin Hastings
--- Paul <ydb...@yahoo.com> wrote:
> > > That's why I liked Bit so much, is that it isn't true and false,
> > > it's 1 and 0 which just happen to be true and false. The problem
> > > with Bool is that novices tend to do this:
> > >
> > > if ($x == true) {...}
> > >
> > > Which is just wrong.
>
> I mentioned the idea of "0 but true" to a friend of mine the other
> day
> and became the recipient of a 20-minute harangue on how the
> introduction of boolean types into computer science was one of the
> great evils. I have no idea what sort of silliness was going on in
> his
> head, but he said "1 and 0 are all you need," and followed it with a
> significant bit (pun intended) of cursing.
>
Now explain closures to him.
When he gets over that, wait about three days, and try continuations.
C<true> (and C<false>, by extension) are methods.
macro infix:but($value, $property) is parsed(/<expr>/) {
return $value as class is typeof($value) {
has $.value;
method $property { 1; }
method new($.value) { }
}.new($value);
}
> my Bool $b = true; # ?
>
> Or even
>
> while true { ... } # ?
>
> or must I say
>
> my Bool $b = "some arbitrary true value";
This offends. Having a Bool type implies having literals for it.
If @Larry don't provide Boolean literals, I'll write you some macros.
macro TRUE { "1" }
macro FALSE { "0" }
> and
> while 1 {}
C<loop>
> I don't mind "while 1" so much, but to explicitly declare a boolean
> value I'd like to be able to use something to initialize it that
> didn't have extraneous information. A 1 is clear enough; I'm just
> grumping.
>
> If I have to choose between having
>
> while true {}
>
> and allowing
>
> if ($x == true) {}
This is stupid but can be made harmless by ruling that the boolean
context coerces $x. Similar to
if (@a >= $maxlen) {}
coercing @a into a numeric context, which yields length.
>
> then I can do without it entirely....
> but there ARE people who would rather write
>
> if ($b == true) {}
>
> than just
>
> if ($b) {}
>
> if it really is a Bool.
> I don't know *why*.....
A year or so ago, I met a Danish guy in Mexico who had just spent 10+
years in the SW Pacific (Indonesia, etc.). (Jens Wiik Jenssen) He said,
"Thank God for different tastes. It's why most food gets eaten, and
most women get married."
=Austin
Paul
> > > false, it's 1 and 0 which just happen to be true and false.
> > > The problem with Bool is that novices tend to do this:
> > >
> > > if ($x == true) {...}
> > >
> > > Which is just wrong.
> >
> > I mentioned the idea of "0 but true" to a friend of mine the other
> > day and became the recipient of a 20-minute harangue on how the
> > introduction of boolean types into computer science was one of the
> > great evils. I have no idea what sort of silliness was going on in
> > his head, but he said "1 and 0 are all you need," and followed it
> > with a significant bit (pun intended) of cursing.
>
> Now explain closures to him.
LOL!!!
> When he gets over that, wait about three days, and try continuations.
Oh, you are *EVIL*!
(Do you give lessons? :)
> > [snip....]
> > That does make me wonder, though.... "0 but true" means "true" is
> > a keyword with some value, even if it's only a trait. It may not
> > be the ONLY possible value for true -- had better not be -- but
> > the keyword exists. Could I then sugar-skip the value part and
> > say
>
> C<true> (and C<false>, by extension) are methods.
>
> macro infix:but($value, $property) is parsed(/<expr>/) {
> return $value as class is typeof($value) {
> has $.value;
> method $property { 1; }
> method new($.value) { }
> }.new($value);
> }
Er? One of us is missing something. I usually assume it's me. :)
So...hmmm...reading more carefully....
Ok, the macro is parsing whatever the lefthand argument was (0 in the
example) and returning a proxy object of the appropriate type (Scalar
for this literal) which has an impromptu method defined on it having
the name of the righthand argument to the "but" operator ("true" in
this case) which returns some boolean true value (in this case, 1). Ok,
that's cool. That means it's NOT a keyword.... and that (as I believe
I've seen in some examples before) I could say
my $age = 13 but lucky;
> > [snip again...]
> > my Bool $b = "some arbitrary true value";
>
> This offends. Having a Bool type implies having literals for it.
There are, but notice that I say it in the plural.
> If @Larry don't provide Boolean literals, I'll write you some macros.
>
> macro TRUE { "1" }
> macro FALSE { "0" }
Nope! Because then I should be able to test with that stupid
if ($x == TRUE) { # ...
and expect it to be *exactly* the same as saying
if ($x) { # ...
which obviously, it isn't. Yes, I agree that such a thing is silly
code, and yes, I agree that the macro would allow
if (TRUE) { # which is really also silly in most any case
but I don't want a literal value for true, because any true value
should equal that, at least in any syllogism I'd like to see. I would
be happy enough to see true evaluate to in any given example, but I
don't intend to leap from that to the assumption that any true value
must be a 1.
> > and
> > while 1 {}
>
> C<loop>
Yes, I know. I'd rather use that anyway. Just using a generic
construct.
btw, I have another friend who almost cursed me for an idiot because I
told him P6 wasn't going to use for(;;){} anymore. (I have a lot of
strongly opinionated friends, lol...)
> > [and yet another *snip*]
>
> A year or so ago, I met a Danish guy in Mexico who had just spent 10+
> years in the SW Pacific (Indonesia, etc.). (Jens Wiik Jenssen) He
> said,
>
> "Thank God for different tastes. It's why most food gets eaten, and
> most women get married."
LOL!!!
TMTOWTDI! :)