Re: [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself

[Peter Bex]

On Sun, Dec 20, 2015 at 06:11:24PM +1300, Evan Hanson wrote:
> Hi Peter,
> 
> I've pushed the read-char and types.db fixes. They make sense and offer
> a good speedup -- nice work!

Thanks!

> Unfortunately the scrutinizer change is a bit hairier. One problem is
> that it causes the "-emit-types-file" option to include system-defined
> types (i.e. those that come from from types.db) in generated .types
> files, whereas it should only include those for values defined in the
> file under compilation.

Damn, I didn't notice that.  Well spotted!

> That file's entries are generated by walking the
> analysis database, so I don't think we'll be able to avoid keeping track
> of whether a given type came from the user or from a types file so that
> we can determine whether to generate a type for it in this situation.

Maybe we can simply mark locally defined variables with another property
which is used to determine whether or not to export it to a types file?

> There's also now the problem of what to do when the user redefines an
> identifier without redeclaring its type. For example, with this change,
> if I redefine string-split with a different signature, csc will produce
> inaccurate scrutiny warnings because calls to *my* string-split won't
> match core's but it'll still have a declared-type, now.

I'd consider that pretty much broken, because when you link that
definition to code that's assumes the types.db definitions are correct,
it will produce invalid code.

For example, if your string-split accepts either symbols or strings, the
#:enforce declaration would be no longer be correct (because it'll now
accept symbols too), and the assumption that the argument is a string
is invalidated.  For example, in the following code:

(define (split-and-original-length x)
  (let* ((split-up (string-split x))
         (len (string-length x)))
    (values split-up len)))

the compiler will specialize "string-length" to ##sys#size.  If used
with the new overridden user definition, the procedure would return a
list of strings and the number 3 if you pass in a symbol, because
symbols are always size 3.

> I haven't dug into this too deeply yet (I'm hoping to take a crack at
> these issues over the holidays) but I do think we'll have to make a
> call about what's correct in this and similar situations.

We *could* declare this situation hopelessly lost in CHICKEN 4 because
it uses unqualified names everywhere in types.db.  Then we can apply
the fix to CHICKEN 5, where the core definitions will all be properly
namespaced into modules.

I don't know how to fix it properly to allow user redefinitions of
existing procedures with different types, but I also think it makes
very little sense to allow this at all.

Cheers,
Peter

signature.asc
Description: Digital signature