Re: [dylan] type checking errors related to raw values

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA384

Hello,

On 27/01/2013 10:11, Bruce Mitchener wrote:
> Result type check can fail - values(<raw-machine-word>) inferred, 
> values(<object>) expected.

This is spurious - and not clear to me whether it is connected to the
compile-time type hierarchy of Open Dylan or the typist types.

But let's look into code (all inside sources/dfmc):
optimization/constant-folding:838
 <run-time-result-type-error>
<- that's the producer of the error message

It will be instantiated for <result-type-check-computation> (control
flow nodes) in evaluate-fixed-values-type-check
(constant-folding:940), in case the type-estimate is (effectively)
disjoint from the expected type

I assume in this case the expected is <object>, where the estimate is
<raw-machine-word>.

effectively-disjoint? is implemented in terms of guaranteed-disjoint?
(both in optimization/dispatch) - which is (mainly) implemented in
type-estimate-disjoint? and ^classes-guaranteed-disjoint?
(typist/typist-algebra).

There's no relationship between raw-type and object - apart from their
current supertype, top.


This small excursion showed me that the involved amount of code, and
more specifically the involved methods about types and type estimates
is huge, and I don't have an easy fix for that (I've been working in
that area in 2009/2010 when I integrated parametric polymorphism into
Dylan (still on a branch due to speed)).

The downside of Open Dylan in that regards is that the typist uses
<type-estimate> instances and specifies the disjointness and subtyping
relation there, as well as on <&type>. Additionally, <object> is not
the top of the type lattice in Open Dylan, but rather the (abstract)
<top>.

I don't have an easy fix for the concrete error, but my proposal is to
get rid of one of the type hierarchies (read: <type-estimate>), and
fix the <&type>/<type> relationship(s). I'm still not sure why
<type-estimate> were introduced in the first place.

Also, we have to find a solution for the top of our type lattice, and
how/where to put raw types - below or side-by-side with <object>.

If anybody has some more insights, I'd be happy to hear these.


Cheers,

Hannes



- --- some random notes ---

Let's approach from another end:
 <raw-machine-word> -> <raw-object> -> <top> (see modeling/raw-types
and raw-type-macros)
 <object> -> <top> (see modeling/objects)

Also, in modeling/raw-types, ^subtype? of <&raw-type> and <&class>, as
well as <&class> and <&raw-type> is defined to be false - hold on - we
have <class> -> <type> -> <object> -> <top>

And ^subtype? being defined on <&type>, <&type> - whereas <object> is
no type.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)

iQIcBAEBCQAGBQJRE5/3AAoJELyJZYjffCjuQywQAJCXnRoTnu5B/nWinuzPcrzz
bXMkHr09eskTGDL6GAUHH9ma8zknnfSV3nMrfvGstVr7k7JiH9R4SJknFZt/Kci6
g1/Q9m3Y1wfljBoZaUub/OlGwHU94XWS969U2hZxKtcZ+h4YDJma0YOffZ53wR2j
9U1m2sVn0n/tpSHBT+fkRAVisaUXzalYndr1gtL1Yh97KsEpsXWog3/5kr0pqXes
jkEAgO26qrmJ7Oghl8dl42+5/mFj3vmi5eQI0NzxjHmnN02SkU9ewHQ0ynO+wCqd
4vOkT4opdpLx3+WZ8sab8k+c5KcvSYNlbfe6r9+wHiyqN/ma5jCjCqHG/Mwg1ogg
b+VttX88vVrh6l/TulwBWUtCa0/XUPBsk9Lgh/BQlc07+tnNvWsLq+byZl0bm8Ew
hABGzFF2irYsaPbOuNZjNia7EOFx6QOwvNCVL6oifpT2H77r+fiugikgRAnBDjgv
SCc6DsH7EyI7x5h32KNbxBmkR21LqHBjE2qVf5xbAnhzFwjYVaJOjlZedDbfYFaW
GkuTI6e0nTIdlBxHxjWvOxGYvWKkWT0uDg50MlJ/Tx1JZXSJrMRgDohiTjuF+GZM
puu3pepNZ9bdnvhTSsuUnKAVqIhQcqiaEj3FMY4YojpBWwSxBSawLqyFb/K+49Lo
HQKp04w3+hif3RkTgNvO
=RAyM
-----END PGP SIGNATURE-----
_______________________________________________
hackers mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/hackers