Value of given type cannot be case to its own type.

Value of given type cannot be case to its own type.

[J. Vincent Toups]

I'm seeing this error:

Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs)
(lib.mecs cannot be cast to lib.mecs)

Which on the face of things is kind of flabbergasting. The specific
line of code which causes the issue suggests that it is indeed the
case that the value lib.mecs@etc... is a lib.mecs instance and its
being used as a lib.mecs instance.

Any ideas?

Re: Value of given type cannot be case to its own type.

[Per Bothner]

On 2/10/21 7:12 AM, J. Vincent Toups via Kawa wrote:
> I'm seeing this error:
> 
> Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs)
> (lib.mecs cannot be cast to lib.mecs)
> 
> Which on the face of things is kind of flabbergasting. The specific
> line of code which causes the issue suggests that it is indeed the
> case that the value lib.mecs@etc... is a lib.mecs instance and its
> being used as a lib.mecs instance.

We cannot possibly diagnose this without a test-case.

There are various possibilities.  The one that first comes to mind is a
class-loader problem: There are two classes named lib.mecs, loaded using
two different classloaders, and thus they are incompatible.  Though that
would be more likely to show up at run-time rather than compile-time.

It is also possible that one of the "lib.mecs" is not a reference to
an instance of the lib.mecs class (which would normally be the case), but
some type that the Kawa compiler displays as lib.mecs. Off-hand I can't
think of what that could be, but I would not be surprised to see that.
This could be a Kawa bug, of course.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Fwd: Value of given type cannot be case to its own type.

[J. Vincent Toups]

---------- Forwarded message ---------
From: J. Vincent Toups <vincent.toups@gmail.com>
Date: Wed, Feb 10, 2021 at 10:42 AM
Subject: Re: Value of given type cannot be case to its own type.
To: Per Bothner <per@bothner.com>


I figured it out, actually. This may be something people new to Kawa
experience from time to time so its worth describing here, I guess:

The issue was that I had defined a class called mecs in lib and there
was also a library called mecs in lib. So there were two classes lying
around called lib.mecs.

It makes sense in retrospect but I wonder if it might not also make
sense to indicate in the class name of a library that it is produced
by a define-library form rather than a class definition to prevent
such classes in most cases.



On Wed, Feb 10, 2021 at 10:36 AM Per Bothner <per@bothner.com> wrote:
>
> On 2/10/21 7:12 AM, J. Vincent Toups via Kawa wrote:
> > I'm seeing this error:
> >
> > Value 'lib.mecs@131a7516' for variable 'm' has wrong type (lib.mecs)
> > (lib.mecs cannot be cast to lib.mecs)
> >
> > Which on the face of things is kind of flabbergasting. The specific
> > line of code which causes the issue suggests that it is indeed the
> > case that the value lib.mecs@etc... is a lib.mecs instance and its
> > being used as a lib.mecs instance.
>
> We cannot possibly diagnose this without a test-case.
>
> There are various possibilities.  The one that first comes to mind is a
> class-loader problem: There are two classes named lib.mecs, loaded using
> two different classloaders, and thus they are incompatible.  Though that
> would be more likely to show up at run-time rather than compile-time.
>
> It is also possible that one of the "lib.mecs" is not a reference to
> an instance of the lib.mecs class (which would normally be the case), but
> some type that the Kawa compiler displays as lib.mecs. Off-hand I can't
> think of what that could be, but I would not be surprised to see that.
> This could be a Kawa bug, of course.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/

Re: Fwd: Value of given type cannot be case to its own type.

[Per Bothner]

On 2/10/21 8:38 AM, J. Vincent Toups via Kawa wrote:
> The issue was that I had defined a class called mecs in lib and there
> was also a library called mecs in lib. So there were two classes lying
> around called lib.mecs.
> 
> It makes sense in retrospect but I wonder if it might not also make
> sense to indicate in the class name of a library that it is produced
> by a define-library form rather than a class definition to prevent
> such classes in most cases.

This is covered in moderate detail here:
https://www.gnu.org/software/kawa/Module-classes.html

It is convenient and flexible to compile both a library (lib mecs)
and a class mecs in package lib to the class lib.mecs.  Sometimes
(as you saw) there can be a clash, but I think the convenience
makes up for it.  Furthermore, changing it at this point might break things.

Kawa should catch this situation if both classes are produced by the same
invocation of the kawa command.  (If not, that is arguably a bug.)
However, if they're produced at different times, then it's harder to catch.

Also, if Kawa is confused by an existing incompatible lib.mecs class while it is
generating lib.mecs, that is also a bug.  I've run into some problems like that in the past,
and I've tried to fix them.  If you have a reproducible simple test-case I can take a look.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/