Front page | perl.perl6.users |
Postings from January 2020
Re: stolen uint's
From: Trey Harris
January 29, 2020 17:19
Re: stolen uint's
Message ID: CALKJ+Ev4yLyaH1L-06R_qnTCuOkqx7NY5pOzcwzYSDSRWd0X8w@mail.gmail.com
On Wed, Jan 29, 2020 at 11:58 ToddAndMargo via perl6-users <
> On 2020-01-28 22:16, Veesh Goldman wrote:
> > Hi Todd,
> > I'd just like to point out one thing. Your confusion here (and in a few
> > related posts) is that you aren't grokking the difference between uint
> > and UInt.
> Hi Veesh,
> I am well aware of the difference between UInt and uint. Two
> weeks ago I was not.
> And because they are different, when I ^name on a variable,
> I don't want to see some different come back than what I
> declared it as.
> Now Perl variables are not "Static" variables as in C. They
> have structures assigned to them that allow for all kinds on
> interesting things not allowed in C. Inside these structures
> is the definition of what the thing is, otherwise you
> could not unbox them, etc.. I want both ^name and .range
> to accurately reflect what is in the structure's definition.
> And especially since this is even possible with C, It should
> be possible with Raku being that Raku is written in C.
> typeMappings[type_index( typeid(unsigned int) )] = "unsigned int";
> And C has no structures to inquire from.
> Basically, if I ask a banana what it is, I don't want
> to be told it is an apple.
> > Please correct me if I'm wrong. But if there needs to be an update to
> > docs, it probably should be to a document that clarifies the difference.
> I would like to see the docs updates to
> 1) reflect that UInt is not a unique variable, but a subset
> of Int
The first line of https://docs.raku.org/type/UInt is:
> The `Int` is defined as a subset of `Int:`
How does that not “reflect that UInt is not a unique [type, I assume you
meant], but a subset of Int”?
> 2) that uint is not a native type, but a subset of int.
But `uint` is not a subset of `int`; they’re both native types so can’t be
subtypes as the constraints would have to hook to the metamodel, which uint
and int lack because they’re unboxed. (A “sticker on the “box” is where you
write the constraints, if you want to think of it that way.)
> 3) that uint and int are not "static" (in the C sense)
> variables and can be changed to other things with
> coercion and boxing. A discussion on when and how
> that is done would be appreciated.
The indexing of Auto-boxing and linking to it where appropriate should
solve this. Please open a doc issue stating exactly this (and not a request
for 1 and 2, which are not valid).