[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH] Fix (restore?) specializations from types.db when compiling core itself |
Date: |
Sun, 20 Dec 2015 21:15:09 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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