[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with
Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'
Wed, 12 Dec 2018 09:13:16 +0100
On Mon, Dec 10, 2018 at 09:24:57PM +0200, megane wrote:
> > 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.
> True. Like this: (make-type-variable 'a (generate-new-tv-id) #f #f).
> I think the biggest benefit for the forall style is the explicitness.
> Especially when printing. It shows which symbols are type variables, and
> what their constraint types are. I think this style has its uses even if
> the internal representation changes.
> I think the biggest cost from typeenv comes from the two first tests in
> 'match1. Here we check all symbols against the typeenv, which is a
> linear search. If we use records, it's just one test.
I have only been following this with half an eye, so I apologize if I'm
being a complete idiot, but wouldn't it be more in line with the style
of CHICKEN core to use a gensym for the type variable and attach a plist
to it to hold the type variable information?
The gensym itself would act both as a unique identifier and as the
variable itself; when printing the type you'd only need to strip the
syntax info and voila, you have a readable type.
Description: PGP signature