On Tue, Jan 28, 2020 at 20:59 ToddAndMargo via perl6-users < perl6-us...@perl.org> wrote:
> > > 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 > Int > > 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 difference: ```console > my UInt $x = 32; 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; 224 ``` 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 < perl6-us...@perl.org> wrote: > 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. > > You’ve > > 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: 0x41 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 native call).
