Re: coercion
On 11-02-2022 15:58, Daniel Sockwell wrote: The question now is that I can't find anything about COERCE in the documentation. Yeah, COERCE definitely should be documented but just hasn't been yet. There's a raku/doc issue about needing to add it (https://github.com/Raku/doc/issues/3807) but unfortunately none of us has done so yet :( That issue does link to a several blog posts that explain the new coercion protocol – you might find those useful and you or anyone else might also be able to adapt them into a great doc PR. -codesections Thanks Daniel and Liz. I can then continue to deprecate quite some methods in favor of the COERCION methods which in the end will make the codebase smaller and perhaps reduce the compile time with it. I will look into issue 3807 to see what needs to be done. Many thanks, Marcel
Re: coercion
> The question now is that I can't find anything about COERCE in the > documentation. Yeah, COERCE definitely should be documented but just hasn't been yet. There's a raku/doc issue about needing to add it (https://github.com/Raku/doc/issues/3807) but unfortunately none of us has done so yet :( That issue does link to a several blog posts that explain the new coercion protocol – you might find those useful and you or anyone else might also be able to adapt them into a great doc PR. -codesections
Re: coercion
It is being tested in Roast, so I'd say it's not really that experimental anymore :-) > On 11 Feb 2022, at 15:20, Marcel Timmerman wrote: > > Hi, > > I stumbled over a discussion between Raku developers on > "Raku/proplem-solving" issue 227 "Coercion reconsidered and unified" and I > saw something interesting about coercion. Without much knowledge I started to > experiment with a method called COERCE(). This ended successful and can now > write, for example, something like > > my Gnome::Gdk3::Visual() $visual = $button.get-visual; > > which feels more natural instead of > > my Gnome::dtk3::Visual $visual .= new(:native-object($button.get-visual)); > > I can also restrict the coercion like so, > > my Gnome::Gdk3::Visual(N-GObject) $visual = …; > > The .get-visual() example returns a native object which must be encapsulated > into the Visual type to access the Visual methods. In the Gnome::* libraries > are many such calls returning native structures which needs to be handled > like above to be able to do something with it. > > > The question now is that I can't find anything about COERCE in the > documentation. Although I have checked the Raku source code and have seen > that it is used there, I wonder if this is still experimental Raku code and > subject to changes. > > Regards, > Marcel
Re: Coercion/type checking: manually reproduce Perl6 standards
Hello,
I'm really glad to read of your experience, because I was wrestling just
yesterday with a problem that feels similar.
I wanted to write a simple sub which could accept both an Array and a List,
and that was simple:
use NativeCall;
sub s(Positional $a)
{
CArray[num64].new: $a.map(|*)».reals.flat.flat;
}
# List argument
say s((1..6)».Complex).list;
# Array argument
my @a = (1..6)».Complex;
say s(@a).list;
(I'm writing a module to interface with libfftw3, which needs arrays of
complex numbers expressed as pair of real/complex parts)
The next problem was that that sub should actually be a multi, accepting
different types and doing different preprocessing before creating the
native CArray.
I wouldn't find a solution with the ability to accept List and Array and
having a type at the same time.
This doesn't work:
use NativeCall;
multi s(Positional[Real] $a)
{
say 'Real';
CArray[num64].new: $a.map(|*).flat;
}
multi s(Positional[Complex] $a)
{
say 'Complex';
CArray[num64].new: $a.map(|*)».reals.flat.flat;
}
say s((1..6)».Complex).list;
my @a = (1..6)».Complex;
say s(@a).list;
because a List can't be typed. It returns an error:
Cannot resolve caller s(List); none of these signatures match:
(Positional[Real] $a)
(Positional[Complex] $a)
I have to admit that I didn't work on this very much, but Vadim's email
today ringed a bell.
On Sun, Sep 2, 2018 at 2:34 AM Vadim Belman wrote:
> Hi everybody,
>
> I'm just transferring here a StackOverflow topic
> https://stackoverflow.com/questions/52117678/coercion-type-checking-manually-reproduce-perl6-standards
> because what was a question over there turned immediately into a discussion
> which doesn't fit into SO format. Not sure if I gonna get any concrete
> answers. But hope to make it a food for thought about some of the language
> rough edges I stumbled upon over the last month or so. Also please keep in
> mind that despite my 20 years with Perl 5 I'm a complete newby in Perl 6
> with roughly just 2.5 months of real life use on my hands.
>
> First of all, I would like to answer the most important question raiph
> (sorry, don't know your real name) has asked me: why?
>
> My motivation for writing AttrX::Mooish was very much strait-forward: I
> have a work project on my hands which I wanna implement in Perl6. Yet, I
> have an internal framework for such projects written in Perl 5. I wanted to
> adapt the framework for the new language because me trying to avoid
> intermixing Perl5 and Perl6 as much as it only possible. Since the
> framework is based on Moo and utilizing all the lazy, triggers, etc. stuff
> it was desirable to get it all for Perl6. Of all Moo's functionality the
> existing Perl6 modules were only about laziness and their implementation
> wasn't even close resembling Moo/Moose behavior.
>
> So, the key point of my module: I needed it a month ago. Hopefully, this
> sufficiently explains the approach I chose.
>
> Now, on the decisions I made while implementing it.
>
> First of all, I wanted to make the module as transparent for a user a
> possible. It basically means that one should not be worried much about
> using 'is mooish' trait and what side effects would it cause to his code.
> This is why Proxy is used as an attribute container. It allows for using of
> auto-generated accessors or user-provided ones without extra headache of
> how to deal with conflicts. It's being said that Proxy is problematic in
> many aspects, but it would be eventually fixed, wouldn't it? So far it does
> the job for me.
>
> This is where I get to the original point of SO subject. It is clear that
> with Proxy I had to use an external storage for attribute values. It also
> means that the default Perl's coercion and type checking rules are not
> applicable. But as it was told above, I wanted
>
> has Str @.a;
>
> and
>
> has Str @.a is mooish(...);
>
> to be totally identical. Which is non-trivial as in the second case the
> actual array would be stored as value in a hash (the external storage).
> This is why mimicking the default Perl's rules had to be done manually by
> AttrX::Mooish. I wish I could re-delegate it to Perl6 itself, but so far my
> research of the core source didn't provide any useful results. Though,
> frankly, I didn't have enough time for it. (*While writing this I have
> achieved an acceptable level of compatibility which allows me to proceed
> with the main project.*)
>
> Hope the above answers most of raiph questions. Now, I'd try to answer a
> couple of others.
>
> *Aiui the existing implementation of Proxys suffers from repeated calls.
> So a read or write can happen several times where you might expect only
> one.*
>
>
> So far, I only seen this bug with *say*. And no, this is not the problem.
>
> What is confusing me is that it's the second time I get advised against
> use of Proxy because of its problems. Is it a first-class member of Perl6
> class family or is it just a play toy?
>
> *my Array[Str] $a = ["a", "b",
Re: Coercion of non-numerics to numbers
On Mon, Mar 05, 2007 at 09:22:59AM -0800, Dave Whipp wrote: : I was wondering about the semantics of coercion of non-numbers, so I : experimented with the interactive Pugs on feather: : : pugs +42 : 42.0 : pugs +x42 : 0.0 : : I assume that pugs is assuming no fail in the interactive environment. : However, Is 0.0 the correct answer, or should it be one of undef, or : NaN? It should probably warn by default since warnings are supposed to be on by default in Perl 6, but if that is supressed the return value should at least be an interesting value of undef containing the warning that would have been emitted, so that the warning can be issued later if the value is actually used. : In my experiments, I also noticed: : : pugs my Int $a = 42 : 42 : pugs $a.WHAT : ::Str : : : It seems that the explicit type of $a is being ignored in the : assignment. Am I right to assume this is simply a bug? Well, it's just not implemented, I think. Or more accurately, still in the process of being implemented, since the pugsers are madly working on metaobjects this week. : testcase (if someone with commit bits can add it): I'm sending you a commit bit so you can add tests. It's traditional to add yourself to AUTHORS as the first checkin to make sure things work. Larry
Re: coercion and context
On 9/14/05, Juerd [EMAIL PROTECTED] wrote: Instead, if you don't want something to coerce, be explicit: $foo.does(Blah) or fail;, or even: $foo.isa(Blah) or fail;.) We've been thinking of changing .isa to something longer, or a method on .meta, because it's a notion that is often misused. Use .does instead; that's what you mean anyway (unless you're snooping around the guts of an object). my Int $int = $num; Explicit coercion, however, isn't done with context: it is done with the .as() method: $num.as(Int). I think that's weird. Not to mention the fact that you might have put an Int there for typechecking purposes instead of coersion purposes, and you actually want it to die if $num is a string. Hmmm, how do we get both at once? Why not see bare types as functions that create context? We'd then have Int $num, Int($num), and automatically, $num.Int. All are easy to recognise because of the capital I. You realize that those functions would all be the identity map with various expectations on their input. That's okay, it's just an interesting notion. Is this weird syntax? Perhaps so, but we've known it from undef for ages. undef without arguments is just undef, but when you give it arguments, it suddenly actually *does* something. undef($foo) makes $foo undef, undef() just returns undef. Except we changed that because it was biting people: undef is null-ary and represents the undefined value; undef $foo is illegal undefine($foo) is mandatory unary, and always undefines its argument Compare with: Int($foo) makes $foo Int, Int() just returns ::Int. That bugs me a little. But it's a bug I could get used to pretty quickly I reckon. I just wonder what kind of role coercion plays in the larger scheme of things. Does coercing to a Str work with anything that has a stringify operation (conversely, is ~ just a Str context applicator?)? If a parent class defines a coercion operation, do you get it too (and what are the implications of that)? What role does coercion play in multimethod dispatch? I can't seem to map the notion of coercion into my world model, so I'd personally like to see a proposal that covers these questions from someone who can map it into his world model. I'll bash it to pieces of course, but it'd be good to have somewhere to start. :-) Luke
Re: coercion and context
Luke Palmer skribis 2005-09-14 22:21 (+): (conversely, is ~ just a Str context applicator?)? Yes, the way I think of it is that ~ is short for Str(), + is short for Num(), and ? is short for Bool(). If a parent class defines a coercion operation, do you get it too (and what are the implications of that)? What role does coercion play in multimethod dispatch? Good questions. Relevant regardless of coercion syntax. I have no idea. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: coercion and context
On Wed, 14 Sep 2005, Luke Palmer wrote: my Int $int = $num; Explicit coercion, however, isn't done with context: it is done with the .as() method: $num.as(Int). I think that's weird. Not to mention the fact that you might have put an Int there for typechecking purposes instead of coersion purposes, and you actually want it to die if $num is a string. Hmmm, how do we get both at once? My 2 cents ... Coercion and typechecking need to be fairly distinguishable for reading and writing code, as they're very different things. I for one like my Int $int as type checking, meaning it'll die if not given an int, and some sort of method/function for coercion, presumably the above-mentioned as(Int). The default should be type-checking is always strict, and coercion is never automatic, IMO. Otherwise it's just not that useful, because you always have to remember the various auto-coercion rules. Of course, for people who think that's intuititive, there could be some sort of use coercion pragma, maybe something like: use coercion Num = Int uses .int, String = Int uses .numerify_if_looks_like_number, Date = String uses .date; Of course I'm pulling the syntax/API from my nether regions. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
