Front page | perl.perl6.users |
Postings from January 2020
Re: stolen uint's
From: Trey Harris
January 29, 2020 02:19
Re: stolen uint's
Message ID: CALKJ+Es0teKJooTOiQ=h492zxe11S7+dRCNiZ5xJF_xCtODMFw@mail.gmail.com
On Tue, Jan 28, 2020 at 20:59 ToddAndMargo via perl6-users <
> > Ah.... You got ‘int’—lowercase ‘int’, not uppercase ‘Int’?? I didn’t see
> > that example and I can’t find it scrolling back. Would you repost it,
> > please? That would change things (and possibly indicate a bug).
> > my uint $u= 0xFF44; say $u.^name
> It was upper case Int. Again, wrong answer. It should
> have been "UInt"
No—it’s the right answer, because it’s a type constraint, and you can
assign a negative integer to a uint and you’ll get the complement. See the
> my UInt $x = 32;
> $x = -32;
Type check failed in assignment to $x; expected UInt but got Int (-32)
in block <unit> at <unknown file> line 1
> my uint $z = -32;
You can argue that it _should_ barf on negative integers instead, but that
would make working with a number of Unix C std lib native calls that use
unsigned values in... historical interesting ways difficult. That’s perhaps
a niche-enough case that I think you could reasonably argue for autoboxing
into UInt instead. But that would be a behavioral change; *answering*
`UInt`, when it’s absolutely autoboxing into an `Int`, would be wrong; Raku
would be lying to you.
To answer your other questions in your prior mail:
On Tue, Jan 28, 2020 at 20:32 ToddAndMargo via perl6-users <
> On 2020-01-28 17:17, Trey Harris wrote:
> > > Write me a C program to do the equivalent, then, please. You will
> > > segfault. If you don’t, then you’re asking a question we might
> > be able
> > > to answer.
> > I can't write in C
> > Perhaps that’s why you don’t understand. Assembler? COBOL? PL/I? Any
> > language with pointer arithmetic?
> I used points all the time in Modula2. And reference pointers in Perl5
Pascal and its descendants used type-safe pointers. You’d have to have
experience with a language with unsafe pointers to get my point there.
> > shown multiple examples of autoboxing. So... you could request Raku add
> > a pragma or trait that would result in a fatal exception being thrown if
> > autoboxing occurs.
> What? I am not wanting to crash anything. he phrase "the unbox type
> is" will do fine. Gives perfect warning.
Finding an example of where that’s generally useful is the question. It’s a
type constraint in addition to being a storage type, so if you don’t
violate the constraint, and you don’t coerce it into something else, it
will be what you constrained it to be.
To want to interrogate that doesn’t seem to have a point beyond just being
mistrustful of the language. If you can articulate the usefulness, then you
could look at it—an `nqp::typeof` existed until a few years ago, and I
imagine it could be re-exposed (which would be the first step, since the
native API offers no way to get at that information from Raku code AFAICT).
But you’d have to show a need for a new low-level call like that.
> You can already wrap the variable in a class that
> > keeps the native value immutable so that it can’t be autoboxed.
> > You can compare a native value to another in a way that will tell you if
> > the are or aren’t the same. From that last, you could build something
> > rather crude that created a value of every type you’re interested in,
> > compared your value to each, and then told you if any matched
> > bit-for-bit, which might be sufficient for your purposes (which I still
> > don’t understand)?
> > But what you *can’t* do is ask what it is without autoboxing it. An
> > unsigned 32-bit int is just 32 bits that are entirely used to express an
> > integer—there’s no room to mark what it is, so asking it what it is is
> > meaningless—and once it’s autoboxed, it’s different than it was before
> > the autoboxing.
> My misunderstandings
> 1) I though 'uint' and 'int' were both separate native types.
> The manual does state such.
They are; show me an example of getting ‘int’ (unboxed) rather than ‘Int’
(autoboxed) from a ‘uint’, though. Do the above test of assign `-32` to a
`uint` vs. an `int` and you’ll see, they’re different, even though they
both autobox into `Int`—the `int` will be -32 rather than the complement.
2) I thought 'unit' had a structure that went along with it,
> as does a string. And inside that structure were unicorn
> values, such as 'undefined' and 'Nil' as well as its type.
Nope. If I give you:
and tell you that’s a single octet, and that’s all you have, and I and ask
you whether that’s an “A” or a decimal 97 or something else described by
01000001, how do you answer? You can’t.
Raku knows at compile time—otherwise, it couldn’t autobox into an ‘Int’ vs.
a ‘Real’ for an int32 vs. a num32, for example—but that’s not currently
exposed to the runtime; you can pitch a new feature, but it would be
necessary to know what one would use it for to design an interface for it.
An ability to cause a failure or exception to be thrown if a given value is
autoboxed would be much more defensible, I think—“I need to ensure this
thing doesn’t get munged by something unexpected into a form that my native
call will barf at” seems more reasonable (though unboxing should prevent
that in cases where you’re not round-tripping outside of Raku before your