Hi Todd,
A couple of things.
One is that Int and int are totally unrelated concepts. Captial Int is a
high level concept, which has a type constraint related to it, and belongs
to raku's object system. Lowercase int is a special case, it's only for the
interface with C, and it represents a low level piece of memory. It's not
that one is bounded and the other has Larry magic sprinkled on it (even
though it happens to have that), they're totally conceptually different.
Raku doesn't actually know what resides in the C space, because int doesn't
really talk to raku, so in order to do something meaningful with that
memory, you need to make sure it's dealt with in the right context. What I
mean to say is that raku won't stop you from assigning negative numbers to
an unsigned int, b/c it doesn't belong in the Object system. It just
defines a way to send raku values down into C-world (which, despite the
name, is not a pleasant place).
When you try to use a native variable like a raku variable, you have 2
choices. Either raku would blow up in your face and die (probably not what
you want), or raku would wrap the variable in something it understands
(autoboxing, as explained above). If you want to get a more specific
wrapper, nothing is stopping you from implementing that yourself. In fact,
someone posted earlier in this thread an implementation where you wrap your
native uints in an object which would point to the specific type you want.
I believe the issue that you're having with the array is also because of
autoboxing. Observe the following code:
use NativeCall
my $ary = CArray.new( 0xff );
say $ary[0];
# -1
multi sub check-it (uint8 $i) { say 'uint8' }
multi sub check-it(Int $i) { say 'Int' }
check-it $ary[0]
# uint8
That proves that raku KNOWs that it's a uint8, just many operations will
autobox it. Perhaps we need some more clarity about autoboxing rules.
What is further interesting, which was a point I think you were making, is
if we add another multi:
multi sub check-it (int8 $i) { say 'int8' }
check-it $ary[0];
# Ambiguous call to 'check-it(Int)'; these signatures all match:
# :(uint8 $i)
# :(int8 $i)
So this may actually indicate that raku does not actually know it's a
uint8, it just knows that it's supposed to be 8 bits long. This is what
I've got, but I think the point here is that int represents memory, and Int
is an object, and they're two totally distinct concepts so what applies to
one is irrelevant to the other.
Hope this helps,
Veesh
On Thu, Jan 30, 2020 at 9:56 PM ToddAndMargo via perl6-users <
perl6-users@perl.org> wrote:
> On 2020-01-30 08:11, Andy Bach wrote:
> >>> I’m STILL waiting for you to show me ONE example of a `uint` turning
> >>> into `int`. Not `Int`, via auto-boxing, `int`, via who-knows-what.
> >
> > $ p6 'my uint8 $u; say $u.^name;'
> > Int
> >
> > Did you not notice the capital "I" in both his request and your code
> output?
>
> Hi Andy,
>
>
> Oh I did. It was just a bad example.
>
> And as far as the Int thing goes, to figure that out,
> the structure of the variable had to be queried,
> so there is a trail back to the actual type of
> of variable. In other words, it should have
> given the correct answer as to what the variable
> was declared as. So no excuses.
>
> Raku variables all come with structures, so
> no excuses for ^name saying a banana is a rabbit.
> The structure is were ^name queried to get
> the Int.
>
> My opinion, ^name should be dropped if it is
> not going to give back the actually type of the
> variable.
>
> I posted a better example showing where a
> declared uint8 was being treated as a int8:
> suddenly, 0xFF became -1.
>
> -T
>
