chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with


From: Evan Hanson
Subject: Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'
Date: Mon, 10 Dec 2018 20:35:11 +1300

Hey megane, good find once again. Sign-off attached.

That's a nice idea regarding tv handling. Some thoughts about that are
inline below.

In the meantime, I think the second patch attacheed to this email would
be good to apply as well. It uses the "real" real name table in a
similar way to what was done before (this should have been the approach
used in the first instance, really), which avoids interfering with macro
handling but still prints the aliases nicely. This avoids a regression
until something more full-on like what you've described can be done.

Cheers,

Evan

On 2018-12-02 18:02, megane wrote:
> Personally I feel the best way to handle this would be to remove 'forall
> altogether inside the scrutinizer and use, for example, a record for the
> typevariables inside the types. For example:
> 
> (forall (a) (vector a)) would be converted to:
> 
> `(vector ,(make-type-variable 'a (generate-new-tv-id) #f))

We'd need to include constraints in there somehow, too.

The "forall" representation has the benefit of making it possible to
know what type variables appear in a form without walking it again (once
the type has been constructed) since they can be coalesced onto the
root. I'm not sure how much we take advantage of that currently, so it
might not matter, but there may be a performance cost if we lose that
property.

Regardless of the representation used within the scrutiniser, It would
be nice to use the quoted shorthand when printing typevars, now that we
have it.

> This way we could get rid of the typeenv too.

How so? Wouldn't we still need to pass the "active" typeenv around to
resolve/match-types/etc. same as today?

> The unification trail would have to be changed too. Turns out it's
> enough to just push the type-variable record to the trail. When undoing
> the unifications just grab a record from the trail and set the type to
> #f.
> 
> If you have Norvig's book Paradigms of Artificial Intelligence
> Programming, there's a short explanation of this in chapter 11.6
> "Destructive Unification".

I'll have to go read PAIP before I ask any more questions. :)

Evan

Attachment: 0001-Fix-renaming-issue-with-the.patch
Description: Text Data

Attachment: 0002-Restore-typevar-un-renaming-via-real-name-table.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]