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: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] * scrutinizer.scm: Fix renaming issue with 'the'
Date: Wed, 12 Dec 2018 09:13:16 +0100
User-agent: NeoMutt/20170113 (1.7.2)

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.

Cheers,
Peter

Attachment: signature.asc
Description: PGP signature


reply via email to

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