On Mon, Jun 01, 2020 at 12:21:37PM +0300, Peter Pentchev wrote:
> On Mon, Jun 01, 2020 at 01:15:23AM -0700, ToddAndMargo via perl6-users wrote:
> > On 2020-05-31 17:13, Peter Pentchev wrote:
> > > On Mon, Jun 01, 2020 at 03:12:05AM +0300, Peter Pentchev wrote:
> > > > On Sun, May 31, 2020 at 04:29:55PM -0700, ToddAndMargo via perl6-users
> > > > wrote:
> > > > > On 2020-05-31 04:58, Peter Pentchev wrote:
> > > > > > > > So my beef is when you feed these guys an undefined
> > > > > > > > variable, that they needs to tell you it requires
> > > > > > > > a "defined" variable. Not a bunch of useless rubbish.
> > > > > > > > For example (useless rubbish):
> > > > > > And also... I thought I mentioned this before. You want a more clear
> > > > > > error message for*one* *single* specific case of a "can't find
> > > > > > this
> > > > > > method, did you mean one of these?" error message. I tried to
> > > > > > explain
> > > > > > that this error message is one that is displayed in many cases, not
> > > > > > only
> > > > > > for "you passed an undefined thing, I want a defined thing"; in my
> > > > > > opinion, it is actually quite helpful in that it actually lists
> > > > > > the candidates in a "did you mean one of these?" style.
> > > > > >
> > > > > > You want it to be clear if you pass an undefined value where a
> > > > > > defined
> > > > > > value was expected; that would mean that somebody would have to
> > > > > > write
> > > > > > the code to make it check whether it is this very specific case and
> > > > > > then
> > > > > > that code would have to be maintained for years and years. Tomorrow
> > > > > > you'll say "but can't it give me a more clear message when I pass an
> > > > > > integer and it expected a string?" and the day after tomorrow
> > > > > > you'll say
> > > > > > "but can't it give me a more clear message when I pass a string and
> > > > > > it
> > > > > > expected a function?".
> > > > > >
> > > > > > The error message says "you passed an object of this type, and I
> > > > > > can't
> > > > > > find this method for this type; here are a couple of types that have
> > > > > > this method, did you mean one of these?" It tells you what the
> > > > > > types
> > > > > > are, and it doesn't have to have thousands of special cases. It
> > > > > > tells
> > > > > > you what the types are.
> > > > >
> > > > > Hi Peter,
> > > > >
> > > > > I like that you in-line and bottom post. You are a lot
> > > > > easier to follow.
> > > > >
> > > > > I think are talking at cross purposes. Let me give an
> > > > > example:
> > > > >
> > > > > Q: is a "cow" a "Plant"?
> > > > > A: a "cow" in not a hazel nut
> > > > > A: a "cow" in not a radish
> > > > > A: a "cow" in not a carrot
> > > > > A: a "cow" in not a cabbage
> > > > > ...
> > > > >
> > > > > Are all of the answers a correct?
> > > > > Yes.. Evey answer is completely correct.
> > > > >
> > > > > Are any of the answers helpful?
> > > > > No
> > > >
> > > > Right. So, once again, just as I said, you are only interested in one of
> > > > the answers - "Str:U is not a Str:D, you want a Str:D". However, how
> > > > should Raku know *which* one of the answers you are interested in?
> > > > Tomorrow you may pass an integer to a function that only accepts strings
> > > > and floating-point numbers; should Raku tell you "you must pass a
> > > > string, not an integer" or "you must pass a floating-point number, not
> > > > an integer"? Raku doesn't know which one of those you meant.
> > >
> > > ...accepts strings *or* floating-point numbers, of course...
> > >
> > > G'luck,
> > > Peter
> > >
> >
> >
> > Hi Peter,
> >
> > I screw up A LOT. When something REQUIRES "Str:D" and I
> > send it a "Str:U", I want to be told such. Not all
> > the things it can't do, which I see thrashing around the
> > protuberance of the scrubbary.
> >
> > starts-with's invocant requires a defined value (Str:D)
> >
> > would be perfect. Not appreciated is a list of all the
> > things it can't do. This makes me have to BOTH troubleshoot
> > my screw up and the everything it can't do error message.
> >
> > I think what you are trying to do is help me fix my screw
> > ups, which is of course, much appreciated. You are trying
> > to help me understand what the error message means.
> >
> > What I am after in this thread is a better error message.
> >
> > Thank you for all the help and tips.
> >
> > -T
> >
> > p.s believe me, there will be a lot more screw ups on my
> > part in the future for you to help me fix! Of that you
> > can rest assured.
>
> OK, so for the last time :)
>
> Imagine the following code:
>
> ===================================================
>
> #!/usr/bin/env raku
>
> use v6.d;
>
> class Thing {
> multi method do-things(Int:D $value) {
> say "A thing can do things with an integer: $value";
> }
>
> multi method do-things(Rational:D $value) {
> say "A thing can do things with a rational number: $value";
> }
> }
>
> my Thing:D $thing = Thing.new;
>
> dd $thing;
>
> $thing.do-things(5);
> $thing.do-things(3/5);
>
> # And now for the clincher...
> $thing.do-things("what?!");
>
> ===================================================
>
> Running it on my system does this:
>
> [roam@straylight ~/tmp/v/roam/testwhee]$ raku functions.raku
> Thing $thing = Thing.new
> A thing can do things with an integer: 5
> A thing can do things with a rational number: 0.6
> Cannot resolve caller do-things(Thing:D: Str:D); none of these signatures
> match:
> (Thing: Int:D $value, *%_)
> (Thing: Rational:D $value, *%_)
> in block <unit> at functions.raku line 23
>
> [roam@straylight ~/tmp/v/roam/testwhee]$
>
> In other words, Raku tells me "I don't know which of these methods you want".
> It doesn't know.
>
> You say "it should tell me exactly what to do" - well, what exactly
> would you like Raku to tell you in this case? Should it assume that you
> meant to pass an integer? Should it assume that you meant to pass a
> rational number?
>
> It cannot tell you anything more specific.
> It just... doesn't... know.
> You are the only one who knows what you're *trying* to do. Raku doesn't.
>
> Hope that helps :)And, yes, I'll just say this again, for the last time :) Yes, I know your case is different. It may seem to you that it would be easy for Raku to check whether all of the methods expect a defined value for the invocant or for one of the parameters and make it easier for you by giving you a *different* error message in this *one specific* case. What I'm telling you is that the Raku developers do not want to check for any specific cases when there is already a general case with an error message that, even if somewhat verbose, gives the programmer *all* of the information. They don't want to write some special code that will take care of this case and this case only, since tomorrow somebody will come along and say "but can't you also write another couple of lines of code that will make Raku tell me 'you must pass either an integer or a rational number here'?" They don't want to write "a couple of lines" for this case and then that case and then the other case when they have already written the code to give you the full information. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
signature.asc
Description: PGP signature
