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
_______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers